Updated July 2026 · Sourced from Stripe docs

Stripe do_not_honor (05): the decline with no reason attached

Q: What does do_not_honor mean on Stripe?

do_not_honor (known in card-network terms as response code 05) means the customer's issuing bank refused the charge and, on purpose, did not say why. Stripe surfaces it as "the card was declined for an unknown reason," and the bank withholds the specific reason so it does not reveal its fraud-detection logic. It is not a sign the card is dead or the customer canceled: the card is usually fine and the account is open. It is simply the bank declining a charge it did not like at that moment, often a recurring payment it did not recognize, a velocity limit, or a temporary risk flag. Because the reason is hidden, do-not-honor is the most common and most ambiguous decline you will see, and the fix depends on which of several hidden causes is actually behind it.

Q: Is do_not_honor 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. But do-not-honor is the trickiest soft decline, because its opacity means it can occasionally be masking a genuinely hard situation: a card the bank quietly closed, a real fraud hold, or a recurring authorization the customer revoked. In those cases no retry will ever work. The practical rule is to treat do-not-honor as soft first, give it one or two well-timed retries, and if those fail, treat it as hard and get the customer involved with a call to their bank or a different card. So it is soft by default, but you should not assume every do-not-honor is recoverable by retrying.

Q: Should you retry a do_not_honor decline?

Yes, but no more than about twice, and time the retries well. Because do-not-honor is a soft decline, a charge that failed once often clears on a second attempt, especially if you move it to a different time of day, since issuer risk models score transactions differently overnight versus business hours. A good schedule is one retry 12 to 24 hours later at a new time of day, and one final retry around day 3 to 5, after any temporary hold or velocity limit has had time to reset. Beyond two retries, your odds fall below roughly 10% and, worse, hammering a flagged charge can get your merchant account flagged by the issuer, which raises declines for all of your customers. So retry a couple of times, then stop and switch to a customer-facing fix.

Q: Why did my bank say "do not honor"?

Because the bank decided not to approve that specific charge and, by design, did not tell you which of many reasons applied. The most common triggers are a recurring charge the bank did not recognize, a velocity limit (too many charges in a short window), an unusual spending pattern versus the cardholder's history, a geographic mismatch between merchant and cardholder, an internal risk threshold on that card, or a temporary account restriction the customer has not been told about. Stripe's own guidance is that the only way to learn the real reason is for the customer to contact their issuing bank. That is the whole difficulty with do-not-honor: it is one code standing in for a dozen different situations, so the recovery move is to try a couple of retries and, if they fail, get the customer to ask their bank directly.

Q: What should a do_not_honor email say?

It should make one thing unmistakably clear: the bank declined this, not you, and the fastest fix is a two-minute call to the bank. Unlike an insufficient-funds email, you are not asking the customer to wait, and unlike an expired-card email, you are not simply asking for a new card, though offering one as a fallback is smart. The most valuable thing you can give the customer is the exact words to say to their bank, because most people do not know how to ask a bank to approve a recurring charge. The template on this page hands them a ready-made script: it names the merchant, the amount, and the date, states that the subscription is wanted, and asks the bank to approve this charge and future recurring payments. That last part matters, so the same decline does not repeat next month.

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

insufficient_funds tells you exactly why the charge failed, the account was short, whereas do_not_honor gives you no reason at all. Both are soft declines a retry can recover, but they need different timing and different messaging. For insufficient funds you know the fix is time, so you retry on a payday-aware schedule of 2 to 7 days and, if you email, you reassure the customer that their card is fine. For do-not-honor you do not know the cause, so you retry only once or twice at different times of day, and if that fails the fix is usually on the bank's side, so your email hands the customer a script to call their bank. In short: insufficient funds is a timing problem you solve with patience, and do-not-honor is an opacity problem you solve with a bank call.

Q: Can you recover a do_not_honor decline automatically?

Partly. Stripe Smart Retries automatically re-attempt the charge at machine-chosen times and clear a meaningful share of do-not-honor declines with no work from you, because many are just a temporary risk flag that lifts on a second try. But the rest need the customer to act, usually a quick call to their bank to approve the recurring charge, and that part cannot be fully automated. The best you can do is automate the retries and the outreach: retry a couple of times, and if it still fails, automatically send a branded email with a call-your-bank script and a one-click option to switch cards. 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.

Q: How many times should you retry do_not_honor?

