The Decline Recovery Ladder: How to Route Soft vs. Hard Declines Without Triggering Network Retry Penalties

For over a decade, default subscription and e-commerce billing engines relied on a blunt instrument: when a card failed, the system retried the exact same card on Day 1, Day 3, Day 5, and Day 7. In 2026, that fixed-calendar retry pattern is one of the fastest ways to erode gross margin and destroy your Merchant ID's (MID) standing with issuing banks.

Why? Because Visa and Mastercard strictly enforce excessive retry rules that assess immediate per-attempt fees on irreversible declines—and issuing banks penalize merchants whose Transaction Authorization Rate (TAR) is diluted by blind reattempts. Here is how experienced operators replace flat retry schedules with a structured Decline Recovery Ladder.

What Is the Difference Between Soft Declines and Hard Declines Under Visa and Mastercard Rules?

Every card authorization failure falls into one of two operational buckets: reversible (soft) declines, where the card account is valid and a properly timed or re-routed attempt can succeed, and irreversible (hard) declines, where the issuer has permanently blocked the credential or recurring authority.

Provider-reported recovery ranges vary materially by merchant mix and measurement window. Solidgate reports that targeted recovery can recover 40%–70% of soft failures; this is its own published observation, not a guaranteed industry or Rebar result. Hard declines and revoked recurring authority must never be included in an automatic retry cohort.

As documented in Mastercard Gateway advice guidance and Current Mastercard rules, Visa and Mastercard enforce two distinct compliance frameworks:

1. Visa's Four Decline Categories (Excessive Reattempts Rule)

Visa classifies every issuer decline response into four categories:

• Category 1 — hard stop: Do not resubmit an authorization classified as non-retryable by the current Visa rules and your acquirer. Lost/stolen or invalid credentials and revoked authority require the permitted customer remediation, not another MID. Exact code classification and applicable fees must come from the current network/acquirer mapping, not a hardcoded historical list.
• Category 2 — issuer cannot approve at this time: A retry may be possible only when current network/acquirer advice permits. Enforce the applicable rolling attempt limit across processors; a generic code or a different MID does not create permission to retry.
• Category 3 — data correction: Resolve the actual issuer/gateway data error using the current acquirer mapping before considering another attempt. No universal response-code list is assumed across gateways.
• Category 4 — generic responses: A generic response such as 05 is not a retry instruction. Check current advice, identity of the obligation and applicable attempt limits; stop when eligibility is unknown.

2. Mastercard's Transaction Processing Excellence (TPE) & Merchant Advice Codes (MACs)

Where Visa groups response codes into four categories, Mastercard attaches a 2-digit Merchant Advice Code (MAC) directly to the authorization response message:

• MAC 01 (New account information available): Do not blind-retry; fetch updated credentials via Mastercard Automatic Billing Updater (ABU) or prompt the buyer.
• MAC 02 — try later advice: Verify the current mapping and applicable timing/attempt limits with the acquirer; do not infer a universal monthly cap from this article.
• MAC 03 / MAC 21 — stop advice: Honor do-not-retry and cancelled-recurring instructions. Confirm the gateway’s current mapping with the acquirer and Mastercard’s rules. Do not route the same obligation through another MID, wallet or token to evade the stop. Exact program fees and fines vary; no universal dollar penalty is asserted here.
• Time-specific merchant advice: Some processors expose MAC 24–30 as timed retry advice. Read the actual advice returned by your supported API and its current network mapping; the gateway message and acquirer rules, not the following illustrative intervals, govern production scheduling.
• Illustrative scheduling interval 1: 1 hour. Use this only when the actual returned network advice permits that interval; do not infer it from a code number alone.
• Illustrative scheduling interval 2: 24 hours. Use this only when the actual returned network advice permits that interval; do not infer it from a code number alone.
• Illustrative scheduling interval 3: 2 days. Use this only when the actual returned network advice permits that interval; do not infer it from a code number alone.
• Illustrative scheduling interval 4: 4 days. Use this only when the actual returned network advice permits that interval; do not infer it from a code number alone.
• Illustrative scheduling interval 5: 6 days. Use this only when the actual returned network advice permits that interval; do not infer it from a code number alone.
• Illustrative scheduling interval 6: 8 days. Use this only when the actual returned network advice permits that interval; do not infer it from a code number alone.
• Illustrative scheduling interval 7: 10 days. Use this only when the actual returned network advice permits that interval; do not infer it from a code number alone.

