The following information applies to the APEXX Atomic platform only.
Cascading
Overview
Cascading is the practice of routing declined transactions to an alternative payment processor with the main goal being that of obtaining an authorisation with one processor where another has been unsuccessful.
In order to ensure transactions are being cascaded in an optimum manner consideration needs to be given to the types of declined transactions that a re-attempted with an alternative acquirer. For example, a transaction declined for insufficient funds is not going to achieve success elsewhere where as some of the less prescriptive extended decline codes could. The ultimate goal of cascading is to increase acceptance rate for merchants.
What is key to Cascading transactions?
In order for cascading to be a usable product they following items are key.
Merchants with multiple payment processors/ acquirers
A rules engine that can dictate how and when a declined transaction is cascaded
Extended decline data
Ability to report on cascaded transactions
Ability to analyse acceptance impact of cascading transactions
How will cascading work?
Select Key Regions and Test
All APEXX Merchants have an Organisational hierarchy/tree depending on how many locations or websites they have. Cascading will be enabled on a Merchant by Merchant basis and controlled via a flag on the Organisation record. For merchants with multiple layers within their hierarchy it can enabled on each individual organisation to support a trial of the functionality or A/B testing. This allows cascading to operate uniquely in each market with the most relevant acquirers, rather than a "general" global ruleset.
Setup Per Key Market/ Organisation
Merchants will have a Preferred Acquirer (Eg. ACQ 1_EU) that operates as the default for all payment authorisation requests. Authorised transactions (eg. Accepted Transactions) to the default acquirer would not be subject to the cascading process. Alongside the Default Acquirer Merchants will have one or more back-up acquirers in order to utilise their services for the cascading of transactions (Eg ACQ 2_EU, & ACQ3_EU).
If the Default Acquirer returns a declined transaction status with one of the Merchant defined "cascadable" decline codes i.e. Do Not Honour. Then a second payment authorisation request would automatically be sent to the back-up acquirer that is the second preference. Where the secondary acquirer returns declined transaction also, a third or fourth preference acquirer could be sent the payment authorisation request. NB, sending the same card details more than 3 or 4 times can cause the issuer of the card to block Merchant transactions as they are being considered potential fraudulent transaction attempts.
If one of the back-up acquirers returns an authorised transaction status the transaction would be returned to the merchant with the authorised status along with a flag that indicates that the transaction had been cascaded and with detail around who the processor of the transaction was. It is important to track which transactions have been cascaded to improve the initial routing activity.
What declines codes could be cascaded?
There is a number of decline codes that should not be re-attempted either because they will never be successful (i.e. Insufficient Funds) or because it would be bad practise or unwise to do so (i.e. Expired card). That being said there are a number of very common decline codes that would be likely to offer an increased acceptance rate if attempted elsewhere. Transaction statuses where this could apply are outlined below:
5 - Do not honor (by far the most applicable to Cascading)
6 - General error
12 - Invalid transaction
15 - No such issuer
20 - Invalid response
22 - Suspected malfunction
30 - Format error
57 - Transaction not permitted to cardholder
58 - Transaction not allowed at terminal
Launching cascading with this approach, and across the decline codes listed above, a 1% to 3% increase in acceptance for enterprise Merchants can be achieved in their key sales territories.
Appendix