Co-badged cards allow transactions to be routed through different payment networks. These cards support a local card scheme for domestic payments and a global card scheme for international payments. Some examples are:
- Australian cards with eftpos and Visa or Mastercard.
- Belgian cards with Bancontact and Maestro.
- French cards with Cartes Bancaires and Visa.
Such cards have multiple payment methods, one of them being a local payment method. In the financial industry, we say the card has multiple applications.
Sometimes there is an outage on a payment network or another problem that temporarily blocks the connection to a specific payment network. When that happens, it is impossible to make payments with an application that is routed over that network. Especially when least cost routing rules use the application by default, this can lead to declined payments.
Preventing declined payments
To prevent unnecessary declined payments when a payment network connection is unavailable, we put an application in our platform's penalty box. Until the problem is resolved, we route payments through other connections. With Adyen, the penalty box is not limited to ecommerce payments. We inform the payment terminal that an application is in the penalty box as soon as the terminal tries to get authorisation for a payment with such an application.
The terminal then puts the application in its own penalty box for the next couple of hours. During this time:
The terminal checks if it can process the transaction offline. It first tries offline EMV, then Store and Forward.
If offline processing is not possible, the terminal skips the application that is in the penalty box. Instead, it uses another application on the card.
For example, if a French card has Cartes Bancaires and Visa and the connection to Cartes Bancaires is temporarily unavailable, we route the transaction to VISA instead of declining the transaction.
If the card is single-branded, the terminal tries to authorise the transaction, in case the outage has been resolved. If that fails, the terminal tries offline processing.
If there are no other applications available and offline processing is not possible, the transaction is declined.
In the future, we will send live updates to the terminal when an application is added to or removed from the penalty box. This ensures applications don't remain in the terminal's penalty box any longer than needed.
Using the payment amount, you can simulate a scenario where an application is in the penalty box, offline processing is not possible, and there are no other applications on the card. The initial transaction is declined and the terminal puts the application in its penalty box for four hours. During this time, the test terminal will skip the application that is in the penalty box.
Proceed as follows:
Make a payment using your test terminal and Adyen test card for an amount ending in 158.
Insert the test card into the terminal and select one of the applications.
The terminal will show the payment is declined.
Check the payment response. To indicate the declined payment is related to a penalty-boxed application, the
AdditionalResponse.refusalReason: 235 AID banned
You can use the
ErrorConditionto code your POS app. The
Messagefields are included for additional insight, and should not be coded against.
In your Customer Area, check that the transaction appears with an acquirer response of Current AID is in Penalty Box. (BAN_CURRENT_AID).
If you have set up platform standard webhooks, check that you receive an AUTHORISATION webhooks with:
reason: Application banned
Make another payment for a different amount that doesn't end in 158 or any of the other special amounts for simulating declined payments, and insert the test card in your test terminal.
The application you selected previously is not available now. This will last for four hours.