Chargebee Pay is available to pre-qualified Chargebee Billing customers. Request access to use Chargebee Pay.
Dunning and Retry Capabilities in Chargebee Pay
Chargebee Pay offers a robust retry mechanism to maximize payment success rates and minimize revenue leakage. These capabilities span both synchronous (real-time) and asynchronous (scheduled) retry strategies.
This document outlines the two layers of retry logic embedded in the system:
-
Synchronous Retries: These retries occur immediately as part of the same execution flow. When an operation (such as an API call or database transaction) fails, the system attempts it again right away, typically using a retry policy with a maximum retry count and a backoff strategy (e.g., exponential backoff).
- Use case: Handling transient errors like timeouts or rate limits.
- Behavior: The system waits for the retry attempts to complete before proceeding.
-
Asynchronous Retries: These retries are deferred and managed independently of the original execution flow. Failed operations are queued or scheduled to be retried later, often through a background job, task queue, or message broker.
- Use case: Recovering from persistent issues or when immediate retry isn't feasible.
- Behavior: The retry is handled in the background, allowing the main process to continue without waiting.
Retry Mechanisms in Chargebee Pay
Chargebee Pay uses a dual-layered retry strategy to maximize payment recovery, combining real-time intelligence with scheduled follow-ups. The table below compares the synchronous and asynchronous retry layers:
| Layer | Synchronous Retry | Asynchronous Retry |
|---|---|---|
| Type | Real-time | Scheduled |
| Timing | Instant (during transaction) | Post-failure (days/weeks) |
| Optimized For | Card issuer behavior and ML-based tweaks | Long-tail recovery, customer reminders |
| Configuration needed | Fully managed | Configurable via Dunning v2 |
Synchronous Retries
When a payment attempt fails, whether for an initial or recurring transaction, Chargebee Pay automatically triggers retries based on the failure reason. No configuration is needed for synchronous retries.
How it works
- When a transaction fails, Chargebee Pay assesses whether to initiate a retry based on the decline reason.
- If a retry is deemed beneficial, the system instantly reprocesses and resubmits the transaction using proprietary machine learning logic. The retry payload is dynamically adjusted based on several factors, including:
- Issuing bank behavior – issuer-specific retry patterns.
- Time of day – timezone-aware adjustments to optimize success rates.
- Historical success patterns – insights from past retry outcomes.
- This intelligent retry mechanism increases the likelihood of transaction recovery in real time. These retries happen within milliseconds of the original attempt and are transparent to the end customer.
Asynchronous Retries
In addition to the intelligent synchronous layer, Chargebee Pay leverages Chargebee Billing’s Dunning v2 engine for scheduled retries. This asynchronous retry flow enables sustained follow-up to recover payments that cannot be resolved immediately.
Salient features
- Flexible retry schedules – Configure retries to occur daily, every few days, or at custom intervals.
- Customer communication – Notify customers via email regarding failed payments.
- Dunning actions – Automatically pause subscriptions, cancel them, or prompt customers to update payment details.
- Multiple retry attempts – Define how many retry attempts should be made over a specified time period.
- Subscription-aware – Fully integrated with the subscription lifecycle for seamless payment recovery.
This provides a long-term follow-up process to recover failed payments that could not be resolved immediately. By combining real-time intelligence with scheduled follow-ups, Chargebee Pay maximizes payment recovery and minimizes revenue loss due to failed transactions.
Was this article helpful?