Der häufigste Integrationsfehler bei der Verification of Payee ist, ein NO_MATCH als fehlgeschlagene Anfrage zu behandeln. Das ist es nicht. Eine erfolgreiche Prüfung, die sagt „dieser Name gehört nicht zu dieser IBAN“, ist trotzdem eine 200-Antwort mit nützlichen Daten. Verwechseln Sie die beiden, schlucken Sie entweder Betrugssignale oder zeigen Nutzern beängstigende Fehler.
Die vier Schemacodes
Jede Verification-of-Payee-Antwort entspricht einem von vier standardisierten SEPA-Schemacodes. Verzweigen Sie auf den Code, nicht auf Freitext:
- MTCH — MATCH: Der Name stimmt mit dem Kontoinhaber überein. Fortfahren.
- CMTC — CLOSE_MATCH: fast richtig (fehlender zweiter Vorname, Handelsname vs. Firmenname). Zeigen Sie den vorgeschlagenen geprüften Namen und bitten Sie den Zahler zu bestätigen.
- NMTC — NO_MATCH: Der Name gehört nicht zur IBAN. Klar warnen und die automatische Freigabe blockieren.
- NOAP — NOT_APPLICABLE: Die Prüfung konnte nicht abgeschlossen werden (z. B. antwortende Bank nicht erreichbar). Lassen Sie den Nutzer mit zusätzlicher Vorsicht entscheiden.
Ergebnis vs. Fehler
Ist der HTTP-Status 200, haben Sie ein Prüfergebnis — lesen Sie scheme_code. Ist er 4xx/5xx, haben Sie einen Fehler — lesen Sie den Fehlercode. Mappen Sie NO_MATCH nie auf Ihren Fehlerpfad.
CLOSE_MATCH gut behandeln
Beim CLOSE_MATCH wird gute UX gewonnen oder verloren. Die Antwort kann den geprüften Kontoinhabernamen tragen; zeigen Sie ihn als Vorschlag („Meinten Sie …?“), damit der Zahler bestätigt oder korrigiert, statt die Zahlung abzubrechen. CMTC als harten Fehlschlag zu behandeln frustriert legitime Nutzer.
Echte Fehlercodes
Getrennt von Schema-Ergebnissen geben Probleme auf Transportebene Standard-HTTP-Fehler zurück — etwa invalid_iban (400), unauthorized (401), rate_limited (429) und scheme_unavailable (503). Jeder trägt eine request id, damit der Support sie verfolgen kann. Übergeben Sie bei jedem Aufruf eine stabile external id, damit Retries idempotent bleiben und Logs sich abgleichen.