Die Verification-of-Payee- API

Ja. Ein Verify-Aufruf antwortet synchron, in der Regel in deutlich weniger als einer Sekunde, und enthält die BIC der antwortenden Bank und die PSP-Verarbeitungszeit zur Leistungsüberwachung.

Aufrufe werden mit einem Bearer-Token über HTTPS authentifiziert. Sie können auch das RoxBusiness-Dashboard für Ad-hoc-Prüfungen ohne Code verwenden.

Ein normalisiertes Ergebnis (MATCH, CLOSE_MATCH, NO_MATCH, NOT_APPLICABLE), der Übereinstimmungstyp-Code des SEPA-Schemas, eine Verifizierungs-ID, die antwortende BIC, die Verarbeitungszeit und Ihre optionale externe ID.

Ja - rufen Sie den Endpunkt pro Datensatz auf, um eine ganze Datei von Lieferanten oder Empfängern vor einem Zahlungslauf zu verifizieren. Sie ist für hohen Durchsatz gebaut.

Ja. Der Endpunkt ist zustandslos, Sie können ihn also aufrufen, wann immer ein Empfänger angelegt wird - etwa in einem Onboarding-Schritt für Verkäufer oder Lieferanten - und erneut unmittelbar vor jeder Auszahlung. Die erneute Prüfung bei der Auszahlung erkennt Bankdaten, die nach dem Onboarding geändert wurden - genau dort passiert in der Regel die Rechnungs- und Auszahlungsumleitung.

Die Verifizierung ist ein REST-Aufruf pro Datensatz, eine Auszahlungsdatei mit Tausenden Begünstigten wird also als Stapel abgearbeitet: Durchlaufen Sie die Datei, rufen Sie den Endpunkt pro Datensatz auf und sammeln Sie die Ergebnisse, bevor Sie den Lauf freigeben. Da die API auf hohen Durchsatz ausgelegt ist, können Sie die Schleife auf Ihr eigenes Freigabefenster takten, statt durch das Onboarding pro Bank begrenzt zu sein. Sprechen Sie mit uns über Ihre Volumina - wir dimensionieren den Durchsatz gemeinsam mit Ihnen.

Ja. Dieselbe Prüfung steht im RoxBusiness-Dashboard zur Verfügung, sodass ein Finanz- oder Operationsteam einen einzelnen Empfänger prüfen kann - eine 'Know your payee'-Prüfung, bevor Geld gesendet wird - während Entwickler die API für automatisierte Abläufe nutzen.

Ja. Die Prüfung vergleicht den übermittelten Namen mit dem registrierten Kontoinhaber, sei es eine Privatperson oder ein Unternehmen, und wird im SEPA-Lastschriftmandat-Ablauf von RoxPay als Vorprüfung verwendet.

NO_MATCH ist kein Transportfehler - es ist eine gültige 200-Antwort, die besagt, dass der Name nicht zur IBAN gehört. Behandeln Sie sie als harten Stopp in Ihrer UI oder Ihrem Zahlungslauf: zeigen Sie eine klare Warnung, blockieren Sie die automatische Freigabe und lassen Sie den Empfänger vor dem Senden erneut prüfen.

CLOSE_MATCH (Schemacode CMTC) bedeutet, dass der Name fast richtig ist - ein fehlender zweiter Vorname, ein Firmen- vs Handelsname. Die Antwort enthält den verifizierten Kontoinhabernamen, sodass Sie ihn als Vorschlag anzeigen und den Zahler um Bestätigung bitten können, statt die Zahlung abzulehnen.

Für juristische Personen erlaubt das Schema die Prüfung gegen die Organisationskennung (z. B. italienische Partita IVA / Codice Fiscale) sowie gegen den Namen. Sie übermitteln die Kennung in der Anfrage und die API gibt das standardisierte Übereinstimmungsergebnis zurück - nützlich, wenn registrierter Name und Handelsname abweichen.

Ja. Durchlaufen Sie für einen Zahlungslauf Ihre Lieferanten- oder Gehaltsdatei und rufen Sie den Verify-Endpunkt pro Datensatz auf, bevor Sie den Stapel freigeben. Für hohen Durchsatz gebaut, ermöglicht sie Finanzteams die Massenvalidierung von IBANs gegen Namen vor jedem Lauf.

Ja. Sie senden eine JSON-Anfrage mit Empfängername und IBAN und erhalten das Ergebnis, den verifizierten Namen (bei einer teilweisen Übereinstimmung) und die antwortende BIC zurück. Eine vollständige Anfrage und Antwort finden Sie in unserem VoP-Beispiel, die Payloads und Schemacodes in der API-Dokumentation.

