Webhook pentru plăți: verificare, duplicate și recuperare

Asociază fiecare eveniment unei decizii

Definește ce stare poate schimba fiecare tip de eveniment și ce obiect intern este vizat. Comanda, încercarea de plată și executarea serviciului trebuie să fie distincte. Leagă referința procesatorului de înregistrarea internă și verifică suma, moneda și contul înainte de a considera confirmarea relevantă pentru acea comandă.

Pentru un curs online, plata confirmată permite inițierea accesului. Dacă serviciul de acces este indisponibil, nu înseamnă că plata trebuie repetată. Aplicația trebuie să păstreze rezultatul financiar și să urmărească etapa de livrare rămasă. Această separare permite suportului să explice problema fără să ceară clientului o nouă operațiune care ar putea fi inutilă.

Webhookuri de plată

Verifică semnătura conform sursei

Documentația oficială Stripe descrie verificarea propriilor mesaje, inclusiv cerințele asupra corpului cererii. Documentația Adyen are propriile reguli. Nu reutiliza un verificator pentru o sursă diferită doar pentru că evenimentele au câmpuri asemănătoare. OrsunPay folosește propriul protocol de webhook cu semnătură HMAC, distinct de mesajele directe ale procesatorilor.

Separă configurațiile de test și producție și protejează secretele punctelor de recepție. Nu le expune în browser sau în jurnale obișnuite. Un mesaj cu structură plauzibilă nu este de încredere înainte de verificare. Înregistrează refuzul în mod sigur, fără să copiezi automat întregul conținut sensibil în instrumentele de monitorizare folosite de mai multe echipe.

Instrumente pentru dezvoltatori

Salvează evenimentul înainte de lucrări costisitoare

După validare, păstrează un record recuperabil și programează acțiunile care pot dura. Trimiterea unui document sau a mai multor emailuri nu ar trebui să ducă la pierderea confirmării inițiale. Răspunsul de acceptare trebuie să reflecte o recepție reală, nu să ascundă o eroare care a lăsat mesajul numai în memoria procesului.

Folosește stări precum primit, aplicat și executat pentru a localiza etapa blocată. Un eveniment poate fi salvat corect, în timp ce o sarcină comercială a eșuat. Referința, sursa și momentele relevante sunt utile investigației. Datele personale trebuie limitate la cele necesare, iar copierea integrală în fiecare jurnal nu trebuie tratată ca soluție implicită pentru depanare.

Previne duplicarea și regresia stării

Livrarea repetată este un scenariu normal de integrare. Reține identificatorii procesati și protejează tranziția în stocare, inclusiv pentru două mesaje simultane. Un simplu control în memoria unui server nu este suficient când mai multe procese pot acționa asupra aceleiași comenzi. Rezultatul trebuie să rămână unic și explicabil.

Ia în calcul evenimente întârziate. Ultimul mesaj primit nu descrie neapărat cea mai recentă stare a operațiunii. Nu permite suprascrierea necontrolată a unui rezultat final cu unul vechi. Dacă informațiile se contrazic, consultă obiectul autorizat sau atribuie cazul unei investigații. Păstrează istoricul care explică decizia, în loc să îl înlocuiești la fiecare actualizare.

Testează recuperarea, nu doar răspunsul HTTP

Pentru fiecare scenariu, verifică starea comenzii și numărul efectelor comerciale produse. Un răspuns corect al punctului de recepție nu dovedește că accesul nu a fost acordat de două ori. Simulează o întrerupere după salvare și confirmă că reluarea procesării nu generează o nouă încasare sau livrare duplicată.

• Respinge semnătura greșită fără modificarea comenzii.
• Repetă același eveniment cu un singur efect final.
• Oprește o dependență și recuperează doar sarcina rămasă.
• Primește un eveniment vechi după confirmarea definitivă.

Atribuie responsabilitatea pentru mesaje nefinalizate

O listă de evenimente ori sarcini neîncheiate trebuie să includă motivul și persoana responsabilă. Suportul ar trebui să poată căuta după referința internă, fără să solicite secrete clientului. Documentează cine poate relua o sarcină și cum verifică dacă efectul nu s-a produs deja.

Reîncercările de livrare OrsunPay sunt limitate, astfel că o întrerupere lungă poate necesita reconciliere și recuperare controlată. Nu presupune că mesajele vor reveni la nesfârșit. Scopul este o legătură verificabilă între confirmarea autentică și comanda executată, cu o istorie care rămâne clară chiar atunci când unele etape au avut nevoie de intervenție manuală.

Surse

• Stripe — Notificări webhook
• Adyen — Notificări webhook