Yuno’s Smart Retries use advanced machine learning techniques to determine the best timing for retrying a declined recurring credit card payment. By analyzing a wide range of data points and transaction attributes, it increases the likelihood of payment success, ensuring a consistent revenue stream and reducing involuntary subscriber churn.
Key advantages
Yuno’s Smart Retries offer several benefits that enhance payment processes and revenue recovery:
- Data-driven decision-making: Leverages machine learning to create the most effective retry schedule.
- Enhanced revenue retrieval: Increases the chances of successfully collecting payments.
- Decreased subscriber turnover: Minimizes disruptions and involuntary subscriber departures.
- Flexible logic: Allows customization of retry schedules to maximize success opportunities.
- Comprehensive approach: Works in conjunction with other revenue recovery strategies.
Retry schedule
Yuno uses a personalized approach for each unsuccessful payment, guided by continuous analysis and machine learning. This method evolves over time to identify the optimal moment for retrying a transaction.
| Event | Deadline after the first attempt |
|---|
| First try | - |
| Second try | 5 minutes |
| Third try | 5 hours |
| Fourth try | 12 hours |
| Fifth try | 24 hours |
| Sixth try | 36 hours |
| Seventh try | 48 hours |
Customization
Every business model is unique, so we allow merchants to define specific rules to enhance the flexibility of our retry schedule. When creating the subscription object, you can use the retries structure to make adjustments:
| Parameter | Type | Description | Example |
|---|
retry_on_decline | bool | Indicates whether to retry a payment after a first decline. Defaults to false. This flag is the only switch that enables retries; there is no dashboard toggle. | TRUE |
amount | number | Number of retries the subscription will attempt. The maximum equals your environment’s configured retry schedule length — 6 in production. Values above the cap are clamped to it. This cap is set per environment and is not configurable per account via the API. | 4 |
strategy | string | The retry strategy. Allowed values: DEFAULT and CUSTOM_SCHEDULE. DEFAULT uses the fixed schedule below (NOT ML-based timing). CUSTOM_SCHEDULE uses the per-attempt schedule you provide. | CUSTOM_SCHEDULE |
stop_on_hard_decline | bool | When true and a hard decline is detected, retries stop for the current cycle only. The subscription stays ACTIVE, billing advances to the next cycle, and no cancel/pause or subscription webhook is emitted. | TRUE |
schedule | object | Contains attempt and delay_seconds fields | Attempt: 2, delay_seconds: 86400 |
The maximum number of retries equals your environment’s configured retry schedule length: 6 in production. Sandbox is currently limited to 5 and is being aligned to match production.
strategy: DEFAULT applies the fixed schedule above, not ML-based timing. Use CUSTOM_SCHEDULE together with the schedule array to define custom delays.
