You Charged the Card Once. Then What?

Checkout worked flawlessly. I subscribed with a test card, the webhook fired, access unlocked, the receipt landed. It’s a real, working payment flow — the AI tool nailed the part that’s genuinely hard to get wrong once Stripe is doing the heavy lifting. So I went looking for the second month. The webhook handler had exactly one branch: grant access on success. No branch for a renewal that fails. No way for a customer to cancel without emailing support. No handler, no alert, for a chargeback. Charging a card once is a demo. Everything after it is the business, and none of it was there.

This is a representative audit — the exact pattern I hit over and over on apps built with Lovable, Bolt, v0, and Cursor. Names and paths are changed, but every finding below is real-shaped and drawn straight from the kind of report the launchworthy skill produces. Call the app fitplan: a Next.js app on Stripe subscriptions, monthly plan, about to go live.

None of this throws an error. Nothing looks broken. That’s exactly why it leaks money quietly for months.

The finding: the handler only knows how to say yes

Here’s the whole switch, near enough. It grants on the happy path and stops:

switch (event.type) {
  case "checkout.session.completed":
  case "invoice.paid":
    await grantAccess(event)     // never revisited when next month's charge fails
    break
}

Renewal charges fail all the time — expired cards, insufficient funds, a bank declining a recurring transaction. With no invoice.payment_failed branch, that failure is silent: the customer either keeps access without paying, or gets cut off with no warning and churns angry. You don’t find out until you notice MRR drifting down for reasons you can’t name.

The fix is a failure branch that lets Stripe run its retry schedule and acts on the terminal state, not on every failed attempt:

switch (event.type) {
  case "checkout.session.completed":
  case "invoice.paid":
    await grantAccess(event)
    break
  case "invoice.payment_failed":
    // one attempt failed; Stripe will retry on the dunning schedule
    await flagPastDue(event)     // surface it, email them — but don't cut access yet
    break
  case "customer.subscription.updated":
    // terminal states, after retries are exhausted
    const s = event.data.object.status
    if (s === "unpaid" || s === "canceled") await revokeAccess(event)
    break
}

The other two leaks: no exit, no defense

Two more gaps, both cheap, both revenue.

No self-serve refund or cancellation. The checkout page linked to nothing — no refund policy, no cancellation path, no way to manage the subscription. “No refunds” is a policy you’re allowed to have; it is not one you’re allowed to hide until after the charge. And a customer who can’t find how to cancel doesn’t email you — they file a chargeback to make the charges stop, which costs you the revenue and a dispute fee.

const session = await stripe.billingPortal.sessions.create({
  customer: customerId,
  return_url: `${origin}/account`,
})
return Response.json({ url: session.url })

No dispute handling. A chargeback starts a short clock — often about seven days — and an unanswered dispute is lost by default. fitplan had no charge.dispute.created handler and no alert, so the first anyone would hear of a dispute is a lost-balance line on the statement weeks later.

case "charge.dispute.created":
  await alertTeam(event)     // Slack / email / PagerDuty — don't wait to notice the balance drop
  break

The false alarm: “Stripe handles all that”

This is the sentence that lets the whole lifecycle go unbuilt.

The rest of the punch list

The missing failed-renewal branch is the one that can’t ship. The rest is ranked so scope stays honest:

The shape is the honest part. One code branch decides whether failed renewals are recovered or lost silently; the rest is the difference between a payment integration and a payments business. Worst-first reads as “add the failure branch before launch, wire the portal and dispute alert this week.”

Why this keeps happening

The first payment is the part you watch happen. You click Subscribe, the card clears, access unlocks — the loop closes on your screen and it feels done. Everything after is invisible during a demo: renewals happen next month, declines happen to other people’s cards, disputes happen weeks later on a statement. AI builders generate the flow you can see and test, and the flow you can see is exactly the one month that works. The eleven months and the edge cases after it never come up while you’re building, so they never get built.

That’s the gap launchworthy exists to close. It plays bouncer at the door of production: it detects the payment provider, knows a webhook with no invoice.payment_failed branch is a HIGH, checks the checkout page for a policy link and the code for a dispute handler, and separates the code fixes from the dashboard settings you have to confirm yourself — instead of calling it done because a test card cleared.

The card was charged. The receipt sent. The demo closed clean. And month two, and the refund request, and the chargeback were all going to arrive with nobody home.