No more than about twice. Because the card is not blocked, a first retry has a genuine chance, particularly if you shift it to a different time of day so it hits the issuer's risk model in a new state. A second retry a few days later catches holds and velocity limits that have since reset. But there is a hard ceiling: beyond two attempts your conversion probability drops below roughly 10%, and repeatedly retrying a charge the issuer keeps declining can get your merchant account flagged, which increases declines for every customer you have, not just this one. So the discipline is two well-spaced, well-timed retries maximum, then stop retrying and move to a customer-facing recovery, an email with a bank-call script or a request to use a different card.

The bank blocked the charge and, on purpose, did not say why. It is the most common decline you will see, and the one most people give up on. A couple of timed retries clear many; the rest need the customer to say the right words to their bank. This page gives them the words.

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

What the bank actually returns

Soft decline, hidden reason. Source: docs.stripe.com/declines.

The short answer

do_not_honor (card-network response code 05) is a generic decline from the customer's bank, it blocked the charge and, on purpose, did not say why. It is a soft decline, so 1-2 well-timed retries (ideally at a different time of day) recover many. When they do not, the fix is on the bank's side: email the customer a short script to call their bank and approve the recurring charge, or switch cards. Do not over-retry, beyond about two attempts you risk the issuer flagging your merchant account.

On this page

01The short answer 02do_not_honor vs the family 03The do_not_honor code (05)04When to retry, when to stop 05The call-your-bank email + script 06What you can't fix 07FAQ 08Recover it automatically

The mindset

The most common decline is also the most misread

do_not_honoris the code you will see more than any other, and it is the one most teams handle worst. The instinct is to assume the worst, that the customer's card is dead or they have silently churned. Usually neither is true. The card is fine and the account is open. The bank simply declined this particular charge and, by design, refused to tell you or the customer why.

That deliberate silence is the whole story of this decline. Banks withhold the reason on purpose, so they do not reveal their fraud-detection logic to anyone who might exploit it. So one code, do-not-honor, ends up standing in for a dozen different situations: a recurring charge the bank did not recognize, a velocity limit, an unusual spending pattern, a temporary hold. It is soft, so a retry often works, but because you cannot see the cause, you have to be smart about how many times you try and when you stop. It is one of the six causes in our why Stripe payments fail hub, and the most opaque of them all.

The two things that actually recover a do-not-honor decline are a couple of well-timed retries and, when those fail, handing the customer the exact words to say to their bank. This page gives you both, the retry window and a copy-paste email with a bank-call script, plus an honest section on the do-not-honor declines you genuinely cannot fix.

the card-network response code for "do not honor"

Shown as do_not_honor in Stripe

Soft

decline, so a couple of retries recover many

But the most opaque code there is

2 max

retries before you risk a merchant flag

Retry at a different time of day (docs.stripe.com)

The 10-second answer

The bank declined it without a reason. Retry once at a different time of day and once more around day 3-5 (two attempts max), and if it still fails, email the customer a script to call their bank and approve the recurring charge, or offer a different card. Do not keep retrying, it can flag your merchant account.

The context

do_not_honor vs generic_decline vs card_declined

do-not-honor belongs to a family of vague bank declines that look almost identical and get confused constantly. They are all soft and all opaque, but knowing which one you have shapes the message you send.

Dimension	do_not_honor (this guide)	generic_decline	card_declined
What the bank told you	Nothing, it just said "do not honor"	Nothing, a catch-all refusal	Nothing beyond "the issuer declined"
Why it's vague	Deliberate, to hide fraud logic	No detailed code returned	The high-level result when no code is given
Decline type	Soft (retriable)	Soft (retriable)	Soft (retriable)
Does a retry help?	Sometimes, 1-2 timed retries	Sometimes, 1-2 timed retries	Sometimes, treat like a generic decline
Best next move	Retry, then a call-your-bank email	Retry, then suggest a different card	Retry, then a card-update email
How common	The single most common decline	Very common	Common

All three behave the same way in practice: retry once or twice, then get the customer involved. Look any of them up in the decline codes reference.

Watch

Stripe Billing and revenue recovery, explained

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

The row-level data

What is the do_not_honor decline code?

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

decline_code

do_not_honor

Also seen as

Card-network response code 05

What it means

The issuing bank refused the charge and, deliberately, gave no specific reason.

Decline type

Soft (retriable), but the most opaque decline

Does a retry help?

Sometimes, 1-2 well-timed retries clear many

Retry window

1-2 retries, at a different time of day, then stop

Stripe's guidance

"The card was declined for an unknown reason. The customer needs to contact their card issuer for more information."

The fix

