TL;DR

Card networks cap how often you can resubmit a declined card transaction. Visa's Reattempt Limit allows 15 attempts on the same card, the same merchant, and the same currency within a rolling 30-day window, with a $0.10 Misuse of Authorization fee on every attempt past 15. Mastercard's Excessive Authorization Attempts program flags merchants over 10 declined auths per card in 24 hours. Hard-decline codes like 14 (invalid card) cannot be retried at all. The fix is branching on the decline code, not the calendar.

What this actually is

Authorization retry is the practice of resubmitting a declined card transaction to the issuer in hope of a different answer. It runs constantly in the background of every subscription business: a card fails on bill day, the dunning system tries again 24 hours later, sometimes the second attempt clears. For a SaaS company with 10,000 active subscriptions, retries can move revenue recovery by 3 to 6 percentage points.

The networks limit the practice because every authorization request burns issuer compute, fraud-screening cycles, and BIN-level capacity. According to the Federal Reserve Payments Study, card-not-present authorization volume more than tripled between 2015 and 2022. A meaningful slice of that growth comes from mechanical retries by subscription billers and SaaS platforms, not from new commerce.

Visa published its Reattempt Limit rule in October 2019 and has tightened the wording several times since. The cap: 15 authorization attempts on the same card, the same merchant, and the same currency within a rolling 30-day window. Attempts beyond 15 carry a $0.10 Misuse of Authorization fee. Chronic offenders move into Visa's Integrity Risk Program with steeper monthly fines and a flagged MID record.

Mastercard's Excessive Authorization Attempts (EAA) program triggers when a merchant submits more than 10 declined authorizations on the same card within 24 hours, or more than 20 within 30 days. Merchants over threshold are placed in monitoring. After three consecutive months in the program, per-attempt fees apply and the acquirer can be required to suspend the MID.

Operator noteThe fees themselves are small. The hidden cost is reputational. A MID flagged in network analytics gets lower issuer approval rates across the board, sometimes 2 to 4 percentage points below comparable MIDs. That gap compounds.

Authorization retry logic is the rules engine that decides when, how often, and under what conditions to resubmit a declined card transaction without breaching network reattempt caps.

How it works under the hood

A declined transaction triggers a chain of decisions:

  1. Your gateway submits an authorization request to the acquirer.
  2. The acquirer routes it through the relevant network rails.
  3. The network routes the message to the issuer.
  4. The issuer returns a response code: approval, soft decline, or hard decline.
  5. Your billing system reads the code and either stops, retries immediately, or queues the transaction for a later attempt.

The response code controls retry legality. Codes split into two groups.

Hard declines tell you the card is unusable or the issuer has flagged the transaction permanently. Common hard codes include 04 (pick up card), 14 (invalid card number), 41 (lost card), 43 (stolen card), 54 (expired card), 57 (transaction not permitted), and R0, R1, R3 (revocation of authorization). The issuer has already given a final answer. A retry produces another decline and counts against your network thresholds.

Soft declines tell you the issuer is willing to consider another attempt under different conditions. Common soft codes include 05 (do not honor), 51 (insufficient funds), 61 (exceeds withdrawal amount), 65 (exceeds withdrawal frequency), 91 (issuer or switch inoperative), and 96 (system malfunction). These are eligible for retry within the network caps.

The networks track retries on a four-key composite: card number or token, merchant ID, transaction amount within a small tolerance, and timestamp. A second attempt matching the first three keys counts as a reattempt against your cap. Changing the amount by a penny does not reset the counter; the networks normalize amounts within standard tolerances that are not publicly documented but appear to extend to roughly 5 percent of the original.

For subscription billing, Visa and Mastercard require Merchant Initiated Transaction (MIT) framework compliance. Each retry must include a reason code indicator (Visa uses MIT-04 for resubmission of a declined auth; Mastercard uses MTF reason code 3705) and a Stored Credential Transaction Identifier tying the retry back to the original consent authorization. Without those fields, the retry runs as a fresh customer-initiated transaction, which raises the fraud-screening burden and disqualifies the merchant from certain recurring interchange categories.

One in five subscription declines is a hard decline. Retrying any of them is pure waste, and the network fees show up as line items most ops teams cannot decode.

