Dezvoltator 7 min de citit

Webhookuri Verification of Payee și rezultate asincrone

O integrare Verification of Payee robustă ia în calcul și cererea care nu se întoarce în 300 de milisecunde. Iată cum să folosești webhookuri și callbackuri pentru a gestiona rezultatele asincrone fără să blochezi finalizarea plății.

Autor Tomaas Vento Starrantino · Recenzat de Donato Leone

Webhookuri Verification of Payee și rezultate asincrone

Idei cheie

  • Tratează VoP ca fiind de obicei sincronă, dar uneori asincronă: proiectează din prima zi o stare de așteptare.
  • Folosește un webhook pentru a primi rezultatul final al potrivirii atunci când un PSP care răspunde răspunde cu întârziere.
  • Verifică întotdeauna semnăturile webhookurilor și fă handler-ele idempotente, ca să reziste la reîncercări.

O cerere Verification of Payee returnează de obicei un rezultat de potrivire în timp real, suficient de repede pentru a fi afișat înainte ca plătitorul să autorizeze un transfer. Dar VoP este un apel de rețea către o altă bancă, iar rețelele nu sunt perfect fiabile. Un PSP care răspunde poate fi lent, o conexiune poate cădea sau o cerere poate ajunge într-o coadă. O integrare de nivel de producție are nevoie de un plan pentru răspunsul care sosește cu câteva secunde — sau câteva minute — mai târziu.

De ce un apel VoP poate deveni asincron

Schema definește o fereastră de răspuns strânsă, dar traficul real produce totuși cazuri limită pe care trebuie să le gestionezi elegant, nu ca pe niște erori dure:

  • PSP-ul care răspunde este temporar supraîncărcat și răspunde exact după expirarea timeout-ului tău sincron.
  • O defecțiune temporară de rețea declanșează o reîncercare care se finalizează după ce cererea inițială s-a întors deja.
  • Trimiți multe verificări în lot (de exemplu o rulare de plăți) și colectezi rezultatele pe măsură ce sosesc.

Cum proiectezi fluxul cu webhookuri

Cel mai curat model este să dai fiecărei verificări un identificator stabil, să returnezi o stare de așteptare când fereastra sincronă expiră și să lași un webhook să livreze rezultatul final.

  1. 1 Trimite verificarea și stochează ID-ul cererii ei, asociindu-l plății pe care urmează să o faci.
  2. 2 Dacă nu sosește niciun răspuns în bugetul tău sincron, arată plătitorului o stare de așteptare, nu o eroare.
  3. 3 Primește rezultatul final — potrivire, aproape potrivire, fără potrivire sau indisponibil — pe endpointul tău de webhook.
  4. 4 Asociază payloadul webhookului cu ID-ul cererii stocat și actualizează decizia de plată.

Securizat și idempotent din start

Verifică semnătura fiecărui webhook înainte de a te baza pe el și fă handler-ul idempotent: același rezultat poate fi livrat de mai multe ori. Leagă procesarea de ID-ul cererii, astfel încât o livrare duplicată să nu acționeze niciodată de două ori asupra unei plăți.

RoxPay returnează un rezultat sincron ori de câte ori poate și trece pe un webhook semnat atunci când un PSP care răspunde este lent, astfel încât finalizarea plății rămâne receptivă, iar înregistrările tale rămân complete.

FAQ

Întrebări frecvente

Nu este obligatoriu, dar este puternic recomandat. Fără o cale asincronă, un PSP care răspunde lent te obligă fie să blochezi plătitorul, fie să renunți la un rezultat valid. Un webhook îți permite să captezi curat răspunsurile tardive.

Fă handler-ul de webhook idempotent. Leagă procesarea de ID-ul cererii de verificare și ignoră un payload pe care l-ai aplicat deja, deoarece același rezultat poate fi livrat de mai multe ori.

O stare de așteptare neutră, nu o eroare, și evită confirmarea automată a unui transfer cu risc ridicat până când sosește rezultatul sau se atinge timeout-ul din politica ta.

Construiește o integrare VoP rezistentă

Discută cu RoxPay despre rezultate sincrone cu un webhook de rezervă pentru PSP-urile care răspund lent.