Failed Payments Retry Rules allows for failed payments to be processed again based on specific criteria. 

The payment retry flow allows users to control how many times a payment retry occurs for a customer and the interval between the number of attempts. Once the configured retries are executed, the payment retry flows restarts from the beginning. 

NOTE: The only way to break the retry cycle in process is for a Customer to enter a new payment method, which immediately removes them from the payment retry flow. 

Preconditions: 

• Customer Account must have Delivery Preferences set to include Email instead of just Print in order for failed payment retry rules to be utilized. 
  
  
• Payment Runs must have Send email when a payment fails toggled ON in order for an email to be generated. 

Table of Contents: 

• Establish Failed Payment Retry Rules
• Retry Schedule Settings
  • (a) Next Scheduled or Manual Payment Run
  • (b) Custom Payment Run
• Additional Events that Remove a Customer from the Payment Retry Flow
• What Happens When a Customer is Removed from the Payment Retry Flow? 
• How Auto-Pay Affects Retry Rules
• Payment Retry History

Establish Failed Payment Retry Rules

Steps: 

1. Navigate to Menu > Setup > Payments > Failed Payment Retry Rules.
2. Click the Enable retry schedule toggle to turn on the feature.

3. Once enabled, select a retry schedule option. The frequency of payment attempts can be based on (a) scheduled or manual payment runs or (b) custom payment runs.

Retry Schedule Settings

(a) Next Scheduled or Manual Payment Run

• When this option is selected, failed payments are retried in the next scheduled payment run as configured in Setup > Schedules > Payment Run Schedules or in the next manually executed payment run.

Configuration Settings

• Maximum number of retry attempts - Set this number to determine the total number of retry attempts for the payment. Once this number is met, no further retries are attempted. 
• For example, to set the limit to 5 total retry attempts, enter the value ‘5.’ Once the number of attempts reaches this number, the customer will exit the retry flow.
• Minimum interval between retry attempts - Set this number to determine the number of days after each failed payment before it will be retried in the next payment run. 
• For example, if there is a daily scheduled payment run, but you want to space out the amount of time between failed payment retries to at least 3 days, enter the value ‘3.’ After an initial failed payment, the system will not try a payment attempt again until the fourth day.

• Processing option after maximum retry attempts:

• • Disable customer Auto Pay feature - This feature stops future retry attempts in Payment Runs after the maximum number of retry attempts has been met. Unless disabled, payment attempts may continue in future Payment Runs.
    • Best Practice: Enable this toggle as the default to prevent failed payments from being retried too often.
  • Enable Webhooks enables custom actions to be taken for failed payments after the maximum number of retry attempts has been met.
    • View sample payload for this webhook.

Notes on Configuring Scheduled Payment Runs: 

• When creating Payment Run schedules, payment runs that are set to trigger based on the “Immediately after a billing run is posted” setting will NOT retry previously failed payments. 

To ensure that previously failed payments will be retried, create at least one Payment Run Schedule using the Based on a schedule option. These settings can be found when creating a new Payment Run Schedule. 

• • • • Navigate to Setup > Schedules > Payment Run Schedules > Add New.

• • • • Toggle ON Send email when a payment fails as a best practice.
      • Toggle ON Automatically retry failed payments.

(b) Custom Payment Run

• When this option is selected, payment retry attempts are executed separately from payment run schedules based on a custom-defined number of retry attempts and time intervals between attempts.
  
  

Configuration Settings

• Attempt # - Determine the total number of attempts that should be made by clicking on “+Add” for each attempt.
• Days After Prior Attempt - Input a number to represent the number of days after the last payment attempt has been made before a new attempt is initiated.

For example, to retry a failed payment everyday for 5 days, create 5 attempt rows and enter “1” for each of the “days after prior attempt” field. A payment run will be initiated daily and each failed payment will be retried every day for 5 days. After 5 attempts, the customer will be removed from the retry flow.

• Send Payment Declined Email - Enable to send an email notification to the customer if the payment fails or is declined. This is configurable for each attempt.
• Payment Run Processing Options

• Create one payment per customer - Enable to consolidate the balance amounts of all open invoices into a single payment.
• For example, if there are 3 open invoices at the time a payment run is executed, one single payment consisting the total balance amount of those 3 invoices will be processed.
• Create refunds for negative invoices - Enable this to create refunds for any invoices that have a negative balance.
• Send email on successfully processing payments - Enable this to send email to the customer when a payment has been successfully processed.

• Processing option after maximum retry attempts:

• • Disable customer Auto Pay feature - Once the maximum number of retry attempts as set above has been met, the Customer's Auto-Pay setting is disabled and no further payment attempts will be made automatically.
  • Enable Webhook enables custom actions to be taken for failed payments after the maximum number of retry attempts has been met.
    • View sample payload for this webhook.

Additional Events that Remove a Customer from the Payment Retry Flow

If the Customer's payment method changes, including:

• A new payment method is added
• Default payment method is changed
• Customer's auto-pay setting is disabled

What Happens When a Customer is Removed from the Payment Retry Flow? 

• When a customer is removed from the payment retry flow, the retry rules no longer apply to any failed payments associated with the Customer. 
• Future payment failures that occur from Payment Runs result in the Customer re-entering the retry flow from the beginning.

How Auto-Pay Affects Retry Rules

When Auto-Pay is Enabled

When failed payments occur with Auto-Pay enabled, the Retry Rules explained above apply until the maximum number of retry attempts is met. 

When Auto-Pay is Disabled

When failed payments occur and a Customer adds a new payment method, Auto-Pay must be re-enabled either manually or via a Webhook or Workflow. A Webhook or a Worflow can trigger a Customer update process to re-enable Auto-Pay for the Customer.

When turning on Auto-Pay for Customer with an outstanding balance; the next Payment Run will process the outstanding amount.

Payment Retry History

• Prior to March 12, 2022, payment attempts are made on the same payment record and the record is updated to reflect the most current status and data. Effective March 12, 2022, each attempt will result in a separate payment record created to preserve the information of previous payment transaction attempts.
• All subsequent payment attempts associated with the customer will be linked and displayed in a Payment Retry History table on the Payment Detail page.

Note: The Payment Retry History table is only displayed for customers that enter the payment retry flow on or after March 12, 2022. Customers that are already in the payment retry flow prior to this date will only see payments in the Payment Retry History when payment attempts are made on or after this date. Previously failed payment attempts will not appear in the retry history.

• Once a payment attempt succeeds, all previously linked failed payments will not be retried.
• In the event that a customer has multiple failed payments and at least one previously failed payment is successfully processed, any remaining payments that continue to fail cannot be retried manually. A new payment run would need to be executed to retry previously failed payments, which would create a new payment retry history of payment attempts for that customer moving forward.

Scenario Example:

• A customer has three open invoices, each in the amount of $50. 
• If the “create one payment per customer” toggle is disabled, three separate payment records in the amount of $50 each will be created during the payment run.
• During a payment run, all three payments fail. The customer enters the payment retry flow and all three separate payments are linked in the payment retry history. 
• When another payment attempt is made, one of the three payments succeeds but the remaining two payments fail.
• Because one payment was a success, the Customer exits the payment retry flow and the remaining two payments cannot be manually retried. 
• Upon the next payment run, new payments will be created against the two outstanding invoices but any payment failures will result in a new payment retry history and the customer will again be entered in the payment retry flow.