Kézikönyv3 rész · 2 percÍrta: Dezső Mező · Megjelent 2026. október 3..mdStripeWebhooksPaymentsIdempotency
A fizetési webhookok az egyetlen hely, ahol a „tesztben működött” aktívan megtévesztő: a tesztesemény egyszer, sorrendben érkezik, az éles kézbesítés pedig rendszeresen hoz duplikátumot, sorrendfordulást és késést. Az alábbi minták jelentik a különbséget a néha duplán teljesítő pénztár és az „ugyanaz az esemény kétszer” non-esemény között.
01Előbb a hitelesítés, minden más után
A Stripe minden kézbesítést aláír; a végponttitokkal ellenőrizd, mielőtt megbízhatóként értelmeznéd vagy naplóznád. A hitelesítetlen webhook publikus POST-végpont, ami azt állítja, pénz mozdult — pontosan ezt jelenti az ellenőrzés nélkül.
02Tárold az eseményazonosítót, dolgozz egyszer
Az event id az idempotencia-kulcsod: feldolgozás előtt illeszd be, és az egyedi megszorítás teszi a második kézbesítést üres műveletté. Ugyanígy a kiváltott teljesítés — létrehozott rendelés, sorba állított levél, kiosztott jogosultság — külön „már megtörtént” rekordot érdemel.
03Állapotot olvass, ne az eseménytartalmat
Az esemény azt mondja, változás történt; az objektumlekérdezés mondja, mi az igazság most. A „checkout.session.completed” kezelése az aktuális munkamenet kiolvasásával — a payloadba vetett bizalom helyett — immunis a sorrendfordulásra, mert a kései esemény is a friss igazságot hozza.
Amit érdemes elvinni
- Ellenőrizd a hitelesítést — a webhook publikus végpont.
- Az event id az idempotencia-kulcs; deduplikálj cselekvés előtt.
- Aktuális állapotot kérdezz; a payload érkezéskor elavult.
- A duplikátum és a sorrendfordulás normális, nem szélsebeset.
Több a laborból
Összes bejegyzés
Mennyibe kerül tényleg az egyedi szoftver
Egyedi szoftver vagy dobozos — a becsületes teszt
A retainer első kilencven napja, ahogy tényleg megy
Miért kapnak az ügyfelek haladás-oldalt státusz-email helyett
Megnézzük ugyanezt a te rendszereden?Kezdjünk bele
