Are you looking for test card numbers?

Would you like to contact support?

Point-of-sale icon

Offline transactions

Continue accepting payments when your integration is offline.

Avoid offline transactions

Consider switching to processing payments over a cellular 3G or 4G connection when the internet connection is down.

If your integration uses local communications, you can continue making in-store payments when there's a temporary loss of internet connectivity.

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

When the internet connection is down and the terminal can't route a payment request to the Adyen payments platform, this is what happens:

  1. You send a payment request from the cash register to the payment terminal.
  2. Your staff hands the terminal to the shopper to present their card and complete the payment.
  3. The terminal tries to reach the Adyen payments platform, but is unable to establish a connection.
  4. The terminal verifies whether the payment can be completed offline, by running the following checks:
    • Which types of offline payment are enabled? If none, the payment is Declined.
    • Is the card configured by the issuer to process offline payments?
    • Has the maximum number of offline transactions been reached yet?
    • Is the transaction amount within the floor limit for the type of offline payment?
    • Does the payment scheme support offline payments?
  5. If Approved, the terminal stores the card data and details of the transaction.
    The terminal also generates a transaction response including data you can use to generate a receipt.
  6. 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.

Before you begin

Before you enable offline payments, make sure that you:

Risk with offline payments

When you enable offline payments, your integration approves transactions 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 transactions. 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 transactions. These are supported by most major credit cards. Most debit cards do not support this type of payment.
    With an offline EMV payment, the payment terminal reads the card information from the EMV chip embedded in the card, and asks the card to approve the payment. Depending on the configuration provided by the issuer, the card approves or declines the payment offline. Because the card is in control, the payment can be processed in the clearing stream directly. This ensures a higher approval rate.

  • Store-and-forward transactions. These are supported by the major credit and debit card schemes for contact chip and contactless transactions. Any cardholder verification method, such as PIN and signature, can be processed.
    Store-and-forward is not supported for local card schemes, QR code wallets, and magnetic stripe transactions.

    Because the terminal approves store-and-forward transactions without any verification, the risk of payments being declined by the issuer is higher than for offline EMV transactions. Typically up to 10% of store-and-forward payments is declined.

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

Enabling offline payments

To enable offline payments, you need to configure floor limits for each type of offline transaction you want to use.

Contact our POS Support Team and give them the following information:

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

    • Chip floor limit: The maximum value of an offline EMV transaction where the shopper inserts their card into the reader. Contact chip transactions above this amount will be declined. If you don't enable store-and-forward transactions, contactless transactions are also declined.

  • To enable store-and-forward transactions:

    • Floor limit: The maximum value of a store-and-forward transaction 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 transactions that normally require a PIN as CVM.

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

Handling an offline payment response

Compared to the response for an online transaction, the Terminal API response you receive for an offline transaction is a bit different:

  • The transaction identifier in the offline payment response includes a tender reference, but not a PSP reference.
    This is because the PSP reference is generated by the Adyen payments platform, so will not be generated when your integration is offline and unable to connect to Adyen.

  • The AdditionalResponse misses some data.
    Some additional data is generated when Adyen processes the payment, and is therefore not included for an offline payment. For example, the payment method variant (type of card) is not included. If you're using this data in your business logic, expect it to be missing for offline payments.
    Other differences in the AdditionalResponse are that it has the offline flag set to true, and that it contains the offline authorisation code Y1 for approved offline transactions.

These differences are important because:

  • They have consequences for refunding and reconciling offline payments.
  • You need to make sure your cash register is able to handle responses that do not include a PSP reference.

Refunding an offline payment

To refund an online payment you'd do a ReversalRequest using the full transaction identifier in the format tenderReference.pspReference to identify the original payment you want to reverse. This is what we call a 'referenced refund'.

With an offline payment you can't do that because you don't have the PSP reference in the payment response. So to refund an offline payment, you need to do 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 original payment, you should specify the tender reference of the original payment here.
    In your Customer Area and Adyen reports, this ID will show as the merchant reference for the transaction.

Reconciling 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. We will then send you notifications for the stored payments when your integration is online again, and these notifications do include the PSP reference.
As an alternative, you can use the tender reference, which is generated by the cash register, to reconcile your payments.

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.

Testing 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:

    • View the details of the test payment in your test Customer Area under Transactions > Payments.
    • View the notification received for the test payment (if you set up webhook notifications).
    • View the Received payment details report.

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

See also