The Verification of Payee API
One real-time REST call to confirm a payee name against an IBAN — match outcome, responding bank BIC and processing time in the response. Built on RoxPay's payments platform and the SEPA VoP scheme.
{ "Name": "ACME Trading Ltd", "Iban": "DE89 3704 0044 0532 0130 00" }
{ "VopResult": "MATCH", "MatchType": "MTCH", "RespondingBic": "CRACIT33XXX" }
Payee verification in a single request
The Verification of Payee API exposes the SEPA VoP scheme as a clean REST endpoint: send a name and an IBAN, get back a standardised match result in real time — no scheme plumbing to build yourself.
It is the same verification RoxPay runs inside its SwiftLine / RoxBusiness banking platform, available to banks, PSPs and businesses through an authenticated API and a dashboard. Each response includes the match type, the responding institution's BIC and the PSP processing time.
Because it is delivered over RoxPay's European open-banking infrastructure, you connect once and reach payee verification across SEPA — instead of integrating with each responding bank.
From zero to verified in four steps
A standard REST integration that drops into your existing payment flow.
Get your credentials
Activate the service and authenticate with a bearer token — no per-bank onboarding to manage.
Send name + IBAN
POST the payee name and IBAN to the verify endpoint, optionally with your own reference id for reconciliation.
Read the result
Receive the outcome (match / close match / no match / not applicable), the responding BIC and the processing time.
Act in your UI
Show a clear signal to the payer, or gate a payment run, a mandate or an onboarding step on the result.
What the API returns
Every response maps to a SEPA VoP scheme code, so your logic stays simple.
MATCH · MTCH
Name matches the account holder. The response also carries the responding bank BIC.
CLOSE_MATCH · CMTC
Close match — handle it as a soft warning and suggest the verified name.
NO_MATCH · NMTC
Name does not match. Surface a clear warning before the payment is confirmed.
NOT_APPLICABLE · NOAP
Verification not available for this IBAN right now. Let the user decide.
Building VoP yourself vs. the API
What you avoid by calling one endpoint instead of joining the scheme alone.
Build it in-house
- Scheme connectivity Integrate per responding PSP
- Time to go live Months
- Response detail You normalise it
- Reuse across products Re-plumb each flow
- Maintenance Yours to own
Verification of Payee API
- Scheme connectivity One connection, SEPA-wide reach
- Time to go live Weeks
- Response detail Standardised result + BIC + timing
- Reuse across products One API for UI, batch & mandates
- Maintenance Handled by the platform
One API, three audiences
The same endpoint serves very different jobs to be done.
Banks & PSPs
Offer Verification of Payee to account holders and meet the Instant Payments Regulation without building scheme connectivity.
Developers
A predictable REST contract, real-time responses, your own reference ids and clear scheme codes to branch on.
Businesses & ERPs
Verify supplier and payroll IBANs in bulk before a payment run, cutting invoice-redirection risk.
The API, answered
What developers and product teams ask first.
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 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.
Integrate Verification of Payee
Get your credentials and go live on the SEPA VoP scheme with one REST integration.