Skip to content
Decline code 05 Issuer catch-all

Do Not Honor

Category: Do Not Honor Retryable: conditional

Read this first

This code is commonly used as a generic catch-all — issuers deliberately withhold the real reason. Treat the label below as a starting point, not a diagnosis. It will not tell you the actual cause, and neither will anyone who reads it to you.

Variability

Issuer catch-all

Issuers use this code as a deliberate non-answer. Treat the label as a starting point, not a diagnosis.

Retryable

conditional

Commonly retried after 3-7 days, but there is no fixed rule — because the underlying reason is undisclosed, timing guidance is a heuristic built from aggregate retry-success data (PSPs with volume build their own 05-specific retry curves), not a scheme-published window.

Namespace: Legacy/conventional ISO 8583 field-39 code as implemented by card networks and processors — not the current ISO 8583:2023 Annex D table.

What this code typically means

The single most common — and least informative — decline code in card payments. Issuers use 05 as a deliberate catch-all: a risk-model score, a daily spend pattern, an internal fraud rule, or simply a preference not to authorize, all get returned as 05 rather than a more specific code — partly so a fraudster probing a stolen card number can't learn which specific defense stopped them. Adyen's own refusal-reason system effectively concedes the same point: its catch-all bucket, code 27 ('Declined Non Generic'), exists precisely because responses like a generic Do Not Honor 'cannot be reliably mapped' to anything more specific.

What to do about it

Merchant action

Do not retry immediately. Wait several days, and cap retries — scheme rules penalize excessive re-attempts on the same PAN regardless of code. If 05 recurs across billing cycles, contact the customer rather than continuing to retry blind.

Customer-facing guidance

Direct the customer to their card issuer; the issuer will not explain the specific trigger to the merchant, only (sometimes) to the cardholder.

What's happening on the issuer's side

Withheld by design — that opacity is the entire function of this code.

Cross-processor equivalents

stripe: do_not_honor

commonly treated as equivalent — Stripe's own description: "The card was declined for an unknown reason"

adyen: 27 — Declined Non Generic

commonly treated as equivalent — Adyen's explicit catch-all for network codes it says it "cannot reliably map"

Cross-processor mappings are commonly treated as equivalent, not identical — every processor's own documentation notes lossy or partial mapping between raw network codes and its own vocabulary.

Confidence: high. Status: convention. This code is widely used across card networks and processors but is not traceable to a single fetchable authoritative standard document — the current ISO 8583:2023 standard uses a different (4-digit) code scheme entirely. This entry is cross-verified against Stripe, Adyen, and/or a dated processor implementation; see sources below.

Sources

Concept + retry philosophy

Decline Codes: why they're opaque and how to retry them