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


ISO8583-1987 - Extended Decline Codes


Code

Meaning

0

Successful approval/completion or that VIP PIN verification is valid

1

Refer to card issuer

2

Refer to card issuer, special condition

3

Invalid merchant or service provider

4

Pickup

5

Do not honor

6

General error

7

Pickup card, special condition (other than lost/stolen card)

8

Honor with identification

9

Request in progress

10

Partial approval

11

VIP approval

12

Invalid transaction

13

Invalid amount (currency conversion field overflow) or amount exceeds maximum for card program

14

Invalid account number (no such number)

15

No such issuer

16

Insufficient funds

17

Customer cancellation

19

Re-enter transaction

20

Invalid response

21

No action taken (unable to back out prior transaction)

22

Suspected Malfunction

25

Unable to locate record in file, or account number is missing from the inquiry

28

File is temporarily unavailable

30

Format error

41

Merchant should retain card (card reported lost)

43

Merchant should retain card (card reported stolen)

51

Insufficient funds

52

No checking account

53

No savings account

54

Expired card

55

Incorrect PIN

57

Transaction not permitted to cardholder

58

Transaction not allowed at terminal

59

Suspected fraud

61

Activity amount limit exceeded

62

Restricted card (for example, in country exclusion table)

63

Security violation

65

Activity count limit exceeded

68

Response received too late

75

Allowable number of PIN-entry tries exceeded

76

Unable to locate previous message (no match on retrieval reference number)

77

Previous message located for a repeat or reversal, but repeat or reversal data are inconsistent with original message

78

’Blocked, first used’—The transaction is from a new cardholder, and the card has not been properly unblocked.

80

Visa transactions: credit issuer unavailable. Private label and check acceptance: Invalid date

81

PIN cryptographic error found (error found by VIC security module during PIN decryption)

82

Negative CAM, dCVV, iCVV, or CVV results

83

Unable to verify PIN

85

No reason to decline a request for account number verification, address verification, CVV2 verification; or a credit voucher or merchandise return

91

Issuer unavailable or switch inoperative (STIP not applicable or available for this transaction)

92

Destination cannot be found for routing

93

Transaction cannot be completed, violation of law

94

Duplicate transmission

95

Reconcile error

96

System malfunction, System malfunction or certain field error conditions

B1

Surcharge amount not permitted on Visa cards (U.S. acquirers only)

N0

Force STIP

N3

Cash service not available

N4

Cashback request exceeds issuer limit

N7

Decline for CVV2 failure

P2

Invalid biller information

P5

PIN change/unblock request declined

P6

Unsafe PIN

Q1

Card authentication failed

R0

Stop payment order

R1

Revocation of authorization order

R3

Revocation of all authorizations order

XA

Forward to issuer

XD

Forward to issuer

Z3

Unable to go online