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

# VOP on pay-ins

> How Verification of Payee impacts pay-ins to Virtual Accounts

In a pay-in scenario, as a Responding PSP, Mangopay supplies the account holder name and IBAN to the Requesting PSP.

Verification of Payee affects all SCT and SCT Inst EUR payments made to Virtual Accounts and Banking Aliases.

<div className="block dark:hidden">
  ```mermaid theme={null}
  %%{
    init: {
      'theme': 'base',
      'themeVariables': {
        'mainBkg': '#FFFFFF',
        'primaryColor': '#FFFFFF',
        'primaryTextColor': '#2D0F37',
        'primaryBorderColor': '#2D0F37',
        'actorBorder': '#2D0F37',
        'lineColor': '#2D0F37',
        'secondaryColor': '#FFFFFF',
        'fontSize': '32px',
        'fontFamily': 'Inter',
        'noteBorderColor': "#E0DBE1",
        'noteBkgColor': "#E0DBE1",
        'noteTextColor': '#2D0F37'
      }
    }
  }%%
  sequenceDiagram
    actor Payer
    participant Requesting PSP
     participant Mangopay
    
      Payer ->> Requesting PSP: Request payment
      Requesting PSP->> Mangopay: Perform VOP check
      Mangopay -->> Requesting PSP: Provide VOP result

    rect rgba(245, 243, 245, 1)
      Requesting PSP -->> Payer: Display VOP result and <br/> handle confirmation
      Payer -->> Requesting PSP: Confirm payment
      Requesting PSP -->> Mangopay: Send payment <br/> (pay-in to vIBAN)
  				Note left of Requesting PSP: VOP result handling <br/> decided by Requesting PSP
    end
  ```
</div>

<div className="hidden dark:block">
  ```mermaid theme={null}
  %%{
    init: {
      'theme': 'base',
      'themeVariables': {
        'mainBkg': "#090D0D",
        'primaryColor': "#090D0D",
        'primaryTextColor': "#FFFFFF",
        'primaryBorderColor': "#FFFFFF",
        'actorBorder': "#FFFFFF",
        'lineColor': "#FFFFFF",
        'secondaryColor': "#090D0D",
        'fontSize': '32px',
        'fontFamily': 'Inter',
        'noteBorderColor': "#12282F",
        'noteBkgColor': "#090D0D",
        'noteTextColor': "#FFFFFF"
      }
    }
  }%%
  sequenceDiagram
    actor Payer
    participant Requesting PSP
    participant Mangopay
    
      Payer ->> Requesting PSP: Request payment
      Requesting PSP->> Mangopay: Perform VOP check
      Mangopay -->> Requesting PSP: Provide VOP result

    rect rgba(34, 37, 37, 1)
      Requesting PSP -->> Payer: Display VOP result and <br/> handle confirmation
      Payer -->> Requesting PSP: Confirm payment
      Requesting PSP -->> Mangopay: Send payment <br/> (pay-in to vIBAN)
  				Note left of Requesting PSP: VOP result handling <br/> decided by Requesting PSP
    end
  ```
</div>

On the pay-in side, the process is as follows:

1. The **Payer** initiates the payment to a virtual IBAN, providing the payee’s IBAN and account holder name to their bank.
2. The Payer’s bank, the **Requesting PSP**, performs the Verification of Payee check with Mangopay.
3. Mangopay, the **Responding PSP**, checks the name of the payee against the IBAN provided by the Requesting PSP, and responds with a result. The check result is not visible to the your platform in the Mangopay API.
4. The Requesting PSP displays the VOP result to the Payer in their banking app or other interface. The Requesting PSP has discretion over what it displays to the Payer and how it handles the result, wether payment is automatic or upon confirmation by the Payer, for example.

## VOP results

There are 4 possible outcomes of the VOP check:

<table>
  <thead>
    <tr>
      <th class="header">Result</th>
      <th class="header">Explanation</th>
      <th class="header">Impact</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td class="table-content">Match</td>
      <td class="table-content">The IBAN and account holder name correspond.</td>
      <td class="table-content">Payment made to this account will reach its intended counterparty.</td>
    </tr>

    <tr>
      <td class="table-content">Close Match</td>
      <td class="table-content">There are minor discrepancies (such as typos) between the name requested and the one registered.</td>
      <td class="table-content">Payment made to this account **may not** reach its intended counterparty.</td>
    </tr>

    <tr>
      <td class="table-content">No Match</td>
      <td class="table-content">The details do not match, indicating a possible error or fraudulent attempt.</td>
      <td class="table-content">Payment made to this account **may not** reach its intended counterparty.</td>
    </tr>

    <tr>
      <td class="table-content">Match Not Possible</td>
      <td class="table-content">A technical issue prevents verification from being carried out, such as formatting errors or the responding service being unreachable.</td>
      <td class="table-content">Payment made to this account **may not** reach its intended counterparty.</td>
    </tr>
  </tbody>
</table>

## Integration recommendations

#### 1. Ensure vIBAN data is passed correctly to the paying user

Ensure that the Payer can easily see and copy the relevant value in your platform’s interface:

* `AccountOwner` returned on [GET View a Virtual Account](/api-reference/virtual-accounts/view-virtual-account#param-account-owner)
* `OwnerName` returned on [GET View a Banking Alias](/api-reference/banking-aliases/view-banking-alias#param-owner-name)

This data point is the account holder name against which the VOP check is performed.

Your platform should systematically perform a GET call to retrieve and display this data before inviting the user to make the payment.

#### 2. Integrate the Virtual Account endpoints

If your platforms is using the [Banking Alias](/api-reference/banking-aliases/banking-alias-object) endpoints, plan to re-integrate using the the [Virtual Accounts](/api-reference/virtual-accounts/virtual-account-object) endpoints for greater control over the naming pattern, as well as all future feature developments.

<Note>
  **Note – User-Owned Accounts requires contract amendment**

  If your platform is offering User-Owned Accounts via the Banking Alias endpoints, you need to sign the VOP contract amendment to continue offering these accounts via the Virtual Account endpoints.
</Note>

The Banking Alias endpoints will be decommissioned in Q3 2026.

Banking Alias objects are available via the [GET View a Virtual Account](/api-reference/virtual-accounts/view-virtual-account) endpoint, by using the Banking Alias `Id` and its `WalletId` as the path parameters.

This means your platform can already integrate the GET to retrieve the account data of Banking Alias objects.

#### 3. Ensure direct bank wire pay-in data is correctly passed to the payer user

If your platform is using the Bank Wire PayIn endpoint, ensure Payers are provided the `BankAccount.OwnerName` returned in the response of [POST Create a Bank Wire PayIn](/api-reference/bank-wire-payins/create-bank-wire-payin).

Note that for direct bank wire pay-ins, Mangopay is not the responding PSP – that role is played by its partners.

## Banking Alias categorization

The legacy Banking Alias object (replaced by Virtual Accounts) did not allow for accounts to be categorized between **Collection** and **User-Owned**. VOP makes this categorization necessary because Mangopay must provide the correct account holder name data to the Requesting PSP.

The `VirtualAccountPurpose` field was added to the Banking Alias object to enable categorization to be performed automatically by Mangopay, based on the logic below.

The categorization applies to all Banking Alias objects, including those with the `Country` value `GB`.

### Criteria for Banking Alias categorization

#### User-Owned case

**IF** the User owning the Banking Alias object’s `WalletId` has:

* The `UserCategory` of `OWNER` or `PLATFORM`
* **AND** the `KYCLevel` of `REGULAR`

**THEN**:

* The `USER_OWNED` value is assigned for `VirtualAccountPurpose`
* **AND** the account’s `OwnerName` will be defined as the `FirstName` and `LastName` for a Natural User or `Name` for a Legal User

<Note>
  **Note – Payouts from User-Owned Account holders may be blocked**

  [Read more](/guides/vop/recipients-payouts) about how payouts made by User-Owned Account holders are impacted by Verification of Payee.
</Note>

#### Collection case

**IF** the User owning the Banking Alias object’s `WalletId` has:

* The `UserCategory` of `PAYER`
* **OR** the `KYCLevel` of `LIGHT`

**THEN**:

* The `COLLECTION` value is assigned for `VirtualAccountPurpose`
* **AND** the account’s `OwnerName` is changed to “MGP `PlatformTradingName`”

### Example categorization

<table>
  <thead>
    <tr>
      <th class="header">Account `OwnerName` before categorization</th>
      <th class="header">User's `UserCategory`</th>
      <th class="header">User's `KYCLevel`</th>
      <th class="header">Account `OwnerName` after categorization</th>
      <th class="header">`VirtualAccountPurpose` after categorization</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td class="table-content">John Doe</td>
      <td class="table-content">`PAYER`</td>
      <td class="table-content">`LIGHT`</td>
      <td class="table-content">MGP `PlatformTradingName`</td>
      <td class="table-content">`COLLECTION`</td>
    </tr>

    <tr>
      <td class="table-content">John Doe</td>
      <td class="table-content">`OWNER`</td>
      <td class="table-content">`LIGHT`</td>
      <td class="table-content">MGP `PlatformTradingName`</td>
      <td class="table-content">`COLLECTION`</td>
    </tr>

    <tr>
      <td class="table-content">John Doe</td>
      <td class="table-content">`PAYER`</td>
      <td class="table-content">`REGULAR`</td>
      <td class="table-content">MGP `PlatformTradingName`</td>
      <td class="table-content">`COLLECTION`</td>
    </tr>

    <tr>
      <td class="table-content">John Doe</td>
      <td class="table-content">`OWNER`</td>
      <td class="table-content">`REGULAR`</td>
      <td class="table-content">John Doe</td>
      <td class="table-content">`USER_OWNED`</td>
    </tr>
  </tbody>
</table>

### One-time categorization for existing accounts

In September 2025, Mangopay categorized existing Banking Aliases by setting the `VirtualAccountPurpose` value to either `COLLECTION` or `USER_OWNED`.

In some cases, the `OwnerName` value was changed to rename the account holder correctly, as described above.

The one-time categorization was final and cannot be changed. This means that the `VirtualAccountPurpose` cannot subsequently be updated if the user becomes KYC verified, for example – a new wallet and virtual account needs to be created.

### Ongoing categorization for new accounts

Mangopay categorizes newly created Banking Alias objects according to the logic above.

Platforms using the [POST Create a Banking Alias](/api-reference/banking-aliases/create-iban-banking-alias) endpoint should take this into account:

* The `OwnerName` property is still required but ignored and set automatically by Mangopay. Platforms use the `OwnerName` provided in the response or retrieve it systematically via the [GET View a Banking Alias](/api-reference/banking-aliases/view-banking-alias) endpoint.
* The `VirtualAccountPurpose` is set automatically by Mangopay on creation.

<Check>
  **Best practice – Integrate Virtual Account endpoints**

  If your platform is still using the [Banking Alias](/api-reference/banking-aliases/banking-alias-object) endpoints for vIBANs, you are strongly recommended to re-integrate using the [Virtual Accounts](/api-reference/virtual-accounts/virtual-account-object) endpoints (see the [guide](/guides/payment-methods/banking/virtual-iban) for more).

  Note that offering User-Owned Accounts via the Virtual Account endpoints requires your platform to sign the VOP contract amendment.

  The Banking Alias endpoints will be decommissioned in Q3 2026.
</Check>