Most failed Stripe subscription payments are not a bug in your integration. The customer's bank refused the charge, and it almost always gives one of four answers: there isn't enough money on the card (insufficient_funds), the card expired or was replaced (expired_card), the bank declined without saying why (generic_decline or do_not_honor), or the bank wanted a 3D Secure confirmation the customer wasn't there to give (authentication_required). Each one has a different fix, and only the first one tends to clear up just by retrying.
If many payments started failing at the same time, that's a different problem, and it's usually on your side. That case has its own section further down.
See why yours are failing. Free audit of the last 90 days, by decline code. No signup, 30 seconds.
Run free payment audit →How to see why a payment failed
In the Stripe Dashboard, open Payments, filter by Failed and click a payment. The failure reason and the decline code are in the payment details. For subscriptions, Billing > Invoices filtered by Past due shows the invoices that are still unpaid, and each one links to the charge that failed.
Pay attention to whether the payment was declined or blocked. Declined means the bank said no. Blocked means Stripe's fraud filter (Radar) stopped it before it reached the bank. A blocked payment won't be fixed by talking to the bank. You have to look at your Radar rules.
Looking at one payment at a time doesn't show the pattern. What matters is the mix: how many of the last 90 days were insufficient funds, how many were expired cards. That decides what to fix first. Our free Stripe audit pulls that breakdown in about 30 seconds, with read-only access and no signup.
The common reasons, and what fixes each
| Decline code | What happened | Does a retry help? | What fixes it |
|---|---|---|---|
| insufficient_funds | Not enough balance or credit at that moment | Often, a few days later | Retry near common paydays. Tell the customer, since some will switch to another card. |
| expired_card | The card on file is past its expiry date | No | The customer needs to enter a new card. Stripe's card updater catches some of these automatically. |
| generic_decline / do_not_honor | The bank refused and didn't say why | Sometimes, once | Retry once. If it fails again, ask the customer to call the bank or use another card. |
| authentication_required | The bank wants 3D Secure, and the customer wasn't present | No | Send the customer a link where they can confirm the payment themselves. |
| lost_card / stolen_card | The card was reported lost or stolen | Never | Stop retrying and ask for a new payment method. |
| incorrect_cvc | Card details were typed wrong (usually on the first charge) | No | The customer has to re-enter the card. |
The full list, with recovery advice for each code, is in our Stripe decline code reference and the longer decline codes explained guide. If you're wondering whether your overall failure rate is high, see what a normal failed payment rate looks like.
Each decline code needs a different fix. Retrying only helps for some of them.
What retries recover, in real data
Across the Stripe accounts that run on Rebounce (a small group of subscription businesses, most of them in Mexico and Latin America), these are the numbers up to September 2026:
Two caveats. The sample is small. And our retries run on top of Stripe's own, so the payments we retry are the ones Stripe's retries had already missed. Even so, the gap is large: retrying a card that is expired, flagged or waiting on 3D Secure doesn't change the bank's answer. Most failed payments get paid when the customer finds out and has an easy way to pay.
When it's your side: many payments failing at once
If the failures started on a specific day, or most charges fail with the same code, check these before blaming the banks:
- Radar rules. A new or overly strict rule can block legitimate payments. Blocked payments show up as blocked, not declined.
- 3D Secure on renewals. If your integration doesn't handle
requires_actionfor off-session charges, every renewal the bank sends to 3D Secure fails. This is common with European cards. - First charge failing at checkout. Subscriptions created with a failed first payment sit as incomplete and expire after 23 hours. These are checkout problems, not renewals.
- Account status. Look for a banner in the Dashboard. Stripe can restrict an account that needs more verification.
- Currency or card type. Prepaid cards, and debit cards used for cross-border charges, fail more often. If your customer base changed recently, the failure rate can change with it.
What to do about it, in order
- Look at the mix of decline codes for the last 90 days. That tells you whether you have a retry problem (insufficient funds) or a reach-the-customer problem (expired cards, 3D Secure, generic declines).
- Turn on Smart Retries and the card updater in your Stripe Billing settings, if they're off. They cost nothing. See our card updater guide.
- Tell the customer, with a direct link to pay. No login, no password reset. One link that opens a page where they enter a new card or confirm 3D Secure.
- Use the channel they read. Email works for some customers. In Latin America, many people read WhatsApp much sooner than email.
- Warn before cards expire. A short email 30 days before the expiry date prevents a share of the expired-card failures.
Steps 3 to 5 are what Rebounce does on top of Stripe: it sees the failure, retries when the decline code makes it worth it, and reaches the customer by email, SMS or WhatsApp with a link to pay. If you'd rather do it by hand, our template library has the emails and messages.