Decline Codes Explained: Hard vs Soft Declines and Which Ones to Retry

How an authorization works, and where declines come from

When a card is charged, the request travels from your software to a gateway, from the gateway to the acquiring processor, across the card network to the bank that issued the card, and back. The issuer's answer is a two-character response code. Code 00 means approved. Everything else is a decline, and the code tells you why, at least roughly.

It helps to know that a decline can come from four different places:

1. The issuer. The customer's bank makes the final decision and produces most declines: no funds, card closed, risk model said no.
2. The network. Occasionally Visa or Mastercard answers on the issuer's behalf when the issuer is unreachable ("stand-in processing"), or blocks a transaction that breaks a rule.
3. The processor or gateway. Fraud filters you or your provider configured: address (AVS) or security code (CVV) mismatches, velocity limits, duplicate-transaction checks, blocked countries. These often surface as a decline even though the issuer approved the authorization, in which case an authorization hold may sit on the customer's card until it expires.
4. Your own rules. Card type restrictions, minimum amounts, or a subscription system refusing a card that failed last time.

The distinction matters because retrying only helps when the thing that caused the decline can change. An issuer that says "insufficient funds" may say yes on Friday. A gateway rule that says "ZIP code mismatch" will say the same thing forever unless the data changes.

Hard declines, soft declines, and the third category

Every decline code falls into one of three groups, and the group is the only thing that should drive what you do next.

• Hard declines mean the card cannot be used, now or later: it is closed, lost, stolen, expired, invalid, or the issuer has blocked this kind of transaction on it. Retrying a hard decline never works, annoys the customer with repeated holds, and is now penalized by the networks. The only fix is a different card.
• Soft declines mean the issuer could not approve this attempt but might approve another one: not enough money right now, a daily limit reached, a temporary outage, or a request for stronger authentication. These are the declines worth a careful, limited retry.
• Data and fraud declines are a mix. A wrong card number or bad format is a data problem: fix the data and resubmit once. A suspected-fraud or security-violation response is a signal to stop and review, not to retry.

Visa formalizes this in its reattempt rules with four categories: Category 1 (the issuer will never approve; do not reattempt), Category 2 (the issuer cannot approve at this time; limited reattempts allowed), Category 3 (data quality; fix and resubmit) and Category 4 (generic responses such as "do not honor"). Mastercard publishes similar guidance through its merchant advice codes, covered below.

The decline code table

These are the ISO 8583 response codes issuers return in the US. Your gateway may show its own label or number next to the issuer code; when in doubt, look for the two-character code in the transaction detail.

Codes are the issuer responses defined in ISO 8583 as used by Visa and Mastercard in the US. Discover and American Express use comparable codes with their own numbering.

Gateway-level declines

The other family of declines you will see comes from fraud filters rather than the issuer. AVS results (a mismatch on street number or ZIP code), CVV results, velocity rules and country blocks are decided by the gateway or by settings you control. These are never soft declines: retrying with the same data produces the same answer. Either correct the data, relax the rule if it is wrong for your business, or ask the customer for a different card.

The network retry rules that now cost money

Retrying declines used to be free, so subscription systems retried everything, daily, for weeks. Issuers objected to the load, and both major networks now enforce limits and charge for excess attempts.

• Visa prohibits any reattempt of a Category 1 (hard) decline. For other categories it allows up to 15 reattempts in 30 days on the same card for the same transaction, and assesses a per-attempt fee on anything beyond that, and on any reattempt of a Category 1 decline. Your processor passes those fees through, usually as a line with "excessive reattempts" or "Visa reattempt" in the name.
• Mastercard returns a merchant advice code alongside many declines that tells you exactly what to do, and charges for attempts that ignore it. The common ones: 01 (updated or additional information needed: get new card details), 02 (cannot approve at this time: try later), 03 (do not try again: the account is closed or blocked), and 21 (the cardholder has cancelled this recurring payment: stop billing). Mastercard also limits repeated attempts on the same card within a 24-hour window and over 30 days, and charges for attempts past those limits.

A retry schedule that works

Retries recover money when the issuer's answer can change and when the retry lands at a moment it is likely to have changed. A schedule by decline type:

A few things that make the schedule work better:

• Vary the time of day. Issuer risk models look at patterns; three identical attempts at 3:00 a.m. look like a script.
• Flag retries correctly. A retry of a stored-card charge is a merchant-initiated transaction and should carry the stored-credential indicators. Unflagged retries are declined more often and can be downgraded. See CIT vs MIT.
• Do not retry by switching gateways. The issuer makes the decision, and it sees the same card and the same merchant either way. The exceptions are 91 and 96 when the outage is at your processor rather than the issuer.
• Tell the customer. A "your payment did not go through, update your card here" message with a link recovers more than any retry. Combine the two: retry on the schedule and message after the first failure.
• Count attempts per card, not per invoice. The network limits apply to the card. A customer with three overdue invoices on one card should not get twelve attempts.

Reducing declines before they happen

The cheapest decline is the one that never occurs. Most of the levers are about giving the issuer more confidence in the transaction.

• Let customers initiate the payment. A card the customer enters on a hosted page, with address and security code, is a customer-initiated transaction. Issuers approve these at a noticeably higher rate than the same card keyed by staff over the phone. This is the core argument for text to pay and emailed payment links, and it is explained in CIT vs MIT.
• Collect AVS and CVV every time on card-not-present transactions. They lower both the decline rate and the interchange rate.
• Use 3-D Secure on higher-risk transactions. It answers the 1A decline before it happens and shifts fraud liability to the issuer. Reserve it for large or unusual transactions; forcing it on everything adds friction.
• Keep stored cards current. A card account updater service replaces expired and reissued card numbers in your vault before the next charge, removing most 54 declines and many 14s. Provider-agnostic tokenization keeps that vault independent of any one processor.
• Flag recurring and card-on-file charges properly. The initial transaction and every follow-on need the right stored-credential indicators, or issuers treat each charge as a new, unverified one.
• Use a recognizable descriptor. Customers who do not recognize a charge call their bank, and banks that get calls tighten the rules on that merchant.
• Do not train issuers to decline you. Excessive retries and high chargeback rates both feed the issuer's model of your business. A disciplined retry policy improves approval rates on first attempts, not just recoveries.

Measuring it: the number that matters is not the one most dashboards show

Most gateways report an approval rate as approvals divided by attempts. Retries distort that badly in both directions: an aggressive retry policy lowers it, and a policy of giving up after one attempt flatters it. Track these instead:

• First-attempt approval rate: approved first attempts divided by unique transactions. This is the health of your setup.
• True authorization rate: transactions that eventually approved divided by unique transactions. This is the money.
• Soft-decline recovery rate: soft declines that later approved divided by soft declines. This is how well your retry schedule works.
• Attempts per unique transaction: if it creeps above 1.3 or so, look for a retry loop.

Rough benchmarks: card-present businesses see decline rates of 1 to 3 percent. Card-not-present is typically 5 to 15 percent, and recurring billing on stored cards higher still, because cards expire and balances run out between charges. Breaking the numbers down by decline code, by card brand and by gateway usually shows one or two causes behind most of the total.

Where FloPay fits

Gateways report declines in their own vocabulary, and a business running more than one of them ends up with several incompatible lists. FloPay's decline recovery normalizes the response from every connected gateway into hard, soft or fraud, retries soft declines on a schedule that respects the network limits, and reports true authorization rates across providers rather than per-attempt approval rates. Payment reminders handle the customer side: a text or email with a link to update the card and pay, sent after the first failed attempt rather than after the fourth.