---
title: "Penalty box"
description: "Increased reliability when accepting local payment methods."
url: "https://docs.adyen.com/point-of-sale/error-scenarios/penalty-box"
source_url: "https://docs.adyen.com/point-of-sale/error-scenarios/penalty-box.md"
canonical: "https://docs.adyen.com/point-of-sale/error-scenarios/penalty-box"
last_modified: "2022-12-26T10:53:00+01:00"
language: "en"
---

# Penalty box

Increased reliability when accepting local payment methods.

[View source](/point-of-sale/error-scenarios/penalty-box.md)

Some cards allow transactions to be [routed through different payment networks](/point-of-sale/aid-selection-rules). These can be co-badged cards, combo cards, or US debit cards. 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](/point-of-sale/aid-selection-rules#least-cost-routing) rules use the application by default, this can lead to declined payments.

When a payment network connection is unavailable, [we put an application in our platform's **penalty box**](#preventing-declined-payments) to prevent unnecessary declined payments.

## Requirements

| Requirement                                     | Description                                                                                                                                          |
| ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Integration type**                            | A [Terminal API integration](/point-of-sale/basic-tapi-integration/) with payment terminals or with a [Mobile solution](/point-of-sale/ipp-mobile/). |
| **[Webhooks](/development-resources/webhooks)** | Subscribe to [standard webhooks](/development-resources/webhooks) to check that you receive an AUTHORISATION webhook when [testing](#testing).       |

## 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 authorization 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](/point-of-sale/offline-payment). 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 authorize 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 do not remain in the terminal's penalty box any longer than needed.

## Testing

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 own penalty box for four hours. During this time, the test terminal will skip the application that is in its penalty box.

Proceed as follows:

1. [Make a payment](/point-of-sale/basic-tapi-integration/make-a-payment) using your test terminal and Adyen test card for an amount ending in **158**.\
   For example:

   **Test payment for an amount ending in 158**

   ```json
   {
       "SaleToPOIRequest": {
           "MessageHeader": {
               "ProtocolVersion": "3.0",
               "MessageClass": "Service",
               "MessageCategory": "Payment",
               "MessageType": "Request",
               "SaleID": "POSSystemID12345",
               "ServiceID": "678",
               "POIID": "V400m-324688179"
           },
           "PaymentRequest": {
               "SaleData": {
                   "SaleTransactionID": {
                       "TransactionID": "27908",
                       "TimeStamp": "2021-09-30T12:36:47.097Z"
                   }
               },
               "PaymentTransaction": {
                   "AmountsReq": {
                       "Currency": "EUR",
                       "RequestedAmount": 41.58
                   }
               }
           }
       }
   }
   ```

2. Insert the test card into the terminal and select one of the applications.\
   The terminal will show the payment is declined.

3. Check the payment response. To indicate the declined payment is related to a penalty-boxed application, the `Response` contains:

   * `Result`: **Failure**
   * `AdditionalResponse.refusalReason`: **235 AID banned**
   * `AdditionalResponse.message`: **ERROR**
   * `ErrorCondition`: **Refusal**

   You can use the `ErrorCondition` to code your POS app. The `refusalReason` and `Message` fields are included for additional insight, and should not be coded against.

   **Response 235 AID banned**

   ```json
   {
       "SaleToPOIResponse": {
           "MessageHeader": {...},
           "PaymentResponse": {
               "POIData": {
                   "POIReconciliationID": "1000",
                   "POITransactionID": {
                       "TimeStamp": "2021-09-30T12:36:51.000Z",
                       "TransactionID": "CWf3001633005411001"
                   }
               },
               "PaymentReceipt": [...],
               "PaymentResult": {...},
               "Response": {
                   "AdditionalResponse": "...&refusalReason=235%20AID%20banned...&message=ERROR...&posAuthAmountValue=4158",
                   "ErrorCondition": "Refusal",
                   "Result": "Failure"
               },
               "SaleData": {
                   "SaleTransactionID": {
                       "TimeStamp": "2021-09-30T12:36:47.097Z",
                       "TransactionID": "678"
                   }
               }
           }
       }
   }
   ```

4. In your Customer Area, check that the transaction appears with an acquirer response of **Current AID is in Penalty Box. (BAN\_CURRENT\_AID)**.

5. If you have set up platform [standard webhooks](/development-resources/webhooks), check that you receive an AUTHORISATION webhook with:

   * `success`: **false**
   * `reason`: **Application banned**

6. Make another payment for a different amount that doesn't end in 158 or any of the other special amounts for [simulating declined payments](/point-of-sale/testing-pos-payments/test-card-v2#testing-declines), and insert the test card in your test terminal.\
   The application you selected previously is not available now. This will last for four hours.

## See also

* [Card application selection](/point-of-sale/aid-selection-rules)
* [Offline payments](/point-of-sale/offline-payment)
