Verification of Payee depends on a remote answer from the payee's bank. When that bank is slow, overloaded or temporarily unreachable, your integration has to decide what to do — and that decision affects both the payer's experience and your compliance position. The worst outcomes are a frozen checkout or a verification that quietly gets charged or counted twice.
The not-available outcome is a feature
The scheme defines a not-available result precisely so you do not have to invent error semantics. When the responding side cannot answer in time, treat it as a first-class outcome rather than an exception.
- Set a synchronous timeout aligned to your checkout budget (often a couple of seconds).
- On overshoot, surface a neutral not-available state to the payer rather than a scary error.
- Decide, by policy, whether the payer may proceed, must wait, or should be routed for review.
Retrying safely
Retries help with transient faults but cause damage if they are not idempotent. A retry must never create a second logical verification or a second charge.
- 1 Attach a stable request identifier to each verification attempt.
- 2 Retry transient network errors with exponential backoff and a small cap.
- 3 Never retry a definitive outcome (match, close match, no match) — only retry true transport failures.
- 4 Reconcile any late answer against the request identifier so it is recorded once.
Budget the wait, then decide
Pick a synchronous budget you can defend to both your UX and compliance teams. Past that budget, fall back deliberately — show pending or not-available — instead of letting the request hang and the payer abandon.
RoxPay returns the standardised outcomes including not-available, supports idempotent retries by request ID, and falls back to a webhook for late answers — so your timeout policy stays simple.