Credit Card Declined Codes and What to Do

The most popular advice on credit card declined codes is to look up the number, read its one-line meaning, and try again. That's exactly how billing teams burn approval rates. A code isn't a diagnosis. It's a routing signal that tells you whether to fix data, wait, switch tender, or stop.

If you treat every decline as the same error, you'll retry stolen cards, hammer empty accounts, and resend expired credentials until the issuer trusts you less. I would start with the cheapest fix instead. Read the raw code, put it in a recoverability family, and set a stop condition before anyone clicks retry.

Common Credit Card Decline Codes at a Glance

Code	Usual meaning	Class	First action
00	Approved or completed successfully	Approval	Capture or complete the order
01	Refer to card issuer	Issuer referral	Ask the customer to contact the issuer; don't blind-retry
03	Invalid merchant	Configuration	Fix merchant ID, MCC, or terminal setup before any retry
04	Pickup card, lost or stolen	Hard security	Stop retries and offer another payment method
05	Do not honor	Ambiguous issuer	Investigate; don't assume one cause
10	Partial approval	Approval where supported	Complete only the approved amount or void per policy
12	Invalid transaction	Unrecoverable format or type	Correct the transaction type or data, then send a new auth
14	Invalid account number	Bad credentials	Ask for a corrected card; don't retry the same PAN
15	Invalid issuer	Unrecoverable routing	Stop and collect a different card
30	Format error	Configuration or payload	Fix the message fields before retrying
41	Lost card, pickup	Hard security	Stop retries and route to another tender
43	Stolen card, pickup	Hard security	Stop retries and route to another tender
51	Insufficient funds or over credit limit	Temporarily recoverable	Space a retry or ask the customer to use another method
54	Expired card	Credential update	Request a new expiry or updated card; don't re-send the old expiry
55	Invalid PIN	Customer input	Prompt for the PIN again or switch channel; don't loop online
57	Transaction not permitted to cardholder	Restriction	Stop and route to another tender
59	Suspected fraud	Hard risk	Stop retries and review with fraud tools
61	Exceeds approval amount limit	Temporarily recoverable	Lower the amount or wait; don't hammer the same amount
62	Restricted card	Hard restriction	Stop and ask for another card
65	Activity count limit exceeded	Temporarily recoverable	Wait out the velocity window
85	Not declined (Mastercard and Visa)	Not a decline on those networks	Treat as non-decline only where the network table says so
93	Transaction cannot be completed, legal or regulatory	Non-retryable	Stop and don't reattempt

How to Read a Row

Read across, not down. The code is what the network returned, the class is your recoverability decision, and the first action is the only move you make before you gather more evidence. If the class says hard security or non-retryable, there is no second attempt to debate.

Don't let gateway text override the row. Processors rename these values, collapse them into a generic declined label, or print friendly text like insufficient funds against a code the issuer used for something else. The stored network code wins.

Practical rule: If support can't see the two-character network code on the transaction record, they can't triage the decline. They can only guess.

Use this table as an index at the terminal or in a support macro. It answers what to do first. It doesn't set retry timing, subscription logic, or customer messaging for ambiguous codes, because those decisions depend on the family and the evidence around the attempt.

Codes 00, 10, and 85 deserve special care. They're not failures in the same sense as the rest, and treating them as declines creates refunds, duplicate orders, and confused customers. Confirm whether your acquirer supports partial approval before you build a flow around 10.

How a Decline Code Travels and Where Labels Diverge

A decline code is a routing signal, not a diagnosis. Start with the raw network value, then decide whether that code family supports a retry, needs a correction, or requires a stop. In ISO 8583, the issuer's authorization response is carried in data element 39. Mastercard's network response code documentation identifies 00 as “Approved or completed successfully,” 01 as “Refer to card issuer,” and 05 as “Do not honor.” The value passes through the issuer, card network, processor, and merchant before it appears in your dashboard.

Numeric responses let payment systems exchange compact, machine-readable outcomes instead of free text. Labels can change at each handoff: processors and gateways map network codes to their own status names, and some reduce distinct responses to the same generic label.

Where the Label Changes

A gateway may group 51, 05, and 61 under one soft-decline label. That hides important differences: insufficient funds, a generic refusal, and an amount limit do not call for the same next step. Treat the code as an input to a recoverability decision, not as a complete explanation of why the issuer declined.

Network applicability also varies. Mastercard's referenced table lists 85 as “Not declined” for Mastercard and Visa, not for every network. Don't treat 85 as a universal approval. Likewise, 10 is only useful as a partial approval when the merchant, acquirer, and network support completing or reversing the remaining amount.

