What is Verification of Payee testing?

Verification of Payee (VoP) testing checks whether a payment system compares the payee name supplied by a payer with the name associated with the destination account before a payment is authorised. It verifies the matching response, the customer choices presented and the resulting payment behaviour, including cases where the service cannot return a reliable result.

What Verification of Payee testing covers

A VoP flow commonly sends a payee name and an International Bank Account Number (IBAN), or equivalent account identifier, to a verification service. The service returns a result for the combination. Depending on the scheme and the institution's implementation, results may include a match, a close match, a no match or an inability to verify. The response labels and available actions should come from the applicable interface specification and business rules.

Testing checks that the payment application handles each response correctly. For example, it should display a clear message for a close match, show any suggested name only where the service permits it, and apply the configured rules before allowing the customer to proceed. The payment should be linked to the account details that were actually checked. If the customer edits the name or account identifier, the system should request a fresh verification where required by the design.

VoP is a name-and-account matching check. A match does not establish that the payee is trustworthy, that the account is free of restrictions, or that the payment will settle. It should not be treated as a replacement for fraud controls or payment validation.

How to test the flow

Start with the service contract and the bank's business rules. Confirm the request fields, response codes, timeout behaviour, retry policy, permitted customer actions and audit requirements. The test environment also needs controlled account data and a verification-service test double or suitable sandbox. Without known test data, a result can be difficult to reproduce, and environment drift can make an expected match appear inconsistent.

Cover positive cases, such as an exact name match, and negative cases, such as a valid account identifier paired with a clearly different name. Include close matches, unavailable responses, malformed requests, service timeouts and responses with missing or unexpected fields. Check name handling rules that are relevant to the product, such as spacing, punctuation, character sets and business account names. Use approved synthetic or otherwise controlled data rather than real customer details.

Assertions should cover more than the message shown on screen. Verify the request sent to the verification service, the response mapped by the payment application, the customer decision recorded, and the state of the payment instruction. Check that an unsuccessful or timed-out check follows the configured policy and does not create an unintended duplicate request or payment. Where relevant, test the flow across channels and confirm that the same checked payee details reach the payment processing system.

Worked example

Assume a customer enters the name "Northfield Supplies Ltd" and an account identifier for a test beneficiary. The service returns a close match with a suggested name. A functional test can assert that:

• The application displays the close-match result and the permitted suggestion accurately.
• The customer can choose an allowed action, such as accepting the suggestion or stopping the payment.
• The recorded decision corresponds to the details shown to the customer.
• If the customer changes the beneficiary details, the system does not reuse a verification result for the old details.
• The payment instruction is created only in accordance with the customer's action and the configured rules.

For a negative test, send a valid account identifier with an unrelated payee name. Confirm that the application displays the configured no-match outcome and follows the specified continuation or cancellation path. A passing test should demonstrate the complete state change, not just the correct warning text.

Verification of Payee and Confirmation of Payee

Verification of Payee and Confirmation of Payee (CoP) describe closely related name-checking services used in payment journeys. Their exact response categories, interfaces and customer actions can differ by scheme or market. Test teams should use the terminology and rules in the system under test rather than assume that one implementation's behaviour applies everywhere.