Gestire timeout e tentativi nella Verification of Payee

La Verification of Payee dipende da una risposta remota della banca del beneficiario. Quando quella banca è lenta, sovraccarica o temporaneamente irraggiungibile, la tua integrazione deve decidere cosa fare — e quella decisione incide sia sull'esperienza di chi paga sia sulla tua posizione di conformità. Gli esiti peggiori sono un checkout congelato o una verifica conteggiata o addebitata due volte in silenzio.

L'esito «non disponibile» è una funzionalità

Lo schema definisce un esito «non disponibile» proprio perché tu non debba inventare la semantica degli errori. Quando il lato rispondente non riesce a rispondere in tempo, trattalo come un esito di prima classe e non come un'eccezione.

• Imposta un timeout sincrono allineato al budget del checkout (spesso un paio di secondi).
• In caso di sforamento, mostra a chi paga uno stato neutro «non disponibile» invece di un errore allarmante.
• Decidi, per policy, se chi paga può proseguire, deve attendere o va instradato in revisione.

Riprovare in sicurezza

I retry aiutano con i guasti transitori ma causano danni se non sono idempotenti. Un retry non deve mai creare una seconda verifica logica o un secondo addebito.

1. 1 Associa un identificativo di richiesta stabile a ogni tentativo di verifica.
2. 2 Riprova gli errori di rete transitori con backoff esponenziale e un tetto contenuto.
3. 3 Non riprovare mai un esito definitivo (corrispondenza, parziale, nessuna): riprova solo i veri guasti di trasporto.
4. 4 Riconcilia un'eventuale risposta tardiva con l'identificativo di richiesta, così viene registrata una sola volta.

RoxPay restituisce gli esiti standardizzati incluso «non disponibile», supporta retry idempotenti per request ID e ripiega su un webhook per le risposte tardive — così la tua policy di timeout resta semplice.