Soft Declines vs. Hard Declines: Which Subscription Payment Failures Can Be Recovered?

When a subscription payment fails, the decline response gives you a starting point for deciding what should happen next.

Some failures are temporary and may succeed with another attempt. Others require updated payment credentials, additional authentication, a different payment method, or direct action from the customer. Some responses indicate that another attempt should not be made.

A soft decline is generally a temporary or context-dependent authorization failure that may be recoverable without replacing the payment method. A hard decline generally points to a more persistent issue with the account, credentials, or authorization that is unlikely to be resolved by submitting the same transaction again.

In practice, those categories are useful but imperfect. Networks, issuers, processors, regions, payment methods, and transaction types can classify or surface the same underlying problem differently.

For subscription businesses, that makes the next step more important than the label itself: can the payment still be recovered, and what needs to happen before another attempt is made?

Soft declines vs. hard declines at a glance

##TABLE:tbl-declines-glance##

The table also points to a second layer of the problem: recoverable and retryable are not quite the same thing.

A payment may eventually be recovered through refreshed credentials, authentication, customer action, or a change to the transaction even when another immediate authorization attempt would be inappropriate.

What is a soft decline?

A soft decline usually occurs when the payment fails because of a condition that may change.

The payment method may still be valid and the customer may still intend to continue their subscription. The issuer simply could not approve the transaction at that moment or under those conditions.

Insufficient funds is a common example. A renewal may fail because the customer does not have enough available balance when the transaction is first attempted, then succeed later once funds are available.

Other soft declines can be related to temporary issuer conditions, transaction limits, authentication requirements, or issuer risk decisions.

So while a soft classification suggests there may still be a path to recovery, the decline reason and surrounding transaction data should guide what happens next.

Insufficient funds

An insufficient-funds decline means there was not enough available balance or credit to approve the payment at the time of authorization.

Because the customer's available funds can change, a later attempt may succeed.

The harder part is deciding when that attempt should happen. Retrying immediately may simply generate another decline, while waiting too long can extend the recovery period and increase the chance that the subscription lapses.

This is one place where fixed retry schedules can fall short. Two customers with the same decline code may have very different chances of succeeding on the next attempt depending on timing and account behavior.

Temporary issuer conditions

Sometimes the issue sits outside the customer's account altogether.

A transaction can fail because the issuer or another part of the payment infrastructure is temporarily unable to complete the authorization. Adyen, for example, includes “Issuer Unavailable” among its refusal reasons.

In those cases, the payment method itself may still be valid, and a later attempt can make sense once the temporary processing issue has passed.

Authentication requirements

Other failures need something to change before another authorization is attempted.

A payment may require 3D Secure or another authentication step before the issuer will approve it. Depending on the transaction, the customer may need to participate in that process.

If the authentication requirement remains unresolved, another attempt under the same conditions is unlikely to help. Recovery starts with addressing the missing authentication step.

“Do not honor” and other generic responses

Generic issuer responses are more difficult because they tell you less about the underlying cause.

“Do not honor” is one of the most common examples. Braintree classifies its “Do Not Honor” processor response as a soft decline, while other payment platforms may map or describe generic issuer responses differently.

The response itself does not explain whether the issuer rejected the transaction because of risk, transaction data, customer behavior, or another condition.

At that point, the other information attached to the payment becomes more useful. Previous attempts, authentication results, credential status, transaction details, and processor guidance can all help determine whether another attempt makes sense and what should change first.

What is a hard decline?

Hard declines usually point to a more persistent problem.

The card may no longer be valid, the account may be closed, the card may have been reported lost or stolen, or the customer may have revoked authorization for recurring payments.

In each of those cases, submitting the same payment information again is unlikely to produce a different result because the underlying issue is still there.

That still leaves room for recovery if the issue itself can be resolved.

Can a hard decline still be recovered?

Consider an expired or reissued card.

A renewal may fail because the credentials stored by the merchant are no longer current. Further attempts using those same credentials are unlikely to help.

But if an account updater provides a new card number or expiration date after the issuer replaces the card, the merchant can attempt the payment again using the refreshed credentials.

Other hard declines may require the customer to provide a different payment method, contact their issuer, or authorize recurring payments again.

The recovery path therefore depends on why the existing payment information can no longer be used.

What is the difference between recoverable and retryable declines?

A retryable decline is one where another authorization attempt may be appropriate.

A recoverable decline is broader. It includes any failed payment that may still be successfully collected through an available recovery action.

Depending on the cause of the failure, that action can look very different.

Retry the transaction later