Timing matters, but not the way most operators think. The network counters do not penalize retries that happen quickly. They count attempts within the 30-day rolling window. A retry 5 seconds after a 51 decline is wasteful but legal, just one of your 15 allowed attempts. A retry 30 minutes after a 91 (issuer unavailable) is actually smart, because the issuer may be back online with a different system state. The clock matters for resource use; the counter matters for compliance.

Account Updater services run on a parallel track. Visa Account Updater (VAU) and Mastercard Automatic Billing Updater (ABU) push card-on-file updates to enrolled merchants before the next bill cycle. A card reissued for fraud or expiration gets refreshed automatically, no retry required. According to industry data published in the Nilson Report, account updater enrollment alone reduces recurring billing failures by 25 to 40 percent for subscription merchants. The two systems work in concert: updaters cut the failure pool, retry logic handles what remains.

Where it goes wrong for operators

Five patterns burn merchant money.

1. Retry-everything cadence. A platform sees "declined" and retries every 12 hours for a week. That hits 14 attempts before any branching logic kicks in. One more attempt and the merchant is paying $0.10 per try to Visa. On a subscription business with 2,000 monthly failures, this is $400 to $700 in penalty fees, charged as vague line items like "MoA Fee" or "Auth Program Fee" that operations teams routinely miss in monthly statement reviews.

2. Retrying hard declines. Decline code 14 means the card number does not exist in the issuer's system. The issuer is not going to change its mind. Yet many dunning systems treat every decline as transient and retry on the same schedule. Every one of those retries is a fee waiting to land. A company with 500 monthly hard declines on a 14-attempt cadence is paying about $700 a month for retries that have a zero percent recovery rate.

3. Smart-retry vendors with opaque cadences. Vendors in this space charge 1.5 to 2 percent of recovered revenue. The pitch is appealing because the merchant pays only on success. The hidden cost: the vendor's retry cadence is calibrated for recovery, not for compliance. A vendor that retries 18 to 22 times per failed card collects fees on the recoveries while the merchant pays the network on the breaches.

Watch outIf your smart-retry vendor will not show you the average attempts per failed card and the count of attempts on hard-decline codes, assume you are paying network penalty fees on top of the vendor commission. Ask for both numbers in writing.

4. Subscription billing without MIT indicators. Billing 25,000 subscribers monthly without proper MIT framework markup means many of those retries get tagged as higher fraud risk. Mastercard's EAA program triggers earlier. Issuer approval rates drop across the MID once it earns a "high decline volume" reputation in network analytics. The fix is configuration, not strategy.

5. No coordination between checkout and dunning. A customer updates her card on the checkout page while the dunning system is still retrying the old card on its scheduled cadence. The new card pays. The dunning system keeps hitting the old card. That is three to five extra wasted attempts per self-service fix. Multiply by the number of customers who self-serve in a typical month, and the wasted attempts eat a meaningful chunk of the 15-attempt window.

A 14-attempt retry cadence recovers about 38 percent of soft declines. Most of that recovery lands by attempt 4. The other 10 attempts cost more in network fees than they collect.

Worked example with real numbers

Merchant profile: BetterDraft, a B2B SaaS company selling design software subscriptions. Monthly card volume: $1.2M. Average ticket: $39 monthly, $399 annual. Current rate: IC++ at 0.20 percent plus $0.10 per transaction. Failed-payment rate: 5.5 percent of attempts.

BetterDraft runs about 30,000 authorization attempts per month between initial bills and retries. At 5.5 percent failures, that produces 1,650 declined authorizations.

Breakdown of the 1,650 declines:

  • 600 hard declines (codes 04, 14, 54): cards invalid, expired, or revoked
  • 700 soft declines from insufficient funds or do-not-honor (codes 51, 05)
  • 350 soft declines from temporary issuer issues (codes 91, 96)

Old retry policy: every failure retries every 24 hours for 10 days, then weekly for 30 more days. Total attempts per failure: 14.

