This guide will detail the options available to recover failed payments through our available automated failed payment handling process.
Depending on your integration, your platform has the option to utilise our automated failed payment handling process if compatible with your integration OR allows your platform to control the failed payment process which gives you more control and flexibility. Simply send Payrix the API call to charge the payers account to collect payment for the rejected transaction via ‘POST Schedule a single payment’ or ‘Process a transaction using saved card details’ (if relevant to your integration) on the day you wish to re-attempt collection of payment.
Further below will detail 4 main options on how we can automate the process to recover failed payments.
To enable any of these features, please contact your Partner manager or our Client Success team - via a support ticket to get you in touch.
Re-submit Rejections
Only available for 'Recurring Cards'. This function will retry the failed recurring card transaction once on the next business day.
This function will stop after 2 failed transaction attempts.
Re-attempt rejections after 'X' days
Intended for use with our unending schedule type which allows a rejected payment to be re-added to the payer’s schedule so it can be re-attempted on a future date. The re-attempt will be scheduled to occur on the number of days specified after the date on which the debit was originally attempted.
The transaction will only re-attempt once.
This process will set a Payer status to “Suspended - Multiple Rejections” if the re-attempted transaction fails.
This transaction type sets a default ‘Transaction Reference’ of “Reattempt of DD/MM/YYYY pmt ({{TransactionID}})”
Accrue rejections
Applicable only to limited schedules. If enabled, when a rejection occurs, the rejected amount will be re-added to the payer’s schedule as a second payment to be debited on the date payer’s next debit is scheduled to occur on.
If there are no more payments in the payer’s schedule when the rejection occurs, then the re-attempt will be scheduled for the next future date that matches the payer’s schedule frequency and day of week/month settings.
Additional setting options
These options below can be used to control how the rejected transactions behave in conjunction with the above functions.
Reschedule last transaction once only
This setting is an option that can be enabled for ‘Accrue rejections’. This setting means that we will only re-schedule the last transaction in a payer’s schedule once on a rejection. The system will not continue to re-schedule the last payment endlessly if it continues to reject.
This setting will re-attempt the transaction once and if that fails, it will set the payer to “Suspended - Multiple Rejections” status.
Do not extend limited schedules
If enabled, no additional payments will be added to the end of limited schedules when a payment rejects (both regular and late rejections/claims/chargebacks).
Suspend on multiple rejections
Applies only to payers on limited schedules. If enabled, the second consecutive rejection of a
scheduled debit will cause the payer to be put into the "Suspended - Multiple Rejections" status.
Suspend on multiple rejections (2x)
Applies only to payers on limited schedules. If enabled, when a rejection is processed, we will check the result of the two most recent consecutive payments that occurred prior to the original processing date of the rejected payment (i.e. if there were two payments processed on the same day as the rejected payment,
then the other payments on that same day are not considered).
If both payments rejected, then the payer will be placed into the "Suspended - Multiple Rejections" status. However, this setting will not allow more than two payments to occur on the one day (as in the case of multiple re-scheduled rejection re-attempts occurring on the same day), so even if both the previous rejections didn't fail, the system will still place the payer into "Suspended - Multiple Rejection" status if there are already two payments scheduled on the payer's next schedule date so as to prevent three payments being scheduled on the next payment date for the payer.
This setting cannot be used in conjunction with the "Suspend on Multiple rejections" setting above and vice versa. Only 1 “Suspend on Multiple rejections" option can be selected.
Payment Recovery Payrix Payment Page
This function allows automatic follow up of rejected recurring bank account and card transactions where payer’s details have been stored in Payrix Portal including email or mobile number. The payer will receive an email and a link which will direct them to the Payrix Hosted Payment Page (HPP).
When a recurring transaction is rejected, an email, SMS or both (depending on settings) are automatically generated by Payrix to notify your payer about the unsuccessful transaction. The notification includes:
Information about client name
Information that scheduled transaction has failed and the payment amount
Link which allows the payer to pay the rejected transaction at real-time
Information when the link will expire (only email)
Email Example:
This email can be individually branded. Please speak to your Partner manager to discuss options. The link will redirect the payer to the Payrix Hosted Payment Page to submit payment.
Sample:
Payment Recovery Payment options
Depending on the settings and rejected transactions type, the payer will have the following options on how to pay:
For rejected card transaction only
Use card stored by Payrix to process the real-time transactions
“Use my current stored card.”
For rejected card and bank account transactions
Enter new card details
“Enter new card details.”
The payer can also have the option to change their payment details for future payments:
Card details – new card details entered by payer can be saved for future via selecting,
“Save card details for future recurring payments.”
Bank account details – new bank account details can be entered by payer via selecting,
“Enter bank account details for future recurring payments.”
For more details around the implementation of the Payment Recovery function, please head over to our ‘Implement Payment Recovery function’ page.