“Do Not Honor” (often numeric response code 05) is an issuer-level, catch-all decline that usually means the card issuer refused authorization without stating a specific reason. Treat it as a soft, ambiguous decline rather than a dead end: run basic diagnostics first, attempt one clean retry if data checks pass, and ask the customer to contact their card issuer when the pattern repeats.

TL;DR:

  • “Do Not Honor” declines often stem from issuer decisions related to fraud flags, credit limits, or account holds, and retrying without assessing the cause is unlikely to succeed.
  • Many declines are caused by internal bank issues, such as temporary holds or account problems, which require customer contact to resolve rather than technical fixes.
  • Network errors, data mismatches, or transient outages can mimic “Do Not Honor” responses, so verifying data accuracy and retrying shortly after initial failure is crucial.
  • A single retry is appropriate only if the decline appears temporary; multiple quick retries rarely fix issuer-side holds and can trigger further security restrictions.
  • Building a diagnostic and retry strategy aligned with industry response code categories helps reduce unnecessary declines while maintaining compliance with network rules.
Davincipay
Reduce Friction in Payment Processing
DavinciPay supports complex ecommerce businesses with acquiring relationships, payment gateways, fraud prevention, and chargeback mitigation.
Explore payment solutions

Table of Contents

What does a “Do Not Honor” decline actually tell you?

Every card transaction travels a short but strict path: your checkout sends the authorization request to your acquirer, the acquirer routes it through the card network, and the issuing bank makes the final call. “Do Not Honor” is generated at that last step. The issuer’s system looked at the transaction and said no, without handing back a reason your gateway can parse into something useful.

That vagueness is not a bug. Issuers keep decline reasons terse on purpose: fraud models work better when fraudsters cannot reverse-engineer the trigger, and banks avoid liability by not confirming account details like “your card is over the limit” or “we froze this account” to whoever is running the transaction. The FTC confirms this directly, noting that a “Do Not Honor” response typically signals an unspecified issuer-side refusal, and the cardholder needs to reach out to their bank to get the real answer.

In network terms, this maps to response code 05 in most card scheme documentation. A few things worth keeping straight:

  • Code 05 sits in the general decline category, distinct from data-quality codes tied to a bad card number, expired date, or CVC mismatch.
  • It is an issuer decision, not something your gateway or acquirer generated on its own.
  • The same code can mean ten different things internally at the bank: fraud score, credit limit, account hold, or a temporary system flag.
  • It carries no guarantee that a retry will succeed or fail: that depends entirely on why the issuer said no.

Understanding this distinction matters because it changes what you do next. A malformed card number needs a data fix. A “Do Not Honor” needs diagnostics, and possibly a conversation between your customer and their bank.

Why issuers return “Do Not Honor” on so many transactions

Most “Do Not Honor” responses trace back to something happening inside the issuing bank, not your checkout. Knowing the common triggers helps your team triage faster instead of guessing.

  • Fraud detection systems flagged the transaction as suspicious based on amount, location, merchant category, or velocity of recent attempts.
  • The cardholder is near or over their credit limit, or a debit account lacks sufficient funds, which the CFPB lists as one of the most common reasons for an unauthorized charge.
  • A hold from an unrelated transaction, such as a hotel deposit or car rental authorization, is temporarily tying up available credit.
  • The account itself has a problem: expired card, closed account, restricted status, or a suspected-compromise flag placed by the bank’s security team.
  • The issuer applied a temporary block, often tied to a recent report of card loss, a suspicious login, or an internal review that only the cardholder can clear by calling in.

The CFPB’s guidance is blunt about resolution here: when a charge fails to authorize, the reason often lives with the account itself or a technical hiccup between merchant and issuer, and the issuer is the only party positioned to explain and fix it.

Pro Tip: Log every “Do Not Honor” decline with a timestamp and amount, then look for clusters by card BIN or issuer. A spike from one issuer often signals a bank-side system issue rather than fraud on your end.

Technical failures that look exactly like a “Do Not Honor”

