Credit card decline codes: meaning and next steps

A credit card decline code is the short response an issuer or card network returns when it refuses an authorization. It tells you what the issuer said, not always why. Code 05, “do not honor”, is the famous example: Stripe describes the matching do_not_honor decline as “declined for an unknown reason”. Use the code to choose an action, retry later, ask for a card update, run authentication or stop, and never to guess a cause you cannot see.

Here is the lookup table, then how Visa and Mastercard group declines, how often you may retry, what to log and what to tell the customer. For Stripe’s own decline strings (insufficient_funds, do_not_honor…), see Stripe decline codes explained.

Decline code lookup table

One code can hide several causes, and different codes can share a fix, so treat this table as a routing aid rather than a diagnosis. The labels are the usual ones for Visa response codes; other networks and processors word some of them differently, so check the codes you rely on against your processor’s documentation.

Code	Common label	What it typically means	Recovery action
00	Approved	Approved and completed successfully	No action; record as paid
01	Refer to issuer	Issuer asks the cardholder to contact the bank	Ask the customer to contact the card issuer or use another method
02	Refer to issuer, special condition	Issuer decision under a special condition	Ask the customer to contact the issuer; avoid repeated attempts
05	Do not honor	Issuer declined without a stated cause	Treat as ambiguous; limited retry, then request a payment update
14	Invalid account number	No such card number	Never retry the same number; request a new payment method
39	No credit account	No credit account linked to the card	Request a new payment method
46	Closed account	The account is closed	Never retry the same card; request a new payment method
51	Insufficient funds	Not enough available funds	Retry later, within network limits
54	Expired card	Card has expired or the expiry date is wrong	Send a card update link
61	Exceeds withdrawal limit	Amount is over an issuer limit	Retry later, within network limits
62	Restricted card	Card invalid in this region or country	One retry at most, then ask for another payment method
65	Exceeds withdrawal count limit, or authentication required	Too many transactions; on Mastercard in PSD2 scope, the issuer wants authentication	Retry later, or run 3D Secure if authentication is required
78	Blocked, first used	Card not properly unblocked by a new cardholder	One retry at most, then ask for another payment method
93	Transaction cannot be completed, violation of law	The issuer cannot approve for a legal reason	Do not insist; ask for another payment method

Read a row in two steps. Match the exact code in your logs first, then check whether the action fits the customer in front of you. A 51 on a subscriber who has paid for fourteen months is usually a timing problem and earns a well-spaced retry. An 01 on a brand new customer is a bank that wants to hear from its own cardholder, and three retries in a row will not change that.

Watch the lookalikes. 51 points at the balance, 61 at an issuer limit on the amount. Code 65 has two meanings, as Adyen’s raw response table shows: “exceeds withdrawal count limit”, and, for Mastercard on payments in PSD2 scope that skipped 3D Secure, “authentication required”. Visa uses 1A for the authentication case. Code 05 stays the odd one out: the honest message to the customer is “your bank declined this charge”, never a guessed cause.

How do Visa and Mastercard group decline codes?

Visa groups response codes into four categories. It introduced them in April 2020, and its rule update effective 17 April 2021 moved several codes between categories. As Adyen summarizes them:

Visa category	Meaning	Codes (Adyen’s table)	Reattempts
1	Issuer will never approve	04, 07, 12, 14, 15, 41, 43, 46, 57, R0, R1, R3	None
2	Issuer cannot approve at this time	03, 19, 51, 59, 61, 62, 65, 75, 78, 86, 91, 93, 96, N3, N4	Up to 15 in 30 days
3	Issuer cannot approve with these details	14, 54, 55, 82, N7, 1A, 70	Up to 15 in 30 days
4	Generic response codes	Any other code, 05 included	Up to 15 in 30 days

Two details from Visa’s own bulletin matter. Codes 03, 62, 78 and 93 moved from Category 1 to Category 2, “to allow merchants to reattempt up to 15 times in 30 days”. Code 14 sits in both Category 1 and Category 3, and “merchants must not reattempt any transaction using the same account number” after it.

Mastercard works differently: alongside the response code, the issuer can send a Merchant Advice Code (MAC) that says whether and when to retry. Stripe exposes it as the network advice code and notes that Mastercard calls these Merchant Advice Codes.

Four responses to a card decline

01 Retry later 51, 61, a first 05: inside Visa and Mastercard limits
02 Update the card 14, 54, expired or wrong details: send a hosted update link
03 Authenticate Mastercard 65 or Visa 1A in PSD2 scope: run 3D Secure
04 Stop Visa Category 1 (14, 46…), Mastercard MAC 03 or 21: ask for a new payment method

How many times can you retry each decline?

A decline code records what the issuer said. How many times you may ask again is a separate question, and the answer comes from the networks, then your processor.

