Do Not Honor is a generic card decline response from the issuer indicating that the transaction was rejected but the issuer is not providing a specific reason through the authorization message. It usually signals issuer-side risk, account, or policy concerns and requires careful decline recovery management.
How does Do Not Honor work?
Do Not Honor appears during card authorization when the issuer declines a transaction and returns a broad response instead of a detailed reason code. It is commonly mapped to ISO response code 05, although processors, gateways, and PSPs may normalize issuer responses differently. The message does not mean the card is invalid, stolen, or permanently unusable. It means the issuer chose not to approve the transaction and did not expose a more precise explanation to the merchant.
In practice, the decline can be triggered by many underlying factors. These include issuer fraud screening, unusual purchase behavior, temporary account restrictions, cardholder verification issues, spending controls, retry logic, or internal issuer decisioning thresholds. Because the merchant often sees only a generic decline, payment teams must infer the likely cause from transaction context such as channel, amount, geography, card type, retry history, and prior issuer behavior.
For operations teams, Do Not Honor is best treated as a soft decline unless richer network or issuer data proves otherwise. Some transactions may succeed later with adjusted retry timing, updated routing, stronger authentication, or a cardholder prompt to contact the bank. Others should not be retried immediately because repeated attempts can suppress approval rates and increase fraud or compliance risk.
Why does Do Not Honor matter for payment teams?
Do Not Honor matters because it combines high operational ambiguity with direct revenue impact. A payment team cannot respond well to a decline reason it cannot clearly see. That makes it harder to decide whether to retry, reroute, request another payment method, or trigger customer outreach.
This code also affects reporting quality. When large numbers of issuer declines collapse into a generic bucket, teams lose visibility into the true mix of fraud controls, issuer preferences, and customer payment issues inside their authorization funnel. According to Tidal Commerce, citing Visa’s Global Declines Transaction Analysis, more than 76% of global transaction volumes declined by Visa issuers in 2016 were tagged as either insufficient funds or do not honor (Tidal Commerce, 2016).
For merchants with recurring billing or high repeat purchase volume, poor handling of Do Not Honor can reduce recovered revenue and damage customer experience. For merchants with fraud exposure, aggressive retries can create unnecessary issuer friction and lower future approval performance.
What are common use cases for Do Not Honor?
-
SaaS and subscription merchants: A recurring rebill receives a Do Not Honor response because the issuer wants fresh risk evaluation or stronger customer authentication before approving another charge.
-
Marketplace platforms: A transaction is declined when issuer risk systems dislike the merchant category, seller profile, or transaction pattern, even though the card details are valid.
-
Travel and OTA merchants: A higher ticket cross-border booking is rejected under issuer travel-risk rules and returned as Do Not Honor instead of a more detailed decline reason.
-
Ecommerce retail merchants: A first-time customer order with a mismatched billing pattern or unusual basket size triggers issuer caution and comes back as Do Not Honor.
-
Digital goods merchants: Fast repeat purchases, virtual delivery, or device-risk signals cause an issuer to decline the authorization with a generic no-approval response.
-
Gaming merchants: The issuer blocks a card payment due to merchant-category restrictions, spend controls, or perceived elevated fraud risk and returns Do Not Honor.
Do Not Honor vs insufficient funds
| Term | What it means | Issuer specificity | Retry approach |
|---|---|---|---|
| Do Not Honor | Generic issuer decline with no clear exposed reason. | Low specificity. | Retry selectively based on timing, customer history, authentication options, and issuer patterns. |
| Insufficient Funds | Issuer indicates the account lacks available balance or credit. | Higher specificity. | Retry later, often aligned to pay cycles or after customer notification. |
How is Do Not Honor measured?
-
Do Not Honor decline rate: Do Not Honor declines divided by total authorization attempts.
-
Share of total declines: Do Not Honor declines divided by all declined transactions.
-
Recovery rate: Successfully recovered Do Not Honor transactions divided by total Do Not Honor declines.
-
Retry success rate: Approved retries from prior Do Not Honor declines divided by total retries attempted on that decline category.
-
Time-to-recovery: Median or average time between the initial Do Not Honor response and a later successful payment.
-
Issuer concentration: Percentage of Do Not Honor volume tied to specific BINs, issuers, regions, or acquirers.
-
Customer save rate: Share of declined customers retained through retries, account updater flows, or payment method changes.
What are best practices for Do Not Honor?
-
Separate Do Not Honor from hard declines in your reporting. Treat it as its own operational class because the recovery path is different.
-
Use issuer, BIN, geography, amount, and merchant category data to segment performance. Generic declines often hide issuer-specific patterns.
-
Do not apply fixed retry logic across all Do Not Honor responses. Timing and attempt count should vary by issuer behavior, payment type, and customer lifecycle stage.
-
Suppress immediate blind retries when fraud signals, velocity spikes, or previous same-day attempts suggest low approval odds.
-
Test authentication, routing, and descriptor changes where available. Some Do Not Honor declines are resolved by reducing issuer uncertainty rather than repeating the same message.
-
Coordinate retry logic with customer communications. For some segments, prompting the cardholder to contact the bank or update a payment method outperforms repeated authorization attempts.
-
Monitor recovery by PSP and acquirer. Data normalization can hide meaningful differences in how decline detail is passed through.
How does SmartRetry help with Do Not Honor?
SmartRetry helps merchants recover Do Not Honor declines by deciding when a retry is worth attempting and when another action is better. It uses payment context, decline history, issuer behavior, and timing signals to reduce wasted retries and improve the chance of recovery.
For recurring revenue teams, this is especially useful because generic issuer declines require more than a simple retry schedule. SmartRetry can support smarter sequencing across retries, customer outreach, and alternative recovery paths so ambiguous declines do not stay unresolved longer than necessary.
Go deeper with Do Not Honor: Smarter Retries & Higher Auth Rates.