Behandeln Sie den Verify-Aufruf als einen zusätzlichen Schritt, bevor die Zahlung autorisiert wird. Authentifizieren Sie sich mit einem Bearer-Token, senden Sie Name und IBAN des Empfängers per POST, lesen Sie das Ergebnis und verzweigen Sie dann: bei MATCH weiterfahren, bei CLOSE_MATCH den vorgeschlagenen Namen anzeigen und um Bestätigung bitten, bei NO_MATCH die automatische Freigabe blockieren und bei NOT_APPLICABLE den Zahler entscheiden lassen. Da der Endpunkt zustandslos ist, fügt sich derselbe Aufruf in Checkout, Lieferanten-Onboarding, einen Zahlungslauf oder einen Auszahlungsstapel ein, ohne dass Sie Ihre Zahlungswege ändern müssen.

Beides, je nach Aufgabe. Als Empfängerprüfung beantwortet sie die Frage 'Wem gehört diese IBAN?' für einen einzelnen Empfänger - nützlich für ein Finanzteam oder einen Zahler vor dem Senden von Geld. Als Zahlungsvalidierungs-API führt sie dieselbe Prüfung in einem automatisierten Ablauf aus, sodass jede Zahlung oder Auszahlung vor dem Versand gegen den Kontoinhaber validiert wird.

'Know your payee' ist die praktische Gewohnheit, den Namen des Kontoinhabers zu bestätigen, bevor Sie zahlen, statt den Angaben auf einer Rechnung oder in einer E-Mail zu vertrauen. Die API macht aus dieser Gewohnheit einen automatisierten Schritt: Der Name wird gegen die IBAN abgeglichen und Sie erhalten in deutlich unter einer Sekunde eine klare Antwort - Übereinstimmung, teilweise Übereinstimmung, keine Übereinstimmung oder nicht möglich.

Confirmation of Payee (CoP) ist das britische Namensprüfungsschema; Verification of Payee (VoP) ist das EPC-Schema, das in der gesamten EU und im SEPA-Raum verwendet wird. Wenn Sie beides brauchen, suchen Sie einen Anbieter, der das SEPA-VoP-Schema über eine einzige Integration abdeckt und die standardisierten Ergebnisse zurückgibt, damit sich Ihr Code nicht je Markt ändert. RoxPay liefert VoP als einzelne REST-API mit den Schemacodes, der antwortenden BIC und der Verarbeitungszeit in jeder Antwort.

Fünf Dinge. Abdeckung: welche Banken und Länder der Anbieter im SEPA-Raum erreicht. Latenz: ob die Ergebnisse zuverlässig in das Zeitfenster der Instant Payments passen. Genauigkeit: wie der Namensabgleich teilweise Übereinstimmungen und Firmen- gegenüber Handelsnamen behandelt. Richtungen: ob anfragende und antwortende VoP über dieselbe Integration laufen. Und Support: wer den Dienst überwacht und was passiert, wenn ein antwortender PSP nicht erreichbar ist. Lassen Sie sich die Antwort-Payload und die Fehlercodes schriftlich geben - sie sagen Ihnen mehr als eine Funktionsliste.

Verzweigen Sie nach dem Schemacode, nicht nach dem Anzeigetext. Behandeln Sie in Ihrer UI MTCH als stilles Durchlaufen, CMTC als weiche Warnung, die den vorgeschlagenen Namen zeigt und den Zahler um Bestätigung bittet, und NMTC als harte Warnung, die die automatische Freigabe blockiert. NOAP ist keines von beiden: Es bedeutet, dass die Prüfung nicht abgeschlossen werden konnte, sagen Sie dem Zahler also, dass die Verifizierung nicht verfügbar war, und lassen Sie ihn entscheiden. Die vier Codes in Ihrem Code getrennt zu halten, macht das Warnverhalten vorhersehbar.

Ja, und das sollten Sie auch. Der Endpunkt ist zustandslos, derselbe Aufruf verifiziert einen Empfänger also beim Anlegen des Datensatzes - etwa in einem Onboarding-Schritt für Verkäufer, Lieferanten oder Mitarbeiter - und erneut unmittelbar bevor Geld fließt. Die erneute Prüfung zum Auszahlungszeitpunkt erkennt Bankdaten, die sich nach dem Onboarding geändert haben - genau dort passiert in der Regel die Auszahlungsumleitung. Ein Endpunkt bedient beide Momente, Sie pflegen also nicht zwei Prüfungen.

Ja. Sandbox-Zugangsdaten werden getrennt von der Produktion ausgegeben, sodass Sie Abläufe für Übereinstimmung, teilweise Übereinstimmung und Nichttreffer gegen die API testen können, bevor Sie live gehen. Dieselben Zugangsdaten schalten auch das RoxBusiness-Dashboard frei, in dem Sie Ad-hoc-Prüfungen ohne Programmierung ausführen können.

Sie erhalten NOT_APPLICABLE (Schemacode NOAP) als gültige 200-Antwort, nicht als Transportfehler. Das bedeutet, dass die Prüfung für diese IBAN in diesem Moment nicht abgeschlossen werden konnte. Behandeln Sie es als Unbekanntes und nicht als Fehler: Informieren Sie den Zahler, dass die Verifizierung nicht verfügbar war, und lassen Sie ihn entscheiden, ob er fortfährt. Echte technische Fehler verwenden die Statuscodes 4xx und 5xx mit einem maschinenlesbaren Fehlercode.