Cost of the policy:

  • 600 hard declines x 14 retry attempts x $0.10 Misuse of Authorization fee = $840 per month. Every one is wasted because hard declines do not recover.
  • About 400 of the soft-decline failures hit the 15-attempt cap because of overlapping retry windows from the dunning cadence. 400 x 5 excess attempts x $0.10 = $200 per month.
  • Total network penalty fees: $1,040 per month, or $12,480 per year.
Real-world exampleBetterDraft was paying $12,480 per year in network reattempt penalty fees that did not appear on any approval-rate dashboard. The fees showed up as "MoA Fees" and "Auth Integrity Charges" on the merchant statement, totaled together at $1,040 per month. A 30-minute statement audit was enough to find them.
BetterDraft monthly retry economics, before and after the policy change.
BetterDraft monthly retry economics, before and after the policy change.

New policy:

  • Hard decline: stop. Email customer. Suppress retries until the card is updated.
  • Soft decline: 24h, 72h, 7d, 14d retry cadence. Maximum 4 retries per failure.
  • Enrolled in Visa Account Updater and Mastercard Automatic Billing Updater.

Result: total retry attempts per failure drops from 14 to 4. Network penalty fees fall to under $100 per month. Recovery rate on soft declines holds steady because the bulk of successful recoveries land in the first three attempts. Approval rate on resubmissions improves about 1.2 percentage points because the MID is no longer flagged in network analytics.

The recovery math also shifts. With a 14-attempt cadence, BetterDraft was recovering 38 percent of soft declines, but most successful retries landed in attempts 1 through 4. The trailing attempts 5 through 14 were recovering less than 0.5 percent each while adding fees. After tightening to a 4-attempt cadence with proper MIT markup, the recovery rate on soft declines stayed at 37 percent. The 1 percentage point of recovery lost on long-tail attempts was more than offset by the 1.2 percentage point lift in approval rate from no longer being treated as a high-decline-volume MID.

Annual savings: roughly $11,000 in eliminated penalty fees, plus another $40,000 to $60,000 in recovered revenue from VAU and ABU enrollment alone.

Operator playbook

  1. Pull the last three processing statements. Search for line items containing "Misuse of Authorization," "MoA Fee," "Integrity Program Fee," "EAA Fee," "Excessive Authorization," or "Reattempt Fee." Total them across the three months. If the total clears $200 per month, you have a retry policy problem, not a vendor problem.
  2. Build a decline-code reference table for your billing system. Mark these as hard, do-not-retry: 04, 14, 41, 43, 54, 57, R0, R1, R3. Mark these as soft, retry-eligible: 05, 51, 61, 65, 91, 96. Anything else, route to a manual queue for a week until you confirm with your acquirer how the issuer interprets it. Hard-coded tables work better than vendor-supplied logic.
  3. Set a hard ceiling of 12 retry attempts per 30-day rolling window per card. The Visa limit is 15. The 3-attempt buffer protects you from race conditions between dunning and self-service checkout flows. Set a separate daily ceiling of 2 attempts to avoid Mastercard EAA triggers.
  4. Confirm your gateway sends Merchant Initiated Transaction reason codes and Stored Credential Transaction Identifiers on every retry. Ask your gateway rep for a sample API request showing the MIT fields populated. If they cannot produce one within 48 hours, your platform is non-compliant and you are paying for it in higher decline rates and missed recurring interchange categories.
  5. Enroll in Visa Account Updater (VAU) and Mastercard Automatic Billing Updater (ABU). About 30 to 40 percent of recurring billing failures stem from card reissuance after fraud events or expiration. The updaters fix these without a single retry. Confirm with your acquirer that updates are applied before each retry cycle, not just at bill creation.
  6. Audit any smart-retry vendor on three numbers: average attempts per failed card, percentage of attempts on hard-decline codes, and total network penalty fees produced per month. If the vendor cannot give you those numbers in writing within a week, switch vendors. The good ones publish dashboards that show this by default.
  7. Set up a monthly decline-code distribution review. If code 51 (insufficient funds) is climbing month over month, customers are running tight. Change the billing-day cadence to align with payday timing in your customer's geography instead of retrying harder. Soft-decline rate is a customer-experience metric, not just a recovery metric.
  8. Document the retry policy in a file in your billing repo. Cite the network rules. Date the file. Review it every quarter when network rule updates publish.