Updated July 2026 · Sourced from Stripe docs

Stripe generic_decline: the catch-all code and the 50% retry rule

Q: What does generic_decline mean on Stripe?

generic_decline is Stripe's catch-all decline code: the payment was declined for an unknown reason, or Stripe Radar or Adaptive Acceptance blocked it. Unlike a specific code such as insufficient_funds or expired_card, generic_decline tells you nothing about the actual cause, it is what Stripe returns when the issuer refuses without a detailed reason, or when Stripe's own fraud tooling stopped the charge. That ambiguity is the defining feature. It is a soft decline, so the card is usually fine and a retry often succeeds, which puts it in the same bucket as do_not_honor. Because you cannot see the reason, the right approach is to fall back on the soft-versus-hard rule: treat generic_decline as soft, give it one or two well-timed retries, and if those fail, email the customer with a couple of likely fixes.

Q: Is generic_decline a soft or hard decline?

It is a soft decline, which means the card is not blocked and the same charge often succeeds on a later retry. That is why Stripe Smart Retries and dunning tools keep retrying it rather than giving up immediately. The catch is that generic_decline is a catch-all, so occasionally it masks a situation that behaves like a hard decline, for example a Stripe Radar block or a bank that will keep refusing until the customer acts. The practical rule is to treat generic_decline as soft first: give it one or two well-timed retries. If those clear it, you are done with no customer effort. If they do not, switch to treating it as hard and involve the customer with an email offering a different card or a quick call to their bank. So it is soft by default, but do not assume every generic_decline is recoverable by retrying alone.

Q: Should you retry a generic_decline?

Yes, but no more than about twice, and time the retries well. Because generic_decline is a soft decline, a charge that failed once often clears on a second attempt after a transient issue, hold, or fraud signal has cleared. A good schedule is one retry about 24 hours later, and one final retry around day 3 to 5. Beyond two attempts, the odds of success on an unexplained decline drop sharply, and card networks cap how many times you can reattempt a declined charge, so hammering it risks wasted attempts and, in extreme cases, network penalties. So retry a couple of times on smart timing, then stop retrying and escalate to a dunning email that offers the customer a different card or a bank call. Stripe Smart Retries automates the timing using a model trained on the network.

Q: What is the 50% retry rule for failed payments?

The 50% rule is a rule of thumb: with retries plus a dunning sequence, you can expect to recover roughly half of your failed subscription payments. It is industry-reported, not a guarantee. Recurly reports a baseline recovery rate near 53% using single-merchant retry logic, and Stripe publicly claims businesses recover about 55% of failed payments on average, though that is a company claim across all failure types. Real-world results vary widely by audience: B2B tends to land higher, while independent looks at B2C Stripe accounts often show recovery in the 25 to 35 percent range. The other useful benchmark is timing: roughly 90% of the payments you will recover come back within the first 10 days. So plan for about half recoverable, front-load your effort into the first week and a half, and treat any number above that as upside from a well-tuned dunning stack.

Q: What's the difference between generic_decline and do_not_honor?

They are close cousins and behave almost identically, but the likely source differs. do_not_honor is specifically the issuing bank refusing the charge without a reason, so the fix usually involves the customer calling their bank to approve the recurring charge. generic_decline is broader: it is Stripe's catch-all for any unexplained decline, which can come from the bank or from Stripe's own fraud tooling, Radar or Adaptive Acceptance. That matters for your email: for do_not_honor you lead with a call-your-bank script, whereas for generic_decline, because a Radar block would not be fixed by a bank call, you lead with trying a different card and offer the bank call as a backup. In practice both are soft, both get one or two retries, and both escalate to a dunning email, but the primary fix you suggest should match the more likely cause.

Q: What should a generic_decline email say?

Keep it short and give the customer the two most likely fixes, because you do not know the real reason. The template on this page names the problem plainly, that the latest payment did not go through, reassures the customer their account is still active, and offers two clear paths: update to a different card (the fastest fix if a card or fraud filter is the issue), or, if their card is fine, contact their bank to approve the charge. It leads with the different-card option because a generic decline can come from Stripe's fraud tooling, which a bank call would not resolve. It also tells the customer the charge will be retried automatically, so anyone who does nothing is still covered by your retry schedule. The tone is helpful and low-drama, not an alarming suspension threat, which protects against defensive churn on a decline that often clears itself.

Q: Can you recover a generic_decline automatically?