A couple of timed retries, then an email with a call-your-bank script (or a different card)

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

Payload: the retry schedule

When should you retry a do_not_honor decline?

Retry sparingly and smartly. Because you cannot see the reason, the goal is to give the issuer's risk model a fresh look in a new state, not to hammer the same charge. Here is a two-attempt schedule and, crucially, when to stop.

Attempt	When	Why it works
Skip	Immediately	An instant retry hits the same risk state and gets the same decline. Give the issuer's risk model time to re-evaluate before you try again.
Retry 1	12-24h later, at a different time of day	Issuer risk models score charges differently through the day. A charge declined overnight often clears during business hours, so shift the retry into a new window.
Retry 2 (final)	Day 3-5	Long enough for a temporary hold or a velocity limit to reset, or for the customer to have called their bank after your email. This is your last automated attempt.
Stop	After 2 retries	Beyond two attempts, conversion falls below roughly 10% and repeated tries on a flagged charge can get your merchant profile flagged, which raises declines across all your customers. Switch to the email, the bank-call script, or a different card.

⚠️ The over-retry trap: do-not-honor tempts you to keep trying because the card is not technically blocked. Resist it. Repeatedly retrying a charge the issuer keeps declining can flag your merchant account for suspicious activity, which raises declines for every customer you have, not just this one. Two well-timed attempts, then stop. Stripe Smart Retries space attempts using a network-trained model, see whether it is enough on its own in is Stripe Smart Retries enough.

Payload: the call-your-bank email

The email that fixes it, with the exact bank script

When retries fail, the fix is on the customer's side, but most people have no idea how to ask a bank to approve a recurring charge. So do not just tell them to call, give them the words. Copy this, swap the bracketed fields, and note the ready-made script in the middle.

Subject

Your bank declined your [Product] payment (a 2-minute fix)

Hi [First name],

Your latest [Product] payment didn't go through, but the block came from your bank, not from us. Your card looks fine on our side. Your bank returned a generic "do not honor" response, which means it declined the charge without telling us why. This is common when a bank sees a recurring charge it doesn't recognize.

The fastest fix is a 2-minute call to the number on the back of your card. Here's exactly what to say:

Read this to your bank

"Hi, I'm seeing a declined charge from [Company] for [$amount] on [date]. It's a subscription I want to keep. Can you approve this charge and allow future recurring payments from this merchant?"

As soon as they approve it, we'll retry automatically, or you can use the button below to pay now or switch to a different card.

Approve / update card →(links to a hosted payment page)

Your [Product] stays active while we sort this out. Thanks for sticking with us.

[Your name], [Company]

Why this works

It names the real culprit (the bank, not your product), so the customer isn't confused or annoyed.
It hands them the exact words, so the bank call takes 2 minutes, not 20.
The script asks the bank to approve future recurring charges, not just this one, so it doesn't repeat next month.
It offers a different card as a one-click fallback for anyone who can't call.
It keeps the subscription active, so there's no panic and no defensive cancel.

What NOT to say

"Your card was declined", it blames the card, which is usually fine; blame the bank's decision instead.
"Update your payment method" as the only option, many do-not-honor declines are fixed by a bank call, not a new card.
"Your account will be suspended", panic drives defensive cancels on a charge that often just needs a retry.
A vague "please contact your bank" with no script, most customers won't know what to ask for.

Tip: send this only after your one or two retries have failed, not on the first decline. Many do-not-honor charges clear on a second attempt, so leading with a bank-call email would send people chasing a fix they did not need. The full multi-touch cadence and per-code tone are in dunning email best practices.

The honest part

What you can't fix about do_not_honor

Here is the part the other guides skip. Because do-not-honor hides its reason, it sometimes masks a genuinely hard situation that no retry and no script will ever recover. Recognizing these early saves you from burning retries and annoying customers. If two retries and a bank-call email have not worked within about a week, it is probably one of these.

A card the bank quietly closed, or reported lost or stolen

Banks often return a generic do-not-honor instead of a specific lost or stolen code, precisely to avoid tipping off fraud. If that is the real cause, the card will never work again, no matter how you retry. The only fix is a brand-new card from the customer.

A genuine fraud hold the cardholder must clear

Sometimes the bank really has flagged the transaction and is waiting for the cardholder to confirm it is legitimate, often via an app notification or a call. Until they do, every retry fails. Your email can prompt them, but you cannot resolve it for them.

The customer revoked the recurring authorization

