Webhook-idempotens: När Stripe Avfyrar Samma Provisionshändelse Tre Gånger

Under 14 månader loggade vi varje Stripe-webhook på thMenu: 312 av 100.000 händelser kom med samma event_id två eller tre gånger. Det är Stripes "at-least-once delivery"-löfte i konkreta siffror — utan idempotens tre dubbletter i provisionsboken.

Varför Samma Händelse Kommer Tre Gånger

Om Stripe inte får 2xx-svar inom ~10 sekunder försöker det igen. TCP-timeouts, lambda cold starts, tillfälliga DNS-fel, även framgångsrik bearbetning följd av avbruten anslutning — allt utlöser retries.

Tre vanliga scenarier: Cloudflare Workers cold start >10s, D1 batch-transaktion commited men anslutning bruten, eller manuell "resend"-klick i Stripe-dashboard.

INSERT-Claim-mönstret

thMenus försvar är tabellen stripe_webhook_events med event_id PRIMARY KEY. Första åtgärd: INSERT. Unique constraint-fel 23505 = dubblett — 200 OK no-op.

Kritiskt: claim måste föregå affärslogiken för att undvika race condition.

Race Condition: Händelser i Fel Ordning

Verklig incident: customer.subscription.updated kom 800ms före checkout.session.completed. UPDATE påverkade 0 rader. Fix: rollback av claim, returnera 503, Stripe försöker igen.

FAQ

Verifiera signatur före eller efter claim? Före. Verify är billigt, DB-skrivning dyrt.

Hur länge bevara idempotensrader? Stripe garanterar 30 dagars retry; vi behåller 90 dagar.

Försöker Stripe för evigt? Nej, max 3 dagar.

Var detta hjälpsamt? Dela det.