Retry Velocity Limits: Issuer Caps Explained September 2026

When a retry velocity limit gets tripped, the damage shows up in two places: the per-attempt fees on transactions that were never going to convert, and the slower approval rate that follows on charges across your entire subscriber base. Most billing teams catch the first one eventually. The second one shows up as an unexplained drop in first-attempt success and stays invisible until someone does the math. Both trace back to the same source: a retry schedule that treats every decline the same way, regardless of what the network or issuer was trying to communicate.

TLDR:

• Retry velocity limits cap how many times you can charge the same card; Visa allows up to 15 retry attempts per 30-day window, Mastercard caps at 10 attempts within 32 days.
• Exceeding those caps costs real money: Mastercard's per-declined-authorization fee rose to $0.50 in January 2025, with program-level fines reaching $100,000 per month.
• Fixed retry schedules breach velocity caps by design, burning your attempt budget on premature retries before subscriber payday windows even open.
• Read all three decline layers before retrying: the gateway code, the network code, and the MAC; identical gateway output can require opposite responses depending on the MAC.
• Slicker's retry engine reads all three layers and weighs over 40 variables per transaction to keep attempts inside network limits while targeting windows where authorization is most likely to succeed.

What Retry Velocity Limits Actually Are

A retry velocity limit is a cap on how many times a merchant can attempt to charge the same card within a set time window. Card networks set these limits at the network level, and issuers layer additional restrictions on top. Together, they define the outer boundary of how aggressively your billing system can chase a failed payment.

These limits exist because card networks treat repeated authorization attempts as a signal of poor billing hygiene. A subscription business that hammers a declined card ten times in a week generates noise on the network, frustrates cardholders, and strains issuer processing resources. Networks responded by formalizing rules that cap retries and attach fees when merchants exceed them.

Recurring billing is where these rules bite hardest. A subscription payment fails silently, and automated billing systems retry, often without reading the decline code explaining why the payment failed; whether it represents a soft vs hard decline matters enormously for recovery. That retry-on-autopilot pattern is precisely what velocity rules target.

The Two Layers of Velocity Enforcement: Networks and Issuers

Velocity enforcement has two distinct layers, and passing the first does not guarantee you clear the second.

The Visa and Mastercard payment retry rules allow up to 20 retry attempts per card within a 30-day window for Visa and 10 attempts within 24 hours on soft declines for Mastercard. These are the published, uniform rules that apply to every merchant on the network, regardless of industry or volume.

Issuers set their own thresholds on top of those rules. A regional bank may flag your merchant ID (MID) after five attempts on the same card in a week, even if you're technically inside Visa's 15-attempt window. The issuer sees the pattern, decides your billing behavior looks aggressive, and starts declining your authorization requests at a higher rate, including payments unrelated to the original failure. There is no published threshold for this. It varies by bank, card portfolio, and how your MID's overall authorization history looks to that issuer.

The practical consequence: you can stay inside network limits and still accumulate silent issuer friction that lowers your approval rate across your entire subscriber base, including accounts you're retrying infrequently.

Visa's Retry Categories and Attempt Limits

Visa organizes every decline into one of four categories. Category 1 covers hard stops: stolen cards, closed accounts, and cardholder-issued stop-payment orders (codes like 04, 41, 43, R0, R1, and R3). These carry zero retry eligibility. Retrying a Category 1 decline triggers Visa's Excessive Reattempts Program fees, starting at $0.10 per attempt.

Categories 2 through 4 are retryable. Visa allows up to 15 retry attempts on soft declines in these categories, where the distinction matters:

• Category 2 covers do-not-honor and generic declines that may resolve without cardholder action.
• Categories 3 and 4 capture issuer-specific conditions like insufficient funds or processing errors, where retry timing matters more than frequency.

A Category 1 code means stop and route to dunning. A Category 2 through 4 code means retry within the 15-attempt cap, with timing logic that gives each attempt the best authorization odds.

Mastercard's Retry Rules and the MAC-Based Timing System

Mastercard combines a volume cap with explicit timing instructions, making its system more prescriptive than Visa's category-based approach. The volume limit is 10 retry attempts within 32 days on soft declines.

The more important layer is the Merchant Advice Code (MAC) returned alongside a decline. Where Visa tells you which category a failure falls into, Mastercard often tells you exactly how long to wait before retrying:

Two codes terminate retry eligibility entirely. MAC 03 (Do Not Try Again) is a hard stop; retrying after receiving it triggers a $0.10 penalty per attempt under Mastercard's Excessive Attempts program. MAC 21 (Stop Recurring Payment) signals a cardholder-initiated cancellation of recurring billing, not a temporary decline. Retrying after MAC 21 risks both the per-attempt fee and a chargeback.

If your billing system doesn't parse MACs, a recoverable soft decline becomes a fee-generating loop with real margin consequences.

What Exceeding Velocity Limits Actually Costs

The fees arrive in two stages, and most billing teams only notice the first one.

At the transaction level, Mastercard's Transaction Processing Excellence (TPE) fee applies once you exceed 10 declined attempts within 24 hours on the same card. That fee rose to $0.50 per declined authorization. Retrying after MAC 03 costs $0.10 per attempt regardless of where you are in the attempt count. At volume, both fees compound fast.

Program-level fines sit on top. A complete subscription payment retry strategy must account for these costs: Visa can levy $5,000 to $75,000 per month for Excessive Reattempts violations. Mastercard fines up to $100,000 monthly under its Excessive Authorization Attempts program, scaling with violation volume.

The less visible cost is MID (merchant ID) reputation damage. Issuers track your authorization behavior at the merchant level, and repeated retry violations lower your approval rate on clean, first-attempt charges. Customers trying to pay successfully get declined because your MID looks unreliable to their bank: lost revenue that never appears in your retry reporting.

How Issuers Add Their Own Velocity Rules on Top of Network Rules

Network-level caps are a floor, not a ceiling. Banks run their own fraud and risk scoring on top of those rules, and repeated authorization attempts from the same merchant on the same card trigger those systems independently.

The pattern issuers flag most aggressively is same card, same merchant, same amount in rapid succession. Many issuers will silently suppress further authorizations after three to five attempts in a short window, even when the network threshold is nowhere close. The decline code that surfaces is typically "do not honor" (code 05) or "velocity exceeded." The distinction matters:

• A "do not honor" on a first attempt may be a temporary issuer risk block that resolves with a longer rest period before retrying.
• The same code on a fifth retry signals an issuer-level velocity flag, where continuing to retry burns attempts, generates fees, and deepens the flag.

These issuer-applied rules are unpublished and vary by bank, card product, and regional risk policy. The signal is behavioral: if the same card keeps returning generic declines after a pause, the card is likely issuer-flagged, not declined for a genuinely recoverable reason.

Why Fixed Retry Schedules Systematically Breach Velocity Caps

Fixed retry schedules don't read decline codes. They fire on a calendar, which means a stolen card gets the same retry treatment as an insufficient-funds decline. The schedule doesn't know the difference, and it doesn't stop until the window closes.

This mechanical approach fails in three distinct ways.

• A hard decline (Category 1 on Visa, MAC 03 on Mastercard) triggers the first retry anyway, because the schedule only knows that time has passed. Each attempt generates a fee. A billing system retrying a Category 1 decline five times in a week isn't recovering revenue; it's buying $2.50 in Mastercard penalties per card while lowering the MID's (Merchant ID) authorization score.
• When Mastercard returns MAC 27 (retry after 4 days), a fixed daily schedule retries the next morning. That attempt counts against the 10-attempt window, not toward recovery. By day 10, when the optimal retry window opens, the attempt budget may already be exhausted on premature tries.
• Most fixed schedules cluster attempts in the first week after a decline, burning through the cap before account balances have had a chance to refresh. Code 51 insufficient funds declines are especially vulnerable to this pattern: by the time a US-based subscriber receives payroll two weeks out, no attempts remain.

The result is lower recovery rates, higher fees, and earlier window exhaustion, produced by a schedule that treats every failed payment identically.

How to Read a Decline Code Before Retrying

Three data points arrive with every decline response. Most billing systems act on only the first one.

The gateway error code is what your processor reports: "insufficient_funds," "do_not_honor," "declined." It tells you something failed, not whether retrying will help.

The network code sits underneath. Where a gateway might return a generic "20005," the network error codes tell you the issuer sent "do not honor" and not a processor-side rejection. Same surface message, different origin, different retry logic.

The Merchant Advice Code (MAC) is the third layer, and on Mastercard transactions it often carries the clearest instruction of the three:

Identical gateway output. Opposite correct response. A billing system reading only the gateway code retries both identically, generating a $0.10 per-attempt fee on every subsequent attempt in the MAC 03 case. Reading all three layers before scheduling a retry keeps attempts inside issuer velocity caps and prevents fees on declines that have already signaled they won't resolve through automated retries.

Designing a Compliant Retry Schedule Within the Limits

Staying compliant means spacing attempts across the full 30-day window instead of exhausting the cap in the first week.

A framework that works across network rules and issuer thresholds:

• Attempt 1: within 24 hours of the initial decline, using the gateway and network code to confirm retryability before scheduling anything further
• Attempts 2-4: aligned to the subscriber's likely payday window instead of fixed intervals
• Attempts 5-15: reserved for later in the window when Merchant Advice Code (MAC) timing signals suggest funds may have refreshed, following the principles in a soft decline retry playbook

Geography changes the payday logic materially:

• United States (biweekly): retry 2-3 days after the 1st and 15th of each month, when payroll deposits clear
• Western Europe and UK (monthly): concentrate attempts within 48 hours of the last working day of the month, then hold until the same window next cycle
• Australia (weekly or fortnightly): a 3-5 day retry interval catches most payroll cadences without burning the attempt budget early

When Mastercard returns a MAC timing code, that window anchors your next attempt. If MAC 27 says retry after 4 days, hold until day 4, not the next morning. Preserving attempts for the windows MAC codes identify leaves budget available when funds are most likely present, which is where recovered revenue actually comes from.

When to Stop Retrying and What to Do Instead

Three signals tell you to stop retrying entirely.

MAC 03 (Do Not Try Again) is the clearest: further attempts generate a $0.10 fee per try with no recovery upside. MAC 21 (Stop Recurring Payment) means the cardholder has cancelled recurring billing through their bank, so retrying risks both the per-attempt fee and a chargeback. Visa Category 1 declines (codes 04, 41, 43, R0, R1, R3) carry the same logic, as the card is flagged, closed, or cardholder-blocked.

Softer stop signals are harder to read but just as important:

• The same generic decline code returning across three or more attempts with no change, suggesting an issuer-level velocity flag and not a temporary condition
• A decline code shifting from "insufficient funds" to "velocity exceeded" mid-sequence, indicating the attempt count itself is now the problem
• A "Try Again Later" code (MAC 02) returning on successive retries, signaling a loop that automated retries won't resolve. MAC 02 carries no specific retry window, so repeated returns indicate the condition is not clearing

When retries stop, a failure reason dunning cadence becomes the recovery path. A stolen card routes to a fraud-alert email prompting the subscriber to contact their bank. An expired card gets a card-update request. A MAC 21 instruction requires ceasing all automated outreach on that account entirely. The decline code that ended retries should also determine whether dunning starts at all.

How Velocity Compliance Interacts With MID Reputation

Issuers track your MID's Transaction Authorization Rate (TAR). When your billing system repeatedly retries unrecoverable declines, those failed attempts register as low-quality authorization traffic. The issuer then applies more friction to future requests from that same MID, depressing approvals portfolio-wide, beyond the accounts you've been retrying.

The feedback loop compounds quietly: penalty-generating retries lower TAR, which causes issuers to soft-block more authorizations, which raises your apparent failure rate, which can trigger further scrutiny under Visa response code retry rules. By the time the pattern surfaces in reporting, the MID reputation damage is already embedded in your baseline approval rate.

For a CFO, the math is direct: a one-point drop in authorization rate on a $100M annual billing base is $1M in lost revenue, and none of it shows up as a retry fee. It appears as an unexplained decline in first-attempt success.

How Slicker Manages Velocity Limits Across Your Subscriber Base

Slicker's retry engine reads all three layers before scheduling any attempt: the gateway code, the network code, and the MAC (Merchant Advice Code). An ensemble of AI models weighing over 40 variables per transaction determines whether to retry, when, and on which payment method, keeping attempts inside network limits while targeting the windows where authorization is most likely to succeed.

Hard stops are enforced automatically. When MAC 03 or MAC 21 appear, the engine stops retrying and routes to dunning, preventing the $0.10-per-attempt Mastercard penalty from compounding across a subscriber base. MAC timing codes (24 through 30) anchor the next attempt to the issuer-prescribed window, but they're one input among many: payday calendars, issuer behavior patterns, and card type all factor into where within that window an attempt is scheduled.

