Table of Contents
- Overview
- Establish Failed Payment Retry Rules
- Retry Schedule Settings
- Additional Events that Remove a Customer from the Payment Retry Flow
- Customer Removal from Retry Schedule
- How Auto-Pay Affects Retry Rules
- Payment Retry History
Overview
Failed Payment Retry Rules allow failed electronic payments to be retried automatically based on configurable criteria. You can control the number of retry attempts, the interval between attempts, and the conditions under which a customer exits the retry flow.
📝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
To use Failed Payment Retry Rules:
- The customer’s Delivery Preferences must include Email (not just Print).
- The Send email when a payment fails toggle must be enabled in Payment Run Schedules
Establish Failed Payment Retry Rules
- Navigate to Menu > Setup > Payments > Failed Payment Retry Rules.
-
Toggle Enable retry schedule to activate the feature.
3. Once enabled, select a retry schedule option: (a) Next Scheduled or Manual Payment Run, (b) Custom Payment Run
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.
- 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.
- 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.
-
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.
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.
-
Create one payment per customer - Enable to consolidate the balance amounts of all open invoices into a single payment.
- 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.
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
Customer Removal from Retry Schedule
- 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.
Additional Notes
-
Electronic Payments Only
Payment retrials are initiated only for failed electronic payments, such as credit card or ACH bank account transactions. -
Retry Trigger Conditions
A retrial occurs only when the failure happens during a Payment Run. Payments from other sources, such as imports or manually processed electronic payments are not eligible for retry. -
Unverified Bank Accounts
If a bank account is unverified, it is typically excluded from processing until verification is complete. Payments that fail due to an unverified bank account will not enter the retry flow. -
Externally Completed Payments
If a failed electronic payment enters retrial mode but is later completed outside the system, the customer remains in retrial mode unless a new payment is successfully processed through an electronic method.
Comments
0 comments
Please sign in to leave a comment.