A later authorization attempt can make sense when the condition that caused the original failure is likely to change.

Insufficient funds and temporary issuer availability are common examples.

Even here, the timing of the retry should reflect the type of failure and any guidance provided by the network or processor. A retry simply because a set number of hours has passed may not be the best use of another attempt.

Change the transaction conditions

Sometimes the transaction needs to be presented differently before another authorization is made.

That may include additional authentication, corrected transaction data, or another change to how the payment is processed.

This becomes especially relevant with generic decline responses, where the response code alone offers limited guidance about the underlying issue.

Refresh the payment credentials

Recurring payments also have to account for the fact that card details change over time.

Cards expire, accounts are reissued, and account numbers can change. Account updater services can sometimes provide refreshed credentials automatically when the issuer makes them available.

Once those credentials are updated, the merchant has a materially different transaction to submit.

Ask the customer to take action

There are also failures that cannot be resolved inside the payment flow.

The customer may need to authenticate the payment, update their card details, contact their issuer, or select another payment method.

A good recovery process should recognize these cases early so customer outreach is used where it is actually needed.

Stop further attempts

And in some cases, the recovery process should end.

Certain issuer or network responses indicate that the payment should not be attempted again. This can happen when the customer has revoked authorization, issued a stop-payment instruction, or when applicable network rules prohibit further attempts.

Clear stop conditions help prevent unnecessary retry volume and keep recovery efforts focused on payments that still have a realistic path to success.

What should you do after a recurring payment declines?

Once a recurring payment fails, the recovery process should identify why it failed and what needs to change before another authorization is attempted.

A practical way to work through that decision is to start with the information returned from the failed payment and narrow down the available options from there.

1. Review the decline response

Start with the decline code, refusal reason, network response, advice code, and any other payment information returned with the failed authorization.

Together, those signals can help narrow down the likely cause and the actions available to the merchant.

2. Determine whether another authorization is appropriate

Some decline responses allow another attempt. Others indicate that the merchant should stop retrying.

If another attempt is permitted, the next consideration is timing.

An immediate retry may make sense after a temporary technical issue. It is less useful when the account has insufficient funds or an authentication requirement remains unresolved.

3. Check whether the credentials are still valid

Credential status is another common reason a payment cannot succeed.

If a card has expired, been replaced, or otherwise changed, check whether updated information is available through an account updater or other credential-management process before attempting the stored card again.

4. Review the transaction context

The surrounding transaction can provide clues that the decline code does not.

Authentication requirements, transaction data, routing, and other payment conditions can all affect authorization outcomes. This becomes particularly useful when the issuer provides only a generic response.

5. Decide whether the customer needs to be involved

At this point, some failures can still be resolved within the payment flow, while others require the customer to update information, authenticate the transaction, or contact their issuer.

Making that determination early helps avoid sending unnecessary dunning messages while moving genuine customer-action cases into the right communication flow.

6. Apply a stop condition

Every additional authorization attempt should have a reasonable chance of succeeding.

If the underlying condition has not changed and is unlikely to change, further retries can increase decline volume and processing costs without materially improving recovery.

Decline occurs → Review decline response and payment signals → Determine whether another authorization is appropriate → Check credential status → Review authentication and transaction context → Decide whether customer action is required → Retry, update, escalate, or stop

Why decline codes alone do not determine the next action

A decline code can narrow down the problem, but it rarely provides enough information on its own to determine the best recovery treatment.

Issuers consider multiple signals when deciding whether to approve a transaction, including account status, available funds, spending behavior, transaction characteristics, credential information, and authentication data.

Processors may also translate raw issuer and network responses differently before the merchant ever sees them.

That means two transactions that look similar at the decline-code level can still have different recovery paths.

For one customer, a later retry may be reasonable. Another payment may need refreshed credentials. A third may require authentication or customer action.

Looking at the decline response alongside credential status, transaction context, authentication, and previous attempts gives the recovery process more information to work with than a fixed decline-and-retry workflow.

How do soft and hard declines contribute to involuntary churn?

Involuntary churn happens when a payment failure remains unresolved long enough for the subscription or customer relationship to end.

The sequence often looks like this:

Renewal is due → payment fails → recovery process begins → payment remains unresolved → subscription lapses or is cancelled

For the customer, that can happen without any intention to leave. They may still want the product or service and may not even be aware that the renewal failed.

That makes the recovery period between the initial decline and the end of the subscription particularly important. The actions taken during that window determine whether the failed renewal is resolved as a billing issue or eventually becomes a lost customer.

