Skip to main content
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.
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:
ResultExplanationImpact
MatchThe IBAN and account holder name correspond.Payment made to this account will reach its intended counterparty.
Close MatchThere are minor discrepancies (such as typos) between the name requested and the one registered.Payment made to this account may not reach its intended counterparty.
No MatchThe details do not match, indicating a possible error or fraudulent attempt.Payment made to this account may not reach its intended counterparty.
Match Not PossibleA technical issue prevents verification from being carried out, such as formatting errors or the responding service being unreachable.Payment made to this account may not reach its intended counterparty.

​
Integration recommendations

  1. Ensure that the Payer can easily see and copy the relevant value in your platform’s interface:
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.
  1. If your platforms is using the Banking Alias endpoints, plan to re-integrate using the the Virtual Accounts endpoints for greater control over the naming pattern, as well as all future feature developments.
The Banking Alias endpoints will be deprecated in Q3 2026. Banking Alias objects are available via the GET View a 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.
  1. 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. 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 has been added to the Banking Alias object to enable categorization. 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 – Payouts from User-Owned Account holders may be blockedRead more about how payouts made by User-Owned Account holders are impacted by Verification of Payee.

​
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

Account OwnerName before categorizationUser’s UserCategoryUser’s KYCLevelAccount OwnerName after categorizationVirtualAccountPurpose after categorization
John DoePAYERLIGHTMGP PlatformTradingNameCOLLECTION
John DoeOWNERLIGHTMGP PlatformTradingNameCOLLECTION
John DoePAYERREGULARMGP PlatformTradingNameCOLLECTION
John DoeOWNERREGULARJohn DoeUSER_OWNED

​
One-time categorization for existing accounts

Starting Monday, September 15, 2025, Mangopay will categorize existing and newly created Banking Aliases by setting the VirtualAccountPurpose value to either COLLECTION or USER_OWNED. In some cases, the OwnerName value will be changed to rename the account holder correctly, as described above. Once the one-time categorization is performed, it is final and cannot be changed. This means that the VirtualAccountPurpose will not subsequently be changed if the user becomes KYC verified, for example; a new wallet and virtual account would need to be created in future.

​
Ongoing categorization for new accounts

The categorization will also apply to newly created Banking Alias objects. Platforms using the POST Create a 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 endpoint.
  • The VirtualAccountPurpose is set automatically by Mangopay on creation.
⌘I