Webhook-idempotentie: Wanneer Stripe Hetzelfde Commissie-Event Drie Keer Afvuurt

14 maanden lang logden we elk Stripe-webhook op thMenu: 312 van 100.000 events kwamen met hetzelfde event_id twee of drie keer aan. Dat is Stripes "at-least-once delivery"-belofte in concrete cijfers — zonder idempotentie drie duplicaten in je commissieboek.

Waarom Hetzelfde Event Drie Keer Komt

Als Stripe geen 2xx-antwoord ontvangt binnen ~10 seconden, probeert het opnieuw. TCP-timeouts, lambda cold starts, tijdelijke DNS-storingen, zelfs succesvolle verwerking gevolgd door verbroken verbinding — alles activeert retries.

Drie veelvoorkomende scenario's: Cloudflare Workers cold start >10s, D1 batch-transactie gecommit maar verbinding verbroken, of handmatig "resend" geklikt in Stripe dashboard.

Het INSERT-Claim Patroon

thMenu's verdediging is de stripe_webhook_events-tabel met event_id PRIMARY KEY. Eerste actie: INSERT. Unique constraint fout 23505 = duplicaat — 200 OK no-op.

Kritiek: claim moet vóór business logic komen om race conditions te voorkomen.

Race Condition: Events Buiten Volgorde

Echt incident: customer.subscription.updated kwam 800ms eerder dan checkout.session.completed. UPDATE raakte 0 rijen. Fix: rollback van claim, 503 retour, Stripe probeert opnieuw.

FAQ

Handtekening verifiëren voor of na claim? Voor. Verify is goedkoop, DB-schrijven duur.

Hoe lang idempotentie-rijen bewaren? Stripe garandeert 30 dagen retry; wij bewaren 90 dagen.

Probeert Stripe voor altijd? Nee, maximaal 3 dagen.

Was dit nuttig? Deel het.