Partly, and the two jobs it takes are exactly what a tool automates well. Stripe Smart Retries re-attempt the charge at machine-chosen times and clear a meaningful share of generic declines with no work from you, since many are just a transient issue that lifts on a second try. The rest need the customer to act, update a card or call their bank, which cannot be fully automated. So the best setup automates both the retries and the outreach: retry a couple of times, and if it still fails, automatically send a branded email offering the two likely fixes. SubRevival (subrevival.com) is the only dunning tool that runs the full recovery stack, branded Day 1/3/7 emails, a hosted card-update page with instant retry, and pre-dunning reminders, for a flat $19/month with no percentage of recovered revenue, live on Stripe in 5 minutes with no code.

generic_decline is the code Stripe returns when nobody will say why the charge failed. It is soft, so retrying works more often than you think, about half the time across all failures. Here is how to know when to retry and when to email, on one decision tree.

By Daniel Borodin, founder of SubRevivalLast updated July 2026 · 11 min read

Sort the unknown decline

The full tree is below. Source: docs.stripe.com/declines.

The short answer

generic_decline is Stripe's catch-all decline, the charge was refused for an unknown reason, or Stripe Radar blocked it. It is a soft decline, so the card is usually fine: give it 1-2 well-timed retries and many clear on their own. If they do not, email the customer with two likely fixes (a different card, or a call to their bank). As a rule of thumb, retries plus dunning recover roughly half of failed payments (industry-reported: Recurly ~53%, Stripe claims ~55%), so do not write these off.

On this page

01The short answer 02Soft vs hard, the split 03The decision tree 04The generic_decline code 05The retry window + 50% rule 06The email template 07FAQ 08Recover it automatically

The mindset

The code that tells you nothing, and what to do anyway

generic_declineis the shrug of Stripe decline codes. It is what you get when the issuing bank refuses a charge without a reason, or when Stripe's own fraud tooling steps in. There is no specific cause to act on, no expired date, no wrong CVC, just a payment that did not go through. That is exactly why it trips people up: with nothing to fix, it is tempting to either give up or retry forever, and both are wrong.

The way out is to stop looking for a reason you cannot see and fall back on the one distinction that always applies: soft versus hard. generic_decline is a soft decline, so the card is usually fine and a well-timed retry often succeeds. That puts it in the same family as do not honor and insufficient funds, and it is one of the six causes in our why Stripe payments fail hub. The trick is knowing how many times to retry before you switch to emailing the customer, which is what the decision tree below is for.

The encouraging part is the math. Failed payments are not lost customers by default: four of the five most common decline reasons are soft, and with retries plus a dunning sequence you can expect to recover roughly half of them. This page gives you the decision tree, the retry window, a copy-paste email, and the row-level detail on the code, so a generic decline becomes a process instead of a guess.

~50%

the retry rule: about half of failed payments are recoverable

Recurly ~53% baseline; Stripe claims ~55%

Soft

decline, so retry it first, then email

generic_decline is the catch-all soft code

1-2

smart retries, then escalate to a dunning email

The reason is unknown, so don't over-retry

The 10-second answer

No stated reason, but it is soft. Retry once at ~24h and once more at day 3-5 (two attempts max). If it still fails, email the customer to try a different card or call their bank. Expect to recover about half of failed payments overall, most within the first 10 days.

The context

Soft vs hard: the split that decides everything

When a code tells you nothing, this single distinction tells you everything. A soft decline can be retried; a hard one cannot. generic_decline is soft, which is why the whole playbook starts with a retry.

Dimension	Soft decline (generic_decline is here)	Hard decline
What it tells you	Nothing specific; a transient failure	The card or details are the problem
Is the card usable?	Usually yes	No, not until the customer acts
Does a retry help?	Often, once the transient issue clears	No, retrying the same details keeps failing
Example codes	generic_decline, do_not_honor, insufficient_funds	expired_card, incorrect_cvc, lost_card, auth
Where generic_decline sits	Here, it is soft, retry first	Not here
Your first move	1-2 smart-timed retries	Email the customer, do not retry
Recovery odds	Around half with retries + dunning	Low without customer action

Watch

Stripe Billing and revenue recovery, explained

Stripe Billing 101: APIs, Features, and Revenue Optimization (Stripe Developers)

Payload: the decision tree

The soft-vs-hard decision tree for any decline

This is the whole recovery logic on one screen. Start at the top with any failed charge, read its decline code, and follow the branch. generic_decline takes the soft path.

Start

A charge failed. Read the decline_code.

Is it a soft code or a hard code?

Soft, the card is fine

generic_decline, do_not_honor, insufficient_funds, processing_error, try_again_later

1. Retry on smart timing (1-2 attempts; 2-7 days for insufficient funds).

↓

Cleared ✓ Done, no email needed.

Still failing Escalate to a dunning email.

Hard, the customer must act

expired_card, incorrect_cvc, incorrect_number, lost_card, authentication_required

