Of all the responses a card network returns, do not honor is the least informative and the most common. It is the issuer's shrug: not a claim that the card is gone, not a claim that the money is absent, just a refusal without a reason attached. Billing teams hate it because it offers nothing to act on. Every playbook step depends on knowing what went wrong, and this code's entire content is that something did.
The first discipline is not inventing a reason. A do not honor on a long-held card with a clean history often traces to issuer-side caution: an unusual pattern flag, a velocity check, a card quietly reissued under a fraud programme the customer has not yet heard about. A do not honor on a first charge after signup reads differently. Same code, different animal, and treating the two cases with one sequence wastes the goodwill of the first customer and the time of the second.
What the code does permit is patience with structure. Because no hard stop has been declared, the payment may succeed on a later attempt once the issuer's temporary caution clears, and the network account updater may supply a replacement credential in the meantime if the card was reissued. The sequence that fits is measured: attempts spaced across days rather than hours, an early and honest message to the customer asking them to confirm the card with their bank, and no theatrical urgency, because from the customer's side nothing visibly happened except your email.
That measured reading is developed in a plain reading of the do not honor code and the patience it actually requires: how it differs from its neighbouring codes, what the spacing between attempts should respect, when to stop retrying and let the customer conversation carry the case, and why hammering an issuer that has raised a caution flag can convert a temporary refusal into a lasting one.
The stopping rule matters as much as the retry rule. A soft refusal that survives a full, well-spaced sequence and a direct customer conversation has told you what it can. Continuing to present the charge teaches the issuer's systems to associate your descriptor with noise, a reputation cost that lands on your other customers' renewals. Every recovery programme has a day on which a case becomes a write-off with a clean final message, and do not honor cases should reach that day on schedule rather than by exhaustion.
There is a reporting lesson buried in this code, too. Because it explains nothing, it inflates quietly: a rising do not honor share is often the first visible symptom of a descriptor problem, a processor change, or an issuer tightening across a whole portfolio. Read it as a trend line, not a case type, once a month. The code that says nothing about one payment can say a great deal about all of them.
For developers wiring decline handling into a billing stack, the practical translation is a small state machine with honest labels: this code enters the patient path, attempts are spaced in days, the updater is checked before each attempt, the customer is asked once, early and plainly, and the case exits to a clean write-off on a fixed day unless money lands first. Teams that encode the shrug as an error to be retried immediately build the hammering behaviour the issuers punish. Teams that encode it as weather, waited out on schedule, recover the quiet share of these cases that were never refusals at all, only pauses.
A shrug from the issuer is not a verdict on the customer. Work it patiently, ask the human early, and stop on time.
Swipe Again sequences do not honor cases on a spaced, issuer-respecting schedule with the customer conversation running alongside, inside its flat-fee recovery service.
Top comments (0)