Fünf Jahre PSD2-Konnektoren: was die Spezifikation nicht verrät

PSD2 versprach eine API für jede Bank in Europa. Was wir bekommen haben, ist eine Spezifikationsfamilie und ein paar hundert Interpretationen davon. Nach fünf Jahren, in denen wir Konnektoren für Kontoinformationen und Zahlungsauslösung für Kunden im gesamten Baltikum gebaut und betrieben haben, ist das Muster klar: Die erste Bank dauert eine Woche, die fünfte einen Tag, und dann dauert die nächste unerwartet einen Monat.

Am Consent-Flow bleiben Projekte hängen

Die API-Aufrufe sind der einfache Teil. Der schwierige Teil ist der Consent-Lebenszyklus - wie ein Kunde Ihren Zugriff autorisiert, wie lange diese Autorisierung gilt und was passiert, wenn sie sonntags um 03:00 Uhr abläuft.

• Manche Banken stellen 90-Tage-Consents aus und erneuern sie still; andere erzwingen eine vollständige Neu-Authentifizierung.
• Sandbox-Consent-Flows unterscheiden sich regelmäßig von den Produktions-Flows. Planen Sie einen zweiten Integrationsdurchgang nach dem Go-live ein.
• Die Fehlertaxonomien sind uneinheitlich: Derselbe abgelaufene Consent kann als 401, 403 oder - in einem denkwürdigen Fall - als 200 mit einer leeren Transaktionsliste auftauchen.

Der letzte Punkt verdient besondere Betonung: eine leere Antwort ist nicht dasselbe wie eine erfolgreiche Antwort. Wenn Ihr Abgleich von einem Transaktions-Feed abhängt, behandeln Sie „keine Transaktionen" als einen zu prüfenden Zustand, nicht als festzuhaltende Tatsache.

Worauf wir standardisieren

Jeder Konnektor, den wir heute ausliefern, läuft hinter derselben internen Schnittstelle, wobei die bankspezifischen Adapter bewusst schlank gehalten werden. Dieselbe Disziplin gilt auf der Zahlungsauslösungsseite - ein kanonisches Payment-Objekt, explizit auf den Dialekt jeder Bank gemappt:

Der Adapter kümmert sich um Authentifizierungseigenheiten und die unterschiedlichen Verfahren zum seitenweisen Abrufen der Daten; alles andere - Retries, Idempotenz, Alarmierung, Warnungen bei ablaufendem Consent - lebt in der gemeinsamen Schicht, einmal geschrieben und einmal getestet.

Wenn eine Bankintegration eine spezielle Retry-Logik braucht, gehört diese Logik in die gemeinsame Schicht, hinter einem Feature-Flag - niemals in den Adapter. Sich selbst überlassene Adapter veralten; die gemeinsame Schicht wird weiter gepflegt.

Das Ergebnis ist Routine - und genau das ist das Ziel. Eine neue Bank ist ein neuer Adapter, eine aus ihrer Sandbox aufgezeichnete Beispieldatei für die Tests und eine Checkliste - kein neues Projekt.