How to Build a Retry Allowlist and Blocklist From Declines (July 2026)

I'll be frank: most retry logic is built on assumptions, not data. A retry allowlist tells your system when to try again; a payment retry blocklist tells it when to stop. The decline categorization between those two lists is where most of the recovery upside gets left on the table. Your last 90 days of declines are the right place to build that from scratch.

TLDR:

• Build your retry allowlist from soft declines and your blocklist from hard declines, using your own 90-day transaction data, not industry generalizations.
• Retrying a hard decline wastes processing fees, triggers negative issuer signals, and can accelerate processor account suspension.
• Timing your retries to decline reason recovers more revenue: code 51 retries align with pay cycles, code 05 warrants a 5-7 day wait.
• After 4 declines in 30 days, internal data suggests recovery probability drops below 5%; route those accounts to dunning instead.
• Slicker ingests your full decline history and applies AI scoring to keep allowlist and blocklist classifications current, without manual review.

What a Retry Allowlist and Blocklist Are

A retry allowlist is the set of decline codes where an automatic retry makes sense, because the underlying issue is temporary and the card is likely to approve on a second or third attempt. A retry blocklist is the opposite: decline codes where retrying is pointless or actively harmful, because the issuer has signaled a hard stop.

Getting this categorization right matters. Retrying a hard decline wastes processing fees, triggers additional negative signals with the issuer, and can accelerate account suspension with your payment processor.

Why Your Last 90 Days of Declines Are the Right Starting Point

Ninety days gives you enough volume to spot statistically meaningful patterns without reaching so far back that issuer behavior, network rules, or your own subscriber mix has shifted enough to distort the signal. Decline codes change meaning over time: a spike in do_not_honor last quarter may reflect a fraud wave that has since passed, while a steady trickle of insufficient_funds codes tells you something durable about your subscriber base. Your most recent 90-day window captures both seasonal effects and current issuer posture, making it the right raw material for building a retry allowlist and payment retry blocklist that reflect how your declines actually behave right now.

How to Pull and Structure Your Decline Data

Start by exporting your last 90 days of decline data from your payment processor or billing system. Most processors let you pull a CSV with the transaction date, decline code, card type, amount, and whether a retry succeeded.

Once you have the raw data, group declines into three buckets:

• Soft declines (insufficient funds, do-not-honor) are often retriable given the right timing and conditions.
• Hard declines (stolen card, invalid account) signal that retrying will fail again and may trigger additional risk flags from the issuer.
• Ambiguous declines (generic processor errors, network timeouts) require closer inspection before you decide whether to retry.

This categorization is the foundation of any retry allowlist or payment retry blocklist you build.

The Decline Code Taxonomy: Soft, Hard, and Ambiguous

Before building any retry allowlist or blocklist, you need a working taxonomy for your decline codes.

Declines generally fall into three buckets:

• Soft declines signal a temporary condition, like insufficient funds or an issuer timeout, where retrying after a waiting period has a real chance of succeeding.
• Hard declines signal a permanent block, like a stolen card or closed account, where retrying wastes attempts and can trigger issuer penalties.
• Ambiguous declines sit in the middle. Codes like "Do Not Honor" (code 05) can behave like either depending on the issuer, card type, and customer profile.

Your retry allowlist should pull from soft declines. Your payment retry blocklist should wall off hard declines entirely. Getting the ambiguous bucket right is where most of the recovery upside actually lives.

Building Your Retry Blocklist First

Start with hard stops. Before you build any retry allowlist, you need to know which decline codes should never trigger a retry attempt.

