Make an offline payment

To process a transaction, your host-to-host integration needs to have internet access. When there is a temporary loss of internet connectivity, you can continue doing business by making offline payments.

With offline payments, your POS system approves a transaction without any verification, and you store the transaction for later processing. When the internet connection is back, you send the transaction to a dedicated Adyen endpoint. This type of offline payments is called Store and Forward (SAF).

SAF is 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, magnetic stripe transactions, or cashbacks.

It is possible to use Adyen's Auto Rescue to automatically retry failed store-and-forward payments to increase authorization rates.

Contact our Support Team to learn whether Store and Forward is supported for a specific local card scheme.

How it works

1. You read the card details using your terminal.
2. Your terminal fails to connect to the network and is is unable to send us an API request to authorize the payment.
3. If configured to process SAF payments, your terminal approves the transaction and saves the card data and the details of the transaction.
4. The shopper leaves with the goods.
5. When your terminal is online again, it sends the stored payment message to the pos/v#/offlinePayments endpoint.
6. You receive a response to confirm that we have received your offline payment request. The response does not represent the transaction. There is no completion request, because the payment was processed asynchronously.
7. We send an authorization to the issuer to verify the transaction.
8. You receive a webhook to learn if the issuer has approved or declined the authorization.

Risk with offline payments

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

Configure Store and Forward offline payments

To set up Store and Forward offline payments, configure your terminals to:

• Authorize and store transactions when there is no internet connectivity.
• Send stored payments to pos/v#/offlinePayments when internet connectivity is restored.
• Exclude payment schemes that do not support offline payments.
• We recommend setting 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.

Make a Store and Forward offline payment

1. Make a POST /hosttohostpaymentgateway/v#/offlinePayments request, if the terminal has no online connectivity. The request must include the following required parameters:

   We recommend to always specify a reference in the body of the request to uniquely identify the offline payment. You can find your reference in the offline payment webhook, and also in your Customer Area.

   Field	Required	Type	Description
   amount		object	An object with amount information consisting of: currency (string): the three-character ISO currency code for the transaction. value (integer): the final amount of the transaction, in minor units (without a decimal point). For Quick Chip, where the customer inserts their card and removes it before the final amount is known, use emvData.tag9f02 to provide an initial amount in addition to the final amount.value.
   merchantAccount		string	The merchant account identifier that you want to process the transaction with.
   posEntryMode		string	A two-character code indicating how the card data was obtained. Consists of the first two characters of field 22 from the ISO 8583:2023 specification. For example, 05 represents ICC (chip card).
   terminalAdditionalCapabilities		string	A 5-byte hex-encoded value representing additional capabilities of the terminal, in accordance with Annex A3 of EMV Book 4.
   reference		string	Your unique reference for the transaction.
   terminalCapabilities		string	A 3-byte hex-encoded value representing terminal capabilities, in accordance with Annex A2 of EMV Book 4.
   terminalCountryCode		string	The country code of the terminal's location. Format: the two-letter ISO-3166-1 alpha-2 country code. Exception: QZ (Kosovo).
   terminalIdentification		string	Unique location of a terminal at a merchant. Equivalent to EMV tag 9F1C. Length: 16 characters.
   terminalType		string	Indicates the environment of the terminal, its communications capabilities, and its operational control. Equivalent to EMV tag 9F35.
   transactionSequenceCounter		integer	Counter maintained by the terminal that is incremented by one for each transaction. Equivalent to EMV tag 9F41.
   cvmResults		string	Results of the Cardholder Verification Method performed, provided as a 3-byte hex-encoded value in accordance with Annex A4 of EMV Book 4. Corresponds to tag 9f34.
   emvData		object	EMV chip data provided as tag values.
   captureDelay		string	Possible values are: manual, immediate, or a whole number that indicates the delay in hours between completing the authorization and capturing the payment. For more information, see Capture methods. If not specified, the capture setting of your merchant account applies.

   EMV data tags

   The emvData object can contain the following EMV data tags.

   Field	Required	Type	Description
   tag4f		string	Application Identifier. Use this tag if tag9f06 is not present.
   tag50		string	Application Label
   tag57		string	Track 2 Equivalent Data
   tag5a		string	Application Primary Account Number
   tag5f20		string	Cardholder Name
   tag5f24		string	Application Expiration Date
   tag5f28		string	Issuer Country Code
   tag5f30		string	Service Code
   tag5f34		string	Application PAN Sequence Number
   tag82		string	Application Interchange Profile
   tag84		string	Dedicated File (DF) Name
   tag8e		string	Cardholder Verification Method List
   tag95		string	Terminal Verification Results
   tag9a		string	Transaction Date
   tag9b		string	Transaction Status Information
   tag9f02		string	Amount Authorised. Optional. Use this tag to provide an initial placeholder amount for use cases like Quick Chip where the final amount.value can be different from this initial amount.
   tag9f06		string	Application Identifier
   tag9f07		string	Application Usage Control
   tag9f08		string	Application Version Number
   tag9f09		string	Terminal Application Version Number
   tag9f10		string	Issuer Application Data
   tag9f12		string	Application Preferred Name
   tag9f1e		string	Interface Device Serial Number
   tag9f21		string	Transaction Time
   tag9f24		string	Payment Account Reference
   tag9f26		string	Application Request Cryptogram
   tag9f27		string	Cryptogram Information Data
   tag9f36		string	Application Transaction Counter
   tag9f37		string	Unpredictable Number
   tag9f53		string	Transaction Category Code
   tag9f6e		string	Form Factor Indicator
   tag9f7c		string	Customer Exclusive Data

   Depending on your use case and the transaction type, add more parameters as needed.

