Do Not Honor (Code 05): What It Means and How to Recover the Payment

"Do not honor" is the bank saying no without telling you why. It is decline code 05, the most common vague refusal in card payments, and it is a soft decline, which means you are allowed to retry it. Most of these payments are recoverable if you handle them patiently instead of panicking.

If you run a subscription business on Stripe, this is probably the decline code staring at you the most. According to Churnkey's data across over $2 billion in subscription revenue, do_not_honor accounts for roughly 10% of all declines in the US, second only to insufficient funds. On Amex cards it is even more dominant, making up the overwhelming majority of their declines, because Amex rarely tells anyone anything specific.

So let's talk about what is actually happening, and then the exact sequence I would run.

What the bank is really telling you

Code 05 comes from the old ISO 8583 messaging standard that card networks still run on. It literally means the issuer declined the authorization and chose not to give a reason. Visa and Mastercard have pushed banks for years to use more specific codes, and many do. But plenty of issuers still reach for 05 as the default shrug.

Behind that shrug, the real cause is usually one of these:

• •Fraud caution. The charge looks unusual to the bank's risk model: new merchant, odd time of day, amount that does not match the customer's habits. This is the most common hidden cause.
• •Balance or limit pressure. The account is technically fine but close enough to a limit that the bank gets conservative. This overlaps heavily with insufficient_funds behavior.
• •A temporary hold or internal review. The bank is looking at something and declines everything until it resolves.
• •Merchant category suspicion. Some banks dislike entire categories (crypto, gambling, supplements, sometimes SaaS billed from a foreign entity) and decline by default.

Notice the pattern: none of these are fixed by the customer typing in a new card number. The card is fine. That is the single most important thing to understand about code 05, because it dictates the whole recovery strategy.

Why retries work so well on this code

Because the most common hidden cause is fraud caution, and fraud caution is temporary. The bank's risk model sees the same charge attempt a few days later, in a different context, and often approves it. Nothing changed except time and the model's mood.

This is why Stripe's Smart Retries and every serious recovery tool treat do_not_honor as retryable. It is also why your first instinct, emailing the customer immediately with "your card was declined, please update it", is wrong for this code. You would be asking them to fix something that is not broken, and some of them will just churn from the annoyance.

The retry sequence I would run

Here is a concrete cadence. Steal it:

• •Attempt 1: the original charge fails with do_not_honor. Do nothing for 24 to 48 hours. No email, no retry. Give the bank's caution a chance to expire.
• •Attempt 2: retry after 2 to 3 days. If you know your customers' payday patterns, aim for just after one. A meaningful share of these succeed here.
• •Attempt 3: retry 3 to 4 days later. Still succeeding sometimes. Still no email needed if it does.
• •Attempt 4: about a week after the first failure. This is the last retry that has real odds.
• •After attempt 4 fails: now you email. Retries have done their job, the rest needs a human.

Two hard rules while you do this. First, the networks cap total retries: Visa allows roughly 15 attempts in 30 days and Mastercard about 35, and merchants who blow past that can face fines. You will never get close with the cadence above, which is the point. Second, never retry more than once per day. Same-day bursts train the bank's risk model to distrust you, and they burn attempts against those network caps for nothing.

When to email, and what to say

The email for a do_not_honor decline is different from a normal failed payment email, because the ask is different. You are not asking them to update their card. You are asking them to do one of two things: approve the charge with their bank, or just wait while you try again.

Something like:

"Quick heads up: your last payment to us did not go through, and your bank did not tell us why (this is common and usually nothing serious). We will retry automatically over the next few days. If you want to speed it up, a 2-minute call to your bank to approve charges from us usually clears it instantly."

Three things that email does right. It does not blame the customer's card. It tells them retries are already happening, which lowers their effort to zero. And it gives the one action that actually works on this code: calling the bank to pre-approve you as a merchant. That call converts a surprising number of these, because the bank's fraud caution evaporates the moment the customer confirms the charge is legit.

What not to do: do not send them to a card-update form as the primary ask. They will dutifully re-enter the same card, it will decline again, and now you have a confused customer and a dead subscription.

The math on why this is worth doing properly

Say you have 1,000 subscribers at $50 a month. A typical month sees around 5% of renewals fail on the first attempt, so 50 failed payments, $2,500 of MRR at risk. If do_not_honor is about 10% of your declines, that is 5 payments and $250 a month sitting behind this one code.

Handled lazily (one retry, immediate aggressive email), maybe you keep half. Handled with the sequence above, the retry layer quietly recovers most of them before any human gets involved, and the email mops up a chunk of the rest. The difference between those two approaches, compounded across all your decline codes over a year, is real money. This is what involuntary churn actually looks like from the inside: not one big loss, but hundreds of small recoverable ones.

The one case where you stop immediately

If the same customer's card returns do_not_honor across multiple weeks and multiple retries, stop. Either their bank has a standing problem with your merchant category, or the account has a deeper issue. At that point the recovery is a conversation, not a cadence: a personal note asking them to add a backup card or pay by another method. Continuing to retry past that point just spends network attempts and goodwill.

The habit that makes all of this easier

Once a month, pull your declines grouped by code. Stripe gives you this in the dashboard, and it takes five minutes. What you are looking for is drift: if do_not_honor suddenly doubles as a share of your declines, something changed. Maybe you launched in a new country whose banks are cautious, maybe a marketing push brought in a prepaid-heavy audience, maybe your descriptor is confusing a new cohort of banks. The code mix is an early warning system for problems that have not shown up in your churn number yet.

While you are in there, note your recovery rate per code. Do_not_honor should recover at a healthy clip with the cadence above. If yours does not, the problem is almost always timing (retrying same-day) or tone (robot emails nobody reads), and both are fixable in an afternoon.

One more thing from the trenches: the worst version of this process is the automated email from no-reply@yourcompany.com with "ACTION REQUIRED: payment declined." Customers ignore those, and honestly, fair enough. I built StayPaid because I wanted recovery emails that come from the founder's actual address, read like a person wrote them, and go out at the right moment in the retry sequence instead of screaming on day one. If that sounds like how you would want to be treated as a customer, that is exactly how it works.