DEV Community: Jon Galarraga

The subscription bugs that quietly let SaaS users keep access for free

Jon Galarraga — Tue, 23 Jun 2026 19:42:28 +0000

My first teardown was about one-time checkouts — the /checkout route bugs that show up
right before launch. This one is about the thing that bites a month later: subscriptions.

One-time payments fail loudly. Subscriptions fail quietly. The charge that doesn't happen,
the cancellation that doesn't revoke access, the trial that never ends — none of it throws
an error. You find out when you read your Stripe dashboard and your app's user table and
notice they disagree. By then a chunk of your "active" users have been using the product
for free for weeks.

Here are the recurring-billing bugs I find in almost every pre-launch SaaS, with the bad
version and the fix. If you're wiring up Stripe Billing, read it with your subscription
code open.

1. Granting access on payment, but never taking it away

This is the big one. You handle checkout.session.completed, flip a flag, and ship.

// the only handler that exists
case 'checkout.session.completed':
  await db.user.update({ where: { id }, data: { isPro: true } })

isPro: true goes in. Nothing ever sets it back to false. The user cancels, their card
expires, they dispute the charge — and they stay Pro forever, because the only event you
listened for was the happy one.

Access has to track the current subscription state, not the moment money first arrived.
At minimum you also handle the events that end access:

case 'customer.subscription.deleted':       // canceled / ended
case 'customer.subscription.updated':       // could be past_due, unpaid, paused
  const sub = event.data.object
  const active = ['active', 'trialing'].includes(sub.status)
  await db.user.update({
    where: { stripeCustomerId: sub.customer },
    data: { isPro: active },
  })

The rule: every grant needs a revoke on the same key.

2. Storing a boolean instead of syncing the real status

isPro: true/false feels clean, but a subscription isn't a boolean. Stripe has at least
seven states — trialing, active, past_due, canceled, unpaid, paused,
incomplete — and your access rules differ across them. A user who is past_due should
probably keep access for a few days while dunning retries; a user who is canceled should
not.

Store the actual status and the period end, and let your access check read them:

// what you persist from the webhook
{ stripeStatus: sub.status, currentPeriodEnd: sub.current_period_end }

// the access check, in one place
function hasAccess(user) {
  if (['active', 'trialing'].includes(user.stripeStatus)) return true
  // grace window: still in the paid period you already billed for
  if (user.stripeStatus === 'past_due' && user.currentPeriodEnd > now()) return true
  return false
}

When in doubt, Stripe is the source of truth — your database is a cache of it.

3. The trial that never actually ends

Free trials are where access logic goes to die. Two common shapes, both broken:

You start a trial with no payment method on file, so when it ends there's nothing to charge — the subscription goes incomplete and the user just... keeps the trial UI.
You compute "is the trial over?" on the client, or off a trialEndsAt you set once and never reconcile with Stripe.

Let Stripe run the trial and tell you when it converts or fails:

await stripe.subscriptions.create({
  customer,
  items: [{ price }],
  trial_period_days: 14,
  // force a decision at trial end instead of a silent dangling sub
  trial_settings: { end_behavior: { missing_payment_method: 'cancel' } },
})

