Die Verification of Payee hängt von einer entfernten Antwort der Bank des Empfängers ab. Wenn diese Bank langsam, überlastet oder vorübergehend unerreichbar ist, muss Ihre Integration entscheiden, was zu tun ist — und diese Entscheidung betrifft sowohl das Erlebnis des Zahlers als auch Ihre Compliance-Position. Die schlimmsten Ergebnisse sind ein eingefrorener Checkout oder eine Verifizierung, die heimlich doppelt belastet oder gezählt wird.
Das Nicht-verfügbar-Ergebnis ist ein Feature
Das Schema definiert ein Nicht-verfügbar-Ergebnis genau dafür, dass Sie keine Fehlersemantik erfinden müssen. Wenn die antwortende Seite nicht rechtzeitig antworten kann, behandeln Sie es als erstklassiges Ergebnis statt als Ausnahme.
- Setzen Sie einen synchronen Timeout, der auf Ihr Checkout-Budget abgestimmt ist (oft ein paar Sekunden).
- Bei Überschreitung zeigen Sie dem Zahler einen neutralen Nicht-verfügbar-Zustand statt eines beängstigenden Fehlers.
- Entscheiden Sie per Richtlinie, ob der Zahler fortfahren darf, warten muss oder zur Prüfung geleitet werden soll.
Sicher wiederholen
Retries helfen bei transienten Fehlern, richten aber Schaden an, wenn sie nicht idempotent sind. Ein Retry darf niemals eine zweite logische Verifizierung oder eine zweite Belastung erzeugen.
- 1 Hängen Sie an jeden Verifizierungsversuch einen stabilen Anfrage-Identifikator an.
- 2 Wiederholen Sie transiente Netzwerkfehler mit exponentiellem Backoff und einer kleinen Obergrenze.
- 3 Wiederholen Sie niemals ein definitives Ergebnis (Treffer, Teiltreffer, kein Treffer) — wiederholen Sie nur echte Transportausfälle.
- 4 Stimmen Sie jede späte Antwort mit dem Anfrage-Identifikator ab, damit sie nur einmal erfasst wird.
Budgetieren Sie die Wartezeit, dann entscheiden Sie
Wählen Sie ein synchrones Budget, das Sie sowohl gegenüber Ihren UX- als auch Compliance-Teams verteidigen können. Jenseits dieses Budgets weichen Sie bewusst aus — zeigen Sie ausstehend oder nicht verfügbar — statt die Anfrage hängen zu lassen und den Zahler abbrechen zu lassen.
RoxPay gibt die standardisierten Ergebnisse einschließlich nicht verfügbar zurück, unterstützt idempotente Retries per Anfrage-ID und weicht für späte Antworten auf einen Webhook aus — sodass Ihre Timeout-Richtlinie einfach bleibt.