Guides · Updated October 17, 2026

One-time purchases and per-seat subscriptions in Stripe: getting access control right

Most Stripe access-control code assumes one rule: active subscription means access. That rule breaks for two common setups: one-time purchases (lifetime deals, one-off plans) and per-seat subscriptions, where paying isn't yes-or-no but "paid for N people". This guide covers what to check for each, with the bugs that cause most of the problems.

Part 1: one-time purchases (Checkout mode=payment)

A lifetime deal sold through Stripe Checkout uses mode=payment instead of mode=subscription (Checkout Session object). There's no subscription status to read later, so the moment of fulfillment is everything.

Grant access on the right signal

• Fulfill from checkout.session.completed and check the session's payment_status. With delayed payment methods such as bank debits the session can complete before the money arrives; Stripe sends checkout.session.async_payment_succeeded when it does (Fulfill orders).
• Make fulfillment idempotent. Stripe warns that your fulfillment function may run more than once for the same session, possibly concurrently.
• Don't rely only on the success-page redirect. Users close tabs. The webhook is the dependable path; the redirect is a fast path.

Know who bought it

• Guest checkouts. In payment mode, Checkout only creates a Customer object when needed unless you set customer_creation=always or pass an existing customer (Create a Checkout Session). Without a Customer, the buyer's email is only on the session's customer_details, and a Customers export won't list them.
• Link the purchase to your user. Pass your user ID as client_reference_id so the webhook handler doesn't have to guess from an email.
• No invoice by default. One-time Checkout payments only generate an invoice if you enable invoice_creation, so code that grants access on invoice.paid never fires for them.

Common bugs

Part 2: per-seat subscriptions (item quantity)

In Stripe, per-seat pricing is a subscription item whose quantity is the number of seats; the cost scales linearly with quantity (Quantities, Per-seat pricing). The seat count lives on the subscription item, so on subscriptions with several items, read the quantity of the per-seat price's item.

Keep the count honest

• Decide what a seat is. Active members only? Does the owner count? Do pending invites? Write it down and count the same way everywhere.
• Enforce on invite. When a team at its limit invites someone, either block it or increase the item quantity. Quantity changes create prorations according to your proration settings (Prorations).
• Sync changes made outside your app. The customer portal can let customers change quantities if you enable it (Configure the customer portal). Handle customer.subscription.updated so your app learns the new seat count (Subscription webhooks).
• Check team status, not just the payer's. When the team's subscription is canceled or unpaid, every member loses paid access, not only the person whose card was on file.

Quick audit without code

1. Export active subscriptions from Billing → Subscriptions, including the customer and quantity if your export offers it. Otherwise open each team's subscription in the Dashboard.
2. Export a count of active members per team from your database (team ID, billing customer ID, member count).
3. Compare in a spreadsheet: members > quantity means unpaid seats; members < quantity means paid seats nobody uses. That's not a leak, but it's a churn risk worth an onboarding nudge.

Doing this with PaidCheck

PaidCheck's reconciliation covers both cases, as long as you give it the data:

• One-time purchases count as paid access when they come from a paid Checkout Session in mode=payment or from a charge with no invoice. Spotting Checkout purchases needs the optional Read permission on Checkout Sessions, and spotting charges with no invoice needs the optional Read on Invoices. It looks back 12 months. Map your price or product IDs to plans so add-ons and credits don't count; without a mapping, any paid one-time purchase counts and findings are marked medium severity. Refunded purchases whose user still has access are flagged separately.
• Seats: if your access feed or CSV includes team_id (or seats_used), it compares seats in use with the subscription item quantity. It flags teams using more seats than they pay for, with the estimated monthly amount, and lists unused paid seats as informational.
• Metered items count as access like any active subscription, but usage amounts aren't audited.

Start with the free leak report (a CSV upload works), or read how to find customers who paid but don't have access first.

FAQ