Verification of Payee is afhankelijk van een antwoord van de bank van de begunstigde. Wanneer die bank traag, overbelast of tijdelijk onbereikbaar is, moet uw integratie beslissen wat er gebeurt — en die beslissing raakt zowel de ervaring van de betaler als uw compliancepositie. De slechtste uitkomsten zijn een vastgelopen checkout of een verificatie die stilletjes dubbel wordt geteld of in rekening gebracht.
De uitkomst 'niet beschikbaar' is een functie
Het schema definieert een niet-beschikbaar-resultaat juist zodat u geen eigen foutsemantiek hoeft te verzinnen. Wanneer de reagerende partij niet op tijd kan antwoorden, behandel dit dan als een volwaardige uitkomst en niet als een uitzondering.
- Stel een synchrone timeout in die aansluit bij uw checkoutbudget (vaak een paar seconden).
- Toon bij overschrijding een neutrale 'niet beschikbaar'-status aan de betaler in plaats van een verontrustende foutmelding.
- Bepaal via beleid of de betaler mag doorgaan, moet wachten, of naar handmatige beoordeling moet worden doorgestuurd.
Veilig opnieuw proberen
Retries helpen bij tijdelijke storingen, maar richten schade aan als ze niet idempotent zijn. Een retry mag nooit een tweede logische verificatie of een tweede afschrijving veroorzaken.
- 1 Koppel een stabiele verzoekidentificator aan elke verificatiepoging.
- 2 Probeer tijdelijke netwerkfouten opnieuw met exponentiële backoff en een klein maximum aantal pogingen.
- 3 Probeer nooit een definitief resultaat opnieuw (Overeenkomst, Bijna overeenkomst, Geen overeenkomst) — probeer alleen echte transportfouten opnieuw.
- 4 Koppel een laat binnenkomend antwoord aan de verzoekidentificator, zodat het maar één keer wordt geregistreerd.
Begroot de wachttijd, beslis dan
Kies een synchroon tijdsbudget dat u kunt verantwoorden tegenover zowel uw UX- als uw compliance-team. Val na dat budget bewust terug — toon 'in behandeling' of 'niet beschikbaar' — in plaats van het verzoek te laten hangen totdat de betaler afhaakt.
RoxPay geeft de gestandaardiseerde uitkomsten terug, inclusief niet beschikbaar, ondersteunt idempotente retries op basis van request-ID en valt terug op een webhook voor late antwoorden — zodat uw timeoutbeleid eenvoudig blijft.