The system also tracks MAC response patterns across attempts. When the same code returns repeatedly, Slicker identifies the loop, breaks the cycle, and escalates to dunning instead of continuing to burn attempts and accumulate fees.

Smart retry systems consistently recover 70 to 85% of recoverable soft declines; fixed retry schedules that ignore velocity signals land between 40 to 60%. The gap comes from preserving attempt budget for windows that actually convert, instead of exhausting it early on premature retries that issuers are already primed to decline.

Final Thoughts on Retry Velocity Limits and Billing Compliance

The gap between a compliant retry strategy and a fee-generating one comes down to what your billing system reads before scheduling the next attempt. Fixed schedules treat every decline the same; the network and issuer rules do not. Preserving your attempt budget for the windows where funds are most likely present is where your recovery rate actually lives. Connect with the Slicker team to walk through how this works against your current decline mix.

FAQs

How does Slicker's AI-powered retry logic differ from a fixed retry schedule when managing issuer velocity rules?

A fixed retry schedule fires on a calendar without reading decline codes, which means it treats a stolen card (Visa Category 1, zero retry eligibility) identically to an insufficient-funds decline, burning attempt budget and generating Mastercard's $0.10-per-attempt fee on unrecoverable cards. Slicker's AI models read the gateway code, network code, and Merchant Advice Code (MAC) before scheduling anything, then weigh over 40 variables per transaction, including issuer behavior patterns, card type, and payday calendars, to place each attempt in the window where authorization probability is highest. The result is fewer wasted attempts against issuer velocity caps, lower fee exposure, and attempt budget preserved for the windows that actually convert.

How do I prove that a payment recovery vendor is genuinely improving my recovery rate and not merely recovering payments that would have resolved anyway?

The only reliable method is a controlled experiment that separates vendor-driven recoveries from self-resolved payments: a split-traffic test where a control group runs your existing logic and a treatment group runs the vendor, with success measured in dollars recovered and statistical significance confirmed via p-values. Slicker uses AABB testing, a methodology borrowed from clinical trial crossover design, to run exactly this test on your own transaction data before any commercial commitment. If Slicker does not outperform your control group with statistical significance, you do not pay.

What does exceeding Visa or Mastercard retry velocity limits actually cost a subscription business?

Program-level fines layer on top of those per-attempt costs (see the fee breakdown above). The less visible cost is merchant ID (MID) reputation damage, where repeated retry violations lower your approval rate on clean, first-attempt charges from customers with valid cards, a revenue loss that never appears in retry reporting.

Can I build a compliant retry schedule without an AI system, just by reading decline codes manually?

Yes, reading all three layers (gateway code, network code, and MAC) and mapping them to Visa's four retry categories and Mastercard's timing codes will keep you inside published network rules. The gap is that issuer-level velocity thresholds are unpublished and vary by bank, card portfolio, and your MID's authorization history, so a rules-based schedule that passes network limits can still accumulate silent issuer friction that depresses approval rates across your subscriber base. A schedule that spaces attempts across the full 30-day window, anchors timing to payday cycles by geography, and stops immediately on MAC 03, MAC 21, or Visa Category 1 codes will outperform a calendar-based approach, but it still applies fixed logic to groups instead of making per-transaction decisions that learn from outcomes.

How does Slicker handle the Mastercard MAC 03 and MAC 21 hard-stop codes to prevent fee accumulation at scale?

When MAC 03 (Do Not Try Again) or MAC 21 (Stop Recurring Payment) appear, Slicker's retry engine stops immediately and routes the account to dunning instead of continuing automated attempts. MAC 03 triggers the $0.10-per-attempt Mastercard penalty on every subsequent retry, so at a subscriber base of even 50,000 accounts, a system that ignores this code converts a recoverable soft-decline pool into a compounding fee liability. MAC 21 carries additional chargeback risk because it signals a cardholder-initiated cancellation of recurring billing, not a temporary decline. Slicker also tracks MAC response patterns across attempts: when the same code returns repeatedly (for example, MAC 02 returning on successive retries), the engine identifies the loop, breaks the cycle, and escalates to dunning instead of burning remaining attempt budget.