2. When you receive the authorization response, note that the resultCode is Received. This only means, that we have received the request. The issuer has not yet approved or declined the authorization. Also save your unique reference for reconciliation or for your particular business model.
   The response contains:

   Field	Description
   pspReference	Our unique identifier for the request. In the response of an offline payment this value does not represent that transaction's PSPReference.
   reference	Your unique reference for the transaction, echoed from the request. Save this value for a possible refund or to look up the transaction in your Customer Area.
   resultCode	The state of the transaction. In an offline payment response this value is set to Received. The resultCode does not represent the final outcome of the transaction.

   The response for an offline payment does not contain the transaction's PSP reference, because the payment is processed asynchronously after the customer has left with the goods. That means that the PSP reference from the /offlinePayments response cannot be used to refund an offline payment. Instead use the PSP reference that you receive in the webhook after the transaction is authorized.

3. Check the webhook to learn the outcome of the payment.

Retry failed store-and-forward authorizations

A store-and-forward authorization can fail for reasons such as insufficient funds. It is possible that the authorization will succeed when submitted again at a later point in time. With Adyen's Auto Rescue, failed store-and-forward payments that are eligible will be automatically retried for one calendar month. Payments that were flagged as fraud are not eligible.

To use Auto Rescue:

1. Ask our Support Team to enable Auto Rescue.
   If you want to see all payments initiated by Auto Rescue, also ask them to add the Payment Requester Type column to your Received payment details report.

2. Subscribe to webhook events to be informed when a retry attempt is successful or unsuccessful and when the retry period ends.

3. Recognize retry attempts:

   • Retry attempts have a unique pspReference, but have the same tenderReference as the original transaction.
   • The merchantOrderReference of the retry attempt is the pspReference of the original transaction.

Refund an offline payment

To refund an offline payment:

1. Get the PSP reference for the offline payment from the webhook that you receive after the payment is processed asynchronously.
2. Make a referenced refund using the PSP reference from the webhook.

Test offline payments

To test a Store and Forward offline payment, proceed as follows.

1. Make sure offline payments are configured.
2. Make a payment request to your terminal and force an internet connection failure.
3. Send a host-to-host payment request.
4. Re-enable the internet connection.
5. Make a host-to-host offline payment request.
6. Verify that you are handling the offline payment response correctly.

7. Verify the result:

   • View the details of the test payment in your test Customer Area under Transactions > Payments.
   • View the webhook received for the test payment.

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

See also