What to Store on One Record

Keep the evidence together so the team can choose a next action and set a stop condition:

• Raw network code: The two-character value from data element 39, unchanged
• Gateway view: The normalized status and response text exactly as returned
• Transaction context: Brand, entry mode, recurring indicator, transaction type, and merchant category
• Attempt history: Retry count and each later outcome, linked to the original code

If the dashboard label conflicts with the raw code, use the raw code for triage. Ask the processor for its mapping table and document how its labels correspond to network responses. Do not infer a cause from friendly text alone.

If a processor returns an unfamiliar string without a network code, ask the acquirer how it maps that response. A guessed ISO meaning can send a configuration problem into a customer retry flow, or lead a team to retry when it should stop. Tie each code family to an explicit recoverability decision, and don't let a gateway label erase that distinction.

Decline Families by Recoverability

A decline code is a routing signal, not a diagnosis. The useful decision is whether to correct the request, wait and retry within limits, or stop. Mastercard's transaction-processing rules distinguish outcomes that merchants can address from those that should not be retried.

The chart groups credit card decline codes by recoverability.

The Four-Way Policy in Practice

Temporarily recoverable codes include 51, 61, and 65. The issuer cannot approve at that moment, but a later attempt may succeed if funds, an amount limit, or an activity window has changed. Set a retry window and stop condition; immediate repeat attempts can add declines without improving approval odds.

Fix before retry applies to 03, 12, 30, 54, and 55. Correct the merchant setup, transaction format, or credential first. Resending the same faulty payload is likely to produce the same result. Code 15 belongs in the stop-and-collect path, not here.

Family	Example codes	Posture	Timing
Temporarily recoverable	51, 61, 65	Spaced retry or alternate tender	Examples include 1 hour, 24 hours, or 72 hours; max 15 attempts in 30 days for governed categories
Fix before retry	03, 12, 30, 54, 55	Correct data or setup, then a new authorization	Do not retry the same bad payload
Hard stop	04, 57, 59, 62, 93	Stop, contact the customer, or use another method	Do not retry
Ambiguous issuer	05, sometimes 01	Gather evidence before choosing a path	Case by case, never a blind loop
Not a decline	00, 85 where the network applies	Complete or treat as non-decline	No recovery needed

J.P. Morgan's authorization guidance distinguishes “issuer will never approve” from “issuer cannot approve at this time.” For certain response categories, it advises limiting reattempts to a maximum of 15 attempts over 30 days, with examples of retry timing after one hour, 24 hours, and 72 hours. Treat that ceiling as an outer limit, not a target.

Hard stops include lost or stolen cards, pickup requests, restricted cards, suspected fraud, transactions that are not permitted, and legal or regulatory responses. Code 05 remains ambiguous: gather issuer or processor evidence before deciding whether to stop or take another path. Automate the family assignment, but only retry when the code, permitted timing, and stop condition are all defined.

What High Volume Codes Look Like at Checkout

Codes mean little until you tie them to evidence at the moment of failure. These scenarios show how a cashier, checkout flow, or billing job should react differently even when the customer only sees declined.

Funds and Limits in the Moment

Say a shopper checks out with an $86 cart on a debit card two days before payday and gets 51. The customer-facing line is simple. Your bank couldn't approve this amount right now, would you like to use another card? Internally, note temporary funds and don't run an immediate second authorization for the same amount. That second attempt adds a decline and can leave a hold without adding approval odds.

Now compare 61 and 65. A $1,200 travel booking that exceeds the approval amount is an amount problem. A sixth small attempt in one day that trips an activity count is a velocity problem. For the first, lowering the amount or splitting tender can change the outcome. For the second, only waiting out the window helps, and another attempt just extends the pattern the issuer is watching.

Credentials That Won't Fix Themselves

Say a stored Visa ending 4242 with expiry 08/25 fails a June 2026 renewal with 54 because the plastic was replaced. Don't send the old expiry again. The fix is an account updater check, a network token, or a card-update email that lands the customer on a secure update form. The internal note should read dead credential, not retry pending.

A 14 or 55 at a form is different. That's usually customer input, a mistyped PAN or PIN. Re-prompt once with field-level validation, highlight the exact field, and let the customer correct it. Evidence that would change your action is repetition. A third bad entry stops being a typo and starts looking like testing.

A passed 3-D Secure authentication still doesn't force approval if funds, limits, or risk rules fail afterward.

When the Right Action Is a Calm Stop

