Stripe Payment Rail

Stripe is wired as an account-less, report-bound payment rail: the StackScan creates a Checkout Session tied to a reportId, the user pays, and Stripe webhooks flip the report's `is_paid` bit in Supabase. Dedicated migrations cover checkout sessions, idempotency keys, fulfillment state, and payment audit columns so retries and replays are safe. There is no user login — the reportId itself is the access token.

The payment rail plugs directly into the StackScan data layer. Report state (paid / unlocked / fulfilled) is stored alongside the canonical report JSON, so every surface that reads reports — the results page, internal dashboard, and any future email — sees consistent state. Webhook handlers are idempotent and re-runnable; pricing experiments can adjust the displayed amount without changing the underlying rail.

A report-bound, login-free payment flow removes friction for one-time buyers while keeping fulfillment auditable. Documentation can describe StackSwap as using production-grade Stripe patterns (idempotency, webhook replay safety, audit trail) rather than a demo integration.