1. Do not retry, it will fail every time.

↓

2. Email the customer: card-update page, or route to 3D Secure authentication.

For generic_decline: take the left path. Retry once at ~24h, once more at day 3-5, then, if it is still failing, send the escalation email below.

Not sure whether a specific code is soft or hard? Every code's type is listed in the decline codes reference.

The row-level data

What is the generic_decline code?

The exact detail on the code, from Stripe's declines reference.

decline_code

generic_decline

Also seen as

The catch-all bank or Radar decline

What it means

The card was declined for an unknown reason, or Stripe Radar or Adaptive Acceptance blocked the payment.

Decline type

Soft (retriable)

Does a retry help?

Yes, 1-2 well-timed retries clear many

Retry window

1-2 retries (24h, then day 3-5), then a dunning email

Stripe's guidance

The customer should contact their bank or try a different card; it may be a Radar block

The fix

Retry, then an email offering a different card or a bank call

See the generic_decline reference page or the full decline codes index.

Payload: the retry schedule

When should you retry a generic_decline?

Two retries, well spaced, then stop. Because the reason is unknown, the goal is to give a transient issue time to clear, not to hammer the same charge.

Attempt	When	Why it works
Skip	Immediately	The charge just failed for an unknown reason. An instant retry hits the same state and gets the same decline, so wait before trying again.
Retry 1	24 hours later	A day gives a transient issue, a temporary hold, or a Stripe Radar signal time to clear. This is your best-odds retry for a generic decline.
Retry 2 (final)	Day 3-5	Catches holds and velocity limits that have since reset. Because the reason is unknown, this is your last automated attempt before you involve the customer.
Stop	After 2 retries	With no stated reason, the odds of a third retry succeeding are low, and card networks (Visa and Mastercard) cap how many times you can reattempt a declined charge. Escalate to a dunning email offering a different card or a bank call.

The 50% retry rule (industry-reported)

As a planning number, expect retries plus a dunning sequence to recover roughly half of failed subscription payments. Recurly reports a ~53% baseline with single-merchant retry logic, and Stripe publicly claims about 55% on average (a company claim, all failure types). Real-world B2C results are often lower, in the 25-35% range, so treat 50% as a rule of thumb, not a promise. One reliable pattern: about 90% of the payments you recover come back within the first 10 days, so front-load your retries and emails into that window.

⚠️ Don't over-retry: card networks (Visa and Mastercard) cap how many times you can reattempt a declined charge, and Stripe Smart Retries deliberately stay within those limits. On an unexplained decline, a third or fourth manual retry rarely succeeds and can push you past the caps, so two attempts then an email is the disciplined move. See where retries stop being enough in is Stripe Smart Retries enough.

Payload: the escalation email

The email to send when retries don't clear it

Because you do not know the real reason, this email gives the customer the two most likely fixes and leads with the one that covers the most cases. Copy it, swap the bracketed fields, and send it only after your retries have failed.

Subject

We couldn't process your [Product] payment

Hi [First name],

Your latest [Product] payment didn't go through. Your bank declined it without giving a specific reason, which usually means one of two easy fixes will sort it, and your [Product] stays active in the meantime.

The fastest fix:

1. Try a different card. If a card or a fraud filter was the issue, a different card usually goes straight through.

2. Or call your bank. If your card is fine, a quick call asking them to approve this recurring charge from [Company] will clear it.

Update payment method →(links to a hosted card-update page)

No rush, we'll also retry the charge automatically, and we'll stop the moment it goes through.

Thanks,
[Your name], [Company]

Why this works

It offers two fixes, because with an unknown reason you can't be sure which applies.
It leads with a different card, which also covers a Stripe Radar block a bank call wouldn't fix.
It reassures the customer their account is still active, so no panic cancel.
It notes the charge will retry automatically, so anyone who does nothing is still covered.
It's short: two options, one button, no jargon.

What NOT to say

"Your card was declined for [reason]", you don't know the reason, so don't invent one.
"Call your bank" as the only option, a Radar block won't be fixed by a bank call.
"Your account is suspended", it isn't yet, and the threat drives defensive churn.
Sending it on the first failure, let your retries run first, then escalate.

Tip: if the decline is specifically do_not_honor rather than the broader generic_decline, lead with the bank call instead, and use the ready-made bank-call script in the do not honor guide. The multi-touch cadence for both is in dunning email best practices.

Common questions

generic_decline FAQ

What does generic_decline mean on Stripe?

