Ontwikkelaar 7 min leestijd

Verification of Payee-timeouts en retries afhandelen

Elke Verification of Payee-integratie ontmoet uiteindelijk een reagerende bank die traag of onbereikbaar is. Het verschil tussen een robuuste en een fragiele integratie is hoe ze de timeout afhandelt.

Door Verification of Payee EU · mogelijk gemaakt door RoxPay

Verification of Payee-timeouts en retries afhandelen

Kernpunten

  • Stel een zinvolle synchrone timeout in en behandel overschrijding als niet beschikbaar, niet als een harde fout.
  • Probeer opnieuw met backoff, maar alleen met idempotente verzoeken geïndexeerd op een stabiele identificator.
  • Definieer een duidelijk fallbackbeleid voor de betaler wanneer er niet op tijd een uitkomst kan worden verkregen.

De Verification of Payee hangt af van een extern antwoord van de bank van de begunstigde. Wanneer die bank traag, overbelast of tijdelijk onbereikbaar is, moet uw integratie beslissen wat te doen — en die beslissing raakt zowel de ervaring van de betaler als uw nalevingspositie. De ergste uitkomsten zijn een bevroren checkout of een verificatie die stilletjes dubbel wordt belast of geteld.

De niet-beschikbaar-uitkomst is een feature

Het schema definieert een niet-beschikbaar-resultaat juist zodat u geen foutsemantiek hoeft te verzinnen. Wanneer de reagerende kant niet op tijd kan antwoorden, behandel het dan als een eersteklas uitkomst in plaats van een uitzondering.

  • Stel een synchrone timeout in afgestemd op uw checkout-budget (vaak een paar seconden).
  • Bij overschrijding toont u de betaler een neutrale niet-beschikbaar-status in plaats van een angstaanjagende fout.
  • Beslis, per beleid, of de betaler door mag, moet wachten of naar beoordeling moet worden geleid.

Veilig opnieuw proberen

Retries helpen bij transiente fouten maar veroorzaken schade als ze niet idempotent zijn. Een retry mag nooit een tweede logische verificatie of een tweede afschrijving creëren.

  1. 1 Koppel een stabiele verzoekidentificator aan elke verificatiepoging.
  2. 2 Probeer transiente netwerkfouten opnieuw met exponentiële backoff en een kleine bovengrens.
  3. 3 Probeer nooit een definitieve uitkomst opnieuw (overeenkomst, gedeeltelijke overeenkomst, geen overeenkomst) — probeer alleen echte transportfouten opnieuw.
  4. 4 Reconcilieer elk laat antwoord met de verzoekidentificator zodat het maar één keer wordt geregistreerd.

Budgetteer de wachttijd, beslis dan

Kies een synchroon budget dat u kunt verdedigen bij zowel uw UX- als nalevingsteams. Voorbij dat budget wijkt u bewust uit — toon in afwachting of niet beschikbaar — in plaats van het verzoek te laten hangen en de betaler te laten afhaken.

RoxPay geeft de gestandaardiseerde uitkomsten terug inclusief niet beschikbaar, ondersteunt idempotente retries per verzoek-ID, en wijkt uit naar een webhook voor late antwoorden — zodat uw timeoutbeleid eenvoudig blijft.

FAQ

Veelgestelde vragen

Stem hem af op uw checkout-ervaring — vaak een paar seconden voor synchroon gebruik. Daarboven wijkt u uit naar een in-afwachting- of niet-beschikbaar-status in plaats van de betaler onbeperkt te blokkeren.

Alleen voor transportfouten, en alleen met idempotente verzoeken geïndexeerd op een stabiele identificator. Probeer nooit een definitieve overeenkomstuitkomst opnieuw; dat is een resultaat, geen fout.

Behandel het als een gedefinieerde uitkomst en pas uw beleid toe: de betaler met voorzichtigheid laten doorgaan, wachten op een asynchroon antwoord, of de betaling naar handmatige beoordeling leiden afhankelijk van het risico.

Maak de VoP betrouwbaar in productie

Praat met RoxPay over timeouts, idempotente retries en webhook-fallbacks op het SEPA-VoP-schema.