Soft vs hard declines: which decline codes to retry

Every declined card payment comes back with a response code. Most teams read the code only to decide what to show the customer. The more valuable question is what the code says about the next attempt: will the same card, sent again, ever be approved? Answer that correctly and you recover payments without paying network fees for attempts that could never work. Answer it wrongly and you either give up on payments you could have saved, or you retry cards that are lost, stolen or closed, which costs money and looks like card testing.

This article is a reference for that decision. It explains the difference between soft and hard declines, shows how Visa and Mastercard classify their codes, lists the codes worth retrying and the ones you must never retry, and works through what a retry policy costs. For how to design the cascade itself, see our article on cascading and decline recovery.

What is the difference between a soft and a hard decline?

A soft decline describes a condition that can change: the account is short of funds today, the issuer’s system is unavailable, the issuer wants the cardholder to authenticate, or the issuer’s risk score was borderline. Another attempt, later, on another route or with more data, may be approved.

A hard decline describes the card or account itself: lost, stolen, closed, invalid or not allowed to make this kind of transaction. The issuer will give the same answer whoever sends the payment and whenever it arrives, because the problem is not the route or the timing.

The distinction is made through the response code in the authorization message. Stripe’s list of network decline codes shows how much detail is available: Visa alone has codes for refer to issuer (01), do not honor (05), invalid account number (14), lost card (41), stolen card (43), not sufficient funds (51), expired card (54), suspected fraud (59), exceeds amount limit (61), issuer or switch inoperative (91), system malfunction (96) and additional customer authentication required (1A), among many others.

How do Visa and Mastercard classify decline codes?

Both networks have turned the soft and hard distinction into rules, with fees attached.

Visa sorts its response codes into four categories. Primer’s documentation and PayPal’s May 2026 guidance describe them the same way:

Visa category	Meaning	Examples	Reattempts
1	Issuer will never approve	04, 07, 12, 14, 15, 41, 43, 46, 57, R0, R1, R3	Not allowed
2	Issuer cannot approve at this time	51, 59, 61, 62, 65, 75, 91, 93	Allowed, within a cap
3	Issuer cannot approve with these details	54, 55, 70, 82, 1A, N7	Allowed after updating data
4	Generic response	All other codes, including 05	Allowed, within a cap

The sources differ on the cap for Categories 2 to 4: PayPal gives 20 reattempts in 30 days, Primer gives 15. They also place a few codes differently (Primer lists 96 in Category 4, PayPal in Category 2). Confirm the current figures with your acquirer, and build your policy so the cap is a setting rather than a constant.

Mastercard works differently. PayPal’s guidance says that under Mastercard’s transaction processing rules, codes 04, 14, 15, 41, 43 and 54 on card-not-present payments must not be retried with the same card number and expiry date at any time. For other declines, Mastercard adds a Merchant Advice Code (MAC) that tells the merchant what to do next:

MAC	Meaning	What to do
01	Updated information needed	Get new card details before retrying
02	Cannot approve now, try again later	Retry later (PayPal suggests after 72 hours)
03	Do not try again	Stop; ask for another payment method
04	Token requirements not met for this token type	Fix the token data
21	Payment cancellation, stop recurring requests	Stop; do not resubmit
24 to 30	Insufficient funds, retry after a set time	Retry after 1 hour, 24 hours, or 2, 4, 6, 8 or 10 days

The advice code matters more than the response code it travels with. Stripe’s table shows Mastercard returning the same response code, for example 05 do not honor, with MAC 01, 03 or 21, and each of those calls for a different action.

Which decline codes are worth retrying?

Codes that describe a temporary state, a technical failure or missing authentication. A practical reference, using Visa codes and the meanings in Stripe’s list:

Code	Meaning	Visa category	Retry?	How
05	Do not honor	4	Once	Different route or with 3-D Secure
51	Not sufficient funds	2	Later	Wait; follow MAC 24 to 30 on Mastercard
61	Exceeds approval amount limit	2	Later or smaller	Lower amount or another method
65	Exceeds withdrawal frequency limit	2	Later	Wait for the issuer’s limit to reset
91	Issuer or switch inoperative	2	Yes	Retry shortly or fail over
96	System malfunction	2 or 4	Yes	Retry or fail over
1A	Additional customer authentication required	3	Yes	Retry with 3-D Secure
54	Expired card	3	Only with new data	Ask for updated card details
N7	CVV2 failure	3	Only with new data	Ask the customer to re-enter

Three of these deserve a closer look.

Code 1A is the clearest soft decline in Europe. Adyen’s help centre describes its Authentication required response as the issuer mandating strong customer authentication, and treats it as a soft decline. The fix is to run 3-D Secure, not to send the same unauthenticated request to another acquirer. Note that Mastercard can also use code 65 for an Identity Check soft decline, according to Stripe’s list.