How Does the 4-Rung "Decline Recovery Ladder" Work?

Instead of treating every failed charge identically, operators should implement a four-rung Decline Recovery Ladder that routes each failure based on its network response code, MAC value, and transaction context (checkout vs. recurring renewal).

Explicit If / Then Decision Rules for Engineering & Payments Teams

To make this framework directly executable in your billing or orchestration logic, enforce these five deterministic rules:

1. IF issuer, network or acquirer advice prohibits retry, or recurring authority has been revoked, THEN set retry_eligible = false across every MID, token and wallet for that obligation. Cancel queued retries and request the permitted customer remediation.
2. IF response_code == '54' (Expired Card) OR mastercard_mac == '01', THEN block same-day retry, execute a synchronous check against your Network Token / Account Updater feed, and only retry if a new expiration date or PAN token is returned.
3. IF response_code == '51' (Insufficient Funds) AND mastercard_mac BETWEEN '24' AND '30', THEN override your default calendar dunning schedule and set next_retry_at to be greater than or equal to the exact hour/day threshold prescribed by the MAC value.
4. IF insufficient funds has no prescribed wait window and a retry is otherwise permitted, THEN test timing against your own customer cohorts and consent. Payroll dates such as the 1st, 15th or Friday are hypotheses, not reliable knowledge of a cardholder’s balance or a network mandate.
5. IF a generic decline occurs on a cross-border or high-value transaction, THEN inspect current network and issuer advice before any retry. Only an expressly permitted attempt may use a properly underwritten local acquirer; complete required 3DS authentication and never reclassify the merchant or bypass a fraud/stop instruction.

How Much Revenue and Fee Leakage Does Intelligent Retry Logic Recover?

When you combine network-code-aware stopping rules with payday-aligned soft-decline timing, the financial impact hits both the top and bottom lines:

• Provider-reported cohort metrics: Solidgate reports +11.6% LTV impact, 42.1% fewer wrongly timed retries in its own analysis. These context-specific vendor figures do not establish an independently verified causal effect or predict Rebar client results.
• Fewer attempts per recovery: Track attempts per recovered obligation and network integrity fees in your own ledger. The supplied 6.1-to-4.4 comparison and universal fee/monitoring thresholds were not corroborated against current primary network sources and are not used as a forecast or a compliance rule.

When you negotiate payment processing rates like an operator or conduct a full processing fee and statement audit, always inspect your processor statement for network integrity and excessive retry line items (such as "VS RAF Excessive Reattempts" or "MC TPE Fee"). Reducing blind retries can reduce avoidable fees; assess actual fee schedules and approval outcomes rather than assuming zero penalties or a portfolio-wide uplift.

Related Rebar payments guidance

Use this playbook alongside how to evaluate payment processor. Explore Rebar Payments advisory for a review of provider options and commercial trade-offs.

Common questions

How many times can you legally retry a declined credit card under Visa and Mastercard rules?

Honor the current issuer/network/acquirer advice and any stop or revoked-consent instruction across all MIDs and credentials. Exact retry windows, mappings and fees depend on the program; do not use a generic code as permission to retry.

What is a Mastercard Merchant Advice Code (MAC)?

Honor the current issuer/network/acquirer advice and any stop or revoked-consent instruction across all MIDs and credentials. Exact retry windows, mappings and fees depend on the program; do not use a generic code as permission to retry.

Why does retrying a hard decline lower my overall payment approval rate?

Issuing banks continuously monitor each Merchant ID's (MID) Transaction Authorization Rate (TAR) and retry velocity. Repeatedly submitting authorization requests for closed, stolen, or revoked cards lowers your overall approval ratio, causing issuer risk models to flag your MID and reject more legitimate customer transactions.

Should a '05 Do Not Honor' decline be treated as a soft decline or a hard decline?

Honor the current issuer/network/acquirer advice and any stop or revoked-consent instruction across all MIDs and credentials. Exact retry windows, mappings and fees depend on the program; do not use a generic code as permission to retry.