7 Things That Break Stripe Integrations in Production

Stripe integrations look fine in testing and then break in production: silent webhook failures, idempotency bugs, race conditions on subscription updates, currency rounding errors. Below are 7 real failure patterns, plus where to get the full checklist.

1. Webhook signature verification skipped in a code path

Teams verify signatures on the main webhook route but add a second internal endpoint (for retries or admin tools) that skips verification. Attackers find it.

2. No idempotency key on retried charges

Network retries without an idempotency key double-charge customers during transient failures. This is the single most common support-ticket generator.

3. Currency rounding on multi-currency plans

Converting minor units incorrectly (cents vs. whole units) causes off-by-100x charges. Always store amounts in the smallest currency unit and never do float math.

4. Race condition between subscription.updated and invoice.paid

Handling these two webhooks in the wrong order flips a customer's access on and off. Order is not guaranteed by Stripe; your handler has to be idempotent and order-independent.

5. Trusting client-side price IDs

If the price ID comes from the frontend instead of being looked up server-side, a modified request can buy the wrong product at the wrong price.

6. No handling for disputed or expired cards mid-cycle

Subscriptions silently churn when a card expires and the app never listens for invoice.payment_failed with proper dunning.

7. Test-mode keys leaking into production config

A single environment variable mix-up processes real orders against test mode (or vice versa), losing real revenue with no error shown to the user.

Full checklist (all 7 items expanded with fixes, plus a pre-launch review sheet) is a $9 one-time download:

Get the Stripe Production Checklist — $9

Longer write-up: dev.to/saasfactory