Transforming Declines into Revenue

When a payment gets declined, it may seem like that’s the end of it. It seems as dead as a doorknob, to use an old-timey term. But the good news is that a lot of those payment declines are just stuck in a limbo state that can be remedied with several different strategies. 

Not all payment declines are dead. Most are just stuck. A transaction that fails on one gateway often succeeds on another, or at a different moment in time. That's your recovery lever. This guide explains what separates fixable declines from permanent ones, why the business case for recovery shifted in 2026, and how to build retry logic that actually moves revenue.

What is Transaction Retry?

Transaction retry is the act of sending a failed payment to a different gateway or trying again under different conditions in order to complete the transaction i.e. so that you get paid and the customer gets their product. 

Instead of treating a decline as final, you route the transaction to a secondary gateway, which scores it differently. You might also wait for fraud systems to re-evaluate, or you might just move the transaction forward when the issuer's systems are back online. There are a lot of different methods by which you can get this done, so what you’ll end up doing is creating workflows that map exactly how to address a declined payment based on certain criteria. 

You configure rules that decide when a transaction is worth retrying. The rules are based on the reason for the decline (fraud hold vs issuer timeout), the payment method (debit cards need faster retry windows than credit cards), or the geography (some issuers are slower in certain regions). When a transaction hits one of those conditions, the system doesn't stop trying to get the payment to go through. It tries again, either on your backup gateway or with updated information.

But you need to be attentive to what’s actually happening, as well. A card that's expired, reported lost, or blocked by the issuer won't succeed on any gateway, so retrying it only costs money and damages your relationship with payment networks. But a card that soft-declined because the issuer's fraud team was reviewing the transaction, or the cardholder hit their daily limit, or your primary gateway's fraud rules were too strict? That card often clears on a second try. So let’s break down the difference between a hard decline and a soft decline. 

What are hard declines?

A hard decline means the card itself has been rejected at the issuer level. The issuer has made a final decision, and retrying won't change it.

Hard declines fall into a few categories:

• Expired card. The issuer won't process transactions on expired cards anymore.
• Lost or stolen. The issuer has blocked the card because it was reported lost or stolen.
• Cardholder block. The cardholder asked the issuer to block the card (maybe they disputed a previous charge, or maybe they've frozen spending on that account).
• Security trigger. The card triggered the issuer's internal security rules for reasons you'll never see (unusual activity pattern, high-risk merchant category, geographic mismatch with the cardholder's profile).

In each of these scenarios, the issuer's decision is final. The card won't clear on your backup gateway because the problem isn't your gateway's fraud scoring. When the issuer’s own systems have rejected the card at the source, retrying just sends the same request to the same issuer, hoping for a different answer. Hint: You’re not going to get a different answer. 

Retrying hard declines costs real money. Every time you attempt to retry that transaction, your issuer charges a transaction fee. 

An even bigger issue you should be aware of is that card networks track retry patterns. If they notice that you’re repeatedly retrying cards that they’ve already blocked,  your merchant account could be flagged as either incompetent (not understanding the difference between hard and soft declines) or malicious (ignoring decline signals and hammering the system). 

Either way, your standing with payment networks isn’t moving in a positive direction, and that leads to higher processing fees, stricter fraud rules, and eventually higher rates or account restrictions. Another hint: You don’t want that. 

So the answer to this one is very much not rocket surgery. Just identify hard declines by their decline codes (the issuer returns codes like "Card Expired," "Do Not Honor," "Call Issuer," or "Invalid Card"), and don't retry them, full stop. 

Route those transactions to a different recovery path: ask the customer for a new payment method, or process the transaction offline if the business model allows it. Just don't retry. The card has already said no.

What are soft declines? 

A soft decline means the card is live, but there is something that is causing the transaction to be blocked temporarily. It’s not that the issuer has declined the card outright, but rather there’s another issue happening behind the scenes. If you can find a way to remove the temporary obstacle, you’ll get a cleared transaction.

That's why soft declines are worth retrying. Around 30 to 50% of them will succeed on a retry, depending on the decline reason and which gateway you retry on. The obstacle might clear (issuer systems recovered, spending limit reset, fraud team approved), or a different gateway's fraud scoring might not flag the transaction. It might even just be an issue of timing.

Why soft declines happen:

• Fraud scoring. The issuer's fraud system flagged the transaction as unusual. Maybe the amount is bigger than the cardholder's typical purchase, or the merchant category doesn't match the cardholder's history, or the transaction is coming from a different geography. The same card clears five minutes later when the fraud team re-evaluates, or on a different merchant where the risk profile looks normal.
• Spending limits. The cardholder or the issuer set a daily or monthly limit, and this transaction hit it. The limit resets at midnight, or the issuer manually lifts the hold once they verify the cardholder is legitimate. The next attempt goes through.
• Issuer infrastructure. The issuer's systems were slow or temporarily unreachable. Your authorization request timed out. By the time you retry, the issuer's systems are back online and the account is accessible again.
• Gateway differences. Different gateways use different fraud scoring models, routing paths, and relationships with issuers. A card that soft-declines on your primary gateway often clears on your secondary gateway because the risk profile looks completely different. The issuer's fraud team sees a different transaction path and makes a different decision.

Soft declines recover on retry because you're giving a live card a second chance, not forcing a dead one through the system. But there’s another reason you might get a soft decline that deserves a look on its own. 

What is a gateway outage? 

Gateways go offline. Network hiccups, scheduled infrastructure maintenance, or temporary service degradation can make your primary gateway unreachable. As an example, if Cloudflare is down, there will be a bunch of gateways that are unreachable as a result. 

When that happens, every transaction hitting that gateway fails until it recovers. If recovery takes 90 seconds and you're processing 1,000 transactions per minute, that's 1,500 failed transactions. Just to reiterate the same math in a different way, that's 1,500 lost sales in a minute and a half. In technical terms, that’s referred to as a whole bouquet of oopsie-daisies.

The way you prevent that is with automatic failover workflows. When your primary gateway is unreachable, failover routes transactions to a backup gateway automatically, in milliseconds. If your backup processes 50% of your traffic while your primary recovers, you've stopped the revenue leak. The customer's payment goes through on the backup, and your transaction volume doesn’t take a hit. 

This is a kind of “rainy day” strategy, if you will. Like having an umbrella and not needing it. You can set up "Outage-Only" mode, where your backup gateway sits dormant and only activates when your primary becomes unreachable. You’ll manage to keep complexity low and costs down while still having that protection you need against the outages that do happen on those rare rainy days.

Retry in Action: Every Transaction Counts

Smart retry requires three things: decline code matching, gateway selection, and timing strategy.

Decline code matching. Every declined transaction returns a code from the gateway or card network. Some codes indicate soft declines; others indicate hard declines. "Do Not Honor" is retryable. "Card Expired" is not. "Call Issuer" is not. Payment networks have standardized these codes, and your gateway should return them consistently. Map each code to a retry decision: yes, no, or maybe after a delay.

Gateway selection. When you retry, route the transaction to a different gateway. If your primary gateway soft-declined it, the secondary gateway's different risk scoring and issuer relationships often produce a different result. This only works if you have multiple gateways configured and can switch between them programmatically.

Timing. Some retries should happen immediately. A gateway outage failover needs to execute in milliseconds. A fraud-triggered soft decline might benefit from a 10–30 second delay, giving the issuer's fraud team time to re-evaluate. Set your retry window based on the decline reason, not just the transaction amount.

For card-on-file merchants, soft declines sometimes involve mismatched tokens. When a card is reissued after fraud or expiration, your token to the old card becomes invalid. Network tokenization keeps your tokens in sync automatically. When the network reissues a card, your token updates without action from you. 

If you're not using network tokens yet, soft decline retry becomes a useful patch. A retry often succeeds because the issuer's systems have a chance to reconcile the mismatch or the card data has been updated in the meantime.

Soft decline recovery is a really big deal for debit payments. A failed credit card authorization is a missed sale where the customer's available credit stays unaffected. A failed debit authorization hits the customer's bank account and can cause all kinds of issues. 

For subscription merchants, utilities, and marketplaces with instant payout, a failed debit token means a customer's rent payment bounces, a subscription renewal never processes, or a vendor waits for funds that never arrive. Debit-heavy verticals need smarter retry logic: shorter retry windows, different gateway selection rules, and monitoring for account status changes.

By the Numbers: Retry Sales Lift

Soft decline recovery used to be an optimization. A nice uplift to your authorization rate, measurable but not worth a major engineering effort.

When Visa introduced the Digital Commerce Service Fee bundling CNP transactions with token authentication and account updater charges and Mastercard restructured its Digital Enablement Fee into a tiered model on transactions between $100 and $2,000, these changes added an estimated $3 billion in annual merchant costs across the industry.

For a merchant processing $100M annually, that's $25K to $50K in new network fees before a single decline happens. Your baseline cost per transaction just went up. Soft decline recovery went from nice-to-have to essential.

A recovered soft decline generates full transaction value minus the cost of the retry attempt. A failed soft decline that stays failed generates zero. When your baseline fees are higher, recovery is paying for itself.

For a typical $100M GTV merchant (like a vacation booking platform):

• Baseline authorization rate: 95%
• Soft decline volume: 3 to 5% of total attempts
• Expected recovery via retry: 30 to 50% of soft declines
• Recovered transaction value: $900K to $1.5M annually
• Retry infrastructure cost: typically 10 to 20 basis points on recovered volume, or $90K to $300K annually

Based on analysis of customer data, merchants implementing a secondary gateway for soft decline recovery see approximately $1.05 in recovered value per $100 GTV. For a merchant at this scale, a 1.24% sales lift translates to roughly $1M additional annual revenue.

The recovery outpaces the cost. Soft decline recovery now justifies the infrastructure spend.

Conclusion

Transaction Retry is a simple and intuitive concept that merchants can’t afford to ignore. Soft decline and outage recovery offers a sizable opportunity for merchants and merchant aggregators seeking to bolster their sales and improve customer retention. By understanding the dynamics of transaction declines and employing a thoughtfully crafted retry strategy, merchants can convert missed opportunities into tangible gains - transforming payments into a key strategic asset. Furthermore, merchant aggregators can highlight soft decline and outage recovery as a value proposition to differentiate their platform. 

Spreedly’s Transaction Retry, with drag-and-drop gateway configuration and soft error code and outage listening, is one of the easiest ways to implement a multi-gateway retry workflow. 

Reach out to your Account Manager to get started with Transaction Retry.

‍

Download the Payments Orchestration eBook Below