Stripe in a vibe-coded app: why checkout works and cancellations don't

Founders test the checkout, see the money land, and ship. Then the first card expires. Here is what a subscription app has to handle after the sale, and why it usually doesn't.

The events that matter

• checkout.session.completed: grant access. This is the one that gets wired.
• invoice.payment_failed: the card declined. Warn the customer, start dunning, and set a grace period.
• customer.subscription.updated: plan changes, pauses, trial ending.
• customer.subscription.deleted: the customer cancelled or dunning gave up. Revoke access.
• charge.refunded and charge.dispute.created: revoke access and log it.

An app that handles only the first one gives away free months to anyone whose card fails, and locks out nobody who should be locked out.

Why AI builders stop at checkout

The prompt was "add Stripe subscriptions." The model produces the shortest thing that demonstrates payment. Handling failure requires a webhook endpoint with signature verification, idempotency, and a state machine for subscription status, none of which is visible in a demo.

The three fixes

1. A verified webhook endpoint that checks Stripe's signature and returns 200 quickly, then processes the event.
2. A subscription status column on the customer that is only ever written by webhooks, never by the frontend.
3. A nightly reconciliation job that asks Stripe for the truth and corrects any drift. This catches the events you missed while the endpoint was down.

How to check yours

In the Stripe dashboard, go to Developers, Webhooks, and look at the endpoint's recent deliveries. If you see events with no endpoint at all, or failed deliveries piling up, the app is not listening.

At JetBuild, payments are one of the seven checks in every audit, and the fixes above are usually a day of work. A subscription app that mishandles cancellations is losing money in both directions, which is why it is always in the "critical" column of the report.