What is Confirmation of Payee testing?

Confirmation of Payee testing verifies that a payment journey sends the intended payee details to a name-checking service and handles its response correctly before the customer proceeds. In the UK context, Confirmation of Payee (CoP) checks whether the entered account name corresponds with the account details supplied, such as a sort code and account number. Testing covers the customer experience, service integration and the resulting payment decision.

What Confirmation of Payee testing covers

A typical flow starts when a customer enters a payee's details. The sending bank or payment service provider submits a check request, receives a response from the CoP service or provider, and presents the result to the customer. Response categories commonly include a match, a close match, no match or an inability to check. Exact labels, fields and handling depend on the integration.

Testing should verify the request fields and their mapping, the response parsing, and the message shown to the customer. For a close match, check that any suggested name is displayed according to the product's rules. For a no-match or unavailable response, verify the configured warning or next step. Confirm that the customer can make an informed choice and that the payment is not submitted before the intended confirmation point.

CoP checks account-name details. It does not establish that a payee is trustworthy, that an invoice is genuine, or that funds will reach the intended person. Payment authorisation, fraud controls and payment execution require their own checks.

Integration and failure scenarios

CoP testing is a form of integration testing in banking when it verifies communication between a payment journey and the checking service. Banking API contract testing can check request and response structure, required fields, status codes and handling of schema changes. End-to-end checks can then confirm that a response leads to the correct customer-facing outcome.

Exercise service timeouts, unavailable responses, malformed or incomplete data, and unexpected response codes. Verify that retries do not create duplicate checks or submit a payment twice. Check what happens if the customer changes the payee details after a result has been returned: the previous result must not be applied to the changed details. Where the service is asynchronous, test correlation identifiers and ensure a response is associated with the correct request.

Test data should cover the account types and name formats supported by the product, including individual and business names where applicable. Use controlled sandbox accounts or approved synthetic data. Avoid using real customer details in lower environments unless an approved data protection process permits it. Record the request, response and displayed outcome in test evidence, with sensitive values masked where appropriate. See Banking test data management for related data controls.

Practical test case

Use a sandbox account configured to return a close match.

• Enter the account's sort code, account number and a slightly different payee name.
• Submit the check and confirm the application sends the expected values once.
• Verify that the close-match response is mapped to the correct message and any permitted suggested name.
• Continue using the product's expected customer confirmation step, then check that the payment is created once with the selected payee details.
• Change the account number and repeat the check. Confirm that the earlier result is discarded and a new check is made.

This case checks both the service response and its effect on the payment journey. Repeat with match, no-match and unavailable outcomes, then add boundary cases for blank, overlong or unsupported name input according to the product's validation rules.