All packsSaaS Billing + Tax CoreSolve
stripe checkout session duplicate subscription prevent double billing
Stopping a second live subscription before it starts
Two tabs, two checkout sessions, one account -- without a guard the second one creates a second live subscription and double-bills. The pack returns 409 first (D13).
What goes wrong
A double-submit -- the same customer opening checkout in two tabs, or clicking buy twice before the page updates -- can create two separate live Stripe subscriptions for one account if nothing stops it. Two live subscriptions on one account means double billing, and unwinding it after the fact means refunds and an awkward support conversation.
Why agents get it wrong
Hosted Stripe Checkout makes starting a subscription so simple (redirect to a session, Stripe handles the form) that it's easy to treat "can this account start a checkout" as a question Stripe itself answers, when in fact Stripe is happy to create a second subscription for an account that already has one live -- the guard has to live in the app, before the redirect.
What SaaS Billing + Tax Core pre-decides
D13 has the checkout route return 409 whenever the account already has a live subscription (ACTIVE, PAST_DUE, or UNPAID), checked against the webhook-maintained cache. It's explicitly documented as best-effort -- a narrow race window exists during the very first checkout's completion -- which is exactly why D12's idempotency keys and D5's supersession rules exist as the second and third layers of the same defense, not a single silver-bullet check.
Source: ARCHITECTURE.md D13