## TL;DR
Most failed payments are temporary: funds, limits, or bank soft declines that clear in days. Churn happens when retries fire too fast, stop too soon, or never tell the customer. Audit the retry schedule against the decline codes you actually receive; the fix is usually spacing retries across payday patterns and adding a card-update path before the final attempt.

```text
billing failure leading to churn: payment retry logic failed
```

## Use this when
- Involuntary churn or delinquency from failed payments is elevated
- Decline codes are dominated by soft declines
- Customers say they never knew payment failed

## Not for this skill when
- Failures are mostly hard declines (stolen or closed cards) needing new payment details
- The product was cancelled deliberately before payment failed

## Steps
1. Export failed payments with decline codes, retry timestamps, and final outcomes for 90 days. Verify: the decline mix and current retry pattern are quantified
2. Measure recovery rate per attempt number and per day since first failure. Verify: the attempts that recover money and the dead attempts are visible
3. Check customer notification timing against the retry schedule. Verify: customers are either warned before retries or surprised by them, confirmed from logs
4. Rebuild the schedule: spread attempts, stop on hard declines, send a card-update prompt before the last retry. Verify: the new schedule and messaging are live
5. Track involuntary churn weekly against the old baseline for one full cycle. Verify: recovery rate improves or the schedule gets another evidence pass

## Variant phrasings
### payment retries failing and causing churn
A related phrasing for the same underlying problem.
### involuntary churn from soft declines
A related phrasing for the same underlying problem.
### dunning retry schedule audit
A related phrasing for the same underlying problem.

Compatibility: Compatibility: billing platforms with configurable retry and dunning (Stripe Billing smart retries, Chargebee, Recurly), current versions.

## Why it happens
Banks return soft declines as a timing signal, not a verdict. Retry engines that hammer daily or give up in 48 hours convert a timing problem into lost customers. Decline-code data shows exactly when money actually recovers, so the schedule can match bank behaviour instead of habit.

## Edge cases / pitfalls
- Never retry hard declines on the same instrument; it risks processor penalties and annoys the bank, not just the customer.
- Card-update links must work without a full login for locked-out users, or the recovery path defeats itself.
- Coordinate retries with invoice emails so the customer never gets a charge attempt they were not warned about.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_WJsvu7iepaXxJM3hduHJmA