Retry Strategies
How LostChurn optimizes retry timing using ML scoring, exponential backoff, quiet hours, and auto-escalation.
LostChurn uses multiple strategies to determine when and how to retry failed payments. The goal is to find the optimal moment when a retry is most likely to succeed, while respecting rate limits, customer time zones, and decline-specific cooldown periods.
Strategy Overview
Smart Retry Engine
Smart retry is the default strategy for Soft Retry declines. An ML model scores each failed payment from 0.0 to 1.0, representing the probability that a retry at the recommended time will succeed.
The model considers:
- Decline type --
insufficient_fundsdeclines are more likely to succeed after a payday cycle thanprocessing_errordeclines - Time of day -- retries during business hours tend to have higher success rates
- Day of week -- certain days (e.g., Fridays, paydays) show higher recovery rates for balance-related declines
- Historical patterns -- how similar declines for this merchant and customer segment have resolved in the past
- Attempt number -- each successive retry has a lower probability of success
How the Score Works
| ML Score | Interpretation | Action |
|---|---|---|
| 0.80 - 1.00 | Very high probability | Retry soon (within hours) |
| 0.50 - 0.79 | Good probability | Retry with moderate delay |
| 0.25 - 0.49 | Fair probability | Retry with longer delay |
| 0.10 - 0.24 | Low probability | Retry, but prepare to escalate |
| 0.00 - 0.09 | Very low probability | Skip retry, escalate to dunning |
When the ML score drops below 0.10, LostChurn determines that retrying is unlikely to succeed and escalates directly to dunning communication. This prevents wasting retry attempts and gets the customer involved sooner.
The model also outputs a recommended delay in hours, which is converted to minutes and used as the scheduling baseline.
Exponential Backoff
For decline codes with a defined cooldown period, LostChurn uses the cooldown as a minimum floor for retry spacing. Successive retries increase the delay to avoid hitting rate limits or velocity checks.
| Attempt | Base Cooldown | Effective Delay |
|---|---|---|
| 1st retry | 48 hours (per decline code) | 48 hours (or ML-recommended, whichever is greater) |
| 2nd retry | 48 hours | ~72-96 hours |
| 3rd retry | 48 hours | ~120-168 hours |
| 4th retry | 48 hours | ~192-240 hours |
The exact timing is adjusted by the ML model based on when a retry is most likely to succeed. The cooldown acts as a minimum, not a fixed schedule.
Each decline code has its own cooldown period. For example, insufficient_funds uses a 48-hour cooldown, while try_again_later uses only 12 hours. See the decline code reference for specific values.
Max Retry Configuration
Every decline code has a maximum retry count that caps how many silent retries LostChurn will attempt before escalating. You can also set a merchant-level maximum.
| Setting | Range | Default | Description |
|---|---|---|---|
| Decline code max retries | 0-10 | Varies by code | Per-code limit from the decline taxonomy |
| Merchant max retries | 1-10 | 4 | Global cap across all decline codes |
| Effective max | -- | min(code, merchant) | The lower of the two values |
The effective maximum is always the lower of the decline-code maximum and the merchant-level setting. For example, if card_velocity_exceeded allows 2 retries but the merchant cap is 4, only 2 retries will be attempted.
Common Decline Code Limits
| Decline Code | Max Retries | Rationale |
|---|---|---|
insufficient_funds | 4 | Customer likely to replenish funds |
processing_error | 3 | Issuer issue usually resolves quickly |
generic_decline | 3 | May resolve but unclear cause |
card_velocity_exceeded | 2 | Needs extended cooldown |
expired_card | 0 | Customer must update card |
fraudulent | 0 | Terminal, never retry |
Quiet Hours
LostChurn supports timezone-aware quiet hours to avoid retrying payments during times when a failure might generate notifications that wake the customer.
Quiet hours apply to both silent retries and dunning communications. When a retry or message is scheduled during quiet hours, it is automatically pushed to after the quiet period ends.
How Quiet Hours Work
- You configure quiet hours in your merchant settings (e.g., 10:00 PM to 8:00 AM)
- When a retry is scheduled, LostChurn checks if the scheduled time falls within the customer's quiet hours
- If it does, the retry is delayed to at least 10 hours from the current time, pushing it past the quiet period
- The retry still executes at the ML-optimized time within the post-quiet-hours window
Configuration
Quiet hours are set per-campaign and can also be configured at the merchant level as a default:
Quiet Hours: 22:00 – 08:00 (merchant timezone)When a customer has a known timezone offset (from their profile), LostChurn adjusts the quiet hours check to their local time rather than the merchant's timezone.
Auto-Escalation
Auto-escalation is the process of moving from silent retries to customer communication. This happens automatically when:
| Trigger | What Happens |
|---|---|
| All silent retries exhausted | After the last retry fails, the recovery state moves to CommunicationPending |
| Hard Customer decline | Decline category requires customer action, so retries are skipped entirely |
| ML score below 0.10 | Model determines retry is unlikely to succeed, escalates early |
| Unknown decline code | Unmapped code is treated conservatively as Hard Customer |
The Escalation Flow
When escalation occurs, the customer is enrolled in the appropriate dunning campaign based on the trigger type. The campaign handles the messaging sequence, including payment update links and self-service options.
Preventing Over-Communication
LostChurn tracks whether communication has already been triggered for each recovery attempt. If a customer is already receiving dunning messages, subsequent retry failures do not trigger duplicate campaigns. Instead, the state moves to AwaitingCustomer to wait for the customer to take action.
Scheduling Methods
Each retry attempt records how it was scheduled, providing visibility into which strategy is driving recovery:
| Method | Description |
|---|---|
SmartRetry | ML model selected the optimal time |
Exponential | Exponential backoff from the previous attempt |
FixedDelay | Fixed delay based on decline code cooldown |
Manual | Manually triggered by a team member |
OrchestrateRecovery | Scheduled by the recovery orchestration engine |
Auto | System-initiated based on default rules |
Next Steps
- Decline Categories -- understand which codes are eligible for retry
- Recovery States -- follow the full state machine
- Campaigns -- configure dunning messages for when retries are exhausted