Decline situation	What the rules or docs say	Source
Visa Category 1 (14, 46…)	Do not retry; Visa charges an excessive retry fee	Visa, Adyen
Visa Categories 2, 3 and 4	Up to 15 reattempts in 30 days	Visa, Adyen
Mastercard MAC 03 “Do not try again”	Do not retry; retries can be subject to Mastercard penalty fees	Adyen
Mastercard MAC 21 “Payment cancellation”	Do not retry	Adyen
Mastercard MAC 02 “Cannot approve at this time”	Try again after 72 hours	Adyen
Mastercard MAC 24 to 30 (insufficient funds)	Retry after a set wait, from 1 hour (MAC 24) to 10 days (MAC 30)	Adyen
Any charge that permits retries, on Stripe	Stripe recommends a maximum of eight retries	Stripe

One rule sits above the table: explicit advice wins. If the network or your gateway tells you when to retry, that replaces any fallback schedule you built. The processor, the acquirer, your merchant category and recurring-transaction indicators can all change what is allowed, so store the network response code, the advice code, the attempt time and a payment-method fingerprint, then enforce a retry budget per card.

Stop conditions worth hard-coding

A never-approve code appears. Visa Category 1 codes such as 14 and 46, and Mastercard MAC 03 or 21, close the loop immediately.
A fraud-related signal arrives. Stop and route to the customer, not to another authorization.
The retry budget is spent. Further attempts on the same card rarely recover anything.
The payment method is flagged for update. Sending an update link beats another decline.

How each billing tool (Stripe, Chargebee, Recurly, Paddle, Braintree…) retries by default is in payment retry schedules compared. Whatever you use, make sure only one system owns the retry schedule for a given invoice.

Why does code 05 need a careful response?

The most common misreading of code 05 is that it names a cause. It does not. Stripe calls the matching decline “declined for an unknown reason” and notes that issuers categorize most declines as generic, “making the exact decline reason unclear”. The issuer may be hiding insufficient funds, a fraud screen or an internal rule. In Visa’s scheme, 05 falls in Category 4, generic responses.

Lookup tables encourage the opposite belief: one code, one cause, one action. That belief produces needless retries and customer emails that state a reason the merchant never received. Sort every response into one of five outcome classes instead: retry cautiously, request a payment update, trigger authentication, contact the issuer, or stop retrying. Code 05 belongs in the first class by default, and often moves to the second after one more attempt.

The checks that turn a 05 into a decision

Recent attempts on the same card. Two failures close together mean the next action is an update link, not a third authorization.
Payment history on this subscription. Months of successful charges suggest a timing or funds issue, so a delayed retry inside the budget is reasonable.
Recent card changes. A new card, or one updated days ago, raises the odds of a verification problem the customer can resolve.
Amount against the usual invoice. A sudden large renewal is more likely to trip an issuer limit than the usual monthly amount.

A customer with three months of clean payments gets one 05 on renewal day: wait, retry once inside your budget, and if that fails, send the update link and pause. Keep any fraud signal internal, because a customer-facing message about suspected fraud is both unverifiable and damaging. The full sequence for this code is in what “do not honor” means and how to recover the payment.

Which declines need a new card or authentication?

The line that matters most runs between a temporary decline and an authentication or card-data problem. Retrying fixes the first. It does nothing for the others.

An authentication-required response, Mastercard 65 or Visa 1A in PSD2 scope, should start 3D Secure, not another authorization. Stripe returns it as authentication_required and notes that a soft decline from an issuer usually triggers an authentication flow. What changes on renewals is covered in SCA and authentication on renewal payments.

A routing sequence for any decline

Read the code and place it in a group. Approval, temporary, card data, authentication or never-approve. If you cannot place it, treat it as never-approve until someone checks.
If authentication is required, run the challenge. The customer confirms with their bank and the payment goes through. Retrying without the challenge repeats a request the issuer already refused.
If the card is expired or the number is invalid, send a hosted update link and pause attempts. Code 14 and expired cards need corrected details; attempts against stale data produce nothing.
If the account is closed, or the card restricted or blocked, ask for a new method. 46 is final at Visa. 62 and 78 may be retried under Visa’s rules, but rarely succeed on the same card.
If the decline is temporary, schedule the next attempt inside the network limits. This is the only branch where timing is your main lever.

Some declines arrive with no network response code at all. Stripe exposes the network’s code and advice code in separate fields (network_decline_code, network_advice_code) next to its own decline_code and advice_code; when the network field is empty, route on the processor’s reason rather than treating the gap as unknown.

The card update itself should happen on the payment provider’s secure page. Your support team never needs card numbers, and a customer typing a new card into a hosted page keeps you out of scope for card-data handling.

How should you log decline codes?

Every decision you make later depends on what you write down now. Seven fields cover it:

The raw network response code, exactly as returned. Not “declined”, not “failed”. Losing the raw code makes a later audit impossible.
Any advice code or retry-after value. This is the issuer’s or network’s instruction about when to try again, and it outranks your own schedule.
A timestamp for every attempt. Without them you cannot prove you stayed inside the network’s window, or see that two systems tried the same charge an hour apart.
A payment-method fingerprint, never card details. A stable identifier lets you count attempts per card without touching sensitive data.
The transaction type. First charge, recurring renewal and one-time payment behave differently at the issuer.
The provider’s decision, and whether it retried on its own. Missing the provider’s own retries is how a customer sees four attempts when your dashboard shows two.
An idempotency key. A duplicated request then returns the original result instead of creating a second authorization.

If two systems can retry the same invoice, the log has to say which one did. That matters most on billing tools that keep their own retry rules, including direct debit providers.

A complete entry reads roughly like this: subscription 8821, Visa ending 4242, fingerprint on file, attempt two of four, network response 51 with no advice code, recurring renewal of the usual monthly amount, attempted Tuesday 09:14 UTC, next retry scheduled by the billing tool, idempotency key recorded. Hold your fields against that sentence and the gaps show up fast.

What should you tell the customer for each decline type?

Tell the customer what they can do next. Do not tell them the internal reason, never mention fraud screening, and never state an account detail you have not verified. “Insufficient funds” in an email is a claim about someone’s bank balance that you are not in a position to make.

Three habits carry the tone:

Say what happened in one clause. “Your bank didn’t approve this payment” is honest and complete.
Say what to do. A link, a card update, a quick call to the bank.
Say when you’ll try again. A date removes the worry that produces support tickets and chargebacks.

Decline type	Message to the customer	Avoid saying
Expired card	Your card has expired; please update your card details using the link	Do not mention issuer checks
Temporary issuer or insufficient funds	Your bank did not approve this payment; we will try again on [date]	Do not name a specific cause
Invalid or closed account	The card details we hold cannot be used; please add a new payment method	Do not claim the bank closed the account
Authentication required	Your bank needs you to confirm this payment	Do not call it a fraud block
Ambiguous code 05	Your bank did not approve this payment; please try another method if it fails again	Do not guess the reason
Restricted or blocked card	This card cannot be used for this payment; please use another payment method	Do not cite legal or fraud rules

Give support, finance and customer success the same wording. A customer who reads one explanation in the email, another in chat and a third on the update page learns that nobody knows what happened. Ready-made wording is in our dunning email templates.

How do you write and test retry rules?

Write the rules before you touch a retry setting: one line per decline group, in this order: group, retry window, attempt budget, stop when, next path. For example: expired or invalid card, no retry window, zero attempts, stop when the code is 14 or 54, next path is the hosted update link. Anyone on the team can check a rule at a glance, and you decide the stop condition calmly rather than during a billing run.

Then build the set in passes:

Find out which retries already run. Stripe, Chargebee, Recurly and most billing tools can retry failed renewals on their own schedule. A second schedule stacked on top doubles the attempts a customer sees.
Write the rules for the remaining groups, with the network limits above as the ceiling.
Test each branch with your provider’s test cards for each decline type, so every path (retry, update link, authentication, stop) runs once before real customers hit it.
Hold the set against one month of real logs. Count how many codes map cleanly to a group and read the ones that don’t: usually codes you never planned for, or gateway declines with no network code.

Review the outcomes monthly: recovered payments per group, the number of stops, and customer replies asking for a new card or a cancellation. A customer writing “my card changed” is worth more than any retry schedule. Change one thing at a time.

FAQ

What is the most common card decline code?

Generic declines. Stripe notes that issuers categorize most declines as generic, which is why code 05 (“do not honor”) and Stripe’s generic_decline show up so often. They give no reason, so treat them with a limited retry, then a card update request.

Can I retry a declined card payment?

It depends on the code. Visa forbids reattempts on Category 1 codes such as 14 (invalid account number) and 46 (closed account), and allows up to 15 reattempts in 30 days for the other categories. On Mastercard, follow the Merchant Advice Code: MAC 03 and 21 mean never retry.

What does decline code 51 mean?

Insufficient funds: the account did not have enough available balance for the charge. It is a temporary decline, so a retry a few days later, ideally around a likely payday, often works. Tell the customer the bank did not approve the payment, not that their balance was too low.

What is the difference between code 05 and code 51?

51 states a reason (insufficient funds) and points to a retry later. 05 gives no reason: the issuer refused without saying why. Treat 05 as ambiguous, retry once inside your limits, then ask the customer to update their card or contact their bank.

How NoChurn helps

NoChurn reads the decline reason behind every failed renewal and runs the follow-up. On Stripe you can keep Smart Retries or let NoChurn time retries to the decline reason and likely paydays; on other billing tools, including direct debit providers, their own retry rules stay in place. On top, it sends AI-written recovery emails matched to the plan and the payment issue, with a hosted card update page, and sorts customer replies (card changed, wants to cancel, question) so each one gets the right action. NoChurn never sees card numbers. Every feature is on every plan, priced by MRR only and free up to $300 of MRR. See failed payments.

Sources

All accessed 14 November 2026.