Not all payment failures are equal. A card that's temporarily over its daily limit and a card that's been reported stolen require completely different responses. The distinction between soft declines and hard declines determines whether you should retry, when you should retry, and whether retrying will ever work.
Getting this wrong means either giving up on recoverable revenue or burning retry attempts on cards that will never work, potentially triggering fraud flags with card networks.
What is a soft decline?
A soft decline is a temporary refusal by the issuing bank. The card itself is valid, the account exists, and the customer hasn't done anything wrong. Something about the timing, amount, or processing conditions caused the bank to say "not right now" rather than "never."
Soft declines account for 60-70% of all payment failures. They're the majority of what you'll encounter, and the majority of them are recoverable.
Common soft decline reasons:
- Insufficient funds at the moment of charge
- Daily or per-transaction spending limit reached
- Bank fraud algorithms flagging an unusual pattern
- Processing or network errors (temporary)
- Issuer system unavailable (temporary)
- Card velocity limit exceeded (too many charges in a short period)
The defining characteristic of a soft decline: the underlying problem can resolve on its own, or with minimal customer action.
What is a hard decline?
A hard decline is a permanent refusal. The card or account has a fundamental issue that retrying won't fix. The bank is telling you this card cannot be charged, period.
Hard declines make up 30-40% of failures. They require the customer to provide a different payment method.
Common hard decline reasons:
- Card expired
- Card reported lost or stolen
- Account closed
- Invalid card number
- Card not activated
- Pickup card (suspected fraud, bank wants the card confiscated)
- Restricted card (blocked for this type of transaction permanently)
The defining characteristic of a hard decline: retrying will always fail. Only the customer providing new payment information can resolve it.
Recovery rates
The recovery data shows a stark difference between the two types.
| Decline Type | Recovery with retry only | Recovery with dunning | Total recoverable |
|---|---|---|---|
| Soft decline | 40-60% | Additional 15-25% | 55-80% |
| Hard decline | < 1% | 25-40% | 25-40% |
For soft declines, automatic retries alone recover 40-60% of failures. That's before any customer communication. Adding dunning (emails asking the customer to update their payment) captures another 15-25% of the remainder.
For hard declines, retries are essentially worthless. The card won't work no matter how many times you try. Recovery comes entirely from dunning: getting the customer to provide a new, working payment method. Even with good dunning, hard decline recovery tops out around 40% because some portion of those customers have already mentally moved on.
Stripe decline codes
Stripe categorizes declines with specific codes that tell you exactly what happened. Here's how the most common ones map to soft vs hard declines.
Soft decline codes in Stripe
| Stripe Code | Description | What to Do |
|---|---|---|
insufficient_funds |
Account balance too low | Retry in 3-5 days (around paydays) |
generic_decline |
Bank refused without specific reason | Retry in 24-48 hours |
do_not_honor |
Bank refused (often fraud-related) | Retry in 24-48 hours, then dunning |
processing_error |
Temporary network/system issue | Retry in 2-6 hours |
try_again_later |
Issuer system temporarily unavailable | Retry in 4-12 hours |
card_velocity_exceeded |
Too many transactions in short period | Retry in 24 hours |
withdrawal_count_limit_exceeded |
Daily withdrawal limit hit | Retry next day |
reenter_transaction |
Bank requests a new attempt | Retry immediately |
Hard decline codes in Stripe
| Stripe Code | Description | What to Do |
|---|---|---|
expired_card |
Card past expiration date | Dunning: ask customer to update card |
lost_card |
Card reported lost | Dunning: ask for new card |
stolen_card |
Card reported stolen | Dunning: ask for new card |
card_not_supported |
Card type not accepted | Dunning: ask for different payment method |
invalid_card_number |
Card number is incorrect | Dunning: ask customer to re-enter |
pickup_card |
Bank wants card confiscated | Dunning: ask for new card |
restricted_card |
Card blocked for this merchant/type | Dunning: ask for alternative method |
new_account_information_available |
Card reissued with new details | Dunning or wait for card updater |
currency_not_supported |
Card can't process this currency | Dunning: different payment method |
The gray zone
Some decline codes sit between soft and hard. They might resolve on their own, or they might require customer action.
| Stripe Code | Description | Nature | Recommendation |
|---|---|---|---|
authentication_required |
SCA/3DS needed | Soft-ish | Dunning with authentication link |
approve_with_id |
Bank needs cardholder verification | Soft-ish | Customer must call bank |
issuer_not_available |
Issuer system down | Soft | Retry in a few hours |
not_permitted |
Card not authorized for this type | Hard-ish | May need different card |
authentication_required is increasingly common in the EU and UK due to Strong Customer Authentication (SCA) regulations. This isn't a traditional decline, but the payment won't complete until the customer authenticates. Treat it like a soft decline that requires customer action: send them a link to complete authentication.
Retry strategy by decline type
The right retry strategy depends entirely on whether you're dealing with a soft or hard decline.
For soft declines: retry with intention
Soft declines deserve retries, but not blind ones. The timing and frequency of retries should match the decline reason.
Insufficient funds: Retry on likely paydays. In the US, the 1st, 5th, and 15th of the month are common payroll dates. Retry 3-5 days after the initial failure, then again 5-7 days later if the first retry fails.
Generic decline / do not honor: These often clear up when the bank's fraud algorithms reset. Retry once in 24-48 hours. If it fails again, switch to dunning because the customer may need to contact their bank.
Processing errors: These are truly temporary. Retry in 2-6 hours. If it fails a second time, something else may be wrong.
Velocity limits: Wait at least 24 hours for daily limits to reset. Don't retry multiple times in the same day, as that can make the velocity issue worse.
General retry cadence for soft declines:
| Retry | Timing | Expected Recovery |
|---|---|---|
| 1st retry | 4-24 hours after failure | 20-30% |
| 2nd retry | 3-5 days after failure | Additional 10-15% |
| 3rd retry | 7-10 days after failure | Additional 5-8% |
| 4th retry (final) | 12-14 days after failure | Additional 2-4% |
Stripe's built-in Smart Retries handle much of this automatically. They use machine learning to pick optimal retry times based on card network data. But Smart Retries only handle the retry. They don't communicate with the customer, which is where dunning adds value.
For hard declines: skip retries, start dunning immediately
Retrying a hard decline wastes time and can hurt your processing reputation with card networks. If a card is expired or reported stolen, it's not going to work tomorrow either.
Instead, trigger your dunning sequence immediately:
- Email within 1 hour of the hard decline. Be specific about the issue: "The card ending in 4242 has expired" is better than "Your payment failed."
- Include a direct link to update their payment method. Don't send them to a generic settings page.
- Follow up on day 3, day 7, and day 10. Hard declines require customer action, and people procrastinate.
How to implement this in practice
Most payment processors, Stripe included, return decline codes with each failed charge. Your dunning system should route failures based on these codes.
Route 1: Soft decline
- Record the failure and decline code
- Schedule automatic retry based on the specific code
- If retry 1 fails, send first dunning email + schedule retry 2
- Continue sequence with parallel retries and emails
- If all retries exhausted, send final dunning emails focused on payment update
Route 2: Hard decline
- Record the failure and decline code
- Skip retries entirely
- Send first dunning email within 1 hour
- Continue email/SMS sequence focused on updating payment method
- Include a direct payment update link in every message
Route 3: Authentication required
- Record the failure
- Send email with 3DS authentication link immediately
- Follow up if authentication not completed within 24-48 hours
This routing logic is the difference between a generic dunning system (same response to every failure) and an effective one. A hard decline that gets retried 4 times over 2 weeks wastes 2 weeks of potential dunning time. A soft decline that triggers immediate dunning instead of a retry misses the easiest recovery path.
Monitoring and adjusting
Track your recovery rates by decline code, not just in aggregate. If your insufficient_funds recovery rate is below 50%, your retry timing may be off. If your expired_card recovery rate is below 30%, your dunning emails aren't compelling enough or you're waiting too long to send them.
Here are benchmarks to aim for:
| Decline Type | Target Recovery Rate |
|---|---|
| Insufficient funds | 60-75% |
| Generic decline | 45-60% |
| Processing error | 80-90% |
| Expired card | 35-50% |
| Lost/stolen card | 30-45% |
| Invalid number | 20-30% |
If you're significantly below these targets for any category, look at your retry timing (for soft declines) or your dunning messaging and speed (for hard declines).
The bottom line
Treating all payment failures the same is the most common mistake in payment recovery. A processing error and a stolen card need fundamentally different responses. Retry logic handles the soft declines. Dunning handles the hard ones. And knowing which is which, at the moment of failure, determines how much revenue you actually recover.
If your current system sends the same email sequence regardless of decline type, you're likely leaving 15-20% of potential recovery on the table. Route intelligently, retry strategically, and communicate clearly.