---
title: "Execute VoP Checks"
slug: "verificationofpayeevoppartnerguidedoc"
updated: 2026-07-09T15:09:34Z
published: 2026-07-09T15:09:34Z
canonical: "www.documentation.paynetics.digital/verificationofpayeevoppartnerguidedoc"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://www.documentation.paynetics.digital/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](https://developers.paynetics.digital/#vopDetails)

### 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. 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.

### 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.

```plaintext
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` (for individuals) or `organisation_id` (for legal entities). The gateway returns a `vop_token` and an EPC result code. 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

```plaintext
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 | Individual account holder name. 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`. | `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**

```plaintext
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"
}
```

**Organisation payee**

```plaintext
POST /v2/vop
Content-Type: application/json
Authorization: Bearer <access_token>
{
  "iban": "FI2112345600000785",
  "organisation_id": "549300DTUYXVMJXZNY75"
}
```

### Successful response

```plaintext
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. 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). |
| `data.matched_name` | The name held by the beneficiary bank. Returned primarily on CMTC for payer confirmation. |
| `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 and obtain explicit confirmation before submitting the transfer. |
| `NMTC` | No match — name does not match the IBAN holder. | Warn the payer and obtain explicit confirmation before submitting the transfer. |
| `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 responses

| Code | Meaning |
| --- | --- |
| `11000` | General service error — retry after a short back-off. |
| `11001` | Validation error — missing IBAN, both fields provided, or neither provided. |

## Step 2 — Submit the Transfer: POST /v2/transfer

After a successful VoP verification, 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

```plaintext
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. |

### Example request

```plaintext
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 `vop` value is returned in subsequent transaction reads.

### Successful response

```plaintext
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 could not be validated. The transfer is not created. |

```plaintext
{
  "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). Paynetics transliterates returned names to Latin using ISO 9 / BGN/PCGN standards before delivering them in `matched_name`.

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`.

### Service availability

If the beneficiary bank or the VoP scheme cannot be reached, the `/v2/vop` response is returned with result `NOAP`. The payer may retry the check or proceed with the transfer — apply the NOAP 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 | 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. |
| 2 | Apply the action for the result code | Inspect `data.result` and apply the action defined in the result code guidance before submitting the transfer. |
| 3 | Pass the token on transfer | Submit `POST /v2/transfer` with `vop = data.vop_token`. |
| 4 | Audit linkage | The `vop` value on the completed transaction links the booking back to the verification record. Retain it for audit and dispute purposes. |

### Frequently Asked Questions (FAQ)

**Q: Can we skip VoP if the name is only slightly wrong?** A: No. **CMTC** (Close Match) requires user confirmation or correction.

**Q: Can we cache VoP results?** A: No. VoP results must be fresh and real-time for every payment.

**Q: What if the service is unavailable?** A: A NOAP (Unable to verify) result will be returned. Inform the payer that the recipient could not be verified. The payer may retry the check or proceed with the transfer.

**Q: Can we use LEI or VAT instead of a name?** A: Yes, for legal entities only — check EPC Directory Service (EDS) if supported.

**Q:** **What happens if name doesn't match?** A: You must give the user the option to “Edit” or “Cancel” the operation.

**Q: Do we show the verified name?** A: You are obliged to show it only in the **CMTC** case.

**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: What is the deadline for the VoP availability?** A: Hard deadline is **Jan 1st 2027** due to Bulgaria not being part of EU zone right now. It is not only a regulation, but a major safety improvement for our end clients.

### Resources

- [Regulation (EU) 2024/886 on instant payments](https://op.europa.eu/en/publication-detail/-/publication/d395dbf7-e597-11ee-8b2b-01aa75ed71a1/)
- [EPC VoP Website](https://www.europeanpaymentscouncil.eu/what-we-do/other-schemes/verification-payee)
- [EPC218-23 VoP Rulebook (v1.0)](https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-10/EPC218-23%20v1.0%202024%20Verification%20Of%20Payee%20Scheme%20Rulebook_0.pdf)
- [EPC VoP FAQ](https://www.europeanpaymentscouncil.eu/what-we-do/other-schemes/verification-payee/questions-answers-verification-payee-scheme)
- [EPC Directory Service documentation](https://www.europeanpaymentscouncil.eu/what-we-do/other-epc-activities/epc-directory-service)

## 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.

Single Euro Payments Area. A European payment integration initiative that enables euro-denominated credit transfers and direct debits across 36 member countries under unified standards and processing rules.

International Bank Account Number. A standardised international format for identifying a bank account. In the Paynetics platform, IBANs are assigned at the Balance level, allowing accounts with multiple balances to have separate IBANs per currency.

Payment Service Provider. A company licensed to provide payment services including card processing, account management, and money transfers. Paynetics operates as a PSP under PSD2 in the EU and the Payment Services Regulations in the UK.

A payment scheme that verifies that the name provided by the payer matches the registered account name before a credit transfer is executed. VoP is designed to reduce misdirected payments and fraud in account-to-account transfers.

An **Account** is a payment or e-money account used to hold funds and execute transactions.

Accounts are created under a specific instance and program and are associated with either a user or a merchant. They provide the logical structure under which balances, cards, and transactions are organised.

Common account purposes include:

- executing card payments and transfers
- holding settlement funds
- pre-funding services such as OCT

An account acts as a container for balances rather than holding funds directly.

**Tokens** are unique identifiers used throughout the Paynetics platform to securely reference objects.

Tokens exist for instances, programs, accounts, balances, cards, merchants, and transactions. They are mandatory in API calls and ensure secure identification without exposing sensitive data, accurate routing of operations, and consistent handling across services.

For example, a balance token specifies which funds are debited or credited, a card token identifies the card used in a transaction, and a merchant token links activity to a specific merchant.

A **Merchant** represents a business entity that accepts payments or uses acquiring-related services.

Merchants are created within an instance and can be associated with one or more accounts, including funding and settlement accounts. Merchant configuration is subject to underwriting and card scheme approvals, depending on the services enabled.

Merchants become operational through **merchant onboarding**, once the relevant application has been approved.

A **Partner** is the entity that integrates Paynetics’ services and offers them to end customers.

Partners operate within their own instance and manage users, merchants, applications, and programs. They define fees, user flows, and configurations within the limits of their contractual agreement and may be responsible for KYC or KYB processing.

The partner is the primary integrator and owner of the end-to-end solution built on Paynetics.