Not every ambiguous decline is really an issuer choice. Processor errors, network hiccups, and bad card data can produce the same message text, and mistaking one for the other wastes time and burns customer goodwill.

  1. Network timeouts or dropped connections between your gateway and the acquirer can return a generic decline that looks identical to a real issuer refusal.
  2. Misrouted transactions, where the acquirer sends the request through the wrong network path, sometimes get bounced back with the same catch-all code.
  3. Incorrect card data, including a mistyped PAN, wrong expiration date, or CVC mismatch, often fails before it even reaches a true issuer decision, and shows up bundled with an AVS or CVC failure flag.
  4. Stripe’s decline documentation recommends checking the AVS and CVC result codes alongside any advice code before assuming the issuer intentionally rejected the charge, since a data mismatch can trigger a decline that reads the same as a genuine “Do Not Honor.”
  5. Transient errors, like a brief acquirer outage, tend to clear on their own within minutes, while persistent errors repeat across multiple cards and customers, which points to something broken in your integration rather than a run of unlucky cardholders.

A single retry makes sense when the failure looks transient: same card, same amount, a gap of a few minutes. A repair makes more sense when the pattern holds across different cards and issuers, which usually means a gateway configuration problem, not a wave of coincidental fraud flags.

Building a merchant playbook for soft versus hard declines

Card declines split broadly into two buckets. A hard decline means the account is closed, stolen, or otherwise permanently unusable, and retrying is pointless. A soft decline means something temporary blocked the transaction, and a later attempt, sometimes with a small delay or corrected data, can succeed. “Do Not Honor” sits in an awkward middle ground: it behaves like a soft decline in Visa’s classification, but the underlying cause can be anything from a temporary hold to a closed account, so blind optimism is not a strategy.

Start with one clean retry only after confirming the card data is correct: right PAN, right expiration, right CVC, matching billing address. If that retry fails again immediately, stop. Repeated attempts in quick succession do not fix an issuer-side hold and can trip additional fraud flags on the account.

Illustrated card decline retry decision flow

Visa’s rules on declined transaction resubmission organize response codes into categories that dictate how and when merchants may resubmit. Category 1 codes generally allow limited reattempts under specific conditions, while Category 2 codes call for more caution, often requiring the merchant to obtain new authorization details or a fresh customer action before trying again. Anchoring your retry logic to these categories, rather than to internal guesswork, keeps you aligned with network rules and reduces the odds of your merchant account getting flagged for excessive retry behavior.

Here is a workable sequence for your checkout flow:

  • Confirm card details on-screen before allowing a retry: number, expiration, CVC, and billing ZIP code.
  • Allow exactly one automatic retry for a suspected transient error, then stop and surface a clear message.
  • If the second attempt fails, prompt the customer to try a different card or contact their issuer directly.
  • Log the full authorization payload (response code, AVS result, CVC result, timestamp, acquirer reference) for every failed attempt.
  • Escalate to manual review only when the same card fails repeatedly across multiple legitimate-looking sessions.

Your customer-facing message matters as much as your backend logic. A generic “payment failed” pushes people to abandon checkout. A specific prompt, such as “your bank did not approve this charge: try a different card or call the number on the back of your card,” gives the customer something actionable and signals that the problem is not your platform’s fault.

Decline messages carry limited diagnostic value on their own. Industry analysis from ProcessOut points out that “Do Not Honor” and similar catch-all codes are low-quality signals by design, and merchants who build heuristics around AVS, CVC, and historical acquirer response patterns get meaningfully better at telling a fixable failure from a dead end.

Recording diagnostics is not just an engineering nicety. If a customer later disputes a charge or claims your platform mishandled their payment, having the auth payload, acquirer response, and timestamp on file gives your support team and any dispute process something concrete to point to.

Cutting your “Do Not Honor” rate before it costs you sales

Every “Do Not Honor” decline is a customer standing at checkout with their card in hand and nothing to show for it. Reducing the rate, and recovering the sales that do get lost, comes down to a handful of concrete moves.

