Card Decline Codes: The SaaS Operator's Retry and Dunning Guide

Card decline codes are numeric signals that tell you exactly why a payment failed, and whether retrying will help or hurt. Most SaaS teams treat every decline the same. The ones who route by code recover 20 to 40 percentage points more of their failed-payment revenue.

From the subscription businesses I've helped, the teams that recover the most aren't the ones running the most aggressive retry schedules. They treat the dunning email as a message to a person, not a billing receipt.

That starts with reading the code, because the code tells you which customers to chase and which to let go.

Key takeaways

• Route each failed charge by reading its specific decline code first.
• Retry code 51 on timed spacing and stop code 41 with no retries.
• Mastercard codes 24 to 30 set retry waits from 1 hour to 10 days.
• Codes 05 and 51 are 76% of declines and recover with timed retries.
• 60-70% of all declines are potentially recoverable when retries are spaced correctly.
• Stop hard declines 04, 41, and 43 before the first excess-reattempt fee.

What are card decline codes?

A card decline code is the numeric response a payment network returns when it or the issuing bank rejects a transaction, encoding the reason the payment failed. The codes come from ISO 8583, the messaging standard the networks share.

That's why a "51" means insufficient funds whether the charge ran through Visa, Mastercard, Amex, or Discover.

The code starts at the cardholder's issuing bank. It travels back through the payment network to your processor, then lands in the authorization response next to the status field. From there it either sits unread in a log, or your billing system reads it and picks the right next action.

That routing is the whole game.

A failed payment is involuntary churn waiting to happen, the kind of customer loss caused by a billing failure rather than a decision to leave.

The code tells you whether you can still save the account. Reading the code instead of the bare "declined" status is what separates the teams that recover most failed payments from the ones that lose them.

One catch sits between you and the network code. Your processor reports the code the issuer sent, but often wraps it in its own label. Stripe shows you "insufficient_funds" instead of "51." That label is usually a clean stand-in.

Still, the code you route on is the underlying network code, because it carries the category-level retry rules you need to stay compliant.

Visa's four decline code categories, and which ones you can retry

Visa sorts every decline code into four categories, and the category decides whether you're allowed to retry. Most billing systems skip this step, and it's the backbone of the Decline Code Action Matrix below.

The split comes down to what the issuing bank is telling you. A permanent decision gets a never-retry category, and a temporary one gets a retry budget. The four sections below give the codes and the action for each.

Read the category before you retry. That's the difference between saving a soft decline and paying fees to retry a card that's already dead. The hard decline vs. soft decline split underneath these categories holds the Decline Decision Tree that feeds this classification.

This matrix is the main thing to take away, so keep it next to your retry config. Here is what your billing system should route against:

Category 1: never retry

Category 1 codes are permanent rejections, so you stop and never retry.

The common ones in subscription billing are:

• 04: pick up card
• 07: pick up card, special conditions, often fraud)
• 41: lost card
• 43: stolen card
• 46: closed account

The issuer has blocked this card, so the only way back is the customer handing you a new one.

Your action is zero retries, an immediate stop, and a payment-permanently-failed flag on the subscription. Then send a manual card-update dunning email asking the customer for a new card, because the old one will never work again.

The hard stop is about money. Excess reattempts on Category 1 codes trigger per-attempt fees from Visa and Mastercard from the first retry. Each reattempt is both an excessive retry fee and a compliance violation that raises your excess-reattempt rate.

Two codes here are subscription-specific. Codes R0 and R1 are stop-payment orders from the cardholder's bank, so you don't retry, you cancel the subscription.

A customer who triggers an R0 or R1 has told their bank to stop your charges, and retrying past that earns you chargebacks instead of revenue.

Category 2: may retry within the network limit

Category 2 codes are temporary, so you retry them with timed spacing inside Visa's retry budget.

The key one is 51 (insufficient funds), the most common soft decline you'll see. After it comes:

• 61: exceeds withdrawal limit
• 65: exceeds frequency limit
• 91: issuer or switch unavailable, a network timeout rather than anything the customer did.

A soft decline is a temporary failure the network lets you retry. The budget here is Visa's limit of 15 retries in 30 days, which our dunning guide covers in full. Space your attempts inside that window, and feed in Mastercard advice codes where you have them to get the exact wait time.

Category 2 matters so much because of volume.

In ChurnWard's SaaS analysis, roughly 60 to 70% of all declines are potentially recoverable. Recovery comes down to timing.

