Most VoP integration guides stop at 'send a name and IBAN, read the outcome'. Production adds two problems: networks fail and clients retry, and finance later asks 'which payment did this verification belong to?'. A single field — a stable external id per request — solves both.
Idempotency on retries
If a request times out, your client may retry it. Without an idempotency key, that's a second verification — extra cost and confusing logs. Attaching the same external id to the retry lets the system recognise it as the same logical request, so retries are safe.
One id, generated once
Generate the external id when you create the payment intent, not per HTTP attempt. That way every retry of the same logical verification carries the same id.
Reconciliation
The same external id is your correlation key. Store it on your payment record, send it with the verification, and you can later join the verification result back to the exact payment — essential for disputes, audits and analytics.
Build the audit trail
- 1 Generate an external id per verification and persist it with your payment.
- 2 Send it on the request; reuse it on any retry.
- 3 Log the returned verification id, outcome and responding BIC against it.
RoxPay's Verification of Payee API accepts an external id per request and returns its own verification id with the responding BIC, so idempotency and reconciliation fall out of one clean pattern.