Stripe "do not honor" decline: recovery playbook

Of every 100 failed charges on Stripe, roughly 30-40 come back as do_not_honor. It's the single most common decline code and the most misunderstood. The customer's bank has refused the charge without telling the acquirer exactly why. The playbook for recovering it is the same — but almost nobody runs it.

1. What do_not_honor actually means

ISO-8583 code 05. Issuer's risk model said no. It's not insufficient funds (separate code), not card invalid (separate code), not velocity limit (separate code). It's the issuer's internal signal that "this charge, on this card, right now, doesn't pass our model." Could be merchant descriptor, amount, time of day, BIN exposure, or 12 other signals the issuer doesn't share.

2. Why blind retry fails

Retrying the same charge through the same rail within 15 minutes hits the issuer's cached decision. You'll get the same decline. Retrying 60+ minutes later might get a different answer, but only ~18% of the time. Blind retry is the floor, not the ceiling.

3. Lever 1: descriptor swap

If your current charge goes out as "PEPTIDESRUS*SHOP" and declines, retrying as "RESEARCHLABS*ORDER" through a different MID (same legal entity, different brand descriptor) recovers about 18-25% of do_not_honor declines. The issuer sees a different merchant profile and re-scores. See descriptor strategy.

4. Lever 2: 3DS step-up

Re-presenting the charge as a 3D Secure authenticated transaction transfers liability from acquirer to issuer. Issuers approve 3DS-verified charges at materially higher rates after an unauthenticated decline — typical lift is 12-20% recovery. Your checkout needs a conditional 3DS retry flow, not always-on 3DS.

5. Lever 3: MID/acquirer swap

Routing the retry through a different acquirer entirely changes the issuer's view of the transaction. This is where multi-MID operators recover 15-25% that single-MID operators don't even see. Requires orchestration infrastructure (not just multiple Stripe accounts — those don't talk to each other).

6. Lever 4: amount adjustment

Some issuer models use round-amount signals. A $100.00 charge that declines sometimes succeeds at $99.47 because the round-number trigger isn't hit. This isn't a reliable lever by itself but is worth layering on for high-value-cart recovery.

7. Lever 5: account updater

Stripe's Card Account Updater auto-refreshes stored cards when issuers push updated credentials. For subscription charges with do_not_honor, enabling the updater recovers 8-15% over 60 days as issuer-side signals resolve.

8. Stacking levers

A full recovery sequence: original charge declines → wait 15 min → retry with descriptor swap → if declined, retry with 3DS step-up → if declined, retry through alternate MID → if declined, queue for updater → if still declined at 14 days, CS outreach. Each layer adds 8-25% recovery; the stack recovers 35-50% total.

9. Reading the BIN concentration

Pull 30 days of do_not_honor declines and cluster by BIN. If one BIN range produces 30%+ of declines, that's an issuer-specific pattern — likely your descriptor or MCC conflicts with their model. Fix the merchant-side signal rather than running recovery forever.

10. Customer service script

The customer sees a generic "payment failed" message. Your CS script: "Your bank returned a soft decline. Please try another card, re-submit, or contact your bank to pre-authorize the charge." Do NOT say "your card was declined" — that's framing the problem as the customer's fault and they'll dispute other charges on frustration.

11. Subscription billing angle

Subscription rebills get higher do_not_honor rates because issuers de-prioritize recurring MCC-5912 / 5499 charges. Stripe's Smart Retries help but don't do descriptor/MID swap. A recovery layer that routes the rebill through a different descriptor on attempt 2-3 recovers materially more. See subscription recovery.

12. What multi-brand operators do differently

Multi-brand operators on single-Stripe accounts can't rail-swap. Multi-brand operators on parent-account structures with 2-3 acquirers behind them can. The lift is typically 15-25% approval rate improvement across the portfolio — at 8-figure revenue, that's the full annual revenue of a small brand.

13. Measuring recovery performance

Track: recovery rate per lever (descriptor swap recovery %, 3DS step-up recovery %, MID swap recovery %), net revenue recovered, false positive rate (customers who would have re-purchased anyway). Without measurement, you can't tune the stack.

14. What not to do

• Don't blind-retry 5x in 15 minutes — flags the BIN and issuer
• Don't blame the customer in messaging
• Don't skip 3DS step-up because of friction — the friction is better than the lost revenue
• Don't ignore BIN patterns — they're telling you something about your merchant profile

Recovery checklist

• Log raw network_reason code, BIN, amount, descriptor, 3DS status per decline
• Configure descriptor pool (2-4 descriptors rotated across MIDs)
• Build conditional 3DS step-up on retry
• Enable Card Account Updater for subscriptions
• Route retry through alternate acquirer if available
• Measure per-lever recovery rate
• Pull BIN concentration monthly to spot patterns

Next steps

Single-brand operators: implement lever 1 + 2 + 5. Recovery lift usually 15-25%. Multi-brand operators: the full orchestrated stack is what we build. See Stripe comparison, pricing, apply.