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.
Processing payments in Processing status
Configurable Payment Retry (CPR) evaluates payment status when a payment run completes.
If a payment is in Processing status when the payment run completes, CPR does not treat the payment as failed and does not add the invoice to a retry cycle. If the invoice is already in a CPR retry cycle, CPR does not select the invoice for another retry when the payment remains in Processing status.
If the payment status later changes from Processing to Processed or Error, the status change does not trigger CPR again or resume the retry cycle.
Recovery after a payment remains in Processing status
For an invoice that is already in a CPR retry cycle, CPR can keep the invoice in a processing state until the recovery scheduler runs, typically after approximately 24 hours. Consider the following behavior:
If the payment is changed from
ProcessingtoErrorbefore the recovery scheduler runs, the invoice is no longer locked and the next retry can proceed.If the payment remains in
Processingstatus until after the recovery scheduler runs, a subsequent retry can fail with anInvoice is lockederror and the retry does not occur.Changing the payment to
Errorafter the recovery period does not cause CPR to select the invoice again.
To recover an affected invoice and allow it to re-enter the CPR process:
Set the invoice's
Auto-Payfield toYes.Clear the invoice's
Retry Statusfield.Include the invoice in the next payment run. If the payment fails again, CPR can add the invoice to a new retry cycle.