If the cardholder told their bank to stop this specific recurring payment, the bank blocks it at the source and returns do-not-honor. Retries are dead on arrival. This one needs a direct conversation about whether they want to continue at all.

Your merchant-side risk factors

Cross-border mismatches, your merchant category code, or a merchant profile already flagged for too many retries can all trigger do-not-honor, and none of those are things the customer can fix. Over-retrying makes this worse, not better.

The honest rule: treat do-not-honor as soft for the first two retries and one bank-call email. If it still fails, stop treating it as recoverable-by-retry and treat it as a hard decline: ask for a different card, or accept that this customer needs to act before anything can succeed. Knowing when to stop is as valuable as knowing how to retry, more on that in how to recover failed Stripe payments.

Common questions

do_not_honor FAQ

What does do_not_honor mean on Stripe?

do_not_honor (card-network response code 05) means the customer's issuing bank refused the charge and, on purpose, did not say why. Stripe shows it as "the card was declined for an unknown reason"; the bank hides the reason so it does not reveal fraud logic. The card is usually fine, so it is a soft decline. It is the single most common and most opaque failure. See where it sits among the six causes in why Stripe payments fail.

Is do_not_honor 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. But it is the trickiest soft decline, because its opacity means it can occasionally mask a hard situation (a closed card, a real fraud hold, a revoked authorization) where no retry works. Treat it as soft first: one or two timed retries, then if those fail, treat it as hard and involve the customer. See the split in soft vs hard declines.

Should you retry a do_not_honor decline?

Yes, but no more than about twice, and time them well. do-not-honor is soft, so a charge that failed once often clears on a second attempt, especially at a different time of day (issuer risk models score charges differently overnight vs business hours). Retry once at 12-24h, once more at day 3-5, then stop. Beyond two, odds fall below ~10% and hammering a flagged charge can get your merchant account flagged. Smart Retries automate this, see whether it is enough in is Stripe Smart Retries enough.

Why did my bank say "do not honor"?

Because the bank chose not to approve that charge and, by design, did not say which reason applied. Common triggers: a recurring charge the bank did not recognize, a velocity limit, an unusual spending pattern, a geographic mismatch, an internal risk threshold, or a temporary hold. Stripe's guidance is that the only way to learn the real reason is for the customer to call their issuing bank, which is exactly what the email template on this page helps them do.

What should a do_not_honor email say?

It should make one thing clear: the bank declined this, not you, and the fastest fix is a two-minute call to the bank. The most valuable thing you can hand the customer is the exact words to say, because most people do not know how to ask a bank to approve a recurring charge. The template above gives them a ready-made script that names the merchant, amount, and date and asks the bank to approve this and future charges. The full cadence is in dunning email best practices.

What's the difference between do_not_honor and insufficient_funds?

insufficient_funds tells you exactly why (the account was short); do_not_honor gives no reason. Both are soft, but they need different handling. For insufficient funds you retry on a payday-aware 2-7 day schedule and reassure the customer their card is fine. For do-not-honor you retry only once or twice at different times of day, then hand the customer a script to call their bank. See the timing playbook in the insufficient-funds guide.

Can you recover a do_not_honor decline automatically?

Partly. Smart Retries clear a share of do-not-honor declines automatically, since many are a temporary flag that lifts on a second try. The rest need the customer to call their bank, which cannot be fully automated, so automate the retries and the outreach instead. 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 do_not_honor?

No more than about twice. A first retry has a genuine chance, especially at a different time of day; a second a few days later catches holds that have reset. But beyond two attempts your odds drop below ~10% and repeatedly retrying a charge the issuer keeps declining can get your merchant account flagged, which raises declines for every customer. Two well-timed retries maximum, then move to the email + bank-call script. Look up the code in our do not honor reference.

Automatic recovery

Automate the retries and the bank-call email

do-not-honor recovery is two jobs: a couple of smart retries, then a well-worded email that hands the customer a bank-call script. Both are exactly the kind of thing a tool does more reliably than a human 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 do-not-honor it lets Stripe's free Smart Retries take the first couple of attempts, then sends a branded email with the call-your-bank script 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 the bank won't explain.

SubRevival retries do-not-honor charges on smart timing and, when they fail, emails your customer a ready-made bank-call script with a one-click card update. $19/mo flat, 5-minute Stripe OAuth, 21-day guarantee.

Start Recovering Revenue$19/mo flat. Timed retries + a call-your-bank email. 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.

How to Recover Failed Stripe Payments

The full 2026 playbook: retries, the dunning sequence, the card-update page, and the math behind each.

Stripe Decline Codes

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