Code 51 looks retryable, and it is, but not immediately and not on another route. The account is the problem, and every acquirer checks the same account. Mastercard’s advice codes 24 to 30 exist precisely to tell merchants when to try again.

Code 05 is the hardest call. It is generic by design, and some issuers use it even when the real reason is permanent. One retry on a different route, or with authentication, is reasonable. A loop is not. Our do not honor entry covers it in more detail.

Which decline codes must you never retry?

Codes that describe the card itself, and codes that tell you to stop:

• Lost, stolen or pick-up: 04, 07, 41, 43. Stripe advises presenting lost and stolen card declines to the customer as a generic decline, without revealing the reason. Treat them as a fraud signal for the account.
• Invalid or closed: 14 invalid account number, 15 no such issuer, 46 closed account.
• Not permitted: 57 transaction not permitted to cardholder, and 12 invalid transaction.
• Stop orders: R0 stop this payment, R1 stop all future payments, R3 stop all merchants. Primer notes that Visa adds a Stop Payment Service fee of EUR 1 per retry after these codes, on top of the excess retry fee.
• Mastercard MAC 03 and 21, whatever response code they come with.

Two codes sit in Visa’s retryable categories but should not be cascaded in practice. Code 59, suspected fraud, is Category 2, yet sending it to a second acquirer to find one that approves is what card testing looks like. Code 93, violation of law, is also Category 2, and retrying it on another route invites exactly the problem the issuer is flagging. Keep both out of automatic retries.

What do excessive retries cost?

PayPal’s May 2026 summary gives these figures, which change from time to time:

• Visa: any retry on a Category 1 code, and any retry beyond the cap on Categories 2 to 4, costs USD 0.10 for a domestic transaction or USD 0.25 for a cross-border one.
• Mastercard, soft declines: fees apply after 10 retries in 24 hours or 35 in 30 days for the same account, card acceptor and amount. The fee per excess retry varies by region, for example EUR 0.55 in Europe, USD 0.40 in the Middle East and Africa, USD 0.50 in Latin America outside Brazil, and BRL 2.00 in Brazil.
• Mastercard, advice codes: a fee applies when a payment declined with MAC 03 or 21 is reattempted within 30 days and declined again with 03 or 21.

The bigger cost is usually indirect. Your own provider may charge per authorization attempt, and a pattern of repeated attempts on dead cards makes your traffic look riskier to issuers.

Worked example: classifying a month of declines

Example figures, for illustration only.

A merchant receives 4,000 card declines in a month, with these codes:

Group	Codes	Declines	Policy
Technical	91, 96	400	Retry or fail over once
Authentication	1A	300	Retry with 3-D Secure
Generic	05	1,300	One retry on another route
Funds and limits	51, 61, 65	1,000	Retry later or offer another method
Data	54, N7	200	Ask the customer for new details
Never retry	04, 14, 41, 43, 46, 57, R0 to R3	600	Stop; block if fraud related
Fraud and law	59, 93	200	Stop; review

A blind policy that retries every decline once sends 4,000 extra authorizations. Of those, 800 (the never-retry and fraud groups) can only fail. If the 600 Category 1 declines are all on Visa cards and half of them are cross-border, the Category 1 retries alone cost about 300 × USD 0.25 plus 300 × USD 0.10, or USD 105 a month in Visa fees, before any provider fees, and they add 800 attempts that look like card testing.

A code-aware policy sends at most 2,000 immediate retries (technical, authentication and generic), schedules 1,000 later retries for funds and limits, and sends nothing for the 800 dead or suspicious cards. Whatever it recovers, it recovers without paying for attempts that could never succeed. Our approval rate calculator shows what each recovered percentage point is worth on your own volumes.

How do you put a decline-code policy into practice?

1. Keep the raw network code. Providers translate codes into their own vocabulary. Store the original network code and, for Mastercard, the advice code alongside the provider’s label.
2. Map every provider’s codes to one set of actions: retry now, retry with authentication, retry later, update data, stop. Review the mapping against outcomes every quarter.
3. Count attempts per card across all providers. The networks do.
4. Make the caps settings. Network limits and fees change; your rules should not need a release to follow them.
5. Separate retries from cascades. Cascading suits technical errors and generic soft declines; scheduled retries suit funds and limits.
6. Measure recovery by code. A code that recovers almost nothing on retry should leave the retry list. Our guide on how to calculate approval rate explains why recovery should be measured on payment intents, not raw attempts.

How does Omno handle declines?

In Omno, cascading is part of the routing rule: if a provider is unavailable or rejects the request, the payment moves to the next provider in the rule until one accepts it. The routing-decision log keeps the response code for every attempt, so recovery can be measured per code, provider and country. The smart routing and cascading page explains the rules.