This section provides implementation examples of how VoP responses from the Initiate Payment API can be presented to the BaaS Client, from the perspective of BaaS Partner front-end.
Case: matchType: "MTCH"
When the Initiate Payment API response contains "matchType": "MTCH", the BaaS Partner’s front-end must consume this value and display a clear message to the BaaS Client indicating that the provided payee name matches exactly with the account holder’s name.
This reassures the sender (BaaS Client) that the payment is being made to the intended recipient.
Example – website:
Verification of payee: match
Example – mobile app:
Verification of payee: match
Case: matchType: "NMTC"
When the Initiate Payment API response contains "matchType": "NMTC", the BaaS Partner’s front-end must consume this value and inform the BaaS Client that the provided name does not match the account holder’s name. However, the payment can still be processed.
In this scenario, the front-end must clearly communicate to the sender (BaaS Client) that it is their decision whether to proceed with or cancel the payment. The VoP response of “No Match” should be presented clearly, along with the implications.
The BaaS Partner must also inform the client that if they choose to proceed and authorize the payment despite the mismatch, the transaction will not be eligible for a refund in the event of fraud.
Example – website:
Verification of payee: no match
Example – mobile app:
Verification of payee: no match
Case: matchType: "CMTC" with matchedName: "<suggested name>"
When the Initiate Payment API response contains "matchType": "CMTC", ConnectPay will always return a matchedName value. This value represents a closely matching name found at the recipient’s financial institution — typically differing due to minor issues like typos, formatting, or spelling variations.
In this scenario, the BaaS Partner’s front-end must consume both matchType: "CMTC" and the corresponding matchedName and inform the BaaS Client that a near match was found. We urge to highlight the suggested name (matchedName) to the user, and allow the BaaS Client to easily update the beneficiary name using the app/web interface before authorization of the payment.
Example – website:
Verification of payee: close match
Example – mobile app:
Verification of payee: close match
Case: matchType: "NOAP"
When the Initiate Payment API response contains "matchType": "NOAP", the BaaS Partner’s front-end must consume this value and inform the BaaS Client that VoP is not possible due to technical issues, unsupported IBAN, system unavailability, etc.
In this scenario, the front-end must clearly communicate to the sender (BaaS Client) that it is their decision whether to proceed with or cancel the payment.
Example – website:
Verification of payee: not possible
Example – mobile app:
Verification of payee: not possible
Case: payeeVerification: null
When the response from the Initiate Payment API contains payeeVerification: null, it indicates that the paymentRail value is not SEPA_SCT or SEPA_SCT_INST.
In this scenario, VoP is not applicable, therefore, no VoP response should be shown to the BaaS client via the platform’s front-end.
No changes are required in your front-end channels for case: payeeVerification: null