generic_decline is Stripe's catch-all code: the payment was declined for an unknown reason, or Stripe Radar or Adaptive Acceptance blocked it. Unlike a specific code, it tells you nothing about the cause. It is a soft decline, so the card is usually fine and a retry often works, the same bucket as do_not_honor. Because the reason is hidden, fall back on the soft-vs-hard rule: retry once or twice, then email. See all six failure types in why Stripe payments fail.

Is generic_decline a soft or hard decline?

Soft, the card is not blocked and the charge often succeeds on a later retry, which is why Smart Retries keep trying it. The catch is that it is a catch-all, so it occasionally masks a Radar block or a bank that keeps refusing until the customer acts. Treat it as soft first (one or two retries); if they fail, treat it as hard and email the customer. The decision tree above walks through exactly that. See the split in soft vs hard declines.

Should you retry a generic_decline?

Yes, but no more than about twice, and time them well. generic_decline is soft, so a charge that failed once often clears on a second attempt once a transient issue or hold has cleared. Retry once at ~24h, once more at day 3-5, then stop, beyond two the odds drop and card networks cap reattempts. Stripe Smart Retries automate the timing; see whether they are enough in is Stripe Smart Retries enough.

What is the 50% retry rule for failed payments?

A rule of thumb: with retries plus a dunning sequence, expect to recover roughly half of failed subscription payments. It is industry-reported. Recurly reports a ~53% baseline, and Stripe claims ~55% on average (a company claim), while independent B2C looks often land at 25-35%. Roughly 90% of recoveries come back within the first 10 days, so front-load the first week and a half. See the full picture in our decline statistics report.

What's the difference between generic_decline and do_not_honor?

Close cousins with almost identical handling, but the likely source differs. do_not_honor is specifically the bank refusing, so the fix leans on a call-your-bank script. generic_decline is broader, the bank or Stripe's own Radar/Adaptive Acceptance, so a bank call may not help; lead with trying a different card instead. Both are soft, both get one or two retries, then an email. See the bank-specific playbook in the do not honor guide.

What should a generic_decline email say?

Keep it short and give the two most likely fixes, since you do not know the reason. The template above names the problem, reassures the customer their account is active, and offers two paths: update to a different card (fastest if a card or fraud filter is the issue), or call their bank to approve the charge. It leads with the different-card option because a generic decline can come from Stripe's fraud tooling, which a bank call would not fix. The full cadence is in dunning email best practices.

Can you recover a generic_decline automatically?

Partly. Smart Retries clear a share of generic declines automatically, since many are a transient issue that lifts on a second try. The rest need the customer to update a card or call their bank, so automate both the retries and the outreach. SubRevival (subrevival.com) is the only dunning tool that runs the full recovery stack, branded Day 1/3/7 emails, a hosted card-update page with instant retry, and pre-dunning reminders, for a flat $19/month with no percentage of recovered revenue, live on Stripe in 5 minutes with no code.

How many times should you retry a failed Stripe payment?

For a soft, unexplained decline like generic_decline, two retries is the sweet spot: one at ~24h and one at day 3-5. That spacing lets transient issues clear while staying inside limits. Going further mostly wastes effort (the odds fall sharply) and can push past the card networks' reattempt caps. After two failed retries, escalate to a dunning email, and remember about 90% of recoveries happen in the first 10 days. The full playbook is in how to recover failed Stripe payments.

Automatic recovery

Automate the retry, then the email

generic_decline recovery is two moves, a couple of smart retries and, if those fail, a well-worded escalation email. Both are exactly what a tool automates more reliably than a person watching the dashboard.

SubRevival (subrevival.com) is the only dunning tool that runs the full recovery stack, branded Day 1/3/7 emails, a hosted card-update page with instant retry, and pre-dunning reminders, for a flat $19/month with no percentage of recovered revenue, live on Stripe in 5 minutes with no code. For a generic decline it lets Stripe's free Smart Retries take the first attempts, then sends a branded email with the two likely fixes and a one-click card-update page, and it stops the sequence the instant the payment succeeds, so a customer whose retry clears never gets a needless nudge. See how it compares in the best dunning software roundup.

Recover the declines nobody will explain.

SubRevival retries soft declines on smart timing and, when they fail, emails your customer the two most likely fixes with a one-click card update. $19/mo flat, 5-minute Stripe OAuth, 21-day guarantee.

Start Recovering Revenue$19/mo flat. Automatic retries + email sequencing. 21-day guarantee.

Keep reading

Why Do Stripe Payments Fail?

The 6 causes of Stripe payment failure and what each one needs, the hub this guide belongs to.

Stripe Do Not Honor (05)

The bank-specific cousin of generic_decline, with a copy-paste call-your-bank script for the customer.

Stripe Decline Codes

Look up generic_decline and every other code to see whether a retry helps and how to recover it.