Testing für Payment-, Banking- und Fintech-APIs.
Systeme, die Geld bewegen, scheitern auf typische Weise: doppelte Belastungen, Abweichungen beim Abgleich, Traffic am Zahltag und Drittanbieter-APIs, die im ungünstigsten Moment in einen Timeout laufen. Genau darauf konzentriere ich mich beim Testen.
Testnachweise für DORA, PSD2 und die britischen Vorgaben zur operationellen Resilienz
DORA
Der Digital Operational Resilience Act (Verordnung (EU) 2022/2554) gilt seit dem 17. Januar 2025. Artikel 25 nennt Testarten für das Programm zum Testen der digitalen operationalen Resilienz, darunter Leistungstests, End-to-End-Tests und szenariobasierte Tests. Performance-, Last- und End-to-End-Testberichte von Assertwise können als Nachweis innerhalb dieses Programms dienen.
PSD2 & Open Banking
Gemäß RTS zur starken Kundenauthentifizierung und sicheren Kommunikation (Delegierte Verordnung (EU) 2018/389) muss die dedizierte Schnittstelle eines kontoführenden Zahlungsdienstleisters dieselbe Verfügbarkeit und Leistung bieten wie die Kundenschnittstelle. Ich teste APIs nach Berlin Group NextGenPSD2 und UK Open Banking auf funktionale Korrektheit, Consent-Flows, Fehlerbehandlung und Performance unter Last.
Operationelle Resilienz in UK
Britische Unternehmen fallen nicht unter DORA, unterliegen aber den Regeln von FCA und PRA zur operationellen Resilienz: wichtige Geschäftsdienste, Auswirkungstoleranzen und Szenariotests, vollständig umzusetzen seit dem 31. März 2025. Last- und Ausfallszenario-Tests können Nachweise für diese Szenariotests liefern.
Assertwise erbringt Testleistungen, keine Rechts- oder Compliance-Beratung. Ich bescheinige keine DORA- oder PSD2-Konformität und führe keine bedrohungsorientierten Penetrationstests (TLPT) durch. Ihre Compliance-Funktion entscheidet, wie Testnachweise verwendet werden.
Fehlerbilder, die typisch für Zahlungsverkehr sind
Idempotenz & Duplikate
Parallele Wiederholungen mit demselben Idempotency-Key, Client-Timeouts mit anschließendem Retry, wiederholte Webhooks. Ziel: eine Zahlung, ein Buchungseintrag – egal, was das Netzwerk tut.
Race Conditions bei Salden
Parallele Belastungen desselben Kontos, Double-Spend-Versuche, Lost Updates. Getestet mit synchronisierten parallelen Anfragen, nicht nur mit sequenziellen Skripten.
Abgleich (Reconciliation)
Stimmen Ledger, PSP-Berichte und Kontoauszüge nach einem Testlauf mit eingespeisten Fehlern und Retries überein? Abweichungen werden pro Transaktion berichtet.
Zahltag- & Monatsend-Spitzen
Lastmodelle auf Basis Ihres Traffics: Gehaltstage, Monatsend-Batchläufe, Cut-off-Zeiten der Kartensysteme, Kampagnenstarts. Lasttests mit Ankunftsraten, nicht nur gleichzeitige Nutzer.
Abhängigkeiten von Drittanbietern
PSP-, KYC- und Bankpartner-APIs, die langsam werden oder ausfallen. Timeouts, Circuit Breaker und Retry-Stürme werden gegen Stubs und Sandboxes getestet.
API-Security
Autorisierung auf Objektebene über Kunden und Konten hinweg, Token-Handling, Rate Limiting und übermäßige Datenpreisgabe – zugeordnet zu den OWASP API Security Top 10.
Steht ein Payment-Feature oder eine Bankintegration an?
Starten Sie mit dem kostenlosen Check: kurze schriftliche Befunde zu Ihrer API, keine Last auf Produktivsystemen.
Weiterlesen: Idempotenz und Race Conditions in Payment-APIs