Skip to content
Card Networks ← All terms

Soft Decline

Definition

A soft decline is an authorization failure where the issuer signals the transaction can be retried — typically due to insufficient funds, a temporary flag, or SCA required.

A soft decline is an issuer rejection of a card transaction for a reason that may be temporary or addressable — such as 'do not honour', 'insufficient funds', or 'transaction not permitted' — as opposed to a hard decline (account closed, card reported stolen) where re-attempting is futile. Soft declines represent the majority of recoverable authorisation failures. Intelligent retry strategies — with timing calibrated to decline reason code — can recover 20–40% of soft-declined transactions.

Issuers return a reason code with every declined authorisation. The distinction between soft and hard declines determines whether a retry is worth attempting and what form it should take. For what a specific decline code means and whether it's this kind of soft decline, see the Card Decline-Code Lookup tool — this page covers the soft-vs-hard concept and recovery timing, not the per-code table.

Hard vs Soft Declines

Hard declines are permanent rejections — the account is closed, the card is reported lost or stolen, or the issuer has blocked the card entirely. Retrying a hard decline wastes processing cost and can generate negative signals for your merchant profile. The correct response is to abandon and, for recurring billing, contact the customer.

Soft declines are conditional rejections that may resolve on their own or with a different kind of retry — a temporary balance shortfall, an issuer risk-model flag, a card control setting, a velocity limit, or (in the EEA) a requirement to re-present the transaction with Strong Customer Authentication. Which specific code falls into which bucket, and what its retry timing looks like, is covered code-by-code in the lookup tool — including the honest caveat that some codes (Do Not Honour chief among them) are deliberate issuer catch-alls that don't map cleanly to either bucket without more context.

Technical declines are infrastructure failures, not issuer rejections:

  • Processing timeout
  • Network unavailability
  • System error

Retry technical declines immediately via a different routing path.

Soft Decline Recovery Strategies

Timing by reason code. Retrying immediately after a soft decline often fails and can compound the problem. Insufficient-funds declines resolve most frequently 24–48 hours after initial decline. A generic Do Not Honour resolves more frequently after 3–7 days — though because the underlying reason is undisclosed, that window is a heuristic, not a guarantee. Using decline-code-specific retry timing curves — available from PSPs and retry optimisation tools, and summarized per code in the lookup tool — materially improves recovery rates versus fixed-interval retry.

Account updater before retry. Visa Account Updater (VAU) and Mastercard Automatic Billing Updater (ABU) let merchants query whether a stored card has been replaced. Querying before a retry eliminates the sub-category of soft declines caused by card reissue.

3DS2 retry path. Many issuers who soft-decline a standard CNP authorisation will approve the same transaction if presented via 3DS2 frictionless authentication. The liability shift makes the issuer more willing to approve.

Impact

On subscription merchants, 2–4% of recurring authorisation attempts are soft declines that are recoverable with appropriate retry strategy. On $10M monthly recurring volume, that's $200,000–$400,000 in revenue that retries correctly — or churns if not retried.

Related terms