Do Not Honour: what decline code 05 actually means

The decline that explains nothing

Of all the authorisation declines a merchant sees, 05 – Do Not Honour is the least helpful. It is the issuer's catch-all refusal: the transaction is declined, and no reason is given.

That vagueness is the problem. A 05 is not one failure mode, it is several very different ones wearing the same label — and the right response to each is different. Retrying a genuine fraud decline is wasted effort and a risk flag. Retrying a temporary issuer timeout is often the whole fix.

So the work is not "how do I stop getting 05s". It is: which underlying reason is this, and what is the right fallback for it?

The reasons hiding behind a 05

Risk decline

The issuer's risk engine refused the transaction. This is the branch that matters most, because it splits into two opposite cases — one where the refusal was correct, and one where it cost you a real customer.

True fraud

The risk decline was right. The transaction was genuinely fraudulent, and the decline did its job. There is no sale to recover here, and retrying only adds risk signal against the merchant.

False positive

The risk decline was wrong. A legitimate customer with a legitimate card was refused. This is the most expensive category on the page: the revenue is real, the customer is real, and the only thing standing between them is a model's judgement call.

Insufficient funds

The account cannot cover the transaction. Recoverable, but on a different timescale — the answer is when to retry rather than how.

Timeout

The authorisation did not complete in time. Nothing is wrong with the card or the customer; the infrastructure simply did not answer. Often the most straightforwardly recoverable of all the causes.

Issuer policy

The issuer's own rules refused the transaction — merchant category, geography, channel, or a limit the cardholder never set themselves. Retrying the same way reproduces the same result.

Fraud decline

An explicit fraud refusal rather than a risk-score outcome. Treat it as final.

Authentication failures

The transaction failed at the authentication step rather than the authorisation one. The fix belongs upstream in the checkout flow, not in the retry logic.

Possible fallback strategies

No single fallback answers every 05, which is exactly why the diagnosis comes first. These are the levers available once you know what you are looking at.

• ·
  Smart retry

  Retry with timing and logic chosen for the cause, rather than blind repetition. Effective against timeouts and insufficient funds; counterproductive against a true fraud decline.
• ·
  Split payments

  Break the amount across more than one authorisation or method, so a limit or a partial balance does not take the whole sale with it.
• ·
  BIN-level benchmarking

  Compare decline behaviour by card BIN to find where 05s concentrate. A rate that clusters on particular issuers or card ranges is a routing problem, not a customer problem.
• ·
  Tokenisation

  Use network tokens so credentials stay current and the issuer sees a cleaner, more trusted transaction.
• ·
  Switch credential

  Ask the customer for a different card, or use another stored credential where one exists — the fastest route past an issuer-policy refusal.
• ·
  Alternative methods

  Offer a non-card path at the point of failure. If the issuer will not authorise, a local method the customer already trusts can still complete the sale.
• ·
  Escalation

  Raise persistent patterns with the acquirer or issuer. A 05 rate that will not move is a relationship conversation, not a configuration one.

Where to start

The single most useful move is to stop treating 05 as one number. Segment it — by issuer, by BIN, by geography, by time of day — and the flat catch-all starts separating into the causes above.

From there the fallbacks stop being guesses. A cluster on one issuer points at policy or routing. A spread across many issuers at the same moment points at a timeout. A pattern that follows a customer segment rather than a card range points at false positives in someone's risk model.

That is the whole argument: a decline you can name is a decline you can act on.

Questions this answers

What does decline code 05 mean?

05 is "Do Not Honour" — the issuer has refused the transaction without giving a reason. It is a catch-all rather than a specific failure, which is what makes it hard to act on: several very different causes all surface as the same code.

Does a 05 decline mean the transaction was fraudulent?

Not necessarily. Fraud is one possible cause, but a 05 can equally be a false positive from the issuer's risk engine, insufficient funds, an authorisation timeout, an issuer policy rule, or a failure at the authentication step. Treating every 05 as fraud writes off legitimate revenue.

Can I retry a Do Not Honour decline?

It depends entirely on the underlying cause. Retrying is often effective against timeouts and insufficient funds, where nothing is wrong with the card itself. Retrying a genuine fraud decline is wasted effort and adds risk signal against the merchant, and retrying an issuer-policy refusal the same way simply reproduces the same result.

What is a false positive decline?

A false positive is a risk decline that should not have happened: a legitimate customer with a legitimate card, refused by the issuer's risk model. It is the most expensive category of 05, because the revenue and the customer are both real and the only obstacle is a model's judgement.

How do I find out what is actually causing my 05 declines?

Segment them. A flat 05 rate tells you nothing, but the same declines broken down by issuer, card BIN, geography and time of day usually separate into their real causes. Declines clustering on one issuer suggest policy or routing; declines spread across many issuers at one moment suggest a timeout; declines that follow a customer segment rather than a card range suggest false positives.

Take it with you

You have just read the whole thing — this is the same content as a file you can keep and share. Infographic · 1 page