Verification of Payee: match, close match and no match
Verification of Payee (VoP) checks supplied recipient details against the receiving payment provider’s records before a transfer. A match helps confirm those details; a close match or no match needs attention. None of these results proves that a payment settled or that a purchase is legitimate.
Scope: A plain-language and integration reference based on the EPC’s VoP scheme. Your provider’s supported workflow governs exact behavior. ZILLQ demonstrates recipient-check mechanics with synthetic data; this is not a live IBAN verification service.
What do the results mean?
| Result | Meaning | Useful next step |
|---|---|---|
| Match | The receiving provider reports a match for the submitted details. | Keep the checked details tied to the payment. The user still needs to review the intended purchase. |
| Close match | The name is close to the receiving provider’s record, with a name returned for review under the scheme. | Show the discrepancy clearly and follow the provider’s review and confirmation flow. |
| No match | The checked recipient details do not match. | Review and verify the intended recipient through a trusted channel before deciding what to do next. |
| Verification not possible | The check could not establish a matching result. | Display the uncertainty. Do not silently translate it into a match or a successful payment. |
The EPC’s Verification of Payee overview explains the request between the payer’s and payee’s providers and the response passed back to the payer. Use its scheme documents and your provider’s integration contract for the exact result fields and permitted actions.
IBAN validation, VoP and settlement are different
An IBAN format check can catch structural errors such as incorrect length or check digits. It does not establish that the account exists, belongs to the intended recipient or has been credited. A VoP request checks a different fact: recipient details held by the receiving provider.
Payment initiation then submits the transfer instruction. Later evidence tells you what happened to that instruction. Keep these observations separate in the interface and in logs. A green recipient-check badge should not become a green “paid” badge.
The IBAN glossary entry and pending-payment guide connect these steps. For the transfer scheme context, see the EPC’s SCT overview.
What if the recipient changes after the check?
Synthetic example: an operator checks the name and account for Supplier A. A later invoice message replaces the destination with Supplier B’s account. The earlier result describes Supplier A’s details. It must not be displayed as evidence that the new destination was checked.
Bind the displayed result to the submitted recipient details and the relevant request. If those details change, handle rechecking and approval through the provider’s supported workflow. Preserve enough context to explain which details were checked and which payment was eventually submitted.
For an AI purchasing agent, this connects directly to the approved-payee boundary. A merchant label is not the authoritative payment destination. The recipient-substitution test case makes that boundary explicit without assuming a particular VoP API.
Useful cases for a product or integration review
- Try the provider’s synthetic fixtures for match, close match, no match and unavailable outcomes.
- Confirm that a close-match response is understandable on a small screen and during a device handoff.
- Change the name or destination after the check and inspect what happens to the earlier result.
- Repeat a check and verify that the visible result belongs to the latest relevant request.
- Interrupt the flow and check that the user can distinguish recipient verification from payment submission.
- Follow a successfully checked payment into its status and account evidence.
A review record should identify the input fixture, provider or emulator, request reference, result and subsequent action. Record actual outcomes as observed, not assumed. Use the payment API testing checklist for the rest of the flow.
Explore recipient checks in the portal
Open ZILLQ’s Payments area using the shared demo-access instructions on the homepage. Use the supplied synthetic account and payee details, inspect the recipient check, and follow the submitted payment into its recorded result.
The portal is a learning and evaluation environment, not a way to verify real customer bank accounts. It gives developers, product teams and payment operations a common place to examine the journey and form better questions about a production integration.
If the wider question is how software can pay on someone’s behalf, continue to agentic payments explained. Recipient checks are one part of that system; consent, bounded authority and outcome evidence remain necessary parts of the design.
Bring the question into ZILLQ.
The public portal connects payment consent, synthetic transfers, recipient checks and recorded outcomes. The platform also includes agent mandate mechanisms and EUDI wallet emulation. Use synthetic data and inspect what the current build actually supports.
Try a synthetic payment → · Explore the platform · Investor and partner brief