# Stripe webhooks on Supabase: the receiving end done right

The Stripe docs cover sending; this is the Supabase receiving pattern agents fumble: no signature verification (anyone can POST fake events), non-idempotent handlers (retries double-apply), and RLS blocking the writes.

## Checkable procedure

1. Create the Edge Function with `verify_jwt = false`. Stripe has no Supabase JWT; verification would 401 every event.
2. Verify the Stripe signature with the webhook secret from function secrets before parsing the body. Reject invalid signatures with 400 immediately. This is the step agents skip, and it is the security of the whole flow.
3. Parse the event and switch on the type you handle. Ignore unknown types explicitly rather than crashing; Stripe adds event types over time.
4. Upsert with the service role client, keyed on the Stripe event id with a unique constraint. Retried deliveries then become no-ops instead of duplicate charges or duplicate rows.
5. Return 200 quickly. Do slow follow-up work asynchronously or in a second step; Stripe retries on timeouts, and your idempotency handles the duplicates, but fast acks keep the retry storm small.

## Ordering constraints

Secret in function secrets before deploy. Unique constraint on the event id before the first event arrives. Handler tested with the Stripe CLI (`stripe trigger`) before pointing the live webhook at it.

## Verification

Send a test event, confirm the database state. Send the same event id again and confirm no duplicate effect. Send a forged event with a bad signature and confirm rejection.