Voluntary churn follows a different path because it starts with a customer choosing to leave. Involuntary churn can begin with a payment problem that has little to do with the customer's satisfaction or intent.

How should you measure decline recovery?

Recovery measurement should show how effectively failed payments are being resolved and how much incremental revenue the recovery process contributes.

Looking at a single overall recovery rate can hide meaningful differences between the types of failures being processed, so it helps to break performance down further.

Eligible decline recovery rate

Measure the percentage of declines identified as recoverable that eventually become successful payments.

Segmenting eligible declines avoids mixing recoverable failures with transactions that could not reasonably have been recovered.

Incremental recovery

Measure the additional revenue recovered beyond what the existing retry or dunning process would have captured.

This is particularly useful when evaluating a new recovery strategy because some failed payments would have recovered through the existing workflow anyway.

Credential-update success rate

Track how often updated credentials lead to a successful authorization after the original stored credentials fail.

Over time, this can show how much of the recovery opportunity is being driven by account updater and credential-management processes.

Time to recovery

Measure the time between the first failed authorization and successful payment.

Recovery speed affects both cash collection and customer experience, especially when failed payments can trigger service interruptions or customer outreach.

Avoidable decline rate

Recovery data can also point upstream.

If a meaningful share of failed payments could have been prevented through better authentication, transaction setup, credential quality, or other authorization changes, those issues may be better addressed before the payment ever reaches recovery.

Payment success rate and revenue captured

At the highest level, payment teams should be able to see whether more legitimate transactions are succeeding and how much revenue is being retained as a result.

Retry counts can help explain the process, but successful payments and recovered revenue show whether that process is actually working.

What does a stronger decline recovery strategy look like?

Many recovery programs follow a predictable sequence after a payment fails: wait for a set period, retry the transaction, wait again, and eventually contact the customer if the payment remains unsuccessful.

That structure is easy to operate, but it gives very different payment failures much the same treatment.

A temporary funds issue may justify another attempt later. Outdated credentials may need to be refreshed first. An authentication requirement may require customer involvement. A revoked authorization may end the recovery process entirely.

Using the information available from the failed payment makes it possible to choose a treatment that better fits the situation.

It also creates a clearer connection between recovery and the broader authorization process.

Payment performance is shaped both by what happens before the first decline and by how the merchant responds afterward. Looking at those two parts together helps payment teams identify where legitimate transactions are being lost and which interventions are actually improving success rates.

Revaly helps subscription businesses improve payment performance across the payment lifecycle, from reducing avoidable authorization failures to applying more appropriate recovery treatments after a decline.

Want to understand where your subscription payments are failing and which failures may be recoverable?

Get a Payment Decline Diagnostic.

Frequently asked questions

What is the difference between a soft decline and a hard decline?

A soft decline is generally caused by a temporary or context-dependent condition and may be recoverable through another attempt or another payment intervention.

A hard decline generally points to a more persistent issue with the account, credentials, authorization, or payment method. The underlying issue usually needs to be addressed before the payment can succeed.

Exact classifications vary across issuers, networks, processors, regions, payment methods, and transaction types.

Are all soft declines recoverable?

No.

A soft decline indicates that the underlying condition may be temporary or correctable. Recovery still depends on the reason for the failure, issuer behavior, transaction context, retry rules, credential status, timing, and the recovery options available.

Can a hard decline ever be recovered?

Yes.

Recovery may be possible after the underlying issue is addressed. Updated credentials, another payment method, successful authentication, or direct customer action can sometimes allow a future payment to succeed.

Is “do not honor” a soft or hard decline?

There is no universal classification across every payment stack.

Some processors categorize “do not honor” as a soft decline, while others may surface or map the response differently.

Because the response is generic, merchants usually need additional payment and transaction context before deciding whether and how to attempt recovery.

Is insufficient funds a soft decline?

Insufficient funds is commonly treated as a soft decline because the customer's available balance can change.

A later retry may succeed once funds become available. The timing and frequency of those retries should reflect the payment context, processor guidance, and applicable network rules.

How many times should you retry a declined subscription payment?

There is no single retry count that applies to every failed subscription payment.

Some decline responses should not be retried. Others allow additional attempts within the rules set by the relevant network and processor.

The decline reason, previous attempts, transaction context, and likelihood that the underlying condition has changed should guide the retry strategy.

How do soft declines contribute to involuntary churn?

A soft decline can contribute to involuntary churn when a customer's renewal payment fails and remains unresolved long enough for the subscription to lapse or be cancelled.

The customer may still want the product or service, which makes the recovery window an important part of retaining subscription revenue.