A new device, mismatched AVS, and a 59 or 04 response is a stop. Tell the customer the bank declined the payment and another method is required. Don't name fraud or theft at checkout. Internally, route the attempt to fraud review, suppress retries on that card, and keep the device and AVS evidence on the record.

Build these cases into your checkout test coverage before launch. Teams that document scenarios this way can borrow structure from sample test plans for software projects to turn each code family into an expected-result test case. That way a release that breaks your 54 update flow fails in staging, not on renewal day.

Where Declines Concentrate by Reason

Rank your fixes by where value fails, not by which code annoys support most. From April 2023 through March 2025, Visa's global VisaNet data identified insufficient funds as the leading decline reason by transaction amount, suspected fraud ranked second, and exceeding the approval amount ranked third. Most value at risk sits in funding and limits, not stolen cards.

Marker	Figure	Period	Source
Leading reason by transaction amount	Insufficient funds	April 2023 through March 2025	Visa VisaNet
Second reason by transaction amount	Suspected fraud	April 2023 through March 2025	Visa VisaNet
Third reason by transaction amount	Exceeding the approval amount	April 2023 through March 2025	Visa VisaNet
Share tied to technical issues or policy errors	15% of card-payment declines	2024	Mastercard internal analysis

That last row is your fixable slice. In 2024, 15% of card-payment declines were attributed to technical issues or policy errors, according to Mastercard's internal analysis. Cleaner message formatting, current credentials, and accurate recurring indicators can remove much of that share without asking the customer to do anything.

How to Use the Ranking

• Funds and limits: Offer timing choices and alternate tenders at the point of failure
• Suspected fraud: Keep the hard stop and send the evidence to fraud review
• Technical share: Give it to engineering as a backlog with code-level counts

These figures describe the broad market, not your merchant category. Compare your own mix by code family against them instead of assuming parity. A subscription business drowning in 54 has a credential problem even if the global ranking leads with funds.

Don't convert market rankings into a retry schedule. They set investment priorities. Mishandled retries and frustrated repeat attempts can also push customers toward disputes, which is where a rising chargeback rate becomes a processor problem rather than a checkout problem. Keep the two dashboards separate.

How to Handle a Decline Without Blind Retries

Run one sequence before anyone reaches for retry. The flow below summarizes the decision order.

Mastercard's transaction processing rules distinguish recoverable, temporarily recoverable, unrecoverable, and non-claimable categories, including 51, 61, and 65 versus 03, 12, 15, 30, 54, and 55. Your runbook should encode that split so no one improvises under pressure.

The Checkout Runbook

1. Read the raw code: Map it to a family before you touch the transaction again
2. Fix deterministic errors: For 03, 12, 15, 30, correct amount, currency, merchant configuration, or account fields, then send a new authorization with a new idempotency key
3. Replace bad credentials: For 14, 54, stop attempts on that card, tell the customer, and request an updated method
4. Space temporary failures: For 51, 61, 65, offer another tender now or schedule only the spaced attempts your rules allow
5. Stop on hard codes: For 04, 41, 43, 57, 59, 62, 93, route to customer service or an alternate payment with no retry
6. Investigate 05: Don't pick a single cause, gather evidence first
7. Log everything: Record the original decline and every later outcome by code family

The stop conditions sit at steps five and six. A hard code ends the sequence. An ambiguous 05 that stays unexplained after data and authentication are clean also ends it, because another attempt adds issuer risk signals without adding information.

Repeated authorizations can create duplicate holds and make a legitimate customer look like a testing pattern. A successful authentication isn't an approval either, so don't let a passed challenge talk you into forcing the payment.

The walkthrough below shows the sequence applied step by step.

Measure recovery by family, not by headline approval rate. A team that recovers more 51s by waiting, while retrying 54s into the ground, has two different problems wearing one metric.

Why Code 05 Is Not a Single Cause

Dictionary pages that give 05 one meaning are selling false certainty. Stripe's authorization guidance notes that code 05 may reflect anything from insufficient funds to repeated denied attempts, while issuer declines can also arise from fraud controls, outdated card data, authentication gaps, or issuer outages. "Do not honor" is the issuer declining to explain itself, not a root cause.

The diagram below maps the conditions a single 05 can hide.

A Four-Branch Decision Tree

Correctable data is your first check. Invalid expiry, CVC, or PAN points to a form prompt owned by checkout or support. If the customer corrects a field and the next attempt approves, you've found your branch. If nothing was wrong with the data, move on instead of asking them to retype correct numbers.

