The Verification of Payee API

Yes. A verify call returns synchronously, typically in well under a second, and includes the responding bank's BIC and the PSP processing time so you can monitor performance.

Calls are authenticated with a bearer token over HTTPS. You can also use the RoxBusiness dashboard for ad-hoc checks without writing code.

A normalised result (MATCH, CLOSE_MATCH, NO_MATCH, NOT_APPLICABLE), the SEPA scheme match-type code, a verification id, the responding BIC, the processing time and your optional external id.

Yes - call the endpoint per record to verify a whole file of suppliers or payees before a payment run. It is built for high throughput.

Yes. The endpoint is stateless, so you can call it whenever a payee is created - a seller or supplier onboarding step - and again immediately before each payout. Re-checking at payout catches bank details that changed after onboarding, which is where invoice and payout redirection fraud usually happens.

Verification is a per-record REST call, so a payout file of thousands of beneficiaries is handled as a batch: loop the file, call the endpoint per record and collect the outcomes before releasing the run. Because the API is built for high throughput, you can pace the loop to your own release window rather than being capped by per-bank onboarding. Talk to us about your volumes and we will size the throughput with you.

Yes. The same verification is available in the RoxBusiness dashboard, so a finance or operations team can check a single payee - a 'know your payee' check before sending money - while developers use the API for automated flows.

Yes. The check compares the submitted name against the registered account holder, whether that is an individual or a company, and is used inside RoxPay's SEPA Direct Debit mandate flow as a pre-check.

NO_MATCH is not a transport error - it is a valid 200 response telling you the name does not belong to the IBAN. Treat it as a hard stop in your UI or payment run: surface a clear warning, block auto-approval, and let the user re-check the payee before sending.

CLOSE_MATCH (scheme code CMTC) means the name is almost right - a missing middle name, a legal vs trading name. The response carries the verified account-holder name, so you can show it as a suggestion and ask the payer to confirm rather than reject the payment.

For legal persons the scheme allows verification against the organisation identifier (e.g. Italian Partita IVA / Codice Fiscale) as well as the name. You submit the identifier in the request and the API returns the standard match outcome - useful when the registered name and trading name differ.

Yes. For a payment run, loop your supplier or payroll file and call the verify endpoint per record before releasing the batch. It is built for high throughput, so finance teams can mass-validate IBANs against names ahead of every distinta/bonifico run.

Yes. You send a JSON request with the payee name and IBAN and get back the outcome, the verified name (on a close match) and the responding BIC. See a full request and response in our VoP example, or the payloads and scheme codes in the API documentation.

Treat the verify call as one extra step before the payment is authorised. Authenticate with a bearer token, POST the payee name and IBAN, read the outcome, then branch: proceed on MATCH, show the suggested name and ask for confirmation on CLOSE_MATCH, block auto-approval on NO_MATCH and let the payer decide on NOT_APPLICABLE. Because the endpoint is stateless, the same call drops into checkout, supplier onboarding, a payment run or a payout batch without changing your payment rails.

It is both, depending on the job. As a payee checker it answers 'who does this IBAN belong to?' for a single payee - useful for a finance team or a payer before sending money. As a payment validation API it runs the same check inside an automated flow, so every payment or payout is validated against the account holder before it leaves.

'Know your payee' is the practical habit of confirming the account holder's name before you pay, rather than trusting the details on an invoice or an email. The API turns that habit into an automated step: the name is compared against the IBAN and you get a clear match, close match, no match or not-possible answer in well under a second.

Confirmation of Payee (CoP) is the UK name-checking scheme; Verification of Payee (VoP) is the EPC scheme used across the EU and SEPA. If you need both, look for a provider that covers the SEPA VoP scheme through one integration and returns the standardised outcomes, so your code does not change per market. RoxPay delivers VoP as a single REST API with the scheme codes, responding BIC and processing time in every response.

Five things. Coverage: which banks and countries the provider can reach across SEPA. Latency: whether results reliably fit inside the instant-payment window. Accuracy: how name matching handles close matches and legal versus trading names. Directions: whether requesting and responding VoP come through the same integration. And support: who monitors the service and what happens when a responding PSP is unreachable. Ask for the response payload and the error codes in writing - they tell you more than a feature list.

Branch on the scheme code rather than the display label. In your UI, treat MTCH as a silent pass, CMTC as a soft warning that shows the suggested name and asks the payer to confirm, and NMTC as a hard warning that blocks auto-approval. NOAP is neither: it means the check could not be completed, so tell the payer that verification was unavailable and let them decide. Keeping the four codes separate in your code is what makes the warning behaviour predictable.

Yes, and you should. The endpoint is stateless, so the same call verifies a payee when the record is created - a seller, supplier or employee onboarding step - and again immediately before money moves. Re-checking at payout time is what catches bank details that changed after onboarding, which is where payout redirection fraud usually happens. One endpoint serves both moments, so you do not maintain two checks.

Yes. Sandbox credentials are issued separately from production, so you can run match, close match and no match flows against the API before you go live. The same credentials also unlock the RoxBusiness dashboard, where you can run ad-hoc checks without writing code.

You get NOT_APPLICABLE (scheme code NOAP) as a valid 200 response, not a transport error. It means the check could not be completed for that IBAN at that moment. Treat it as an unknown rather than a failure: inform the payer that verification was unavailable and let them decide whether to continue. Genuine technical failures use 4xx and 5xx status codes with a machine-readable error code.