Search

Are you looking for test card numbers?

Would you like to contact support?

Point-of-sale icon

Offline payments

Continue accepting payments when your integration is offline.

3G/4G alternative

To avoid offline payments, you can process payments over a cellular 3G or 4G connection when the internet is down.

To process a transaction, the payment terminal needs to have internet access. When there's a temporary loss of internet connectivity, you can continue making in-store payments by enabling offline payments. This is possible either:

Offline payments are not possible if your integration uses cloud communications.

How it works

  1. You initiate a payment like you usually do.
  2. When the shopper completes the payment, the terminal tries to reach the Adyen payments platform, but is unable to establish a connection.
  3. The terminal verifies whether the payment can be completed offline, by running the following checks:
    • Are one or more types of offline payment enabled? If no, the payment is Declined.
    • Is the card configured by the issuer to process offline payments?
    • Has the payment terminal reached its maximum number of store-and-forward offline payments yet?
    • Is the transaction amount within the floor limit for the type of offline payment?
    • Does the payment scheme support offline payments?
  4. If Approved, the terminal stores the card data and details of the transaction.
    • If you are using a standalone terminal, it will print the receipt.
    • In a local integration, the terminal generates a transaction response including data you can use to generate a receipt.
  5. Later, when the terminal is able to connect to the internet again, it sends the stored payments to the Adyen payments platform for further processing.

Risk with offline payments

When you enable offline payments, your integration approves payments before the money is received from the shopper's account. That means it's possible that you will not receive the money for the goods that are taken by the shopper. There's also a higher risk that card fraud goes undetected.

You are fully liable for the risk of failed captures, chargebacks, and disputes related to payments that you process offline.

To reduce your exposure to these risks, you need to set a transaction floor limit before your integration can make offline payments. This is a maximum per-transaction amount that your terminals can approve while they are offline.

Types of offline payment

There are two types of payment that you can do while your integration is offline. Each varies by card type, region, and the risk of the payment being declined by the issuer when it is processed:

  • Offline EMV payments: The payment terminal verifies that the PIN entered by the shopper matches the PIN on the EMV chip embedded in the card, and then asks the card to approve the payment. Whether the transaction is approved, depends on how the issuer configured the card. Because the card is in control, the payment can be processed in the clearing stream directly. This ensures a higher approval rate.
    Offline EMV transactions are supported by most major credit card schemes. Most debit cards do not support this type of payment.

  • Store-and-forward payments: The payment terminal approves payments without any verification. Because of this, the risk of payments being declined by the issuer is higher than for offline EMV transactions. In practice the authorisation rates range from 95% in some industries to several percentage points higher.

    Store-and-forward payments are supported for contact chip and contactless transactions by the major credit and debit card schemes and also by some local card schemes. Any Cardholder Verification Method (CVM), such as PIN and signature, can be processed.
    Store-and-forward is not supported for most local card schemes, QR code wallets, and magnetic stripe transactions.
    Contact our POS Support Team to learn whether store-and-forward is supported for a specific local card scheme.

If you enable both types of offline payment, the terminal will try offline EMV first, then store-and-forward.

Enable offline payments

To enable offline payments, you need to contact our POS Support Team and give them the following information:

  • Type of offline payments you want to enable: offline EMV and/or store-and-forward.
  • Transaction limit: The maximum number of store-and-forward transactions per terminal that you can process while the terminal is offline.
  • Card types: Normally your offline settings apply to all credit and debit cards in your account. If you want to exclude some of them, inform our POS Support Team.
  • To enable offline EMV payments:

    • Chip floor limit: The maximum value of an offline EMV transaction where the shopper inserts their card into the reader.
      Transactions above this amount will be declined.

  • To enable store-and-forward payments:

    • Floor limit: The maximum value of a store-and-forward payment that can be approved while your integration is offline. Transactions above this amount will be declined.
    • Whether you also want to enable store-and-forward for payments that normally require a PIN as CVM.

Our POS Support team will contact you when offline payments have been enabled for your integration. You may need to do some extra configuration to reconcile payments that are made offline.

Recognize the offline payment response

Compared to an online payment response, the Terminal API response for an offline payment differs in some respects. Data that is generated by the Adyen payments platform, such as the PSP reference, is missing because your integration is unable to connect to Adyen. Authorisation data is missing as well, because the issuer hasn't authorised the payment yet. The response also includes some values to indicate the payment took place offline.

These differences are important because:

  • They have consequences for refunding and reconciling offline payments.
  • If your cash register normally uses the PSP reference, you need to make sure it is also able to handle responses that do not include a PSP reference.

Offline payment response details

The PaymentResponse for an offline transaction has the following characteristics:

  • POIData.POITransactionID.Transaction.ID: Misses the PSP reference. Only contains the tender reference.
  • PaymentResult.AuthenticationMethod: OfflinePIN
  • PaymentResult.OnlineFlag: false
  • PaymentResult.PaymentAcquirerData: Misses the AcquirerTransactionID and ApprovalCode parameters.
  • Response.AdditionalResponse includes:

    • offline: true
    • offlineAuthCode: Indicates the type of offline payment.

      • Offline approved indicates an offline EMV payment.
      • Failed go online offline declined indicates a store-and-forward transaction.

    • unconfirmedBatchCount: The number of payments that the terminal hasn't been able to send to the Adyen payments platform.
  • There are also fields missing from the Response.AdditionalResponse. The most important missing data are:
    • Authorisation data: authCode, authorisationMID, authorisedAmountCurrency, authorisedAmountValue, refusalReasonRaw
    • PSP reference: pspReference, transactionReferenceNumber

