do_not_honor: what this Stripe decline code means and why the issuer won't say more
lane: retry_gentledo_not_honorThe card was declined for an unknown reason. Stripe's suggested next step is for the customer to contact their card issuer for more information.
What it means
The issuer declined and gave no reason. That is the whole message. On the card networks this is response code 05, the default no, and an issuer sends it when the real reason is one it doesn't want to disclose or one its systems never mapped to anything more specific. Stripe relays it as decline_code do_not_honor under error code card_declined. It has nothing to add, since the issuer's response contained nothing more.
The awkward part is that 05 covers opposite situations. It is what an issuer's fraud model returns when a renewal from a merchant it hasn't seen before looks off, and issuers use it there on purpose so that someone testing stolen cards learns nothing from the response. It is also what many issuers return when the cardholder has switched on a control in their banking app, when the account is past due, when the card has been flagged pending replacement, or when their system had no better code to hand. Some of those clear by themselves on the next attempt; some never will. From where you sit the two are identical.
The one person who can find out is the cardholder. A call to the bank usually gets a real answer and often lifts the block on the spot, because a cardholder asking why a payment was refused is a routine conversation for an issuer's support line, and one an issuer will not have with a merchant. You can't diagnose it and you can only retry it carefully, so beyond that the most useful thing you can do is tell the customer plainly that their bank declined the charge without saying why.
The CVC and postal-code check results from when the card was saved are on the PaymentMethod, and Stripe's own guidance for do_not_honor is to have the customer verify those details if either check failed. If the network supplied an advice code, Stripe exposes it on the error as advice_code, with values such as try_again_later and do_not_try_again. For an 05 that field is the closest thing to a hint you will get about whether a retry is worth anything.
Why it happens
Issuer risk scoring
The pattern tripped the issuer's model: a merchant the cardholder hasn't paid before, an unusual amount, a first recurring charge, a country the cardholder never shops in. The decline is about the transaction's context rather than the card, which is why the same card often passes later with nothing changed.
Controls the cardholder set
The cardholder set a card lock, a category block, a no-online-transactions switch or a monthly cap in their banking app. Whether an issuer reports these as do_not_honor or as transaction_not_allowed is up to the issuer.
Account trouble the issuer won't disclose
The balance is past due, the account is frozen or under review, or a compliance hold is in place. The issuer knows exactly why and has no reason to tell a merchant.
No more specific code available
Smaller issuers and processors fall back to 05 for anything their systems don't classify. There may be no interesting reason at all.
Velocity, including your own retries
Too many attempts on the card in a short window, from you or from anyone else. A burst of reattempts after a first 05 can be the cause of the second one.
Common mistakes
Treating it as a fraud signal
Stripe has a separate decline code, fraudulent, for suspected fraud, and Radar records its own verdict in the outcome fields on the Charge. do_not_honor is neither. Flagging or blocking a customer over an 05 loses legitimate subscribers whose only offence was having a cautious bank.
Sending the update-your-card email
In most 05 cases the card is fine. The customer re-enters the same card, the next attempt gets the same decline, and you've spent an email and some credibility on a message that was wrong. Card-update requests belong to codes that say something is wrong with the card.
Retrying in a tight loop
If the reason was velocity or risk, each fast retry confirms the issuer's suspicion. This is the code most likely to harden under pressure, from a decline that would have cleared on its own into one that won't, and the reattempts count against network limits whether or not they succeed.
Saying nothing to the customer
Retries can't clear an account hold or a card control. When they fail, the customer needs to hear that their bank declined the charge and that a call to the bank is the fastest fix. Otherwise they find out when access stops, and by then it reads as your outage rather than their bank's decision.
How Lirova handles it
Lirova routes do_not_honor to retry_gentle, the spaced-out retry lane. The code covers both transient risk declines and hard account problems, so the lane has to be safe under both readings. Retrying is worth doing because some of these clear with nothing changed. Retrying gently is required because a fast burst is what makes an issuer's risk model dig in. And since the card is usually fine, the case goes to retries rather than to a card-update request.
The retry schedule differs by decline reason. For do_not_honor the spacing is the point, since a retry is only useful once the issuer's view of the card has had a chance to change.
FAQ
What does do_not_honor mean?
The card issuer declined the payment and did not give a reason. It is the networks' generic decline, response code 05, and it covers a fraud model flagging an unusual charge and a card lock set in a banking app alike. Stripe passes it through unchanged.
Is do_not_honor a fraud decline?
Sometimes, but you can't tell from the code. Issuers return it for suspected fraud because it reveals nothing, and they return it for plenty of non-fraud reasons too. Stripe's own fraud signals are the fraudulent decline code and the outcome fields Radar writes on the Charge, and a do_not_honor has neither.
Can Stripe tell me why the issuer returned do_not_honor?
No. Stripe relays the issuer's response and the issuer sent no reason. Card issuers discuss the specifics of a decline only with their own cardholder, so the customer can usually get an answer by calling their bank, and that call often lifts the block as well. If the network supplied an advice code, Stripe exposes it on the error as advice_code; read that before deciding whether to retry.
Should I retry a do_not_honor decline?
Yes, but spaced out. A later attempt on the same card often succeeds because the issuer's decision was about context rather than about the card. Rapid repeats look like card testing to the issuer and count against Visa and Mastercard reattempt limits, and the usual result is a decline that would have cleared turning into one that won't.
What should I tell a customer whose card came back do_not_honor?
That their bank declined the charge without telling you why, and that a quick call to the bank usually resolves it. Don't guess at a reason and don't mention fraud. They can switch cards if they want to, but the one on file is probably fine.
Related codes
Updated 2026-09-01