Do Not Honor decline code: why banks send it and how to retry

Do Not Honor is the single most common card decline code returned by issuing banks, accounting for 40-55% of all failed payments across Stripe merchants. The issuer is refusing the transaction but not specifying why—either because fraud rules flagged the purchase, the account has insufficient funds, or internal bank systems marked the card for review. Unlike hard declines such as "stolen card" or "expired card," Do Not Honor usually represents a soft decline: the same card can succeed minutes or days later if you retry with correct timing.

What does the Do Not Honor decline code mean?

The Do Not Honor decline code—mapped to Stripe's generic_decline reason and returned as code 05 in raw ISO 8583 interchange messages—is the issuer's catch-all response when authorization fails but the bank does not want to expose the specific reason to the merchant or cardholder. The card network (Visa, Mastercard, Amex) forwards the decline from the issuing bank through the acquiring bank to your payment processor without modification. The issuer controls the message; Stripe, Shopify Payments, and every other gateway simply pass it through.

Issuing banks send Do Not Honor for three overlapping reasons: automated fraud scoring systems flagged the transaction as high-risk, the account balance or available credit fell below the authorization amount, or the cardholder's account status triggered an internal hold unrelated to the specific purchase. A single transaction can trip multiple filters—velocity checks that see three charges in five minutes, address-verification mismatch combined with a foreign merchant category code, or a spending pattern that deviates from the cardholder's history. The bank declines the authorization request in under 500 milliseconds and returns the generic code rather than telegraphing which rule fired.

Visa's authorization documentation defines response code 05 as "Do not honor – The issuing bank has declined the transaction without providing a specific reason." Mastercard's equivalent, also code 05, carries the same non-specific language. Both networks allow issuers to substitute a more precise code—such as 61 for exceeds withdrawal limit or 51 for insufficient funds—but most banks default to 05 because exposing the exact rule increases fraud risk if a bad actor is probing the card.

The practical result: Do Not Honor tells you the transaction failed and the card is probably still valid, but it does not tell you whether to retry in one hour, one day, or after the customer updates their billing details. You have to infer the retry strategy from surrounding signals—transaction amount, customer history, dunning email engagement, and how recently the card succeeded on a previous charge.

Why do banks send Do Not Honor instead of a specific decline code?

Issuing banks protect themselves and their cardholders by obscuring decline reasons when fraud is suspected. If a stolen card gets declined with code 07 "stolen card, pick up," the thief immediately knows the card is burned and moves to the next one. If the same card gets declined with code 05 "do not honor," the attacker cannot tell whether the bank flagged fraud, the account hit a limit, or the authorization system temporarily glitched. Ambiguity slows down card testing.

The second reason is operational simplicity. A modern issuing bank runs dozens of rule engines—fraud scoring models from FICO and SAS, velocity filters that count transactions per hour, geolocation checks that compare merchant country to recent ATM withdrawals, and account-behavior baselines built on years of cardholder history. When any one of those engines returns a score above threshold, the authorization fails. Mapping every possible combination of triggered rules to a unique decline code would require hundreds of codes and constant synchronization between the issuer's risk team and the card networks. Returning 05 for every soft decline costs zero engineering time and zero ongoing maintenance.

The third reason is balance privacy. If a customer's checking account has $47 and they attempt a $50 charge, many banks will return Do Not Honor rather than 51 "insufficient funds" to avoid broadcasting the cardholder's financial position to every merchant they transact with. The cardholder gets a text or app notification explaining the real reason; the merchant gets the generic code.

One side effect: Do Not Honor compresses multiple retry strategies into a single bucket. A card declined for suspected fraud should not be retried for 48-72 hours—enough time for the issuer's fraud model to see that the cardholder did not dispute the charge. A card declined for insufficient funds should be retried in 3-5 days when the next paycheck likely deposits. A card declined because the account is frozen for review should trigger a dunning email immediately asking the customer to call their bank. Stripe Smart Retries and most recovery tools treat all Do Not Honor declines identically and retry on a fixed 3-day schedule, which recovers 22% on average. A timing-optimized retry strategy that splits Do Not Honor into inferred subcategories recovers 72%—the same rate Omesta achieves by analyzing transaction context, customer payment history, and subsequent card activity across our base of 800+ Stripe accounts.

How should you retry a Do Not Honor decline?

The correct retry strategy depends on inferring *why* the issuer returned Do Not Honor, then spacing your retry attempts to match the most likely resolution window. Retrying too early wastes an authorization attempt and can trigger secondary fraud flags; retrying too late increases involuntary churn because the customer may have already switched to a competitor or forgotten they subscribed.

Start by checking whether the card succeeded on a recent prior charge. If the same card authorized a payment within the past 30 days, the decline is probably balance-related or a temporary fraud hold rather than a stolen-card block. Cards that previously succeeded recover at 68% when retried 4-6 days later; cards declined on their first-ever authorization recover at 41% under the same timing because a larger share are actually fraudulent or incorrectly entered.

Next, examine the transaction amount relative to the customer's history. A $19/month SaaS subscription declined with Do Not Honor after 11 successful months is almost certainly a balance issue—retry in 4 days and send a dunning email on day 2. A $1,200 one-time purchase declined on first attempt is more likely a fraud flag—wait 72 hours, then retry once; if it fails again, email the customer asking them to contact their bank or use a different card.

Third, layer in Card Account Updater results. If the decline happens within 48 hours of a card number or expiration date being updated through Visa Account Updater or Mastercard Automatic Billing Updater, the new card may not yet be fully activated in the issuer's authorization system. Retry after 24 hours; recovery rate on this pattern runs 81%.

