Stripe Works in Test Mode and Fails in Live Mode

Test mode was perfect. Card 4242 4242 4242 4242 went through every time, the success page rendered, the subscription appeared, the user got access.

You flipped to live mode, made a real payment with a real card, and something went wrong: the charge succeeded but the account did not upgrade, or checkout threw "No such price", or the webhook returned a 400 and Stripe has been retrying ever since. Worst case, you have someone's money and they have nothing.

Stripe's test and live modes are two entirely separate universes that happen to share a dashboard. Nothing crosses between them — not objects, not keys, not webhook endpoints, not settings. Almost every failure here is one of those separations, and they are all fixable in an evening.

Fix the money problem first

Before debugging, deal with the customer. If a real charge succeeded and the user did not get what they paid for, refund or manually provision access now, then tell them. A five-minute email preserves the relationship; discovering it themselves does not.

Then open the Stripe dashboard's Events and Logs views in live mode. Every API call you made is there with its full request and response. The actual error is almost always sitting in that log with a clear message, which beats guessing by a wide margin.

The ten causes, in the order you should check them

1. Test keys still in production

Live secret keys start with 'sk_live_' and test keys with 'sk_test_'. If your production environment still holds test keys, live payments hit test mode and quietly do nothing real.

Check both halves — publishable key in the frontend, secret key on the server — and check them in the deployed environment, not your local file. And remember that build-time variables are baked in: changing an environment variable without redeploying changes nothing. This is the single most common cause and also the most embarrassing to find after two hours.

2. Mixed keys between frontend and backend

Publishable key from live mode, secret key from test mode, or the reverse. The symptom is confusing: the payment form renders and submission fails with an error about the object not existing. Both keys must come from the same mode, always.

3. Products and prices do not exist in live mode

"No such price: price_1ABC..." is the classic. Every product, price, coupon, tax rate, and payment link you created in test mode exists only in test mode. Live mode starts empty.

Recreate them in live mode — which generates new IDs — and make sure your app reads those IDs from environment variables rather than hardcoding them. An AI-generated integration will almost always have hardcoded the test IDs somewhere in a component or a config file. Search for 'price_' across the repo and see how many you find.

4. The live webhook endpoint was never created

Webhook endpoints are per-mode. You configured one in test, possibly through the Stripe CLI, and never added the live one. Payments then succeed and your app never hears about it — which is exactly the "money taken, access not granted" scenario.

Add the endpoint in live mode, pointing at your production URL, subscribed to the events you handle. At minimum: 'checkout.session.completed', 'invoice.paid', 'invoice.payment_failed', and 'customer.subscription.updated' and 'deleted' if you run subscriptions.

5. The webhook signing secret is different

Every endpoint gets its own signing secret, starting 'whsec_'. The one from your local CLI session is not the one for your live endpoint, and the CLI's rotates each run.

The symptom is a 400 with a signature verification failure on every event. Copy the signing secret from the live endpoint's page in the dashboard into your production environment.

6. The webhook body is being parsed before verification

This one is subtle and extremely common in generated code. Signature verification requires the exact raw request body. If your framework's JSON body parser runs first, the payload gets re-serialized and the signature no longer matches — even with the correct secret.

In Express, that means a raw body parser mounted specifically on the webhook route, before the global JSON middleware. In Next.js route handlers, read the raw text before parsing. If you have verified the secret three times and signatures still fail, this is your bug.

7. Real cards behave differently than test cards

Test cards always succeed on demand. Real cards get declined for insufficient funds, get flagged by the issuer, require 3D Secure authentication, or fail on address checks.

3D Secure is the one that surprises people, because it is mandatory for European cards under SCA and generated code frequently ignores it. If your flow assumes a payment intent goes straight from created to succeeded, any card requiring authentication will hang in 'requires_action' forever. Stripe Checkout handles this for you; a custom flow with Payment Elements must handle the next-action step explicitly.

8. Your account is not fully activated

Live mode requires business details, bank account, and identity verification. Partially activated accounts can accept payments and cannot pay out, or are restricted to certain methods. Check the dashboard for outstanding requirements — the banner is easy to dismiss and forget.

9. Localhost URLs in the live configuration

Success and cancel URLs, return URLs, and the webhook endpoint all need production values. 'http://localhost:3000/success' in a live Checkout session sends a paying customer to a page that does not exist on their machine. This is the same class of failure as any other environment variable problem in production.

10. No idempotency, so retries double-charge

Not a go-live failure exactly, but the one that costs the most when it surfaces. Stripe retries webhooks on any non-2xx response, and a user who double-clicks submits twice. Without idempotency keys on charge creation and deduplication on webhook event IDs, both cases can charge twice or provision twice.

Store processed event IDs and ignore repeats. It is twenty lines and it prevents the worst support conversation in SaaS.

Symptom to cause, at a glance

Verify properly before you trust it

Testing live mode means one real payment with a real card. Use a small amount, refund it afterward, and walk the whole path: charge appears in the live dashboard, webhook delivers with a 200, your database updates, the user's access changes, the receipt sends.

Then check the failure paths, because that is where generated integrations are thinnest. Trigger a decline. Cancel a subscription and confirm access is revoked. Replay a webhook from the dashboard and confirm nothing duplicates. Take the app down for a minute and confirm Stripe's retries are handled when it returns.

That last one matters more than it sounds — webhook delivery is the only thing standing between a successful payment and a customer who paid for nothing. Everything else in a payment integration is recoverable; a silent webhook failure is the one that reaches your inbox as a chargeback. If you want the full build-it-right version rather than the debug version, adding Stripe to a SaaS covers the architecture, and error handling in AI-generated apps covers the silent-catch pattern that hides these failures.

Frequently asked questions

Why did my payment succeed but the user got nothing? Almost certainly the webhook. Either the live endpoint does not exist, its signing secret is wrong, or your handler threw an error and returned a non-2xx. Open the endpoint in the live dashboard — it shows every delivery attempt with the response your server sent, which tells you which of the three it is in about ten seconds.

Can I copy my test products to live mode? Not by moving them, but you do not have to recreate them by hand. The Stripe CLI and API can create the same objects against live keys, and some dashboard flows offer a copy action for products. Either way the IDs are new, so your app must read them from configuration rather than having them hardcoded.

Do I need to handle 3D Secure if my customers are all in the US? Today, mostly no — but "all US" tends to stop being true the week after launch, and an unhandled authentication step means those payments silently stall rather than fail loudly. Stripe Checkout handles it for free. If you built a custom flow, handling the requires_action state is an hour of work now versus a mystery bug later.

---

If a live payment has already gone wrong, the problem is usually one of ten specific mismatches — and the same audit that finds it usually finds the missing idempotency too. SprintX hardens payment flows for AI-built apps: webhooks that verify, retries that do not double-charge, and the failure paths nobody generated. Tell us what happened on your first live charge.