Soft Decline vs Hard Decline: What They Mean for Your Revenue

Why Decline Types Matter

When a subscription payment fails, not all failures are the same. The decline type tells you whether to retry the charge or contact the customer — and getting this wrong either wastes retry attempts or delays customer outreach.

There are two types:

• Soft declines — temporary issues that may resolve on their own
• Hard declines — permanent issues that require customer action

Treating them the same leaves revenue on the table. Here's how to handle each.

Soft Declines: Temporary and Recoverable

A soft decline means the card is valid, but the transaction was rejected for a temporary reason. 70-80% of all payment failures are soft declines, and they're highly recoverable with the right retry strategy.

Common Soft Decline Codes

| Decline Code | Meaning | Recovery Strategy | |---|---|---| | insufficient_funds | Account balance too low | Retry in 3-5 days (next payroll) | | processing_error | Network/system issue | Retry in 1-4 hours | | card_declined (generic) | Issuer declined without specific reason | Retry in 2-3 days | | try_again_later | Temporary issuer issue | Retry in 2-6 hours | | do_not_honor | Issuer declined (ambiguous) | Retry once, then email | | withdrawal_count_limit_exceeded | Too many transactions | Wait 3-5 days |

How to Handle Soft Declines

1. Retry on a smart schedule — space retries 3-7 days apart to align with payroll cycles
2. Send an informational email after attempt 2 — let the customer know, in case it's something they can fix
3. Retry up to 4-5 times over 14-21 days
4. Target Tuesday-Thursday, 9am-3pm for optimal retry timing

Soft decline recovery rate with optimized retries: 75-90%

Hard Declines: Permanent and Customer-Dependent

A hard decline means the card cannot process this transaction — ever. No amount of retrying will succeed. The customer must take action (usually updating their payment method).

Common Hard Decline Codes

| Decline Code | Meaning | Recovery Strategy | |---|---|---| | expired_card | Card past expiration date | Email immediately — customer must update | | stolen_card / lost_card | Bank has blocked the card | Email immediately | | invalid_number | Card number on file is wrong | Email — re-enter card details | | card_not_supported | Card type not accepted | Email — use a different card | | pickup_card | Bank flagged for retrieval | Email immediately | | new_account_information_available | Card reissued with new number | Enable auto card updater |

How to Handle Hard Declines

1. Do NOT retry — it won't work and wastes processing capacity
2. Email the customer immediately with a clear explanation and one-click update link
3. Follow up with your dunning sequence if they don't respond
4. Offer save alternatives before canceling (discount, pause, downgrade)

Hard decline recovery rate with proper communication: 40-60%

Side-by-Side Comparison

| Factor | Soft Decline | Hard Decline | |--------|-------------|-------------| | Nature | Temporary | Permanent | | Share of failures | 70-80% | 20-30% | | Retry useful? | Yes | No | | Customer action needed? | Sometimes | Always | | Recovery rate (with retries) | 75-90% | 0% (retries alone) | | Recovery rate (with communication) | 85-95% | 40-60% | | Best response | Smart retry schedule | Immediate customer notification | | Time to recovery | 1-14 days | Depends on customer response |

The Cost of Getting It Wrong

Retrying Hard Declines

If you retry hard declines (like expired_card), you:

• Waste 3-4 retry attempts that will never succeed
• Delay the customer notification by days or weeks
• Give the customer less time to update before cancellation
• May trigger fraud flags with the issuing bank

Not Retrying Soft Declines

If you email-only for soft declines (like insufficient_funds):

• You add friction (customer has to log in and take action)
• Many soft declines resolve naturally (next payroll deposits)
• You miss the opportunity for a seamless background recovery

Implementation: Decline Code Routing

The key is routing your response based on the decline code:

Payment fails →
  Check decline code →
    Soft decline? → Schedule retry + send email after 2nd failure
    Hard decline? → Skip retries + email customer immediately
    Ambiguous? → Retry once + email customer

In Stripe

Stripe provides the decline code in the invoice.payment_failed webhook event. The relevant fields:

• payment_intent.last_payment_error.decline_code — the specific decline reason
• payment_intent.last_payment_error.type — card_error, api_error, etc.

Use these to route your dunning response automatically.

The Ambiguous Middle Ground

Some decline codes are genuinely ambiguous:

• do_not_honor — the most frustrating code. The bank declined without explanation. Could be temporary (soft) or permanent (hard). Best approach: retry once after 3 days, then email the customer.
• restricted_card — might be a temporary hold or a permanent restriction. Retry once, then email.
• transaction_not_allowed — could be a card type limitation or a temporary block. Email the customer.

When in doubt, retry once and then shift to customer communication.

Key Takeaways

1. 70-80% of failures are soft declines — these recover with smart retries, no customer action needed
2. Hard declines need customer action — retrying is pointless, email immediately
3. Route by decline code — this is the single biggest optimization for payment recovery
4. Soft decline recovery: 75-90% with optimized retries
5. Hard decline recovery: 40-60% with proper customer communication
6. Don't treat all failures the same — the response strategy should match the decline type