Retryable issuer condition comes next. Temporary funds or a limit problem fits when the amount is high, the timing is tight, or the customer confirms a balance issue. The action is a spaced retry or another tender, owned by billing. The customer message shouldn't accuse. Your bank couldn't approve it right now is enough.

Authentication-related failures need a new authenticated attempt when a step-up was missing or failed. Warn the customer that completing the bank check doesn't guarantee approval, because the issuer can still decline afterward for funds, limits, a blocked card, or risk. Risk owns this branch.

Non-retryable security or account status is the final branch. Lost, stolen, restricted, or explicitly not permitted conditions end the sequence. Support owns the calm message and the alternate payment offer.

Don't let a dashboard rename 05 as insufficient funds. That guess follows the customer into every support conversation and it's often wrong.

Escalate to the issuing bank through the customer when 05 repeats after data is verified and authentication is clean. At that point the issuer is the only party who can see the reason. Your job is to hand the customer a clear ask and stop spending attempts.

What to Do on a Failed Subscription Renewal

A card that approved yesterday fails today for boring reasons. Cards expire, banks reissue plastic, risk models shift, and none of it means the customer changed their mind. EMVCo's recurring and installment guidance treats recurring and installment payments as a distinct use case requiring coordinated communication among the merchant, cardholder, and issuer to prevent declined transactions.

The timeline below shows how those changes line up against renewal day.

Stored credentials go stale when a card expires or is replaced. Network tokens are designed to remain usable when underlying card details change, and an account updater is the parallel path for expired or replaced PANs. If you're still relying on raw stored numbers with no updater coverage, renewal declines are a predictable cost of that choice.

Map the Renewal Action to the Failure

• Expired or invalid credentials: Request updated payment details and pause attempts on the dead card
• Temporary funding or approval-limit failures: Use a controlled, spaced retry with the recurring indicator and an idempotency key
• Authentication requested: Send the customer through authentication, then submit a new authorization
• Closed, lost, stolen, or not permitted: Stop immediately and ask for a different method

That split tracks the soft versus hard distinction in network guidance. Some soft declines, including insufficient-funds responses, may be retried after a reasonable waiting period, while lost-or-stolen-card responses shouldn't be retried. Also check the setup itself. A card saved for one-click checkout may not carry the recurring linkage a renewal needs, and migrations that drop the original transaction reference show up as sudden renewal failures.

Measure recovered revenue by decline category, not by retry volume. High attempt counts with low recovery mean your dunning is generating issuer risk signals, not revenue.

Set the stop rule in advance. After the customer is notified, the update window has passed, and you hit either the attempt cap or a hard code, cancel the dunning attempt and pause the subscription. The question isn't what 51 means in the abstract. It's what you do next, and when you stop.

Stop Dunning and Record the Outcome

Stopping well is a billing skill. A clean stop protects your authorization rates, keeps the customer relationship intact, and leaves a record the next invoice can use.

The Four Stop Conditions

1. Hard stop family: For 04, 41, 43, 57, 59, 62, 93, end dunning at once, release any lingering hold, and mark the card so the next invoice doesn't retry it
2. Cap or window exhausted: When spaced attempts run out, or a dead credential isn't updated after notice and the update window, cancel the attempt and pause the subscription
3. Record the outcome: Write the decline family, raw code, customer notice date, and final result on the original record
4. Separate disputes from declines: If a charge went through and the customer later disputes it, a decline code won't defend the sale, so review promptly and refund before escalation where the process allows

That customer conversation matters. Framing matters as much as timing when money is overdue, and the principles behind escalating unpaid invoices without damaging relationships apply to a paused subscription too. Firm on the stop, clear on how to restart, no blame in the message.

On the dispute side, speed is the lever. Our alerts connect to Visa, Mastercard, American Express, and other card networks, and the merchant is notified of a dispute in seconds. Our Verifi Network (CDRN) coverage provides direct issuer alerts and 72 hours to refund and stop chargebacks, and you only pay when we prevent a chargeback from hitting your account. That's the window where a refund is cheaper than the formal process described in our guide to fighting chargebacks after they file.

Outcomes still depend on issuer, processor, and network rules, and nothing here promises a specific chargeback result. The end state you're aiming for is simple. Every failed authorization carries its raw code and family, retries stay under the cap, and every stop is written down.

---

Stop guessing at declines and start routing them by family, then protect the payments that do go through. Disputely connects dispute alerts across Visa, Mastercard, American Express, and other card networks, notifies you in seconds, and gives you up to 72 hours through CDRN coverage to refund before a dispute becomes a chargeback. Visit Disputely to set your refund rules and only pay when a chargeback is prevented from hitting your account.