A Verification of Payee request usually returns a match outcome in real time, fast enough to show before the payer authorises a transfer. But VoP is a network call to another bank, and networks are not perfectly reliable. A responding PSP can be slow, a connection can drop, or a request can land in a queue. A production-grade integration needs a plan for the answer that arrives a few seconds — or a few minutes — late.
Why a VoP call can become asynchronous
The scheme defines a tight response window, but real traffic still produces edge cases you must handle gracefully rather than treat as hard errors:
- The responding PSP is temporarily overloaded and answers just outside your synchronous timeout.
- A transient network fault triggers a retry that completes after your initial request returned.
- You batch-submit many checks (for example a payment run) and collect results as they come back.
Designing the webhook flow
The cleanest pattern is to give every check a stable identifier, return a pending status when the synchronous window expires, and let a webhook deliver the final outcome.
- 1 Submit the verification and store its request ID against the payment you are about to make.
- 2 If no answer arrives within your synchronous budget, show the payer a pending state instead of an error.
- 3 Receive the final match, close match, no match or not-available outcome on your webhook endpoint.
- 4 Match the webhook payload back to the stored request ID and update the payment decision.
Secure and idempotent by default
Verify the signature on every webhook before trusting it, and make your handler idempotent: the same outcome may be delivered more than once. Key your processing on the request ID so a duplicate delivery never double-acts on a payment.
RoxPay returns a synchronous result whenever it can and falls back to a signed webhook when a responding PSP is slow, so your checkout stays responsive and your records stay complete.