How to Add Stripe Payments to an AI-Built App (Past the Checkout Button)

The short version: A working checkout button is the easy 10% - real Stripe billing is a database kept in sync with Stripe through verified, idempotent, retry-safe webhooks, with feature access driven by current subscription state.

"Add Stripe payments" is one prompt. Your AI builder returns a checkout button, drops in a Stripe key, and on click it sends the user to a hosted Checkout page. You pay with the 4242 4242 4242 4242 test card, you land back on a success page, and money moves. It demos perfectly.

Then a real customer pays, closes the tab before the redirect, and never gets access to the thing they bought. Another customer double-clicks the button and gets charged twice. A third refunds their purchase and keeps using the paid features for months. None of these show up in the demo, because the demo only ever walks the happy path. The checkout button is the easy 10%. The unsexy correctness work underneath is what decides whether your billing is trustworthy.

Here is the real flow, what AI builders get wrong inside it, and how to test the parts that break.

The Success Redirect Is Not Proof of Payment

The first wrong assumption almost every AI-generated Stripe integration makes: it grants access on the success-page redirect.

The flow it generates looks like this. User clicks checkout, pays on Stripe, Stripe redirects to yoursite.com/success, and the success page code marks the order paid or unlocks the feature. Clean and intuitive, and wrong.

The redirect is a client-side event. It happens in the user's browser, and the browser is not a reliable narrator. The user can close the tab the instant payment completes and never load the success page - they paid, they got nothing. They can also forge the redirect, hitting /success directly without paying at all and unlocking the feature for free. Tying fulfillment to the redirect means you both lose legitimate customers and hand the product away to anyone who reads a URL.

Stripe is explicit that fulfillment belongs on the webhook, not the redirect. Its fulfill orders guide says to listen for the checkout.session.completed event and grant access there, treating the success page as a confirmation screen only. The redirect tells the user what happened. The webhook tells your server what happened, and only the server's version counts.

Webhooks: The Source of Truth Your AI Never Wired Up

A webhook is Stripe calling your server to say "this thing happened." Payment succeeded. Subscription renewed. Charge refunded. Card expired. These are the events that should drive your database, because they come from Stripe, not from a browser you cannot trust.

When an AI builder does generate a webhook handler, two things are usually missing or broken.

Signature verification. Your webhook endpoint is a public URL. Anyone who finds it can POST fake "payment succeeded" events at it and unlock paid features for free, unless you verify that each request genuinely came from Stripe. Stripe signs every webhook with a secret, and you verify it with constructEvent before trusting a single byte of the payload. AI-generated handlers routinely parse req.body directly and skip this entirely. Stripe's webhook signature guide walks through constructEvent and the framework-specific catch that breaks it most often: you must verify against the raw request body, and many frameworks - Next.js included - parse the body to JSON before your handler sees it, which silently invalidates the signature.

Reliability and retries. Stripe retries failed webhook deliveries, which is a feature, not a nuisance. If your endpoint is down or throws, Stripe will resend the event - so your server must respond 200 quickly and do the slow work afterward, and it must handle the same event arriving more than once. Stripe's webhooks overview covers retry behavior, event ordering, and why you return 200 first and process second. AI-generated handlers tend to do heavy database work inline and time out, which Stripe reads as failure, which triggers more retries, which compounds the next problem.

Idempotency: The Reason One Payment Becomes Two Records

Retries and double-clicks create the same hazard: the same operation runs twice. Without protection, that means two charges, or one payment recorded as two paid orders, or a subscription provisioned twice.

There are two places to defend.

On the outbound side - requests your app sends to Stripe - use an idempotency key. If a user double-submits and your server fires two "create charge" calls, an idempotency key tells Stripe they are the same operation, and the customer is charged once. Stripe's idempotent requests documentation recommends a V4 UUID per logical operation and explains that idempotency applies to POST requests only.

On the inbound side - webhooks Stripe sends you - assume every event can arrive more than once, because with retries it will. Before you act on checkout.session.completed, check whether you have already processed that event ID. Store processed event IDs, or make the database write itself idempotent (an upsert keyed on the Stripe object ID rather than a blind insert). AI-generated handlers almost always do a naive insert, so a single retried event produces two paid orders for one payment, and your revenue numbers stop matching Stripe's.

