The Do Not Honor decline is ISO 8583 response code 05— a generic refusal the cardholder's issuing bank sends when it declines a transaction without stating a specific reason. It is the single most common decline code in card payments, and also the least informative, which makes it the hardest one to build a sane retry strategy around.
Most decline-code explainers stop at the processor layer: what Stripe calls it, what button to click. This guide goes one level deeper — into how code 05 actually moves through the card network, why issuers deliberately keep it vague, what Visa and Mastercard each say about retrying it, and how to build a recovery approach around a code that, by design, does not tell you what actually went wrong.
Key takeaways
05 Do Not Honoris a catch-all: issuers use it to decline a transaction without exposing the specific reason behind their fraud or risk logic.- It is classified as a soft decline, but Visa still caps retries at up to 15 attempts within a rolling 30-day window under its own resubmission rules.
- The code can be hiding insufficient funds, a fraud or risk-model hold, a spending limit, or a data mismatch — you cannot tell which from the code alone.
- Retrying the identical charge back-to-back rarely works and can look like probing to the issuer — a delayed, limited retry beats an immediate blind one.
What is the Do Not Honor decline, exactly?
Do Not Honor is response code 05 in ISO 8583, the messaging standard almost every card authorization runs on. When a customer's card is charged, the merchant sends the request to its acquirer(the merchant's bank), which routes it through the card network— Visa, Mastercard, or Amex — to the customer's issuing bank. Field 39 of the response message carries the answer, and 05 is the issuer saying no, on its own authority, without specifying which of several possible reasons applied.
That is a deliberate design choice, not a limitation of the messaging format. Issuers could report a more specific code — 51 for insufficient funds, 62 for a restricted card — and sometimes do. When they choose 05 instead, it is usually because disclosing the real reason would expose details about their own fraud-detection or risk-scoring logic that they would rather keep opaque, even from the merchant.
How a 05 decline actually travels through the network
Every card authorization is an ISO 8583 message, a fixed messaging standard that predates the modern internet and still underpins the vast majority of card transactions worldwide. The request that leaves your checkout page is a message type indicator (MTI) 0100 — an authorization request — built from dozens of numbered data elements: DE2 carries the card number, DE4 the amount, DE41 the terminal ID, and so on. The issuer's reply comes back as an MTI 0110 — an authorization response — and the field that actually carries the yes/no answer is DE39, Data Element 39, sometimes just called "Field 39." It is a two-digit numeric field, and 05 is one specific value it can hold.
The round trip runs through four parties, and it happens fast enough that shoppers never notice the hops. The merchant's payment page or terminal builds the 0100 request and hands it to its acquirer— the bank or processor that holds the merchant's account. The acquirer routes it onto the card network (Visa, Mastercard, or a regional equivalent), which forwards it to the issuing bankthat actually issued the card to the cardholder. The issuer's systems — balance checks, fraud scoring, standing holds — decide the answer, stamp DE39 with a response code, and the 0110 travels back the same four hops in reverse. Network rules require the whole exchange to complete inside a strict time window, typically measured in single-digit seconds, or the request times out and gets treated as a decline on its own.
The MTI itself carries structure beyond just "request" versus "response." Its four digits each mean something: the first identifies the ISO 8583 version in use, the second the message class (authorization, financial, reversal, and so on), the third the specific function within that class, and the fourth which party originated it. A card-not-present authorization request typically arrives as 0100, but reversals, advices, and network management messages each get their own distinct MTI, which is how every system along the route knows how to handle a message correctly before it ever inspects a single data element inside it.
This matters for one practical reason: DE39 is a two-digit code, not a sentence. The ISO 8583 standard reserves specific values for specific meanings — 00 for approved, 51 for insufficient funds, 54 for an expired card, 62for a restricted card — but nothing in the message format forces an issuer to pick the most specific value available. When an issuer's host system returns 05, that is a choice made inside the issuer's own authorization logic, not a limitation of what the standard allows it to say. The network and the acquirer relay whatever two digits the issuer sends; neither one has visibility into the reasoning behind them.
Why do issuers stay vague on purpose?
As Adyen's own guidance on the decline explains, banks lean on Do Not Honor to protect cardholders when a transaction looks unusual against normal spending patterns, geography, or frequency — without having to reveal the specific security signal that tripped it. A merchant who knew exactly which fraud rule fired could, in theory, adjust future transactions to route around it. Keeping the reason generic closes that loophole at the cost of merchant visibility.
The practical effect: one code, several real causes
In practice, 05 ends up covering a mix of insufficient funds that never got broken out as 51, an internal risk or fraud-model hold, a spending or velocity limit, and authorization-data mismatches. Card networks are known to remap some suspected-fraud cases into 05before a merchant ever sees a more specific code — so two customers seeing the identical "Do Not Honor" message at checkout can be experiencing two completely different underlying problems.
Four plausible reasons behind one 05
Because the code itself withholds the reason, the most honest thing any guide can do is describe plausible causes rather than claim certainty. The four scenarios below are genuinely common triggers for issuer-side declines that get coded as generic 05 — but none of them is confirmable from the response code alone, and a given decline could just as easily be something else entirely.
Scenario 1: A spending-limit or velocity hold
Many issuers set soft internal ceilings that never show up on a cardholder's printed credit limit — a per-transaction cap, a rolling daily total, or a maximum number of authorizations in a short window. A single large purchase, or several smaller ones in quick succession, can trip one of these limits even when the account has plenty of available credit or balance overall. Some issuers report this distinctly as 61 (exceeds withdrawal limit) or 65 (activity count limit exceeded); others fold it into the generic 05 instead, especially when the limit itself is a discretionary risk control rather than a hard contractual ceiling.
Scenario 2: A first purchase against a high-risk merchant category
Every merchant account carries a Merchant Category Code (MCC), a four-digit classification the acquirer assigns based on the type of business. Issuers weight MCCs into their real-time fraud scoring, and categories that see disproportionately high fraud rates — certain digital goods, money transfer, high-value electronics, some subscription categories — draw more scrutiny, particularly on a cardholder's first transaction with a given merchant. Both major networks run proprietary AI scoring on every authorization: Visa's Advanced Authorization assigns a risk score from roughly 1 to 99 based on around 400 risk attributes in under a millisecond, and Mastercard's Decision Intelligence evaluates several hundred data points in real time during the authorization itself. Neither network publishes the exact weighting, and the decision to decline sits with the issuer, not the network — but MCC is a documented input into both systems, which makes an unfamiliar, higher-risk-category merchant a plausible reason a first charge gets a generic 05 when a second, smaller charge a week later sails through.
Scenario 3: A billing address or AVS mismatch on a stored card
The Address Verification Service (AVS) checks the billing street number and ZIP or postal code submitted with a transaction against what the issuer has on file, and returns a result code — Y for a full match, A or Z for a partial match, N for no match, and U, G, or S when the issuer cannot or does not perform the check at all, which is common for non-U.S. issuers. AVS mismatches are especially likely on stored cards used for recurring billing: a customer moves, updates their address with the bank but not with every merchant who has their card on file, and the next automatic charge submits a now-stale billing address. Some issuers decline outright on a poor AVS result; others weight it as one input among several into a broader approve/decline decision — and either way, the merchant sees 05, not the AVS result that actually drove it, unless the processor happens to surface AVS separately in its own response.
Scenario 4: Cross-border or unfamiliar-geography risk scoring
A transaction that routes through a merchant, acquirer, or processing region different from the cardholder's home country carries its own risk signal, independent of anything about the specific purchase. Cross-border card-not-present transactions see meaningfully higher fraud rates than domestic ones industry-wide, and issuer risk models score geography accordingly — a card that has never transacted outside its home country suddenly seeing an international merchant is a pattern real-time fraud scoring is specifically built to flag. A subscription business selling internationally, or one that recently changed acquiring banks or payment processors into a different country, can see a step change in generic declines for reasons that have nothing to do with the customer's ability or intent to pay.
Is Do Not Honor a soft decline or a hard decline?
It is a soft decline — the card is not blocked and the account is not closed, so a later attempt can succeed once whatever triggered it changes. See our full soft decline vs hard declinebreakdown for how that classification governs retry strategy across every code, not just this one. But "soft" does not mean "retry freely" — Visa still treats it as a distinct risk category with its own resubmission rules, covered next.
How many times can you actually retry it?
Under Visa's own published rules for declined-transaction resubmission, response codes fall into categories that determine what a merchant is allowed to do next. Codes where the issuer will never approve — lost_card, stolen_card, pickup_card — sit in Category 1, where resubmission is not permitted at all. 05 Do Not Honor sits in Category 2, alongside other issuer-discretionary declines, where Visa permits up to 15 retry attempts within a rolling 30-day windowwithout it counting against a merchant's authorization performance.
Mastercard does not publish one single fixed number the way Visa does. Instead, it signals retry guidance per transaction through its own Merchant Advice Code system, which can tell an acquirer to stop immediately, wait a specific window, or proceed — the exact instruction depends on the code Mastercard attaches alongside the decline, not a blanket cap. Either way, a technical ceiling is not the same as a smart one: repeated identical retries on a persistent 05rarely succeed and can read as probing to the issuer's own fraud model, independent of whether the network would technically allow another attempt.
Why subscription billing sees this code more than retail
If you run recurring billing, you will see 05 far more often than a card-present retail business does, and there is a structural reason for that rather than a coincidence. Recurring charges are Merchant-Initiated Transactions (MITs)— the customer is not present, not entering their card, and not actively approving that specific charge in the moment. The card networks' own Stored Credential Framework, which took effect in October 2017 with phased enforcement into 2018 for both Visa and Mastercard, requires every MIT to carry flags identifying it as such and to reference the Network Transaction ID (NTID) from the original customer-initiated authorization when the card was first stored. Issuers use those flags as an explicit input into their authorization decision, separate from anything about the purchase itself.
That separate treatment cuts both ways. On one hand, a correctly flagged MIT that references a valid NTID gives the issuer more context than an anonymous charge would — it can see the transaction is a known, previously authorized recurring relationship rather than a fresh, unknown one. On the other hand, MITs are unattended by definition: there is no 3-D Secure challenge to complete, no cardholder to step up and verify, and no CVV being entered, since merchants are barred from storing CVV for recurring use. When an issuer's risk model has a concern — an old card nearing its usual replacement cycle, a subscription that recently changed price, a billing pattern that looks different from the customer's established rhythm — a card-present transaction has a cardholder standing at the terminal who can step up and resolve it immediately. An MIT has nobody there, so the issuer's only safe option is to decline, and it frequently does so with the same generic 05 rather than a more specific code.
Insufficient funds skews heavily toward recurring billing
Industry data on decline reasons consistently shows insufficient-funds-type declines making up a much larger share of MIT failures than of card-present, customer-initiated ones — unsurprising once you consider that a recurring charge fires on a schedule the merchant sets, not on a date the cardholder chose because they knew funds would be available. That same dynamic — a charge landing at a moment the cardholder did not actively choose — is part of why recurring billing sees a disproportionate share of generic 05 declines too, not just explicit 51s.
Card updater services close one slice of this gap — an issuer-initiated update pushed to your processor automatically when a stored card gets a new number or expiration date, before the old one lapses — but they do nothing for a fraud-model hold, a spending limit, or an AVS mismatch, which is why a code-aware retry layer still earns its keep even for merchants who already run Account Updater. The two tools solve different halves of the same MIT-decline problem.
Practically, this means a recurring-billing business should expect a meaningfully higher baseline rate of 05 declines than a one-off checkout business, and should not treat that rate as evidence something is broken in the integration. It is closer to a structural feature of MIT authorization than a symptom to fix — which is exactly why a timed, code-aware retry strategy matters more here than almost anywhere else in payments.
Do Not Honor next to the codes it gets confused with
A few adjacent codes show up in the same conversations as 05 — some because they represent a cause it might be hiding, others because they look similar but behave completely differently:
do_not_honor (05)Soft · retryThe card network's catch-all decline: the issuer refused the transaction without stating why. The subject of this guide.
What to do: Retry once, timed a few days out rather than immediately — never more than two or three times before switching tactics.
insufficient_funds (51)Soft · retryThe issuer explicitly confirms the account did not have enough available balance — the specific version of what 05 often hides.
What to do: Retry near the customer's likely payday rather than on a fixed daily schedule.
card_velocity_exceeded (61/65)Soft · retryThe card hit a spending or transaction-count limit the issuer enforces — a specific case that a vague 05 can also be standing in for.
What to do: Retry after a short delay once the velocity window resets; avoid stacking retries close together.
expired_card (54)Hard · needs new cardUnlike 05, this is unambiguous: the card on file is past its expiration date.
What to do: Do not retry as-is. Ask for updated card details or run Account Updater if you have it enabled.
pickup_card / stolen_cardHard · needs new cardVisa's Category 1: the issuer will never approve this card again under any circumstance.
What to do: Never retry. Contact the customer for an entirely different payment method.
If you are working inside Stripe specifically, Stripe passes 05 through with minimal translation as its own do_not_honor decline code — our Stripe decline codes guide covers exactly how Stripe surfaces it and every other code alongside it, if that is the layer you are working at day to day.
How to recover a Do Not Honor decline
- Do not resubmit immediately. An instant retry on the identical charge almost never succeeds and can look like probing to the issuer's fraud model.
- Time the retry, don't just delay it. A retry timed a few days out — ideally near a likely payday if the underlying cause could be funds-related — beats a blind fixed-interval schedule.
- Cap it at two or three attempts. Visa's ceiling is technically higher, but a persistent
05past a couple of tries is unlikely to be a timing problem — it is more likely a hold, a limit, or a mismatch that a retry alone will not fix. - Ask for a different payment method once retries stall. Send a specific, honest message — not a generic "payment failed" — and suggest the customer contact their bank if a second card also fails the same way. See our dunning email templates for copy that names the actual problem instead of hiding behind "there was an issue."
- Track it by code, not as a generic failure. A tool like Revova reads the decline code automatically and routes
05to a timed retry while routing an unambiguous hard decline straight to a payment-method update — instead of treating every failure the same way.
Two refinements matter once you get past the basic sequence above. First, vary something between attempts if you can.Retrying the exact same amount, at the exact same processor, with the exact same stored card details, gives the issuer's fraud model nothing new to evaluate — it is likely to return the same answer for the same reason. If a scenario like a stale billing address is plausible, prompting the customer to confirm or re-enter their card details before the next attempt can resolve an AVS-driven decline that a blind retry never would. Second, watch for a pattern across a specific card, not just a specific charge. A single 05 is often noise. The same card failing with 05 across two or three unrelated charge attempts, or across a widening set of customers all serviced by the same acquiring relationship, is a signal worth escalating rather than continuing to retry mechanically.
Mistakes merchants make with this code
Because 05 looks like an ordinary, retryable failure, it invites handling that would be reasonable for a network timeout but works against you here. The most common mistakes share one root cause: treating a deliberate issuer decision as if it were a transient glitch.
- Retrying immediately, automatically, on every failure. A dunning system configured to retry any failed charge within minutes treats
05identically to a dropped network connection. The issuer's decision was deliberate, not transient, so an instant retry is very unlikely to change the outcome — and repeated rapid attempts on the same card can themselves become a fraud signal, making the next legitimate attempt less likely to succeed, not more. - Retrying too many times in the window. Visa's Category 2 ceiling of up to 15 attempts in 30 days is a compliance limit, not a target. Merchants who retry aggressively up toward that ceiling risk their acquirer's authorization approval-rate metrics, which card networks monitor and can penalize independent of any single customer's outcome.
- Treating a soft decline exactly like a hard one — or the reverse. Some dunning logic gives up on
05after one try, the way it should forlost_cardorstolen_card; other logic keeps retrying a hard decline likeexpired_cardthe way it should for05. Both waste the useful part of the classification: soft declines deserve a patient, timed retry sequence; hard declines deserve an immediate ask for updated payment details instead of any retry at all. - Never looking at the AVS or CVV result alongside the decline code. Most processors return AVS and CVV match results on the same response as the decline code, even when the decline itself is a generic
05. Ignoring those fields throws away the best available hint at the real cause — a poor AVS match points toward a stale billing address; a CVV mismatch (on a card-not-present transaction where it was checked at all) points toward manual entry error or a different kind of risk entirely. - Messaging the customer as if the merchant were at fault. A generic "something went wrong, please try again" email undersells what is actually an issuer-side decision the customer may need to act on — by calling their bank, confirming a recent transaction as legitimate, or updating a stale address. Naming the likely cause, even hedged, gets a faster resolution than a vague apology does.
None of these fixes require rebuilding a payment stack. They come down to configuration: routing by decline category instead of one blanket retry schedule, reading the AVS and CVV fields a processor already returns instead of discarding them, and writing recovery messages that name the likely cause instead of defaulting to "payment failed." The businesses that recover the most revenue from a code like 05 are rarely the ones retrying hardest — they are the ones retrying fewest times, at the right moment, and stopping early once a card is clearly not going to come back.
Where to find the code in your processor
Every major processor — Stripe, Braintree, Chargebee, Recurly, Paddle — passes the underlying ISO 8583 response code through with light translation into its own decline-code vocabulary. In Stripe it surfaces as do_not_honoron the charge or PaymentIntent; most others expose an equivalent field on the failed transaction or invoice object. If you want the formal, network-level rulebook rather than a processor's summary of it, Visa publishes its own rules on declined-transaction resubmission directly.
Frequently asked questions
What does the "Do Not Honor" decline mean?
Do Not Honor is ISO 8583 response code 05 — a generic decline the cardholder's issuing bank sends when it refuses a transaction without stating a specific reason. It is not a technical error; the issuer made a deliberate decision not to approve, and card network rules let it withhold the exact cause to avoid exposing its own fraud-detection logic.
Why is code 05 so common compared to other decline codes?
Because issuers route several different underlying problems through the same catch-all response instead of a specific code: insufficient funds that never got broken out as 51, a fraud or risk-model hold, an internal spending limit, or a data mismatch on the authorization request. That funneling is exactly why "Do Not Honor" shows up so often — it is one label standing in for several distinct causes.
Is Do Not Honor a soft decline or a hard decline?
Soft. The card itself is not blocked and the account is not closed, so a later attempt can succeed once the underlying condition changes. That said, Visa treats it as a "Category 2" response specifically because it is issuer-discretionary, not because it is risk-free to retry blindly — see our broader breakdown in soft decline vs hard decline.
How many times can I retry a Do Not Honor decline?
Under Visa's published rules on declined-transaction resubmission, Category 2 codes — which includes 05 — permit up to 15 retry attempts within a rolling 30-day window before it counts against your acquirer's authorization performance. Mastercard does not publish one fixed cap; it signals guidance per transaction through its own Merchant Advice Code system instead. Either way, retrying the identical, unchanged transaction back-to-back rarely succeeds and starts to look like probing to the issuer's fraud model.
What is the difference between Do Not Honor (05) and Insufficient Funds (51)?
Both can mean the same underlying problem — the account did not have enough available balance — but 51 is the issuer explicitly telling you that, while 05 withholds the reason. Some issuers report 51 directly; others, and some networks' own risk logic, remap the same underlying shortfall to the vaguer 05 instead. You cannot tell which case you are in from the code alone.
Is this the same as Stripe's do_not_honor decline code?
Yes, at the surface — Stripe's do_not_honor decline code is Stripe passing ISO 8583 code 05 through with minimal translation. Our Stripe decline codes guide covers how to handle it inside Stripe specifically; this guide goes one level deeper, into what the raw code means at the card-network layer and why it behaves differently depending on which network and issuer are involved.
How should I recover a payment that failed with Do Not Honor?
Do not resubmit immediately. Wait, ideally timing the retry to a few days out rather than blindly retrying every 24 hours, cap yourself at two or three attempts within the window, and if it keeps failing, stop retrying the same card and ask the customer to update their payment method or contact their bank directly — persistent 05s past a couple of tries are unlikely to be a timing problem.
Where does DE39 fit into the ISO 8583 authorization message?
DE39, Data Element 39, is the two-digit field in the ISO 8583 authorization response (message type 0110) that carries the actual answer to the request. Everything else in the round trip — merchant to acquirer to card network to issuing bank and back — exists to deliver a value into that one field. 00 means approved; 05 means the issuer declined without stating why.
Why does my subscription business see more Do Not Honor declines than a retail storefront would?
Recurring charges are Merchant-Initiated Transactions (MITs) under the card networks' Stored Credential Framework — there is no cardholder present to step up and resolve an issuer's concern in the moment, no CVV entered, and no 3-D Secure challenge available. Issuers that would let a card-present purchase through after a quick verification often have no safe option but to decline an unattended MIT outright, frequently coded as generic 05.
Can I find out the real reason behind a specific Do Not Honor decline?
Not reliably, and not from the response code alone. You can improve your odds indirectly: check the AVS and CVV match results your processor returns alongside the decline, watch whether the same card fails repeatedly versus once, and consider whether the transaction was cross-border, a first-time charge, or a stale stored card. None of that confirms the cause the way a specific code like 51 or 54 would — it only narrows the plausible list.
Stop guessing which decline codes are worth retrying
Revova reads the actual decline code behind every failed payment — including the ambiguous ones like Do Not Honor — and times each retry instead of hammering the card immediately, then scans your history for failures nobody ever chased. Start free and see the real number.
Start my 14-day free trial →No credit card · Free Lost Revenue scan · 30-day money-back guarantee
