> ## Documentation Index
> Fetch the complete documentation index at: https://docs.y.uno/llms.txt
> Use this file to discover all available pages before exploring further.

# Smart Retries

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 |

<Note>
  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.
</Note>

<Note>
  `strategy`: `DEFAULT` applies the fixed schedule above, not ML-based timing. Use `CUSTOM_SCHEDULE` together with the `schedule` array to define custom delays.
</Note>