Webhook-idempotens: Når Stripe Sender Den Samme Provisjons-eventen Tre Ganger

Gjennom 14 måneder logget vi hver Stripe-webhook på thMenu: 312 av 100.000 events ankom med samme event_id to eller tre ganger. Det er Stripes "at-least-once delivery"-løfte i konkrete tall — uten idempotens tre duplikater i provisjonsboken.

Hvorfor Samme Event Kommer Tre Ganger

Hvis Stripe ikke mottar 2xx-svar innen ~10 sekunder, prøver igjen. TCP-timeouts, lambda cold starts, midlertidige DNS-feil, til og med vellykket behandling fulgt av tilkoblingsbrudd — alle utløser retries.

Tre hyppige scenarier: Cloudflare Workers cold start >10s, D1 batch-transaksjon committet men tilkobling brutt, eller manuelt "resend"-klikk i Stripe dashboard.

INSERT-Claim-mønsteret

thMenus forsvar er tabellen stripe_webhook_events med event_id PRIMARY KEY. Første handling: INSERT. Unique constraint-feil 23505 = duplikat — 200 OK no-op.

Kritisk: claim må komme før forretningslogikk for å unngå race condition.

Race Condition: Events Ute av Rekkefølge

Reell hendelse: customer.subscription.updated ankom 800ms før checkout.session.completed. UPDATE påvirket 0 rader. Fix: rollback av claim, returner 503, Stripe prøver igjen.

FAQ

Verifiser signatur før eller etter claim? Før. Verify er billig, DB-skriving dyrt.

Hvor lenge beholde idempotens-rader? Stripe garanterer 30 dagers retry; vi beholder 90 dager.

Prøver Stripe evig? Nei, maksimalt 3 dager.

Var dette nyttig? Del det.