De Verification of Payee- API

Ja. Een verify-aanroep antwoordt synchroon, doorgaans in ruim minder dan een seconde, en bevat de BIC van de antwoordende bank en de verwerkingstijd van de PSP, zodat u de prestaties kunt monitoren.

Aanroepen worden geauthenticeerd met een bearer-token over HTTPS. U kunt ook het RoxBusiness-dashboard gebruiken voor ad-hoccontroles zonder code te schrijven.

Een genormaliseerd resultaat (MATCH, CLOSE_MATCH, NO_MATCH, NOT_APPLICABLE), de matchtype-code van het SEPA-schema, een verificatie-id, de antwoordende BIC, de verwerkingstijd en uw optionele externe id.

Ja — roep het endpoint per record aan om een heel bestand met leveranciers of begunstigden te verifiëren vóór een betaalrun. Het is gebouwd voor hoge doorvoer.

Ja. Het endpoint is stateless, dus u kunt het aanroepen wanneer een begunstigde wordt aangemaakt — bijvoorbeeld bij de onboarding van een verkoper of leverancier — en nogmaals vlak vóór elke uitbetaling. Dat hercontroleren bij de uitbetaling vangt bankgegevens af die na de onboarding zijn gewijzigd, en dat is precies waar omleidingsfraude bij facturen en uitbetalingen meestal plaatsvindt.

Verificatie is een REST-aanroep per record, dus een uitbetalingsbestand met duizenden begunstigden behandelt u als een batch: doorloop het bestand, roep het endpoint per record aan en verzamel de uitkomsten voordat u de run vrijgeeft. Omdat de API is gebouwd voor hoge doorvoer, kunt u het tempo van de lus afstemmen op uw eigen vrijgavevenster in plaats van beperkt te worden door onboarding per bank. Praat met ons over uw volumes en we stemmen de doorvoer samen met u af.

Ja. Dezelfde verificatie is beschikbaar in het RoxBusiness-dashboard, zodat een finance- of operationeel team één begunstigde kan controleren — een 'know your payee'-controle voordat er geld wordt verstuurd — terwijl ontwikkelaars de API gebruiken voor geautomatiseerde flows.

Ja. De controle vergelijkt de ingediende naam met de geregistreerde rekeninghouder, of dat nu een particulier of een bedrijf is, en wordt binnen de SEPA-incassomandaatflow van RoxPay gebruikt als voorcontrole.

NO_MATCH is geen transportfout — het is een geldig 200-antwoord dat aangeeft dat de naam niet bij de IBAN hoort. Behandel het als een harde stop in uw UI of betaalrun: toon een duidelijke waarschuwing, blokkeer automatische goedkeuring en laat de gebruiker de begunstigde opnieuw controleren voordat er wordt verstuurd.

CLOSE_MATCH (schemacode CMTC) betekent dat de naam bijna goed is — een ontbrekende tweede voornaam, een statutaire naam versus een handelsnaam. Het antwoord bevat de geverifieerde rekeninghoudernaam, zodat u die als suggestie kunt tonen en de betaler om bevestiging kunt vragen in plaats van de betaling te weigeren.

Voor rechtspersonen staat het schema verificatie toe tegen het organisatie-identificatienummer (bijvoorbeeld het Italiaanse Partita IVA / Codice Fiscale) naast de naam. U dient het identificatienummer in het verzoek in en de API geeft het standaard matchresultaat terug — handig wanneer de statutaire naam en de handelsnaam verschillen.

Ja. Doorloop voor een betaalrun uw leveranciers- of salarisbestand en roep het verify-endpoint per record aan voordat u de batch vrijgeeft. Gebouwd voor hoge doorvoer, zodat financeteams IBAN's tegen namen kunnen massavalideren vóór elke betalingsrun.

Ja. U stuurt een JSON-verzoek met de naam en IBAN van de begunstigde en ontvangt de uitkomst, de geverifieerde naam (bij een bijna overeenkomst) en de antwoordende BIC. Bekijk een volledig verzoek en antwoord in ons VoP-voorbeeld, of de payloads en schemacodes in de API-documentatie.

