5 Subscription Billing Mistakes SaaS Founders Make

Billing bugs are the most expensive kind: they either charge customers wrongly or quietly stop charging them at all. These five mistakes show up again and again in systems I am hired to fix.

1. Trusting the success page

The user reaches /payment-success, so the app grants access. But users close tabs, banks delay, and 3D Secure interrupts. Grant and revoke access only from webhook events; the redirect page is decoration.

2. Canceling on the first declined charge

Five to ten percent of recurring charges fail at some point, most recover on retry. Cancel immediately and you throw those customers away. Use smart retries and treat past_due as its own state.

3. No proration preview

Upgrades mid-cycle create partial charges that confuse customers into support tickets and chargebacks. Preview the exact amount before they confirm; Stripe’s upcoming-invoice endpoint exists for this.

4. Plan limits hardcoded in the app

// Painful: every pricing change is a code deploy
if (user.plan === 'pro') maxProjects = 10

// Better: limits live in data next to the plan
const plan = await db.plans.find(user.planId)
if (projectCount >= plan.maxProjects) {
  return upgradePrompt()
}

5. No admin view of billing state

When support cannot answer why was I charged, every billing question escalates to a developer digging through Stripe logs. An admin page showing subscription state, recent invoices, and events pays for itself in the first month.

The theme behind all five

Billing is a state machine, not a checkout button. Model the states explicitly and let verified payment events drive every transition:

trialing --payment--> active
active --invoice.payment_failed--> past_due
past_due --invoice.paid--> active
past_due --final retry failed--> canceled
active --user cancels--> canceled (at period end)

Do that, and the five mistakes above become structurally impossible.