Is `do_not_honor` worse than a generic decline?

No. They are effectively the same underlying issuer behavior. `do_not_honor` maps to the network's "05" code directly; `generic_decline` is Stripe's broader catch-all that often covers the same situations.

Does this code mean fraud was suspected on my card?

Sometimes, but not always. Fraud holds are one of several possible causes, alongside spending limits, velocity triggers, and plain bank system issues.

Why do subscription charges hit `do_not_honor` more than a one-time purchase would?

Overnight batch billing runs and stacked recurring charges across multiple merchants both look different to a bank's automated fraud screening than a single customer-initiated purchase.

Should the retry happen right after the decline?

No. An immediate retry usually fails because the same condition is still active. Spacing retries out over hours gives temporary holds time to clear.

Does Foxhound email the customer as soon as this code appears?

No. Foxhound retries silently in the background first. The customer only receives an email if all scheduled retries fail to recover the charge.

Decline code

Do Not Honor

`do_not_honor` is the card network's oldest and most common decline reason: the issuing bank said no to the charge without telling Stripe why. It is a soft decline. The name sounds serious, but in practice it functions as a catch-all, not a verdict on the card, the account, or the customer. Under the ISO 8583 standard that card networks use to move authorization messages, `do_not_honor` maps to response code "05," the single most frequent decline code seen on card-not-present transactions across the industry. Banks route a wide variety of situations through this code: a temporary fraud flag, a spending limit reached, several declines stacking on the same card in a short span, a velocity trigger, or an internal bank system issue. None of those mean the card is closed or the account is fraudulent. The bank is simply declining right now, for a reason it has chosen not to share.

Back to decline codes

do_not_honorRetries automatically

Draft content: this page's explanatory copy is Pass 3 template writing pending a dedicated content pass. The classification badge above and the recovery behavior described below are live, not draft: both come directly from the recovery engine.

Why it happens

Recurring billing triggers this code more than one-time purchases for reasons rooted in timing and pattern recognition. A subscription charge that fires automatically at 3am as part of a merchant's batch billing run looks statistically different to a bank's fraud model than a purchase a customer makes by hand at 2pm. Add in the fact that a customer's card may already have other charges stacking up around the same billing cycle (other subscriptions, other merchants), and the velocity signals a bank watches for are more likely to trip.

How to fix it

Yes. This is functionally the twin of `generic_decline`: both are soft, catch-all issuer declines, both correspond to the same underlying "05" network response, and the practical difference is only whether the bank returned "05" directly or Stripe applied its own broader label over the same underlying signal. The handling is identical. An immediate retry usually fails for the same reason the first attempt did. A retry spaced out by hours, once a temporary hold or fraud flag has had time to clear, succeeds far more often. Treat it the same way as `generic_decline`: retry on a delay rather than instantly, respect network-imposed retry caps, and reserve customer-facing emails for cases where automated retries have already failed. Sending an alarming "your payment was declined" email the moment this code appears, before giving a delayed retry a chance to work, creates unnecessary customer anxiety over what is usually a same-day or next-day resolution.

How Foxhound recovers it

A Foxhound-scheduled silent retry runs first, timed for the specific decline pattern rather than an immediate repeat. If the retry succeeds, the customer never sees anything happened. If it does not, Foxhound moves to a dunning email sequence across the following weeks, written in the merchant's own brand voice, with a hosted card-update link on every email as a passive fallback channel.

Questions

No. They are effectively the same underlying issuer behavior. `do_not_honor` maps to the network's "05" code directly; `generic_decline` is Stripe's broader catch-all that often covers the same situations.
Sometimes, but not always. Fraud holds are one of several possible causes, alongside spending limits, velocity triggers, and plain bank system issues.
Overnight batch billing runs and stacked recurring charges across multiple merchants both look different to a bank's automated fraud screening than a single customer-initiated purchase.
No. An immediate retry usually fails because the same condition is still active. Spacing retries out over hours gives temporary holds time to clear.
No. Foxhound retries silently in the background first. The customer only receives an email if all scheduled retries fail to recover the charge.

See what this looks like on your account

The free audit shows what Stripe already recovered and what is still dying, no signup required.

Run your free audit