Behandel de verify-aanroep als één extra stap voordat de betaling wordt geautoriseerd. Authenticeer met een bearer-token, POST de naam en IBAN van de begunstigde, lees de uitkomst en vertak: ga door bij MATCH, toon de voorgestelde naam en vraag om bevestiging bij CLOSE_MATCH, blokkeer automatische goedkeuring bij NO_MATCH en laat de betaler beslissen bij NOT_APPLICABLE. Omdat het endpoint stateless is, past dezelfde aanroep in een checkout, de onboarding van leveranciers, een betaalrun of een uitbetalingsbatch zonder dat u uw betaalinfrastructuur hoeft te wijzigen.

Het is beide, afhankelijk van de taak. Als begunstigdechecker beantwoordt de API de vraag 'van wie is deze IBAN?' voor één begunstigde — handig voor een financeteam of een betaler voordat er geld wordt verstuurd. Als betalingsvalidatie-API voert dezelfde controle binnen een geautomatiseerde flow uit, zodat elke betaling of uitbetaling tegen de rekeninghouder wordt gevalideerd voordat die vertrekt.

'Know your payee' is de praktische gewoonte om de naam van de rekeninghouder te bevestigen voordat u betaalt, in plaats van te vertrouwen op de gegevens op een factuur of in een e-mail. De API maakt van die gewoonte een geautomatiseerde stap: de naam wordt met de IBAN vergeleken en u krijgt in ruim minder dan een seconde een duidelijk antwoord: overeenkomst, bijna overeenkomst, geen overeenkomst of niet mogelijk.

Confirmation of Payee (CoP) is het Britse schema voor naamcontrole; Verification of Payee (VoP) is het EPC-schema dat in de hele EU en het SEPA-gebied wordt gebruikt. Hebt u beide nodig, kies dan een provider die het SEPA VoP-schema via één integratie dekt en de gestandaardiseerde uitkomsten teruggeeft, zodat uw code niet per markt verandert. RoxPay levert VoP als één REST-API met de schemacodes, de antwoordende BIC en de verwerkingstijd in elk antwoord.

Vijf dingen. Dekking: welke banken en landen de provider binnen het SEPA-gebied kan bereiken. Latentie: of resultaten betrouwbaar binnen het venster van instantbetalingen passen. Nauwkeurigheid: hoe naamherkenning omgaat met bijna overeenkomsten en met statutaire versus handelsnamen. Richtingen: of het aanvragen en het beantwoorden van VoP via dezelfde integratie lopen. En ondersteuning: wie de dienst monitort en wat er gebeurt als een antwoordende PSP onbereikbaar is. Vraag de antwoordpayload en de foutcodes schriftelijk op — die zeggen u meer dan een lijst met functies.

Vertak op de schemacode in plaats van op het getoonde label. Behandel in uw UI MTCH als een stille goedkeuring, CMTC als een zachte waarschuwing die de voorgestelde naam toont en de betaler om bevestiging vraagt, en NMTC als een harde waarschuwing die automatische goedkeuring blokkeert. NOAP is geen van beide: het betekent dat de controle niet kon worden afgerond, dus meld de betaler dat verificatie niet beschikbaar was en laat die beslissen. Door de vier codes in uw code gescheiden te houden, wordt het gedrag van de waarschuwingen voorspelbaar.

Ja, en dat zou u ook moeten doen. Het endpoint is stateless, dus dezelfde aanroep verifieert een begunstigde wanneer het record wordt aangemaakt — een onboardingstap voor een verkoper, leverancier of medewerker — en nogmaals vlak voordat het geld beweegt. Dat hercontroleren op het moment van uitbetalen vangt bankgegevens af die na de onboarding zijn gewijzigd, en dat is waar omleidingsfraude bij uitbetalingen meestal plaatsvindt. Eén endpoint bedient beide momenten, dus u onderhoudt geen twee controles.

Ja. Sandbox-inloggegevens worden apart van productie uitgegeven, zodat u flows met overeenkomst, bijna overeenkomst en geen overeenkomst tegen de API kunt testen voordat u live gaat. Dezelfde inloggegevens geven ook toegang tot het RoxBusiness-dashboard, waar u ad-hoccontroles kunt uitvoeren zonder code te schrijven.

U krijgt NOT_APPLICABLE (schemacode NOAP) als een geldig 200-antwoord, niet als transportfout. Het betekent dat de controle voor die IBAN op dat moment niet kon worden afgerond. Behandel het als onbekend in plaats van als mislukking: meld de betaler dat verificatie niet beschikbaar was en laat die beslissen of hij doorgaat. Echte technische fouten gebruiken 4xx- en 5xx-statuscodes met een machineleesbare foutcode.