Front-end validation catches a chunk of failures before they ever reach the network. Real-time CVC and AVS checks, format validation on card number and expiration, and clear inline error messages stop bad data from generating a false “Do Not Honor” in the first place.

Smart routing helps on the processor side. Dynamic acquirer routing, where your gateway can send a transaction through a different acquiring bank if the first attempt fails, sometimes clears a decline that had nothing to do with the cardholder. Building in a short retry window, rather than an instant resubmission, also respects the Visa reattempt guidance while giving temporary issuer holds time to clear.

Fraud tools need regular tuning, not a set-and-forget configuration. Rules calibrated too aggressively will reject legitimate repeat customers, which shows up in your data as a “Do Not Honor” spike that has nothing to do with real fraud.

  • Validate card number, expiration, and CVC format on the client side before submission.
  • Route through a secondary acquirer automatically when the primary acquirer returns an ambiguous decline.
  • Review fraud rule thresholds monthly against your false-positive rate, not just your fraud-catch rate.
  • Offer a fast fallback, such as a saved alternative card or a different payment method, right at the point of failure.

Pro Tip: Give customers a one-click option to try a saved backup card immediately after a decline. Recovering the sale in the same session beats any follow-up email campaign.

Practical notes from a payments operator

Retry policy is a balance, not a formula. Push too hard on automatic retries and you annoy legitimate customers or trip issuer fraud flags. Push too little and you leave recoverable sales on the table.

The teams that handle this well are the ones logging everything: response codes, AVS and CVC results, acquirer, timestamp. Without that data, you are guessing at patterns instead of seeing them. When “Do Not Honor” rates climb for a specific vertical, especially subscription or high-risk categories, that is usually the signal to loop in underwriting or consider a processor built for that risk profile rather than patching the symptom.

— Peter

How DavinciPay reduces authorization friction for high-risk merchants

High-risk verticals see more ambiguous declines than most, because issuers apply tighter fraud controls to categories like telehealth, nutraceuticals, and subscription billing. Some payment providers work with merchants in these categories, matching them to acquiring banks that understand the vertical instead of flagging every transaction as suspicious by default.

Davincipay

Services like these map directly to the problems in this article: acquiring relationships chosen for authorization performance in your category, gateway integration with real-time reporting so you can see decline patterns as they happen, fraud tools tuned to your actual risk profile, and chargeback mitigation support for when disputes do occur.

When you evaluate a payments partner, ask these questions:

  • Do they have existing acquiring relationships in your specific vertical, or are you their first account in that category?
  • Can they show you real-time authorization and decline reporting, not just monthly summaries?
  • What underwriting support do they offer if your decline rate or chargeback ratio needs active management?

Our supplements, nutraceuticals, and telehealth processing pages walk through the specifics for each category. If you are ready to see what better authorization performance looks like for your business, apply now.

Sources

FAQ

What does a “Do Not Honor” decline mean?

It means the card issuer refused to authorize the transaction without giving a specific reason, according to the FTC. The cardholder needs to contact their bank directly to find out the actual cause, since the merchant and gateway have no way to see it.

My transaction has been declined due to “Do Not Honor,” what should I do?

Confirm your card number, expiration date, and CVC are entered correctly, then try once more. If it fails again, contact your card issuer directly, since the block usually sits on their side, whether that is a credit limit, a fraud hold, or an account restriction.

Rules on fees tied to declined transactions depend on your card agreement and jurisdiction, so there is no single universal answer. Regulators including the CFPB have scrutinized fees charged around declined or instant-decline transactions, so merchants should stay transparent about any fee tied to a failed payment and confirm the practice against current guidance.

What does a “57” decline code mean?

“Do Not Honor” (code 05) is a general refusal from the issuer without explanation, requiring issuer-side clarification. Other codes point to specific restrictions or issues with card use, which also require issuer-side clarification.

What should I offer customers after a repeated “Do Not Honor” decline?

Suggest a different card on file or an alternative payment method like a bank transfer, since repeated attempts on the same card rarely change the outcome. Bankrate recommends verifying card details first and having the cardholder contact their issuer if the problem persists across attempts.