Cum faci un webhook de plată sau WhatsApp idempotent?

Asociază fiecărui webhook un ID unic de la expeditor, cum ar fi un ID de comandă sau un ID de mesaj, și execută efectele secundare o singură dată. O livrare repetată găsește ID-ul deja procesat și nu face nimic. Publică munca reală într-o coadă în loc să o faci inline, astfel încât expeditorul să nu fie ținut în așteptare.

De ce sosesc webhooks de mai multe ori?

Expeditorii reîncearcă în caz de timeout-uri, probleme de rețea și răspunsuri non-2xx, preferând să livreze de două ori decât să nu livreze deloc. Atât gateway-urile de plată, cât și WhatsApp fac acest lucru. Un handler care acționează la fiecare livrare va emite bilete duplicate, va trimite de două ori o confirmare de rezervare sau va taxa de două ori.

Ce ar trebui să fie cheia de idempotentă?

Folosește identificatorul pe care expeditorul îl garantează ca fiind stabil între reîncercări: ID-ul comenzii pentru webhooks de plată, ID-ul mesajului pentru WhatsApp. Stochează cheile procesate și verifică înainte de a acționa. O cheie generată de tine pentru fiecare livrare nu funcționează, deoarece fiecare reîncercare ar părea un eveniment nou.

De ce să publici într-o coadă în loc să faci munca în handler?

Generarea unui bilet și trimiterea unui email inline face ca gateway-ul să aștepte o muncă care nu îl interesează, ceea ce invită la timeout-uri și reîncercări. Confirmă rapid, publică un eveniment de plată confirmată în RabbitMQ și lasă un consumator să facă munca. O livrare repetată publică o singură dată; a doua este un no-op.

Unde se folosește asta în producție?

La FindYourVibe webhook-ul de plată este idempotent pe baza ID-ului comenzii și publică în RabbitMQ înainte ca un consumator să emită biletul. La Trexind fiecare handler de webhook WhatsApp este idempotent pe baza ID-ului mesajului, astfel încât o livrare reîncercată actualizează starea o singură dată în loc să reinițieze efectele secundare de rezervare sau facturare.

Cum testezi că un webhook este idempotent?

Trimite aceeași încărcătură de două ori, ideal simultan, și verifică că efectul secundar s-a întâmplat o singură dată: un bilet, o rezervare, o taxare. Apoi redă o încărcătură veche după ce prima a fost procesată complet. Dacă vreun contor este peste unu, verificarea cheii este în curs de execuție concurentă sau lipsește o constrângere unică.

Publicat inițial la sakshamjain.codes/blog/idempotent-payment-and-whatsapp-webhooks. Ai nevoie să fie implementat? Vezi serviciile mele pe NexoRush sau trimite-mi un mesaj.