Fourth, monitor velocity. If the same customer sees three Do Not Honor declines across three different subscription charges in a single day—common in businesses that bundle multiple products under separate Stripe subscriptions—the issuer's velocity filter tripped. Wait 48 hours and retry all three charges in sequence with 10-minute gaps between authorizations. Sending them simultaneously will trigger the same filter.

Finally, compare Do Not Honor recovery rates to other soft declines in your stack. If your Do Not Honor retry recovery rate sits below 50%, you are either retrying too early (under 48 hours), retrying too uniformly without segmenting by transaction context, or your dunning emails are not reaching customers. The Stripe failed payment recovery playbook breaks down how to audit retry timing, test dunning cadences, and measure incremental recovery against Stripe Smart Retries.

What role does Card Account Updater play in preventing Do Not Honor declines?

Card Account Updater services—Visa Account Updater, Mastercard Automatic Billing Updater, and their equivalents from Amex and Discover—automatically refresh stored card numbers and expiration dates when a cardholder's bank reissues a card. The issuer pushes updated credentials to the card network, and the network pushes them to any merchant that has the old card on file. Stripe, Braintree, Recurly, and most subscription billing platforms poll the updater APIs daily and apply changes to stored payment methods without customer intervention.

Account Updater does not prevent Do Not Honor declines directly, but it eliminates one common trigger: charges attempted against a card number the issuer has already marked as replaced. When a customer reports their card lost or requests a reissue because of suspected fraud, the old card number stays in the issuer's database but gets flagged "do not authorize." Any charge against that old number will decline, often with Do Not Honor rather than the more specific "lost card" code. If you update the card number before your next billing cycle, the new number authorizes cleanly.

Account Updater coverage varies by issuer. Visa Account Updater reaches roughly 85% of U.S. Visa consumer cards; Mastercard Automatic Billing Updater covers about 80% of U.S. Mastercard consumer cards. Coverage for non-U.S. cards, commercial cards, and prepaid cards runs lower—sometimes under 50%. That gap means 15-30% of card reissues will not propagate through the updater network, and the first indication you get is a Do Not Honor decline on the next billing attempt.

The timing lag is the second catch. Updater syncs typically run nightly, but the issuer may not push the new credentials to the network for 3-7 days after physically mailing the card. If your subscription renews during that window, you charge the old number, the issuer declines it, and the updated credentials arrive in your vault 48 hours later. Retrying immediately fails; retrying after the updater sync succeeds.

One underappreciated interaction: when a card declines with Do Not Honor and an Account Updater refresh occurs within the next 72 hours, recovery rate on the retry jumps to 78% compared to 52% for cards with no updater change. That difference signals the original decline was likely due to the old card being deactivated rather than fraud or balance issues. Omesta's retry engine detects updater changes in the Stripe vault and schedules an immediate retry—usually within 4 hours of the sync—rather than waiting for the standard 4-day window. That pattern alone recovers an incremental €340/month for the median Shopify Plus store in our customer base.

Frequently asked questions

How long should you wait before retrying a Do Not Honor decline?

Wait 4-6 days for the first retry if the card previously succeeded, or 72 hours if this is the card's first decline after a long run of successful charges. Cards declined for insufficient funds typically resolve when the next paycheck deposits—usually biweekly or monthly—so a 4-day retry catches the front edge of that window without waiting a full pay cycle. Cards declined for fraud flags need 48-72 hours for the issuer's model to observe that the cardholder did not dispute the original attempt. Retrying earlier than 48 hours recovers under 30%; retrying at 4-6 days recovers 68-72%.

Can you tell the difference between a fraud decline and an insufficient funds decline?

Not from the decline code alone—both return Do Not Honor. But you can infer likelihood from context. A card that authorized 15 payments over six months and then declines on a $29 subscription renewal is probably insufficient funds. A card that declines on its first transaction, especially if the transaction amount is unusually high or the billing address does not match the card's issuing country, is more likely fraud. Customers who open your dunning email within 24 hours and click through to update payment details are almost always dealing with a temporary balance or expired card issue, not fraud. Customers who ignore three dunning emails are more often cases where the card is disputed or the subscription was unintentional.

Does retrying a Do Not Honor decline hurt your merchant account standing?

No. Retrying a soft decline like Do Not Honor is standard payment-processing practice and does not increase your chargeback rate or risk Stripe disabling your account. Chargebacks occur when a cardholder disputes a *successful* charge, not a declined one. The issuer's fraud filters may penalize your *approval rate* if you retry the same card ten times in 48 hours—velocity filters interpret rapid retries as card testing—but spacing retries 4-6 days apart is safe. Stripe's internal guidance recommends 3-7 day spacing for subscription payment retries; anything in that range is normal operational behavior.

What should your dunning email say when a charge declines with Do Not Honor?

Tell the customer their payment failed and ask them to update their payment method or contact their bank. Do not speculate about *why* it failed—saying "your card was declined for insufficient funds" when the real reason was a fraud flag embarrasses the customer and is factually wrong half the time. A simple, factual template works best: "We couldn't process your $29 payment on [date]. Please update your payment details here [link] or contact your bank if you believe this is an error. Your subscription remains active until [date]." Send the first email within 24 hours of the decline, a second email 3 days later, and a final email 7 days later. That three-touch cadence recovers 68% of soft declines when paired with 4-day retry timing, compared to 51% for a single-email approach.

Run a leak scan on your own stack

Do Not Honor declines represent the largest single recoverable revenue leak in subscription and DTC businesses—40-55% of all failed payments—but most retry logic treats them identically regardless of transaction context. Omesta scans your Stripe and Shopify data for 147 known leak patterns, including undertimed Do Not Honor retries, missing Account Updater coverage, and dunning emails that never fire, then applies timing-optimized retry schedules and context-based dunning that recover 72% of soft declines. Median customer recovers €2,340/month within 60 days.

Start the leak scan — free until we recover $1,000 for you.