0b4a216954
Zwei Features an derselben Stelle, die im Arbeitsverzeichnis nebeneinander lagen und sich dieselben Dateien teilen (Routen, BankingController, Bankzugang, Zugangsformular, Dokumentation) – getrennte Commits ließen sich daraus nur mit einem kaputten Zwischenstand schneiden. PayPal als zweite Art von Bankverbindung ---------------------------------------- „Bankverbindung anlegen“ führt zur Wahl der Art: HBCI/FinTS oder PayPal (bank_zugaenge.typ, Migration 014). Die Abfrage läuft über die Classic-NVP-API (Services\PaypalNvp, TransactionSearch und GetBalance). Kein Dreischritt, da PayPal genau ein Guthabenkonto führt – Zugangsdaten und Kontenzuordnung stehen in einem Formular. Konten, Umsätze, Protokoll, Regeln und Abgleich bleiben dieselben. Bankleitzahlen-Verzeichnis -------------------------- Verwaltung → Bankleitzahlen (/verwaltung/bankinstitute, Migration 015) nimmt die CSV-Institutsliste der Deutschen Kreditwirtschaft auf und beantwortet damit die eine Angabe, die beim Anlegen einer FinTS-Verbindung regelmäßig fehlt: den PIN/TAN-Zugangspunkt. Reine Nachschlagedaten ohne benutzer_id; ein Import ersetzt den gesamten Bestand, statt ihn zu ergänzen. „Nur prüfen“ und „Übernehmen“ sind zwei Knöpfe an derselben Datei – abgelegt wird sie nicht, ihr Inhalt steht ja in der Tabelle. Services\FintsInstituteImport nimmt der Datei ihre Eigenheiten ab: ISO-8859-1 statt UTF-8, ein Institutsname über zwei Zeilen in Anführungszeichen, dieselbe Bankleitzahl vielfach (eine Zeile je Filiale), Hunderte leerer Zeilen am Ende, Text statt Adresse, wo es keinen PIN/TAN-Zugang gibt. Spalten werden über ihre Überschrift angesprochen; fehlen BLZ und Institut, bricht der Import ab. Gesucht wird über Bankleitzahl, BIC, Name und Ort in einem Zug: „1822“ steht bei der 1822direkt im Namen und bei der Frankfurter Sparkasse im BIC, in keiner der beiden Bankleitzahlen. Aus der Trefferliste führt „Verbindung anlegen“ ins gefüllte FinTS-Formular. Die FinTS-Adresse ist damit kein Pflichtfeld mehr – bleibt sie leer, wird sie zur Bankleitzahl nachgeschlagen. Findet auch das nichts, weist Bankzugang den Zugang ab, statt ihn ohne Gegenstelle zu speichern. Tests: 31_PaypalZugangTest, 32_BankinstituteTest, e2e/specs/banking.spec.js, e2e/specs/bankinstitute.spec.js. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
18 lines
1.1 KiB
SQL
18 lines
1.1 KiB
SQL
-- PayPal als zweite Art von Bankverbindung.
|
|
--
|
|
-- Bisher war jeder Bankzugang ein HBCI/FinTS-Zugang. Die Spalte `typ` trennt
|
|
-- beide Wege; die FinTS-Felder (BLZ, Adresse, Benutzerkennung, PIN) bleiben bei
|
|
-- PayPal leer, die API-Felder umgekehrt.
|
|
--
|
|
-- Die drei PayPal-Angaben sind die Zugangsdaten der Classic-NVP-API:
|
|
-- API-Benutzername, API-Kennwort und Signatur. Kennwort und Signatur stehen
|
|
-- AES-verschlüsselt in der Datenbank (Services\Crypto), genau wie die FinTS-PIN.
|
|
|
|
ALTER TABLE bank_zugaenge
|
|
ADD COLUMN IF NOT EXISTS typ ENUM('fints','paypal') NOT NULL DEFAULT 'fints' AFTER benutzer_id,
|
|
ADD COLUMN IF NOT EXISTS api_benutzer VARCHAR(191) NOT NULL DEFAULT '' AFTER pin,
|
|
ADD COLUMN IF NOT EXISTS api_kennwort TEXT NULL AFTER api_benutzer,
|
|
ADD COLUMN IF NOT EXISTS api_signatur TEXT NULL AFTER api_kennwort,
|
|
-- Sandbox-Zugangsdaten sprechen einen eigenen Endpunkt an; mit dem falschen
|
|
-- antwortet PayPal mit „Security header is not valid“ und sonst nichts.
|
|
ADD COLUMN IF NOT EXISTS sandbox TINYINT(1) NOT NULL DEFAULT 0 AFTER api_signatur;
|