What is the difference between a hard and soft decline?

A soft decline is temporary — insufficient funds, rate limiting, or a processor timeout. These can be retried. A hard decline is permanent — expired card, stolen card, or closed account. These require the customer to update their payment method. LostChurn classifies every decline and routes it accordingly.

How does LostChurn classify 341 decline codes?

LostChurn maintains a normalized decline code database covering 20 payment providers. Each provider-specific code is mapped to a standard category (hard/soft), subcategory (e.g., insufficient funds, expired, fraud), and recommended recovery action. This database is continuously updated as providers add new codes.

Should I retry hard declines?

Generally, no. Retrying hard declines (stolen card, closed account) can trigger fraud alerts and increase your processor decline ratio. LostChurn never retries hard declines — instead, it routes them to dunning campaigns that ask the customer to update their payment method.

What is a "generic decline" and how do I recover from it?

A generic decline (also called "do_not_honor") is the most common decline code, accounting for 30-40% of all failures. The issuing bank declines the charge without a specific reason. LostChurn treats these as soft declines and uses optimized retry timing — often recovering 60-70% within 72 hours.

Use CaseDecline Recovery

Decode your declines

Not all declines are equal. LostChurn classifies 341 decline codes across 20 payment providers, routing each failure to the right recovery strategy — retry, dunning, or payment update.

The problem

Cryptic decline codes

Payment processors return vague codes like "do_not_honor" or "generic_decline" that provide no actionable information for recovery.

One-size-fits-all retries

Most processors retry all failures on the same schedule. But a "card expired" decline needs a different strategy than "insufficient funds."

Hard vs soft decline confusion

Retrying a hard decline (stolen card, closed account) wastes resources and can trigger fraud flags. Only soft declines should be retried.

Cross-processor inconsistency

The same failure reason has different codes across Stripe, Braintree, Adyen, and others. Normalizing these for a consistent recovery workflow is a major engineering effort.