Verification of Payee depinde de un răspuns la distanță din partea băncii beneficiarului. Când acea bancă este lentă, supraîncărcată sau temporar de neatins, integrarea dumneavoastră trebuie să decidă ce face — iar această decizie afectează atât experiența plătitorului, cât și poziția dumneavoastră de conformitate. Cele mai grave rezultate sunt un flux de plată blocat sau o verificare care este taxată ori contorizată de două ori, în tăcere.
Rezultatul „indisponibil” este o funcționalitate
Schema definește un rezultat „indisponibil” exact pentru ca dumneavoastră să nu fie nevoit să inventați o semantică a erorilor. Când partea care răspunde nu poate răspunde la timp, tratați acest lucru ca pe un rezultat de primă clasă, nu ca pe o excepție.
- Setați un timeout sincron aliniat la bugetul fluxului de plată (adesea câteva secunde).
- La depășire, afișați plătitorului o stare neutră de „indisponibil”, nu o eroare înspăimântătoare.
- Decideți, prin politică, dacă plătitorul poate continua, trebuie să aștepte sau ar trebui direcționat către o verificare manuală.
Reîncercarea în siguranță
Reîncercările ajută la erorile tranzitorii, dar produc daune dacă nu sunt idempotente. O reîncercare nu trebuie să creeze niciodată o a doua verificare logică sau o a doua taxare.
- 1 Atașați un identificator de cerere stabil fiecărei încercări de verificare.
- 2 Reîncercați erorile de rețea tranzitorii cu backoff exponențial și un plafon mic.
- 3 Nu reîncercați niciodată un rezultat definitiv (potrivire, potrivire parțială, lipsa potrivirii) — reîncercați doar erorile reale de transport.
- 4 Reconciliați orice răspuns tardiv cu identificatorul cererii, astfel încât să fie înregistrat o singură dată.
Stabiliți bugetul de așteptare, apoi decideți
Alegeți un buget sincron pe care îl puteți susține atât în fața echipei de UX, cât și a celei de conformitate. Dincolo de acest buget, treceți deliberat pe soluția de rezervă — afișați „în așteptare” sau „indisponibil” — în loc să lăsați cererea să atârne și plătitorul să renunțe.
RoxPay returnează rezultatele standardizate, inclusiv „indisponibil”, acceptă reîncercări idempotente după ID-ul cererii și folosește un webhook ca soluție de rezervă pentru răspunsurile tardive — astfel încât politica dumneavoastră de timeout rămâne simplă.