Idempotent Stripe Webhook Handler

Specify a production Stripe webhook handler that stays correct when Stripe retries, events arrive out of order, and the handler crashes halfway. STACK Runtime: [NODE | PYTHON | GO] Framework: [NEXT.JS ROUTE | EXPRESS | FASTAPI | HONO] Database: [POSTGRES] Events we care about: [checkout.session.completed, customer.subscription.updated, customer.subscription.deleted, invoice.paid, invoice.payment_failed — edit this list] What each event must change in our DB: [MAP EVENT → TABLES] Signature secret env var: [NAME] DELIVER 1) Route contract: raw body required for signature verification, which parsers will break it, and the exact rejection codes (400 vs 401 vs 500) and why 500 is the one Stripe should retry. 2) Verification steps with the Stripe library call, tolerance window, and what we log on failure (never the payload secrets). 3) Idempotency design: a processed_events table (event id primary key, type, created_at, status) and the insert-first pattern that makes a retry a no-op. Show the SQL, including the unique conflict path. 4) Ordering: how we handle an updated event that arrives before created, using Stripe object status as the source of truth rather than event arrival order. 5) The DB transaction boundary: what is inside the transaction with the event row, and which side effects (email, analytics) happen after commit and how they retry without double-granting entitlements. 6) A table of 6 failure cases and the expected outcome: duplicate delivery, signature mismatch, unknown event type, partial failure after commit, clock skew, subscription canceled then a late invoice.paid. 7) Local test recipe: Stripe CLI command shape and 3 fixtures to assert. Do not tell me to trust the client for plan state. Entitlements change only from verified events or a server-side Stripe API read.