Your blocklist covers two categories (for a broader overview of how retry logic works, see Checkout.com's payment retry guide):

• Hard declines where the issuer has permanently rejected the transaction (stolen card, account closed, do-not-honor with no retry flag): retrying burns goodwill with the network and risks card account flagging.
• Soft declines that carry issuer-side signals indicating a retry window hasn't opened yet, such as codes tied to fraud review holds or velocity limits.

Pull your last 90 days of decline data and calculate retry success rates by code. Any code with a near-zero recovery rate across multiple attempts belongs on your blocklist.

Building Your Retry Allowlist

Your allowlist is the set of decline scenarios where a retry genuinely has a good chance of succeeding. Building it from your own 90-day decline history means you're working from real patterns, not assumptions.

Start by pulling every decline from the past 90 days and grouping them by decline code. Look for codes where a meaningful share of first retries succeeded within 24 to 48 hours. Those are your allowlist candidates: soft declines like insufficient funds (code 51) or do not honor (code 05) where the underlying issue is typically temporary.

Your allowlist should cover:

• Soft declines with a documented retry success rate from your own transaction history, not industry generalizations
• Codes where retry success clusters around predictable windows, such as post-payday dates or early morning processing hours
• Issuers where your historical data shows consistent retry lift across similar card types or geographies

Once you've identified these codes, set conservative retry windows anchored to when your data shows success peaks. A narrower, evidence-backed allowlist recovers more revenue per retry attempt and keeps your decline rate from climbing due to aggressive retrying on lost causes.

Card Network Rules That Set Hard Limits on Your Allowlist

Before your retry allowlist can go live, card network rules set the ceiling on what's permitted.

Visa and Mastercard both cap retry attempts on declined transactions, and exceeding those limits triggers fines that can reach thousands of dollars per violation. Soft declines generally allow up to 15 retries within 30 days. Hard declines, like stolen cards or closed accounts, prohibit retries entirely under network rules.

Your blocklist, in practice, is partly defined for you. Any decline code that falls into a hard-decline category belongs on it by default, regardless of what your 90-day data suggests.

Timing and Scheduling Logic for Allowlisted Codes

Once you've sorted declines into retry-eligible and blocked categories, the next question is when to retry. Not all allowlisted codes behave the same way, and retrying too soon wastes authorization attempts while retrying too late loses the customer.

Matching Retry Windows to Decline Reasons

The timing logic should reflect why the card was declined in the first place.

• Insufficient funds (code 51) responds best to retries aligned with pay cycles: 1-3 days after the initial decline for weekly earners, 7-10 days for monthly salaried customers.
• Temporary holds or processing errors (codes 57, 96) can be retried within 24-48 hours, since the issue is typically resolved at the issuer level quickly.
• Do-not-honor responses (code 05) warrant a longer wait of 5-7 days before any retry attempt, as immediate retries rarely succeed and can flag the merchant. Spacing retries with this logic keeps your authorization rate healthy and avoids burning goodwill with card networks. The payoff is measurable: better retry sequencing directly protects your recovery rate on the codes your allowlist has cleared for reattempt.

Spacing retries with this logic keeps your authorization rate healthy and avoids burning goodwill with card networks. The payoff is measurable: better retry sequencing directly protects your recovery rate on the codes your allowlist has cleared for reattempt.

The Handoff Point: When to Stop Retrying and Escalate

Retries have a natural ceiling. Once a card has been declined four or more times over 30 days, internal data suggests recovery probability drops below 5%. Continuing past that point wastes retry attempts, risks issuer flags for excessive retries, and frustrates customers who may not even know their payment is failing.

Your payment retry blocklist should capture these cases automatically. Cards coded as stolen, fraudulent, or do-not-honor with a hard decline signal belong on the blocklist immediately. Soft declines with no recovery after a defined attempt window follow shortly after.

The escalation trigger is straightforward: when retry probability falls below your threshold, route the account into a dunning sequence instead. At that point, customer action (updating a card, confirming account details) is the only viable path to recovery. Baremetrics' dunning management guide breaks down how subscription businesses structure that escalation across billing cycles.

Maintaining and Iterating Your Lists Over Time

A 90-day snapshot is a starting point. Issuer behavior changes, card network rules update quarterly, and your subscriber mix evolves as you grow, so both lists need active maintenance.

Review decline categorization every 60 to 90 days. The clearest signal that a code needs reclassification is recovery rate movement: a code you've added to your retry allowlist at 30% recovery dropping to 5% over two consecutive billing cycles belongs on the payment retry blocklist. When a processor change alters how a code is reported, treat it as a fresh classification decision. Test on a controlled subset of that code's volume before updating your full list, so you're validating the new categorization against real outcomes before it applies at scale.

How Slicker Automates Allowlist and Blocklist Logic Across Your Transaction Mix

Slicker ingests your full decline history and applies rule-based logic alongside AI scoring to sort every transaction into the right category automatically. Hard declines like stolen cards and fraud flags go straight to the blocklist. Soft declines tied to timing or transient issuer issues get queued for smart retries with optimized windows based on your subscriber mix, card types, and geographic payday patterns.

Your allowlist and blocklist stay current. As new decline data arrives, classifications update without manual review, so a card that was temporarily blocked after a soft-decline cluster gets reassessed as conditions change. The result is a retry strategy built on your actual transaction history, not industry averages.

Final Thoughts on Getting Retry Allowlists and Blocklists Right

The goal is simple: retry the cards that can recover and stop wasting attempts on the ones that cannot. Your own transaction history, reviewed every 60 to 90 days, is what keeps that line in the right place. Get in touch with the Slicker team to learn how automated classification handles this without manual upkeep.

FAQ

What's the difference between a retry allowlist and a payment retry blocklist?

A retry allowlist contains the decline codes where a retry has a documented chance of succeeding, typically soft declines like insufficient funds (code 51) or temporary issuer holds. A payment retry blocklist walls off codes where retrying is pointless or harmful, such as stolen cards, closed accounts, or any code where your own 90-day data shows near-zero recovery across multiple attempts. The two lists work together: the allowlist tells your system when to act, the blocklist tells it when to stop entirely and route into dunning instead.

Should I build my retry blocklist from industry averages or my own decline data?

Build it from your own data. Industry averages mask issuer-specific behavior, card-type variation, and the particular subscriber mix your business has accumulated. Pull your last 90 days of declines, calculate retry success rates by code, and put any code with near-zero recovery across multiple attempts directly on your blocklist. The 90-day window captures current issuer posture without reaching so far back that fraud waves or network rule changes from prior quarters distort your categorization decisions.

How do I know when to stop retrying and escalate to a dunning sequence?

Once a card has been declined four or more times over 30 days, internal data suggests recovery probability drops below 5%. At that point, continued retries waste authorization attempts and risk issuer flags for excessive volume. The escalation trigger is when retry probability falls below your recovery threshold: route the account into a dunning sequence where customer action, such as updating a card or confirming account details, becomes the only viable path back to good standing.

How often should I review and update my decline categorization lists?

Review your decline categorization every 60 to 90 days. The clearest signal that a code needs reclassification is a meaningful shift in recovery rate: a code sitting on your retry allowlist at 30% recovery that drops to 5% over two consecutive billing cycles belongs on the payment retry blocklist. When a processor change alters how a code is reported, treat it as a fresh classification decision and test on a controlled subset of that code's volume before applying the new categorization at scale.

Can AI automate retry allowlist and blocklist management across a large transaction mix?

Yes. Slicker ingests your full decline history and applies rule-based logic alongside AI scoring to sort every transaction into the right category automatically, with no manual review required as new decline data arrives. Hard declines go straight to the blocklist; soft declines tied to timing or transient issuer issues get queued for smart retries with windows calibrated to your subscriber mix, card types, and geographic payday patterns. The lists stay current because classifications update continuously, so a card temporarily blocked after a soft-decline cluster gets reassessed as conditions change, instead of sitting on the wrong list indefinitely.