Soft decline retries
Soft decline retries specifically target temporary payment failures that can be resolved by reattempting the transaction. This Cardflo feature intelligently identifies soft declines and automatically resubmits them according to tailored schedules.
It significantly boosts approval rates by addressing transient issues without customer intervention, thereby reducing involuntary churn.
- Category
- Recovery
- Capabilities
- 10
- Available on
- All plans
The overview
Soft decline retries operate within the payment orchestration layer to rescue transactions that failed due to temporary issues rather than permanent account closures or insufficient funds.
Unlike a hard decline, which indicates a final rejection from the issuer, a soft decline signifies that the authorisation failed because of a transient error such as a processor timeout, system maintenance at the acquirer, or a temporary card limit restriction.
Within the payments stack, this function sits between the gateway response and the final settlement status. By analysing the raw response codes provided by the schemes and issuers, the system identifies whether a retry is permissible under scheme rules.
This mechanism is particularly critical for Merchant Initiated Transactions where the customer is not present to provide an alternative payment method.
Automating this process ensures that the capture is attempted again at an optimal time, which minimises manual intervention and helps maintain continuous service for subscription-based business models.
How it works
Identification of Response Codes
The system parses the decline codes returned by the issuer via the acquirer.
It distinguishes between hard declines, such as stolen cards or closed accounts, and soft declines like technical errors or suspected fraudulent activity that may be cleared upon a subsequent attempt with updated parameters or different timing.
Application of Scheme Rules
Before scheduling a retry, the logic verifies compliance with Visa and Mastercard scheme rules regarding retry frequency and volume.
This prevents excessive attempts that could lead to fines or the flagging of the Merchant Identification Number by the card schemes, ensuring all recovery efforts remain within authorised bounds.
Algorithmic Scheduling and Intervals
The transaction is queued for resubmission based on the specific refusal reason.
For example, a system timeout might trigger an immediate retry within seconds, whereas a soft decline related to daily spend limits might be scheduled for the following morning to align with the reset of the account balance.
Secondary Authorisation Execution
The system automatically resubmits the authorisation request using the original tokenised credentials and transaction metadata.
This often involves specific flags to indicate a Merchant Initiated Transaction, ensuring the issuer recognises the retry as a legitimate continuation of an existing billing relationship rather than a new, suspicious request.
Why it matters
Reduction in Involuntary Churn
Involuntary churn occurs when a customer's subscription is cancelled due to technical payment failures rather than an intent to leave. By automating the recovery of soft declines, businesses can preserve the customer lifecycle without requiring the user to update their payment details.
This maintains stable revenue streams and reduces the high cost associated with re-acquiring lost customers who may not return after a service interruption.
Optimised Authorisation Rates
Authorisation rates are a primary key performance indicator for digital merchants. Soft decline retries provide a secondary layer of capture that addresses the natural volatility of global banking systems.
By intelligently timing these attempts, merchants can capture revenue that would otherwise be lost to transient infrastructure issues, directly improving the bottom line and increasing the overall efficiency of the payment processing workflow.
Use cases
Subscription Billing Cycles
Recurring service providers use retries to handle month-end processing spikes where issuer systems may experience temporary latency or account limits are reached before payday.
Cross-Border E-commerce
Merchants selling into international markets use retries to manage time-zone related outages and varying stability levels across diverse global acquirer networks.
High-Volume Digital Goods
Platforms with high transaction counts use automated logic to filter out temporary technical errors from genuine fraud, ensuring legitimate buyers are not permanently blocked.
SaaS Renewal Sequences
Software companies use multi-day retry schedules to capture funds during the grace period of a license renewal before access to the platform is suspended.
By the numbers
This represents the typical percentage of soft declines successfully captured through automated retry logic across the payments industry.
Merchants utilising intelligent retry schedules often see a three-fold decrease in subscription failures compared to those with static retry rules.
An industry-standard range for the overall increase in successful authorisations after implementing soft decline management across a global MID.
Related terms
Talk to our team about a live rollout on your acquiring stack.
What you get with Soft decline retries
- Categorisation of ISO 8583 response codes to isolate recoverable soft decline events and errors.
- Dynamic retry logic based on specific issuer behaviour and historical success rates for each BIN.
- Compliance monitoring to ensure retry attempts stay within Visa and Mastercard merchant performance programmes.
- Automated scheduling for Merchant Initiated Transactions to capture revenue during optimal banking windows.
- Integration with card account updaters to ensure retries use the most recent card credentials.
- Detailed reporting on recovery efficiency and the total value of saved revenue per month.
- Customisable thresholds for the number of retry attempts permitted before a final decline status.
- Support for smart-routing retries through alternative acquirers to bypass local processing outages.
- Preservation of original transaction metadata to maintain 3DS and SCA compliance during secondary attempts.
- Reduction in manual customer support tickets related to failed payments and account access issues.
A short scoping call, then a written plan for your MIDs.
Questions about Soft decline retries
What is the primary difference between a soft decline and a hard decline in payment processing?
A hard decline occurs when an issuer rejects an authorisation definitively, usually due to a stolen card, closed account, or invalid credentials; these should never be retried as they can lead to scheme penalties.
A soft decline is a temporary refusal, often caused by a system timeout, a transient limit on the cardholder's account, or a processor error.
Identifying the distinction is critical because soft declines represent recoverable revenue, whereas hard declines require the merchant to obtain new payment information from the customer.
How many times can a soft decline be retried without risking scheme fines?
Card schemes like Visa and Mastercard have strict rules regarding the number of authorisation attempts allowed within a specific period.
Generally, for a single transaction, the industry standard is to limit retries to no more than 15 attempts over a 30-day window, though many merchants choose a more conservative approach of 3 to 5 attempts.
Exceeding these limits can result in excessive retry fees or the Merchant Identification Number being flagged for poor processing behaviour, which may lower overall authorisation rates.
Does a soft decline retry require the customer to enter their CVV again?
No, if the merchant is using card-on-file or subscription logic, the retry is typically processed as a Merchant Initiated Transaction.
Since the original transaction was authorised via a customer-present interaction with 3DS or SCA, the subsequent retries rely on the stored token and the reference to the initial authorised transaction.
This allows the retry to occur in the background without any friction or action required from the cardholder, which is essential for reducing involuntary churn.
Which decline codes are most commonly associated with successful soft decline retries?
Commonly retriable codes include '05: Do Not Honour' (which can be a catch-all but often recovers), '19: Re-enter Transaction', '65: Exceeds Withdrawal Frequency', and '91: Issuer or Switch Inoperative'.
Codes related to system errors or temporary freezes often see high success rates on the second or third attempt. Conversely, codes like '14: Invalid Card Number' or '41: Lost Card' are hard declines and must be filtered out of any automated retry logic.
Can retrying a transaction through a different acquirer improve success rates?
Yes, this is a core component of payment orchestration. If a soft decline is triggered by a technical failure or a regional outage at one acquirer, routing the retry through a second acquirer can bypass the local infrastructure issue.
This is particularly effective for cross-border payments where an issuer might be more likely to authorise a transaction coming through a local domestic acquirer rather than an international one, depending on the risk profile of the transaction.
How does SCA and PSD2 impact the ability to perform soft decline retries?
Under PSD2 in Europe, most transactions require Strong Customer Authentication. However, retries are usually categorised as Merchant Initiated Transactions (MITs) if they are part of a recurring series or follow an initial authenticated transaction.
As long as the first transaction was correctly authenticated and the subsequent retry is flagged with the correct scheme indicators and the original transaction ID, it can usually proceed without a new SCA challenge, assuming the issuer accepts the MIT exemption.
Ready for velocity?
Tell us about your business. We'll match you with the right acquiring partners and the right route, typically inside a week.