Die Verification-of-Payee- API
Ein REST-Aufruf in Echtzeit, um einen Empfängernamen gegen eine IBAN zu bestätigen — Ergebnis, BIC der antwortenden Bank und Verarbeitungszeit in der Antwort. Auf der RoxPay-Plattform und dem SEPA-VoP-Schema aufgebaut.
{ "Name": "ACME Trading Ltd", "Iban": "DE89 3704 0044 0532 0130 00" }
{ "VopResult": "MATCH", "MatchType": "MTCH", "RespondingBic": "CRACIT33XXX" }
Empfängerprüfung in einer einzigen Anfrage
Die Verification-of-Payee-API stellt das SEPA-VoP-Schema als sauberen REST-Endpunkt bereit: Senden Sie einen Namen und eine IBAN, erhalten Sie ein standardisiertes Ergebnis in Echtzeit — ohne die Schema-Anbindung selbst bauen zu müssen.
Es ist dieselbe Prüfung, die RoxPay in seiner Banking-Plattform SwiftLine / RoxBusiness ausführt, verfügbar für Banken, PSPs und Unternehmen über eine authentifizierte API und ein Dashboard. Jede Antwort enthält den Übereinstimmungstyp, die BIC der antwortenden Institution und die PSP-Verarbeitungszeit.
Da sie über die europäische Open-Banking-Infrastruktur von RoxPay bereitgestellt wird, verbinden Sie sich einmal und erreichen die Empfängerprüfung im gesamten SEPA-Raum — statt sich mit jeder antwortenden Bank zu integrieren.
Von null bis verifiziert in vier Schritten
Eine standardmäßige REST-Integration, die sich in Ihren bestehenden Zahlungsablauf einfügt.
Holen Sie Ihre Zugangsdaten
Aktivieren Sie den Dienst und authentifizieren Sie sich mit einem Bearer-Token — kein Onboarding pro Bank zu verwalten.
Senden Sie Name + IBAN
POSTen Sie Name und IBAN des Empfängers an den Verify-Endpunkt, optional mit Ihrer eigenen Referenz-ID zur Abstimmung.
Lesen Sie das Ergebnis
Erhalten Sie das Ergebnis (Übereinstimmung / teilweise / keine / nicht anwendbar), die antwortende BIC und die Verarbeitungszeit.
Handeln Sie in Ihrer UI
Zeigen Sie dem Zahler ein klares Signal oder machen Sie einen Zahlungslauf, ein Mandat oder einen Onboarding-Schritt vom Ergebnis abhängig.
Was die API zurückgibt
Jede Antwort entspricht einem Code des SEPA-VoP-Schemas, sodass Ihre Logik einfach bleibt.
MATCH · MTCH
Der Name stimmt mit dem Kontoinhaber überein. Die Antwort enthält auch die BIC der antwortenden Bank.
CLOSE_MATCH · CMTC
Teilweise Übereinstimmung — behandeln Sie sie als Warnung und schlagen Sie den verifizierten Namen vor.
NO_MATCH · NMTC
Der Name stimmt nicht überein. Zeigen Sie vor der Bestätigung der Zahlung eine klare Warnung an.
NOT_APPLICABLE · NOAP
Prüfung für diese IBAN derzeit nicht verfügbar. Lassen Sie den Nutzer entscheiden.
Die VoP selbst bauen vs. die API
Was Sie vermeiden, indem Sie einen Endpunkt aufrufen, statt dem Schema allein beizutreten.
Inhouse-Entwicklung
- Schema-Konnektivität Integration pro antwortendem PSP
- Time-to-go-live Monate
- Antwortdetail Sie normalisieren es
- Wiederverwendung über Produkte Jeden Ablauf neu verkabeln
- Wartung Ihre Aufgabe
Verification-of-Payee-API
- Schema-Konnektivität Eine Verbindung, SEPA-weite Reichweite
- Time-to-go-live Wochen
- Antwortdetail Standardisiertes Ergebnis + BIC + Timing
- Wiederverwendung über Produkte Eine API für UI, Stapel & Mandate
- Wartung Von der Plattform übernommen
Eine API, drei Zielgruppen
Derselbe Endpunkt erfüllt sehr unterschiedliche Aufgaben.
Banken & PSPs
Bieten Sie Kontoinhabern die Verification of Payee an und erfüllen Sie die Verordnung über Echtzeitzahlungen, ohne Schema-Konnektivität zu bauen.
Entwickler
Ein vorhersehbarer REST-Vertrag, Echtzeitantworten, Ihre eigenen Referenz-IDs und klare Schemacodes zum Verzweigen.
Unternehmen & ERPs
Verifizieren Sie Lieferanten- und Gehalts-IBANs vor einem Zahlungslauf im Stapel und senken Sie das Risiko der Rechnungsumleitung.
Die API, beantwortet
Was Entwickler und Produktteams zuerst fragen.
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. 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 sowie den Namen. Sie übermitteln die Kennung in der Anfrage und die API gibt das Standardergebnis 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.
Integrieren Sie die Verification of Payee
Holen Sie sich Ihre Zugangsdaten und gehen Sie mit einer einzigen REST-Integration auf dem SEPA-VoP-Schema live.