Decline Code Decoder — Tokens & Rails

21 CODES

Approved

APPROVED

Not a decline — the issuer said yes. Included here because every response carries a code, and 00 is the one everybody wants.

WHAT TO DOShip the goods. Settle the batch.

Refer to issuer

HARD · DO NOT RETRY

The issuer wants a conversation before approving — a relic of the voice-authorization era. Today it usually means the account is flagged for review.

WHAT TO DODon't retry blind. The cardholder should call the number on the back of the card; offer another payment method meanwhile.

Pickup card

HARD · DO NOT RETRY

The issuer wants this card taken out of circulation — flagged lost, stolen, or canceled. In-store, the terminal is literally asking the cashier to confiscate it.

WHAT TO DONever retry. Request a different payment method. In-person: follow your confiscation policy carefully (most merchants don't bother — it's not worth the confrontation).

Do not honor

SOFT · RETRYABLE

The most common — and least informative — decline on earth. The issuer is saying "no, and I won't tell you why." Usually the issuer's fraud model didn't like something: the merchant, the amount, the time, the location. Deliberately vague so fraudsters can't learn the rules.

WHAT TO DOThe classic soft decline. Wait and retry once (many recover within 24–72h), or ask the customer to try another card or contact their bank. If your business sees spikes of 05s, your MCC or descriptor may be tripping issuer risk models.

Invalid transaction

FIX & RESUBMIT

The issuer can't make sense of the request — wrong transaction type for this card or merchant setup. Often a configuration problem on the merchant/processor side, not a card problem.

WHAT TO DODon't burn retries. Check with your processor: MCC setup, transaction type flags, currency configuration.

Invalid amount

FIX & RESUBMIT

The amount field is malformed — negative, zero, or beyond what the message format allows. Almost always a software bug.

WHAT TO DOFix the request. Check for double-conversion bugs (charging ₹100.00 as 10000.00).

Invalid card number

FIX & RESUBMIT

The PAN doesn't exist — failed checksum or no such account. Usually a typo; occasionally a BIN attack probing random numbers.

WHAT TO DOAsk the customer to re-enter. If you see thousands of 14s in bursts, you're being card-tested — rate-limit your checkout.

Format error

FIX & RESUBMIT

The message itself was malformed — a field missing or mis-encoded somewhere between terminal and issuer. The payments equivalent of a syntax error.

WHAT TO DONothing the customer can do. Escalate to your gateway/processor with timestamps.

Lost card

HARD · DO NOT RETRY

The cardholder reported the card lost. Every authorization on it will fail until the replacement arrives.

WHAT TO DONever retry. If you store this card on file, a network token would have auto-updated to the replacement — this decline is the ad for network tokens.

Stolen card

HARD · DO NOT RETRY

Reported stolen. Whoever is using it is not the cardholder — and if you complete this sale another way, the chargeback is guaranteed.

WHAT TO DONever retry. Decline politely, don't offer alternatives, and log the attempt for your fraud screening.

Closed account

HARD · DO NOT RETRY

The account behind the card no longer exists. Common on old cards-on-file and subscription renewals.

WHAT TO DORemove the card from your vault. This is the churn that network tokens and account-updater services exist to prevent.

Insufficient funds

SOFT · RETRYABLE

The honest decline: the money isn't there right now. The single biggest cause of failed subscription payments — and the most recoverable.

WHAT TO DOThe dunning workhorse: retry on a smart schedule (paydays — the 1st and 15th — outperform), or offer to split the amount. Recovery rates of 30–50% on 51s are normal with good retry logic.

Expired card

FIX & RESUBMIT

The expiry date on file has passed. The physical card was probably replaced months ago — your vault just never heard.

WHAT TO DOPrompt for the new expiry. Better: enroll in network tokens / account updater and this code mostly disappears from your life.

Transaction not permitted to cardholder

HARD · DO NOT RETRY

The card can't do this — gambling block, no international usage, corporate card restrictions, or India's default-off rules for online/cross-border use.

WHAT TO DODon't retry the same way. The cardholder may be able to enable the category in their banking app (common in India); otherwise, request another method.

Suspected fraud

SOFT · RETRYABLE

The issuer's risk engine scored this transaction as likely fraud — but unlike 04/41/43, the card itself is fine. Maybe the amount is unusual, the merchant is new, or the customer is traveling.

WHAT TO DOAsk the customer to approve the transaction in their banking app or answer the bank's SMS, then retry once. 3DS on the retry often converts these.

Exceeds amount limit

SOFT · RETRYABLE

Over the card's per-transaction or daily spending limit. The money may exist; the limit doesn't allow it.

WHAT TO DORetry tomorrow, split the payment, or have the cardholder raise the limit in their app (instant in most modern banks).