One code here needs a lighter touch. Code 59 (suspected fraud) sits in Category 2, but you retry it once after 24 hours, and if it fails again you switch to a card-update email. Retrying a fraud code hard turns a recoverable account into a dispute.

Category 3: correct and retry

Category 3 codes mean the data was wrong, so you fix the data before you retry, never the same credentials twice. The codes that matter are:

• 54: expired card
• 14: invalid card number
• 55: incorrect PIN, which is card-present only and rare in subscription billing

Code 54 is the one you'll see most. The upstream fix is account updater, the service that refreshes a stored card before it expires, so a clean billing stack rarely lets a 54 reach a live charge. When one does fire, it routes to the dunning sequence below rather than a blind retry.

One code here changed recently and trips up older retry logic. Visa moved 14 (invalid card number) into Category 3 in April 2024, after years of treating it as a never-retry code. A retry rule written before that date may still stop on a code you can now correct and retry.

Either way, you only retry a 14 once the customer has re-entered a valid number.

Category 4: generic response codes

Category 4 holds every code that doesn't fit the first three, and it carries the same retry budget as Category 2. The one that matters is 05 (do not honor), the most common generic decline, where the issuer declined without giving a specific reason.

Code 05 is not permanent, so treat it as a soft decline and space the retries with backoff. Retry after 48 hours, then 72, then 96. Together with code 51, it makes up about 76% of all decline volume according to ChurnWard's analysis.

Routing it to your stop queue throws away your largest pool of recoverable revenue. Reading "do not honor" as "do not retry" is the common mistake, and it costs you, because the code is soft often enough that backoff spacing pays off.

Mastercard merchant advice codes: the timed-retry signals most billing systems ignore

Mastercard merchant advice codes, MACs 24 through 30, tell your billing system exactly how long to wait before the next retry, and most systems throw them away. They come back in the same authorization response as the decline code, so the wait time is already in the response you read.

The mapping is direct. MAC 24 means retry after 1 hour, MAC 25 means 24 hours, MAC 26 means 2 days, up to MAC 30, which means 10 days.

Two MACs are stop signals instead. A MAC 03 means do not try again, a permanent decline, and a MAC 21 means payment cancellation, a stop the subscriber asked for.

Retrying past either one costs $0.50 per excess attempt as of January 2025, up from $0.10 in 2022. Ignoring the signal is a growing fee, not just a missed retry.

Say your billing system gets a code 51 with MAC 26. The issuer is telling you the account should have funds in 2 days, so you retry on day 2. Without the MAC, most systems pick a random day and waste the attempt.

MACs are a Mastercard feature, and that's the boundary. Visa works at the category level instead, so for a Visa decline you lean on the category plus your own retry spacing. For a Mastercard decline carrying a MAC, you let the MAC set the timing.

How decline codes wire into your dunning sequence

Every decline code maps to exactly one of four dunning actions. The classification you just built isn't the goal. Routing each code to one of these four is:

• Timed retry for soft declines.
• Account-updater query for data-quality declines.
• Card-update email for permanent credential failures.
• Stop and churn-flag for hard declines and MAC 03 or 21.

The routing reads two things in the authorization response. It needs the code itself, plus either its Visa category or its Mastercard MAC.

A system that reads only the status and sees "declined" loses both signals. So it retries everything and burns fees on dead cards, or stops everything and throws away recoverable revenue.

Take a code 54, an expired card. Account updater should have caught it first. When it slips through, check account updater, then email for a new card. Never blind-retry, because the number is out of date.

Not every setup exposes the raw network code. Stripe normalized decline reasons ("expired_card," "insufficient_funds," "do_not_honor") map one-to-one with network codes for most declines. Route on the Stripe label when the raw code isn't exposed.

The full mapping lives in Stripe's dunning guide.

Use the churn rate calculator to size the revenue at risk before you build the routing.

FAQ

What is a 500 decline code?

A "500" is a processor gateway error, an HTTP 500 that means the gateway itself failed before the card network ever responded. Check your gateway logs for it, since the card network decline tables only cover the numeric and R-series codes.

Can my customer fix a hard decline by calling their bank?

Sometimes, depending on the code. A lost or stolen card gets reissued with a new number the customer hands you, but a fraud flag or closed account is the issuer's call to make.

How do I see which decline codes my Stripe account is receiving?

Stripe puts the code in the decline_code field on the Charge or PaymentIntent object, and in the Dashboard under each payment's detail view. Pull it from there before you build routing logic, because you can't act on a code you can't see.