Stripe Checkout vs Stripe Billing

When to use Checkout

You have fewer than a thousand paying users. You need someone to give you money. That's it. That's the requirement. Not "subscription lifecycle management." Not "metered billing with usage-based proration." Someone, somewhere, wants to pay you for something. Stripe Checkout handles this with a single API call: create a session, redirect to Stripe's hosted page, verify the payment on return. No webhooks. No subscription objects. No event queue. No idempotency keys for out-of-order webhook delivery. Just money, moving from their account to yours, with Stripe's hosted page handling the card form, the 3D Secure challenge, and the receipt.

If someone wants to cancel, they email you. You refund them from the Stripe dashboard. This takes eleven seconds. I timed it. One founder launched an entire MVP with Stripe Payment Links — not even the API, just the links — and was processing revenue within two hours. Jason Fried at Basecamp described manually generating invoices as an intentional early-stage choice. The phrase was "do things that don't scale," and it remains the best advice in technology. It remains the most ignored advice in technology too, but that's a separate observation I'm making for free.

The verification happens server-side. After the customer completes payment and Stripe redirects them back to your success URL, you call stripe.checkout.sessions.retrieve() with the session ID from the URL parameters. If the payment status is paid, you provision access. If it isn't, you don't. This is the entire payment integration. It fits in a function shorter than most import statements in a modern JavaScript application.

When to use Billing

You have a thousand paying subscribers. Manual refunds and dashboard invoicing have become tedious — not impossible, merely tedious. There's a difference, and the difference matters, because "tedious" means you have a thousand customers generating enough revenue to justify engineering time. You need self-serve plan changes because customers expect to upgrade, downgrade, and manage their subscriptions without emailing you. You need metered billing because your pricing model depends on usage. You need automatic dunning because failed payments at scale require automated retry logic, not manual follow-ups.

At this point, the full Stripe Billing suite is justified: eight to twelve webhook events, a subscription state machine with eight statuses, idempotency handling for duplicate events, out-of-order event processing with timestamp verification, and a customer portal that lets subscribers manage their own accounts. The infrastructure earns its complexity because the revenue justifies the maintenance. Not before. The complexity doesn't scale down. A subscription state machine with eight statuses is exactly as complex for ten customers as it is for ten thousand. The difference is that ten thousand customers generate enough revenue to hire someone to maintain it. Ten customers do not.

The additional 0.7% billing fee means Stripe takes 3.6% plus thirty cents per transaction instead of 2.9% plus thirty cents. On a hundred-dollar subscription, that's an extra seventy cents per month per customer. At a thousand customers, that's seven hundred dollars a month for subscription management infrastructure. Whether that's worth it depends on how much engineering time the alternative costs. I've done the math. At a thousand customers, it usually is. At fifty customers, it never is.

The lie you told yourself was "I need subscriptions from day one." You don't. You need a way to accept money. These are different things in the same way a bicycle and a space shuttle are both technically vehicles. One gets you to the shop. The other requires a launch team, mission control, and a budget measured in billions. Start with the bicycle. You can see the shop from here. See how Stripe Checkout fits into the full boring stack.