Restricted card

HARD · DO NOT RETRY

The card can't be used here — geographic restriction, sanctioned country, or product-level block.

WHAT TO DODon't retry. This is policy, not chance. Offer an alternative method.

Activity count limit exceeded

SOFT · RETRYABLE

Too many transactions in the window — the count limit, not the amount limit. Also a favorite tripwire for card-testing bots.

WHAT TO DORetry after 24h. If you're the merchant seeing many 65s from one customer, check whether your own retry logic is the thing hammering the card.

PIN tries exceeded

HARD · DO NOT RETRY

Three wrong PINs and the card locks. Whoever is holding it either forgot the PIN — or never knew it.

WHAT TO DONo retry until the cardholder resets the PIN with their bank. Suggest contactless/online where PIN isn't required, within limits.

Issuer unavailable

SOFT · RETRYABLE

The issuer's authorization system didn't answer — maintenance window, outage, or timeout. The card is fine; the bank is asleep. Spikes at 2–4am local time are normal.

WHAT TO DORetry in a few minutes. Some networks 'stand in' and approve small amounts on the issuer's behalf during outages — which is why your card sometimes works when the bank's app is down.

System malfunction

SOFT · RETRYABLE

Something broke somewhere in the chain — a generic technical failure between acquirer, network, and issuer.

WHAT TO DORetry once after a short wait. If persistent, it's your processor's problem, not the customer's.

DEBUG BY FAMILY

Read declines in families.

Individual codes matter less than their family. Card-status codes mean the card is gone; funds-and-limits codes mean timing; the vague ones mean risk models. Three situations every billing team eventually debugs, then a tree.

PATTERN 01 · THE DECAYING VAULT

Renewals quietly rot

WHAT YOU SEESubscription approval rates drift down a little every month: a growing mix of 54s (expired), 46s (closed), and 51s (insufficient funds).

WHYCards on file decay. Banks reissue cards, accounts close, paydays move — and a stored card number knows none of it. A vault left alone loses a few percent of its cards every month.

THE FIXAccount updater and network tokens heal 54s and many 46s silently, before the renewal even runs. The 51s respond to payday-aware retry schedules. Purge what stays dead — retrying a 46 forever helps nobody.

PATTERN 02 · THE 05 WALL

"No, and I won't say why"

WHAT YOU SEEA good customer, a normal amount, and the least informative code in payments: 05, do not honor.

WHYThe issuer's risk model disliked something — and it's deliberately unexplained, so fraudsters can't learn the rules. When 05s cluster on your merchant account specifically, the model may dislike you: your descriptor, your MCC, or your recent fraud history.

THE FIXBlind retries barely move 05s. A 3-D Secure step-up on the retry often converts them, and the customer approving the merchant in their banking app works even better. If your 05 rate spikes across many issuers, investigate your own descriptor and MCC before anything else.

PATTERN 03 · THE MIDNIGHT STORM

A wall of declines at once

WHAT YOU SEEDeclines spike suddenly across the board. Two very different causes produce the same scary dashboard.

WHYEither an issuer went down (91s and 96s clustered on one bank's cards, often during 2–4am maintenance windows) — or you're being card-tested (14s and 65s across thousands of different card numbers, because bots are using your checkout as a sorting lab).

THE FIXSplit the spike by issuer and by card-number diversity. One bank failing: wait it out, and let network stand-in handle small amounts. Thousands of fresh numbers: rate-limit your checkout now, before the network's monitoring programs notice you didn't.

A DECLINE CAME BACK. WHICH FAMILY IS IT?

1 · Is it a card-status code? (04 · 41 · 43 · 46 · 54)

THE CARD IS GONELost, stolen, closed, or expired — no retry will resurrect it, and repeated attempts on these codes draw network fines. Update the card via network tokens or account updater, or ask for another payment method.

CARD LIVES — KEEP GOINGGo to step 2.

2 · Is it a funds-or-limits code? (51 · 61 · 65)

A TIMING PROBLEMThe account is alive; the money or the limit says not now. This is the retryable family: payday-aware schedules recover 30–50% of 51s, and limits reset daily. Patience, not force.

NEITHER — KEEP GOINGGo to step 3.

3 · Is it vague (05 · 59) or technical (30 · 91 · 96)?

VAGUE = RISK MODEL05 and 59 mean the issuer's model objected. Step up with 3-D Secure or an in-app approval; blind retries teach the model you're a nuisance.

TECHNICAL = PLUMBING30, 91, and 96 mean the message or the rails failed, and the customer can't fix that. Send timestamps to your processor, wait out outages, and keep the customer's goodwill with a clear "try again shortly."