Dunning and Retry Capabilities in Chargebee Embedded Payments

Chargebee Embedded Payments 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 Embedded Payments

Chargebee Embedded Payments 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:

Synchronous Retries

When a payment attempt fails at the time of transaction, either for an initial transaction or a recurring charge, depending on the failure reason, Chargebee Embedded Payments automatically triggers retries. No configurations are needed for synchronous retries.

How It Works

When a transaction fails, based on the decline reason, Chargebee Embedded Payment assesses whether or not to initiate a retry attempt.

If a retry is deemed beneficial, the system instantly repurposes 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 fully transparent to the end customer.

Asynchronous Retries

In addition to the intelligent synchronous layer, Chargebee Embedded Payments leverages the full power of 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 ensures a long-term follow-up process to recover failed payments that couldn’t be fixed immediately. Learn more about configuring Dunning in Chargebee Billing.