What `processing_error` actually means
This is usually transient network or issuer noise, not a customer problem.
Treating it like every other decline is the mistake: a fixed day-1/day-3/day-7 cadence sends the wrong message at the wrong moment and trains the issuer to keep refusing.
Retry timing
Retry at 6 hours. Earlier attempts land before the underlying condition clears; later attempts arrive after the customer has mentally cancelled.
Cap total attempts at three to four across 7-10 days. Beyond that, incremental recovery is under two points and the fraud-signal cost rises.
How much of your involuntary churn is recoverable?
Compares a 40% single-channel baseline against the 63.8% RRLabs platform average.
- At risk / month
- $5,600
- Extra recovered / month
- $1,333
- Annualised, less $3,000 plan
- $12,994
Message framing that converts
Retry silently first; only message the customer after the second failure.
Dispatch over Silent retry. The channel decision matters more than the subject line: a message that is never opened cannot convert regardless of copy quality.
What to measure
Track recovery rate for `processing_error` in isolation, not blended. A blended 60% can hide a 25% processing error bucket that is quietly the largest churn source in the account.
Log model, latency and recovery score per message so you can attribute lift to copy changes rather than seasonality.