Below is an example of an offline EMV or store-and-forward payment response.

Offline EMV or store-and-forward payment response
{
    "SaleToPOIResponse": {
        "MessageHeader": {...},
        "PaymentResponse": {
            "POIData": {
                "POIReconciliationID": "1000",
                "POITransactionID": {
                    "TimeStamp": "2020-12-14T10:27:07.000Z",
                    "TransactionID": " {hint:only a tender reference, no PSP reference}57Ra001607941627000"{/hint}
                }
            },
            "PaymentReceipt": [...],
            "PaymentResult": {
                "AmountsResp": {...},
                "{hint:extra parameter}AuthenticationMethod"{/hint}: [
                    "OfflinePIN"
                ],
                "CustomerLanguage": "fr",
                "OnlineFlag": {hint:failed to go online}false{/hint},
                "{hint:misses AcquirerTransactionID and ApprovalCode parameters}PaymentAcquirerData"{/hint}: {
                    "AcquirerPOIID": "P400Plus-123456789",
                    "MerchantID": "YOUR_MERCHANT_ACCOUNT"
                },
                "PaymentInstrumentData": {...}
            },
            "Response": {
                "{hint:several different or missing fields}AdditionalResponse": "..."{/hint},
                "Result": "Success"
            },
            "SaleData": {...}
            }
        }
    }
}

The next example shows the AdditionalResponse (converted to JSON format) for an offline EMV payment.

Offline EMV AdditionalResponse
{
    ...
    "offline": "{hint:failed to go online}true"{/hint},
    "offlineAuthCode": "{hint:indicates this is an offline EMV transaction}Offline approved"{/hint},
    ...
    "{hint:number of offline transactions stored on the terminal}unconfirmedBatchCount": "3"{/hint}
}

The next example shows the AdditionalResponse (converted to JSON format) for a store-and-forward payment.

Store-and-forward AdditionalResponse
{
    ...
    "offline": "{hint:failed to go online}true"{/hint},
    "offlineAuthCode": "{hint:indicates this is a store-and-forward transaction}Failed go online offline declined"{/hint},
    ...
    "{hint:number of offline transactions stored on the terminal}unconfirmedBatchCount": "3"{/hint}
}

Refunding an offline payment

To refund an offline payment, we need the PSP reference of the offline payment. You'd specify this in your ReversalRequest, preferably in the format tenderReference.pspReference. But because you don't receive the PSP reference in the offline payment response use one of these options:

  • Make a referenced refund (a ReversalRequest) specifying the tenderReference of the offline payment and the POIID of the payment terminal that was used for the offline payment.
    In case of a refund for the full amount using the same payment terminal that was used for the offline payment, you can omit the POIID.

  • Find the PSP reference for the offline payment in your Customer Area or in the notification webhook (if you set that up). Then make a referenced refund specifying the PSP reference.

  • Make an unreferenced refund. This is a PaymentRequest with:

    • PaymentData.PaymentType: Refund
    • SaleData.SaleTransactionID.TransactionID: Your unique reference for the refund. To be able to reconcile the refund with the offline payment, include the tender reference of the original payment in your transaction ID. In your Customer Area and Adyen reports, this ID will show as the merchant reference for the transaction.

Making refunds while offline

While your integration is offline, it is possible to issue a refund. The payment terminal will try to process this as an offline EMV transaction. Whether the transaction is approved, depends on how the issuer configured the card.

To allow making refunds while offline, contact our POS Support Team to set an Offline refund maximum amount.

Reconcile offline payments

Because the PSP reference is generated by the Adyen payments platform, the Terminal API response for an offline transaction does not have a PSP reference.
If you are using the PSP reference for reconciliation, we recommend you set up notification webhooks. When your integration is online again, you will receive notifications for the stored payments, and these notifications do include the PSP reference.
As an alternative, you can use the tender reference, which is generated by the terminal, to reconcile your payments.
Also note that you can add the POS Store and Forward indicator column to your Received payment detail report.

Because offline payments can be declined by the issuer, your financial operations specialist needs to set up a method of handling this type of declines. This would mean the goods are provided to the shopper and the money is not received for this type of payment. This is the inherent risk of processing store-and-forward transactions.

Test offline payments

To test an offline payment, proceed as follows.

  1. Make sure offline payments are enabled.
  2. Send a payment request to your test terminal and force an internet connection failure.
    The most convenient way to force an internet connection failure depends on your network setup. For example, you could unplug the Ethernet cable from a switch. Or if you're using the P400 plus, you could unplug the Ethernet cable from the payment terminal.
  3. Complete the offline payment using your test card. The test card enforces the configured offline limits.
  4. Verify that you are handling the offline payment response correctly.
  5. Re-enable the internet connection.
  6. Verify the result:

    This information should help your financial operations specialist to adapt your financial system to offline payments.

See also