Of all the decline codes a subscription business meets, "do not honor" is the one that feels most like a personal judgement and means the least specific thing. It is the issuer's generic refusal — a single code standing in for a drawer full of unrelated reasons: a fraud screen tripped, a card reported and replaced, an account under review, a velocity rule, a restriction the bank will not explain to you and often will not explain to its own customer either. Treating it as one problem is the first mistake. It is a category wearing a code's clothes.
What the code rules out, and what it does not
A do-not-honor is not a hard decline in the permanent sense — the card is not necessarily dead, and the same card sometimes pays weeks later without anything visible changing. But it is also not a soft decline you can simply schedule around with confidence, because some share of these really are closed accounts and fraud blocks that will never clear, and the code refuses to tell you which share you are holding.
That ambiguity should set the strategy: limited, spaced, and information-seeking. A small number of attempts, separated by days rather than hours, gives a transient block time to lift. An early, plain message to the subscriber does work no retry can do, because the subscriber can ask their bank a question you are not permitted to ask — and a meaningful slice of do-not-honor blocks lift the moment the cardholder confirms the charge is legitimate. The retry is the blunt instrument here; the customer's phone call is the precise one. A code-by-code walkthrough of what a do not honor decline means and how to work it lays out that ordering; most queues get it backwards, retrying first and asking last.
The insistence trap
The failure mode to avoid is volume. Because the code is unexplained, teams compensate by trying more often, and insistence is the one strategy this particular code punishes. Repeated rapid attempts against an issuer that has already said an unexplained no can deepen fraud-screen suspicion and convert a temporary block into a durable one. Every attempt also spends goodwill in the customer's inbox if each is paired with a notice. With this code, restraint is not caution — it is the mechanism itself.
Track it separately, too. If do-not-honor is folded into your general soft-decline rate, you will never see the patterns that make it legible: a concentration in one issuer, one card network, one geography, or a spike after a descriptor change. More than one operator has discovered that their own billing descriptor — truncated, unfamiliar, resembling nothing the customer bought — was manufacturing these declines at scale. The code said nothing. The distribution said everything.
A working protocol
Concretely: cap attempts low, space them wide, send one clear message early that tells the subscriber exactly what to ask their bank, and offer an update path for the cases where the old card really is gone. Then review the class monthly by issuer and by cohort before touching the cadence again. That protocol recovers less per account than an aggressive one promises — and more per queue than an aggressive one delivers, because it stops converting the recoverable middle into permanent losses.
Reading codes as categories rather than verdicts is most of the craft in this corner of billing, and it is the habit maintained in the recovery work at Swipe Again. The bank will not explain itself. Your job is to build a sequence that does not need the explanation — one that asks the only person who can get one, early, politely, and exactly once.
Top comments (0)