The general rule: your database, not Stripe and not the browser, is the source of truth - but only once you have made the path to it safe against duplicates.

Feature-Gating That Survives Refunds and Chargebacks

Granting access on payment is half the job. Revoking it is the half AI builders forget exists.

A customer pays, you flip is_pro = true, they use the product. Three weeks later they refund, or their bank issues a chargeback, or - for a subscription - their renewal card declines. If your code only ever listens for the "payment succeeded" event, that is_pro flag stays true forever. You are giving away paid features to people who are no longer paying, and you will not notice until you reconcile by hand.

Feature-gating has to be driven by the current subscription state, synced from Stripe, not by a one-time "they paid once" flag. That means handling the full set of lifecycle events - customer.subscription.updated, customer.subscription.deleted, invoice.payment_failed, charge.refunded - and updating access accordingly. Stripe's subscriptions overview maps the subscription statuses (active, past_due, canceled, unpaid) you need to react to. The correct mental model: store the subscription status in your database, update it from webhooks, and gate features on that status. Never trust a boolean that only one event can ever set.

This is the same shape as the authorization problem on the auth side, where access has to reflect current state rather than a one-time grant - the companion piece on adding authentication to an AI-built app covers that wall. Both come down to: state changes, and your gates have to follow it.

Tax and SCA: The Compliance You Cannot Prompt Away

Two more pieces sit outside what any "add payments" prompt produces, and both are legal requirements, not nice-to-haves.

SCA (Strong Customer Authentication). European cards frequently require an extra verification step - a bank push notification, a 3D Secure challenge - mid-payment. If your integration does not handle the authentication-required state, those payments simply fail and you never learn why. Stripe Checkout and the Payment Element handle most of this for you, which is one concrete reason to prefer them over a hand-rolled card form an AI builder might generate; Stripe's how Checkout works guide covers what the hosted flow manages on your behalf.

Tax. Depending on where you and your customers are, you may be obligated to collect VAT or sales tax. This is not something the model will surface unprompted, and getting it wrong is a liability that surfaces at filing time, not at checkout. Stripe Tax can automate the calculation, but you have to know to turn it on - the AI will not flag it, because nothing in "add Stripe payments" implies a tax obligation. Stripe's set up Stripe Tax guide walks through enabling it.

How to Test the Parts That Break

You cannot test webhook correctness by clicking the button and watching the success page - that only ever exercises the happy path. Use the Stripe CLI.

stripe listen --forward-to localhost:3000/api/webhook forwards live test-mode events to your local handler and prints the webhook signing secret you need for constructEvent. Then stripe trigger checkout.session.completed fires a real event so you can watch your handler run end to end. Fire it twice and confirm you get one paid order, not two - that is your idempotency check. Trigger charge.refunded and confirm access is revoked. Trigger invoice.payment_failed and confirm a subscriber is downgraded. Stripe's webhooks overview documents the CLI workflow and the local testing loop.

A short test matrix that catches most of the real failures:

• Pay, then close the tab before redirect. Did the user still get access? (Tests webhook-driven fulfillment.)
• Fire the same checkout.session.completed twice. One order or two? (Tests idempotency.)
• POST a fake unsigned event to your webhook URL. Rejected? (Tests signature verification.)
• Refund a payment. Access revoked? (Tests lifecycle gating.)
• Let a subscription renewal fail. User downgraded? (Tests subscription-state sync.)

What "Done" Looks Like, and When to Get Help

Real Stripe integration is not a checkout button. It is a database that stays in sync with Stripe through verified, idempotent, retry-safe webhooks, with feature access driven by current subscription state. The button took one prompt. This took the rest of the work.

If your AI builder got you the checkout flow and you are now staring at webhook signatures, double-charge bugs, and subscribers who refunded but never lost access, that is the predictable wall - the 30-40% that prompt-loop builders leave for you. We have written about why these tools stall at the same point regardless of which one you pick. When the billing correctness work is the thing between you and charging real money safely, that is the kind of finish-the-hard-part problem Creatr takes on - shipping the webhook handlers, the idempotency, and the subscription sync as production code you can trust with revenue.

Money is the one part of your app where "looks like it works" and "actually works" have very different consequences. Build the boring layer underneath the button.