Execute VoP Checks
Overview
What is VoP?
VoP is a mandatory SEPA-wide pre-payment service that checks if the name and IBAN provided by a payer match the account holder data held by the payee's PSP. It helps reduce:
· Fraud (APP fraud)
· Misdirected payments
· Payment disputes
The VoP endpoint
The Verification of Payee (VoP) endpoint verifies whether the payee details supplied by the payer match the actual account holder held by the beneficiary bank for a given IBAN. It is called before initiating a SEPA Credit Transfer to help prevent misdirected payments and authorised-push-payment fraud.
This guide covers:
· POST /v2/vop - request, response, result codes, and error codes.
· How the returned vop_token is used when creating a transfer via POST /v2/transfer.
· Operational notes (latency, name handling, service availability) and an integration checklist.
Full endpoint definition can be found here: Paynetics API documentation
Scope of VoP
VoP applies to all SEPA Credit Transfers initiated by a payer - both standard SCT and SCT Inst - under Regulation (EU) 2024/886 and the EPC VoP Scheme Rulebook. It applies to every payee, whether a person or a business. The Paynetics API requires a valid VoP token on the transfer payload for these transactions.
Integration Flow
The integration is two sequential API calls. First obtain a VoP token, then present that token when creating the transfer. The API Gateway validates the token before booking the transaction.
Before you start: enable VoP
VoP is switched on per instance. Before your first call in production, ask Paynetics Support (or your Account Manager) to enable VoP for your production instance. In sandbox, VoP is available for testing on request in the same way.
Authentication and base URL
Both endpoints sit behind the same Paynetics public v2 API Gateway you already use for /v2/transfer and other v2 calls. Use the same base URL, bearer token, and TLS configuration - no new credential is required for VoP.
Authorization: Bearer <access_token>
Content-Type: application/json
Step-by-step
Step | Call | What you do |
1 | POST /v2/vop | Call the VoP endpoint with the beneficiary IBAN and either account_holder_name (the name of a person or a business) or organisation_id (an LEI or VAT number, legal entities only). Each verification, including one that cannot be completed, returns a vop_token and a result. Apply the action defined in the Result code guidance section below. |
2 | POST /v2/transfer | Include the vop_token from Step 1 in the vop field of the transfer payload. The gateway validates the token, books the transaction, and links it to the verification record. |
Step 1 - Verify the Payee: POST /v2/vop
Before initiating a transfer, call the VoP endpoint to obtain a verification token.
Endpoint
POST /v2/vop
Request body
Field | Type | Required | Description | Example |
iban | string | Yes | IBAN of the beneficiary account being verified. | DE89370400440532013000 |
account_holder_name | string | Conditional | Account holder name, for a person or a business. Mutually exclusive with organisation_id - exactly one must be present. | John Doe |
organisation_id | string | Conditional | Legal entity identifier - either an LEI or a VAT number. Mutually exclusive with account_holder_name. Few banks support checks by identifier yet; for business payees we recommend sending the business name in account_holder_name instead. | 549300DTUYXVMJXZNY75 |
user_token | string | Optional | Token of the user initiating the verification. | 3a8d0a0b-...-d1b2 |
merchant_token | string | Optional | Token of the Merchant the verification is associated with. | 9bbf84f1-...-dcd1 |
Important: Exactly one of account_holder_name or organisation_id must be present. Sending both, or neither, returns error code 11001.
Example requests
Individual payee
POST /v2/vop
Content-Type: application/json
Authorization: Bearer <access_token>
{
"iban": "DE89370400440532013000",
"account_holder_name": "John Doe",
"user_token": "3a8d0a0b-7d7e-4d10-b2a4-2b7a3d1b2c11",
"merchant_token": "9bbf84f1-3e6a-4d01-9c8a-2a47b8c3dcd1"
}
Business payee, by name (recommended)
POST /v2/vop
Content-Type: application/json
Authorization: Bearer <access_token>
{
"iban": "FI2112345600000785",
"account_holder_name": "Example Company Oy"
}
Business payee, by organisation identifier
POST /v2/vop
Content-Type: application/json
Authorization: Bearer <access_token>
{
"iban": "FI2112345600000785",
"organisation_id": "549300DTUYXVMJXZNY75"
}
Successful response
HTTP 200 OK
{
"code": 0,
"data": {
"vop_token": "0ba5e81d-c43b-4008-b2d6-0d390f6f8c08",
"result": "MTCH",
"matched_name": "John Doe",
"timestamp": "2026-04-28T10:22:11.123Z"
}
}
Response fields
Field | Description |
data.vop_token | UUID identifying this VoP verification. Returned on every verification, including one that could not be completed (result ERROR). Not returned with validation errors (11001) or general service errors (11000). Pass this as the vop field when creating the transfer (Step 2). |
data.result | EPC VoP result code: MTCH (full match), CMTC (close match), NMTC (no match), NOAP (not applicable). ERROR when the verification could not be completed. |
data.matched_name | The name held by the beneficiary bank. Returned primarily on CMTC for payer confirmation. |
data.error_message | Returned only with result ERROR. Describes why the verification could not be completed, for example "VOP Responder Not Found". |
data.timestamp | Verification timestamp in ISO 8601 format with millisecond precision. |
Result code guidance
Code | Meaning | Action |
MTCH | Full match - name matches the account holder. | Proceed to transfer. |
CMTC | Close match - names are similar but not identical. | Display data.matched_name to the payer, who can correct the name or go ahead with the transfer. |
NMTC | No match - name does not match the IBAN holder. | Warn the payer that the funds might go to an account not held by the payee they entered. We recommend editing or cancelling; the payer may still proceed. |
NOAP | Not applicable - unable to verify. | Inform the payer that the recipient could not be verified. The payer may retry the check or proceed with the transfer. |
ERROR | The verification could not be completed, for example because the payee's bank is not reachable through the VoP scheme. | Handle as NOAP: inform the payer that the recipient could not be verified. The payer may retry the check or proceed with the transfer using the returned vop_token. |
Paynetics does not block a transfer based on the result. Any transfer with a valid vop_token is accepted. Whenever the payer chooses to proceed after CMTC, NMTC, NOAP or ERROR, inform them that authorising the transfer might send the funds to an account not held by the payee they entered. We recommend recording their choice.
Error responses
Code | Meaning |
11000 | General service error - retry after a short back-off. No vop_token is returned. |
11001 | Validation error - missing IBAN, both fields provided, or neither provided. No vop_token is returned. |
11008 | The verification could not be completed. The response still contains data.vop_token, with data.result ERROR and the reason in data.error_message. Handle as described for ERROR above. |
Example of a verification that could not be completed:
{
"code": 11008,
"data": {
"vop_token": "0ba5e81d-c43b-4008-b2d6-0d390f6f8c08",
"result": "ERROR",
"error_message": "Client error: ... resulted in a 404 Not Found response: {\"error\":\"VOP Responder Not Found: Unauthorised\"}"
}
}
Step 2 - Submit the Transfer: POST /v2/transfer
After a VoP verification, whatever its result, create the transfer and include the vop_token received in Step 1 as the vop field of the transfer payload.
Note: The /v2/transfer endpoint does not call the VoP service. It only validates the vop_token you supplied against the verification records created by your earlier /v2/vop call. You must obtain the token first.
Endpoint
POST /v2/transfer
Only the fields directly related to the VoP flow are documented here. Refer to the Transfer API documentation for the complete request schema.
VoP-related request fields
Field | Type | Required | Description |
vop | string (UUID) | Required for SCT and SCT Inst | The vop_token returned by POST /v2/vop in Step 1, whatever the result of the verification. |
Example request
POST /v2/transfer
Content-Type: application/json
Authorization: Bearer <access_token>
{
"amount": 1250.00,
"currency": "EUR",
"reference": "Invoice INV-2026-0411",
"isInstant": true,
"debtor": {
"iban": "BG80BNBG96611020345678",
"name": "Acme Trading EOOD"
},
"creditor": {
"iban": "DE89370400440532013000",
"name": "John Doe",
"bic": "COBADEFFXXX"
},
"vop": "0ba5e81d-c43b-4008-b2d6-0d390f6f8c08"
}
Validation behaviour
The API Gateway validates the supplied vop value against the verification records, then creates the transfer and stores the vop value on the transaction record. The verification result does not affect this: any valid vop value is accepted. The vop value is returned in subsequent transaction reads.
Successful response
HTTP 200 OK
{
"code": 0,
"data": {
"transaction": "f3a6d9b2-1c1f-4b6e-9a2d-2f7b5d8a91cc"
}
}
VoP-specific error
Code | Constant | When returned |
16021 | VOP_RESPONSE_FAILED | The vop value is missing, unknown or expired and could not be validated. The transfer is not created. Run a new verification and retry the transfer with the new token. |
{
"code": 16021,
"message": "services.balances.vop_response_failed"
}
Operational Notes
Latency
/v2/vop is a synchronous call to the VoP scheme. Typical end-to-end response time is below two seconds, but is bounded by the response time of the beneficiary bank. We recommend a client-side timeout of five seconds and a single retry on an 11000 service error.
Name handling and transliteration
Names returned by responder banks may include non-Latin scripts (most commonly Cyrillic). They are transliterated to Latin script before you receive them in matched_name, so no transliteration is needed on your side.
When sending account_holder_name, prefer the name exactly as it appears on the payer's records. Avoid pre-processing such as removing diacritics, expanding business suffixes (Ltd / Limited / EOOD), or reordering name parts - these reduce match quality and are more likely to produce CMTC rather than MTCH.
For business payees, send the business name in account_holder_name, the same way as for a person. There is no need to ask the payer whether the payee is a person or a business.
Service availability
If the beneficiary bank or the VoP scheme cannot be reached, the /v2/vop response returns either result NOAP or result ERROR with an error_message. In both cases a vop_token is included, and the payer may retry the check or proceed with the transfer - apply the action defined in the result code guidance above.
Integration Checklist
Use this checklist to verify your integration is complete before going live.
# | Step | Detail |
1 | Enable VoP for your instance | Ask Paynetics Support (or your Account Manager) to switch VoP on for your production instance before going live. |
2 | Call POST /v2/vop before every SEPA transfer | Always call before submitting. Include the beneficiary IBAN and either account_holder_name or organisation_id - never both. |
3 | Apply the action for the result code | Inspect data.result, including ERROR, and apply the action defined in the result code guidance before submitting the transfer. |
4 | Pass the token on transfer | Submit POST /v2/transfer with vop = data.vop_token, on every SEPA and SEPA Instant transfer. |
5 | Audit linkage | The vop value on the completed transaction links the booking back to the verification record. Retain it, together with the result shown and the payer's choice, for audit and dispute purposes. |
Frequently Asked Questions (FAQ)
Q: Can we skip VoP if the name is only slightly wrong?
A: No. Every transfer needs a check. On a close match (CMTC), show the payer the name held by the payee's bank, so they can correct the name or go ahead.
Q: Can we cache VoP results?
A: No. Every payment needs a fresh, real-time check.
Q: Do saved beneficiaries need a check too?
A: Yes. Beneficiaries saved or used before VoP are not exempt: every SEPA transfer needs its own check. We also recommend running a check when a beneficiary is saved, so mismatches are caught early.
Q: What if the service is unavailable?
A: The result is NOAP or ERROR, and a vop_token is still returned. Inform the payer that the recipient could not be verified. The payer may retry the check or proceed with the transfer.
Q: Do we need to collect an LEI, VAT number or other identifier for business payees?
A: No. The check uses the same fields for every payee, person or business: the name and the IBAN. For business payees, send the business name in account_holder_name, the same way as for a person. If the payer doesn't have the business name but has its LEI or VAT number, you can send that in organisation_id instead. This is an alternative option, not a requirement.
Q: Do we need to ask users whether the payee is a person or a business?
A: No. Send the name as the user entered it in account_holder_name, for people and businesses alike. A field label such as "Payee name" works better than "First and last name", so users enter a business name where needed.
Q: What happens if the name doesn't match?
A: Warn the user that the money might go to an account not held by the payee they entered, and let them edit the name or cancel; we recommend not proceeding. If the user still wants to send the money, they can. Paynetics doesn't block transfers based on the result, because the regulation doesn't allow VoP to stop the payer from authorising a transfer.
Q: Do we show the verified name?
A: Yes, on a close match (CMTC): you must show the name held by the payee's bank, in full, without masking or shortening it. For other results the bank doesn't return a name. You can also offer the user to update the saved beneficiary with the returned name.
Q: Why do checks to UK (GB) IBANs fail?
A: UK banks are not part of the SEPA VoP scheme, so the check returns ERROR ("VOP Responder Not Found"). This is expected. Inform the payer that the recipient could not be verified and ask them to double-check the beneficiary details. The payer may proceed with the returned vop_token.
Q: Can users bypass VoP?
A: No, the check is mandatory for all SEPA Credit Transfers (SCT) and SEPA Instant Credit Transfers (SCT Inst).
Q: Can we support VoP for personal accounts only?
A: No. VoP applies to every SEPA payee, including businesses and organisations.
Q: How do we get VoP enabled?
A: Ask Paynetics Support or your Account Manager to switch VoP on for your instance. Until it is enabled, calls to /v2/vop on that instance are not available.
Q: What is the deadline for the VoP availability?
A: Paynetics must comply by 1 January 2027, one year after Bulgaria adopted the euro. The service is already live, so partners can integrate now. It is not only a regulation, but a major safety improvement for our end clients.
Resources
· Regulation (EU) 2024/886 on instant payments
· EPC VoP Website
· EPC218-23 VoP Rulebook (v1.0)
· EPC VoP FAQ
· EPC Directory Service documentation
Support
If you encounter issues during integration or in production, contact the Paynetics Support team through your usual support channel. Please include:
· The endpoint involved (/v2/vop or /v2/transfer).
· The request timestamp and the affected vop_token or transaction ID.
· The full error response (code and message), with any Partner-side correlation IDs.