Then drive access off the webhook status (#2), not a date you stored at signup.

4. No handler for `invoice.payment_failed`

A renewal fails — expired card, insufficient funds, a bank decline. If you don't listen
for it, one of two things happens: the user silently keeps full access while paying you
nothing, or (worse, if you did wire up a revoke) they get kicked out mid-month with no
warning and no idea why. Both are bad. Both are invisible until someone complains.

case 'invoice.payment_failed':
  // don't cut them off on attempt 1 — Stripe will retry on your dunning schedule
  await notifyUser(customer, 'Your payment didn't go through — update your card')
  // access is governed by subscription.status (now 'past_due'), per #2

Turn on Stripe's automatic retries (Smart Retries) and a couple of dunning emails. Most
"failed" payments succeed on retry once the customer updates their card — but only if you
gave them the chance.

5. Plan changes with no proration logic

User upgrades from $9 to $29 mid-cycle. What do they pay today? If your "change plan"
button just creates a new subscription, you've now got two active subscriptions billing
the same customer. If it swaps the price with no proration setting, the behavior is
whatever the default happens to be — which is rarely what you'd have chosen.

Update the existing subscription item and be explicit about proration:

await stripe.subscriptions.update(subId, {
  items: [{ id: itemId, price: newPrice }],
  proration_behavior: 'create_prorations', // charge/credit the difference now
})

One subscription per customer, one explicit proration decision. Test the downgrade path
too — that's the one that quietly hands out credits you didn't mean to give.

6. Webhooks that aren't idempotent or ordered

Stripe sends events at-least-once, and not always in the order you'd expect. The same
subscription.updated can arrive twice; a deleted can land before a late updated. If
your handler isn't idempotent, a duplicate flips state back and forth. If you trust
ordering, a stale event overwrites a newer one.

// idempotency: ignore events you've already processed
if (await db.processedEvent.find(event.id)) return res.sendStatus(200)

// ordering: only apply if this event is newer than what you have
if (event.data.object.created < user.lastEventAt) return res.sendStatus(200)

Record the event ID, gate on a timestamp, and reconcile against the Stripe object when in
doubt. (And verify the webhook signature on the raw body — that's bug #4 from the first
teardown, and it applies here too.)

The 5-minute subscription self-check

When a user cancels or their card fails, does anything actually revoke their access?
Is access driven by the live subscription status, or a boolean you set once at signup?
Can a trial end with no payment method and leave the user in limbo?
Do you have a handler for invoice.payment_failed — and does it warn the user before cutting them off?
If a subscription.updated event arrives twice, or out of order, does your state stay correct?

If any of those makes you pause, that's the one to fix before you turn on billing.

I do fixed-scope pre-launch payment reviews for small SaaS teams: I map your checkout and
billing flow, find the launch-blockers, and send back a prioritized fix list — no code
changes, just findings you can act on. The checklist and example code I work from is open
here: github.com/galakurpi/stripe-prelaunch-security-checklist

If you're about to switch billing on and want a second set of eyes, I'll do a free
5-minute look at your flow first so you can see how I work before paying for anything.
Happy to answer Stripe Billing questions in the comments.

The 7 Stripe bugs I find in almost every pre-launch checkout

Jon Galarraga — Tue, 23 Jun 2026 18:58:49 +0000

I do pre-launch payment reviews for small SaaS teams — the quick pass you want before
real cards start hitting your /checkout route. Different stacks, different teams, but
the same handful of bugs show up over and over. None of them are exotic. All of them are
the kind of thing that's fine in a demo and quietly expensive once you're live.

Here's the list I check first, with the bad version and the fix. If your checkout is
about to go live, read it with your own code open in the other window.

1. Trusting the amount the browser sends you

This is the big one, and it's everywhere.

// client
await fetch('/api/checkout', {
  method: 'POST',
  body: JSON.stringify({ priceId: 'pro', amount: 4900 }) // <-- attacker controls this
})

// server
const intent = await stripe.paymentIntents.create({
  amount: req.body.amount,           // straight from the request
  currency: 'usd',
})

Anyone can open devtools and change amount to 1. The fix is boring and absolute:
the server decides the price. The client is allowed to say which product, never how
much.

const PRICES = { pro: 4900, team: 9900 } // cents, server-side source of truth
const amount = PRICES[req.body.plan]
if (!amount) return res.status(400).json({ error: 'unknown plan' })

const intent = await stripe.paymentIntents.create({ amount, currency: 'usd' })

If your prices live in a database or a config table, look them up by ID server-side.
Never let a number from the request reach paymentIntents.create.

2. No idempotency key, so a retry double-charges

Mobile users tap twice. Networks drop the response after the charge succeeds. Your own
frontend retries on timeout. Without an idempotency key, each of those creates a brand
new charge.

// one tap, one network hiccup, two charges
await stripe.paymentIntents.create({ amount, currency: 'usd' })

Stripe gives you the fix for free — pass a key tied to the thing being paid for, not
a random value:

await stripe.paymentIntents.create(
  { amount, currency: 'usd' },
  { idempotencyKey: `order_${orderId}` }
)

Same key, same logical operation, at most one charge. Use the order/cart ID, not
crypto.randomUUID() — a fresh UUID on every retry defeats the entire point.

3. Fulfilling the order before the payment actually settles

The classic race. You create the PaymentIntent, the client says "looks good," and you
immediately mark the order paid, send the welcome email, and provision the account —
while the charge is still processing and might fail.

const intent = await stripe.paymentIntents.create(...)
await db.orders.markPaid(orderId)   // too early
await sendWelcomeEmail(user)        // way too early

Payment confirmation is asynchronous. The only thing that should flip an order to "paid"
is the payment_intent.succeeded webhook:

// webhook handler
if (event.type === 'payment_intent.succeeded') {
  const orderId = event.data.object.metadata.orderId
  await db.orders.markPaid(orderId)   // now it's real
  await sendWelcomeEmail(...)
}

Put orderId in the PaymentIntent metadata when you create it so the webhook can find
its way back. If you're giving access before the webhook fires, you're giving away
product to failed payments.

4. The webhook endpoint that trusts anyone

A webhook that doesn't verify the signature is an open POST that flips orders to paid.
Anyone who finds the URL can fake a payment_intent.succeeded.

// no verification — anyone can forge this
app.post('/webhook', (req, res) => {
  const event = req.body
  if (event.type === 'payment_intent.succeeded') grantAccess(event)
})

Verify with the signing secret, and verify against the raw body (parsing to JSON
first breaks the signature):

app.post('/webhook', express.raw({ type: 'application/json' }), (req, res) => {
  let event
  try {
    event = stripe.webhooks.constructEvent(
      req.body, req.headers['stripe-signature'], process.env.STRIPE_WEBHOOK_SECRET
    )
  } catch {
    return res.status(400).send('bad signature')
  }
  // event is now trustworthy
})

5. Live keys committed to the repo

I find sk_live_… in a committed .env, in a config file, or in the git history more
often than you'd want to believe. Once it's in a commit, deleting the file doesn't help —
it's in the history forever, and anyone who clones the repo has your money keys.

Check before you ship:

git log -p | grep -E 'sk_live_|whsec_|sk_test_'

If anything turns up: rotate the key in the Stripe dashboard immediately (rotating beats
scrubbing — assume it's compromised), then purge it from history with git filter-repo.
Secrets belong in the environment, never in the tree.

6. Discounts and coupons computed on the client

Same disease as #1, second location. If the discount is applied in the browser, the
discount is whatever the user wants it to be.

// client
const final = price * (1 - couponPercent)  // user sets couponPercent to 1.0

Validate the coupon server-side, against your own records, and compute the final amount
there:

const coupon = await db.coupons.findValid(code) // null if expired/fake/used
const amount = coupon ? base - coupon.discountCents : base

A free-money coupon bug is the kind of thing that doesn't show up until someone posts
the trick on a forum.

7. Payment-status and admin endpoints with no row-level authorization

The checkout itself is locked down, and then /api/orders/:id returns anyone's order if
you change the number in the URL. Receipts, emails, partial card details, addresses —
straight out the side door.

// returns ANY order, not just the caller's
app.get('/api/orders/:id', async (req, res) => {
  res.json(await db.orders.findById(req.params.id))
})

Scope every read to the authenticated user:

app.get('/api/orders/:id', requireAuth, async (req, res) => {
  const order = await db.orders.findOne({ id: req.params.id, userId: req.user.id })
  if (!order) return res.status(404).end()  // 404, don't confirm it exists
  res.json(order)
})

The same hole shows up on admin/payment-status pages that check "is logged in" but not
"is allowed to see this record." Authentication is not authorization.

The 10-minute self-check before you launch

Can I change the price in devtools and pay less? (#1, #6)
Does a double-tap or a retry create two charges? (#2)
Does anything get fulfilled before the webhook confirms payment? (#3)
Does my webhook verify the Stripe signature on the raw body? (#4)
Is there a live key anywhere in my git history? (#5)
Can I read someone else's order by changing the ID in the URL? (#7)

If any answer makes you wince, fix that one first.

I run this as a fixed-scope pre-launch scan: I map your checkout flow, find the
launch-blockers, and send a prioritized fix list — no code changes, just findings you can
act on. The checklist and example code I work from is open here:
github.com/galakurpi/stripe-prelaunch-security-checklist

If you're about to go live and want a second set of eyes, I'll do a free 5-minute look at
your checkout first so you can see how I work before paying for anything. Happy to answer
Stripe questions in the comments too.