Use Configurable Payment Retry
Understand how Configurable Payment Retry creates payment runs, evaluates invoice due dates and balances, and executes configured or Smart Retry logic to retry failed payments at optimal times.
When Configurable Payment Retry creates payment runs to retry failed payments, it uses the current date as the Target Date for the Payment Run. Any billing document with a due date later than the current date is not processed by Configurable Payment Retry.
Keep in mind the following when using Configurable Payment Retry:
Payment Schedules has its own retry mechanism that is intended to handle retries for scheduled payments. Configurable Payment Retry does not have visibility into individual payment schedule items. Instead, Configurable Payment Retry determines whether to retry based solely on the invoice balance and the invoice due date.
Because of this behavior, even if a payment schedule item has been paid, the invoice balance might still be greater than zero. In such cases, Configurable Payment Retry continues retry attempts until one of the following conditions is met:
A successful payment is received.
The invoice balance becomes zero.
All configured retry attempts have been exhausted.
Additionally, Configurable Payment Retry uses the current date as the target date. If the invoice due date is later than the target date, retry cycles might stop prematurely because the system determines that collection cannot proceed for amounts that are not yet due.
Activation of the retry logic
Upon the completion of a payment run, Configurable Payment Retry logic is activated. Configurable Payment Retry evaluates payments when the payment run completes. If an asynchronous payment is still in Pending status at that time, CPR does not treat it as a failed payment and does not schedule a retry. If gateway reconciliation later changes the payment status from Pending to Error, that status update does not trigger CPR again. Initial payments from the payment run that are not successful are sent into the retry system and trigger the configured retry logic.
If you configured your retry logic manually based on the payment gateway response codes, the retry logic that you defined for the customer group is executed. If you enabled Smart Retry, the AI-driven retry logic is executed to retry failed payments at optimal times. For details about how to configure these two approaches, see Edit retry rules for a customer group.
When a retry attempt is executed in Configurable Payment Retry, a payment run with the record of the payments being attempted is also created and visible in Payment Runs of Zuora Payments. Retry attempts are executed in batch on the hour rather than continually being executed. A maximum of 24 payment runs can be made in a day. Therefore, the retry logic cannot be set to retry sooner than every hour.
Ensure that the out-of-box payment retry is not running in your Zuora environment, and the Callout Notification setting for Configurable Payment Retry is configured. Failure to disable the out-of-box payment retry while running Configurable Payment Retry might result in disruption to the service. See Configurable Payment Retry process overview for details.
See Payment Runs for more information about payment runs.