Autonomous stores

Autonomous stores are stores without staff or checkout. A shopper presents their card to the payment terminal before entering the store, to pre-authorize a certain amount and gain entry. The shopper then takes some items and leaves the store. The purchase amount is adjusted and charged to the card that the shopper used to enter the store.

Requirements

Before you begin, take into account the following requirements, limitations, and preparations.

How it works:

1. You make a card acquisition request on the terminal to get the card details.
2. The shopper presents their card to the payment terminal.
3. You use identifiers from the card acquisition response to check if you recognize the shopper. If it is a first-time shopper, you collect their details like phone number or email. You can use card identifiers to tokenize the card for future recurring payments.
4. You send a payment request to pre-authorize an amount.
   We recommend that you also tokenize the card for future recurring payments. This enables you to recover the full payment in case an authorization adjustment fails.
5. The shopper enters the store, takes items, and leaves the store.
6. If the purchase amount is different from the pre-authorized amount, you send an authorization adjustment request, followed by a capture request.
7. If the authorization adjustment fails for any reason, you can capture the pre-authorized amount. After that:
   • If you tokenized the card, you can make a recurring online payment for the remaining amount.
   • If you collected the shopper's email or phone number, you can send them a payment link for the remaining amount.

If you cannot charge the shopper for their purchase, you can put the card alias on the not-allowed list in your system to prevent the card from being used to enter the store again.

Note that in the autonomous store flow, you need to rely on webhooks to know if the capture succeeded. If you use asynchronous authorization adjustment, you also need to rely on webhooks for the authorization adjustment result.

Also note that you need to implement logic on your end, for example how to trigger card acquisition requests on the terminal, open the doors, or calculate the amount when you make an authorization adjustment.

1. Get the card details

In your back-end, implement a trigger for the card acquisition request on the terminal to prompt the shopper to present a card. From the response, you can take certain details such as the card alias to determine if the shopper should be let in.

1. Create a SaleToPOIData JSON object with:

   • Operation.Type: Payment
   • Operation.Variant: PreAuthToEnterShop. Hides the pre-authorization amount specified in CardAcquisitionTransaction.TotalAmount from showing on the initial screen. This is to prevent shoppers from thinking they need to pay to enter the store.

2. Encode the Operation JSON object to Base64. You will pass the resulting string in SaleData.SaleToPOIData.

3. Create a SaleToAcquirerData JSON object with:

   • authorisationType: PreAuth. Pre-authorizes the amount specified in CardAcquisitionTransaction.TotalAmount.
   • recurringProcessingModel: UnscheduledCardOnFile. Enforces cardholder authentication during pre-authorisation (if configured by our Support Team). To tokenize the card, include this field in both the card acquisition and the follow-up pre-authorization payment request.
     
     If the PSD2 SCA compliance rules apply to your business, we recommend enforcing cardholder authentication. To enable this, contact our Support Team.

4. Encode the JSON object to Base64. You will pass the resulting string in SaleData.SaleToAcquirerData.

5. Make a card acquisition request, including:

   • The CardAcquisitionRequest.SaleData object with:

     Parameter	Required	Description
     SaleTransactionID		An object with: TransactionID: your reference to identify the transaction. We recommend using a unique value. TimeStamp: date and time of the request in UTC format.
     TokenRequestedType		Customer. Returns the card alias in the TokenValue field of the response. Note that the card alias is always returned in the AdditionalResponse.
     SaleToPOIData		The Base64-encoded Operation JSON value from step 2.
     SaleToAcquirerData		The Base64-encoded JSON value from step 4.

   • The CardAcquisitionRequest.CardAcquisitionTransaction object with:

     Parameter	Required	Description
     TotalAmount		The transaction amount you want to pre-authorize before entering the store. This amount needs to be equal to the TotalAmount in the pre-authorization request.

   The following example shows a card acquisition request to get the card details.

   The following example shows a card acquisition response with an amount of EUR 10.

6. From the CardAcquisitionResponse, save the following details :

   • POIData.POITransactionID: since you are continuing with a payment, keep the TimeStamp and the TransactionID because you need these card acquisition details in your payment request.
   • Response.AdditionalResponse.alias: this is a value that uniquely represents the shopper's card number (PAN), for example A37317672402294. With this, you can recognize the card that a shopper is using and identify if they are returning customers. You cannot use the card alias for making payments.

   The format of the AdditionalResponse can be a Base64-encoded or URL-encoded. To always receive the AdditionalResponse in one of those formats, contact our Support Team.

If the shopper is entering the store for the first time, we recommend you collect their details. Otherwise, you can proceed with a pre-authorization payment request.

2. Optional: Get the shopper's details

If the shopper is entering the store for the first time, you can ask them to enter their contact details, or to provide consent to tokenize their card.

1. Ask the shopper's consent to save their details. For this, you can use confirmation or signature input requests.
2. Collect the shopper's contact details. For this you can use phone number or text input requests. You can then use these details when tokenizing the card or to send the shopper a payment link.
3. Save the shopper's contact details and the card alias received in the Response.AdditionalResponse.alias of the card acquisition response.

You can use the card alias to recognize the shopper the next time they present their card to enter the store. This way, the shopper does not have to enter their details again.

3. Pre-authorize an amount

After you collect the card and shopper details, send a payment request to pre-authorize the amount specified in the card acquisition request.

You can also tokenize the card with Adyen. This enables recurring payments with the shopper's card and allows you to recover failed payments in case the shopper has insufficient funds at the time of purchase.

1. Prepare the SaleData.SaleToAcquirerData value for the pre-authorization payment request that you will make.
   Include the following data elements:

   • authorisationType: PreAuth. This indicates this is a pre-authorization request.

   • To tokenize the card, also include:

     • shopperReference: Uour unique reference for this shopper. Minimum length: three characters. Note that the value is case-sensitive. Do not include personally identifiable information (PII), such as name or email address.
     • recurringProcessingModel: UnscheduledCardOnFile. Creates a recurring contract for transactions that occur on a non-fixed schedule and/or have variable amounts. Enforces cardholder authentication (if configured by our Support Team).
     • shopperEmail: Optional. The shopper's email address, if you collected that.

   Format the SaleData.SaleToAcquirerData value in one of the following ways (refer to Add information to a payment):

   • Option 1: A JSON object converted to a Base64-encoded string. For example:

     Encode the Operation JSON object to Base64.

   • Option 2: Form-encoded key-value pairs (using & as a separator). For example:

2. Make a pre-authorization payment request, including:

   • The PaymentRequest object with:

     Parameter	Required	Description
     SaleData.SaleTransactionID		An object with: TransactionID: your reference to identify a payment. We recommend using a unique value per payment. TimeStamp: date and time of the request in UTC format.
     PaymentTransaction.AmountsReq		An object with: Currency: the transaction currency. RequestedAmount: the pre-authorized transaction amount. This amount must be equal to the TotalAmount in the card acquisition request.
     PaymentData.CardAcquisitionReference		An object referring to the card acquisition: TimeStamp: The time stamp returned in the POIData.POITransactionID of the card acquisition response. TransactionID: the transaction ID returned in the POIData.POITransactionID of the card acquisition response.
     SaleData.SaleToAcquirerData		The Base64-encoded string or form-encoded key-value pairs you prepared.

   The following example shows how to pre-authorize a payment of EUR 10:

   The customer presents their card to the payment terminal. If the pre-authorization is successful, the terminals show the transaction is approved.

3. From the response, save the following details:

   To do this	Use these parameters
   Authorization adjustment and capture	POIData.POITransactionID.TransactionID: transaction identifier for the payment, in the format Tender_reference.PSP_reference. Response.AdditionalResponse.pspReference: the PSP reference of your pre-authorization request.
   Calculating the amount for the authorization adjustment	PaymentResult.AmountsResp: the AuthorizedAmount and Currency of the pre-authorized payment. Response.AdditionalResponse.authorisedAmountValue: the pre-authorized amount in minor units.
   Synchronous authorization adjustment	Response.AdditionalResponse.adjustAuthorisationData: a blob with authorization data, if the synchronous flow is enabled for your account.

   For easier shopper recognition and recovering failed payments, from the Response.AdditionalResponse save the following details:

   Parameter	Description
   alias	The card alias. Also returned in PaymentResult.PaymentInstrumentData.PaymentToken.TokenValue if the request contains TokenRequestedType: Customer.
   PaymentAccountReference	A value that represents the payment account that the card and/or NFC wallet is linked to.
   recurring.recurringDetailReference or tokenization.storedPaymentMethodId	The token representing the shopper's payment method.
   recurring.shopperReference or tokenization.shopperReference	Your unique reference for this shopper.
   shopperEmail	The shopper's email address .

   The following example shows the response to a EUR 10.00 pre-authorization request.

   Note that the PaymentToken object contains the card alias. You cannot use this for making payments. It is intended only for recognizing the card.

After a successful pre-authorization, you need to have logic implemented to open the door of the autonomous store. The shopper then enters the store, takes items, and leaves.

4. Adjust the pre-authorized amount

If the purchase amount for items that shopper has taken differs from the pre-authorized amount, you need to send an authorization adjustment request. This is not a Terminal API request to the terminal itself or the Cloud endpoint for the terminal.
Depending on your infrastructure and implementation, you may want to use the asynchronous or synchronous authorization adjustment.

5. Capture the amount

After you make the authorization adjustment, capture the payment manually to ensure the reserved funds are transferred to your account. Make sure that you have enabled manual capture, either for your account or for an individual transaction.

1. Make a POST /payments/{paymentPspReference}/captures request, where paymentPspReference is the pspReference of the authorization being captured. You received this as part of the transactionID field in the response to your payment request. See Transaction identifier.

   In your request, include:

   Parameter	Required	Description
   amount		The currency and value of the final amount in minor units. This is the sum of the original, pre-authorized amount and all later adjustments.
   merchantAccount		The name of your merchant account that is used to process the payment.
   reference		Your reference to this payment modification, for use in your reconciliation process.

2. In the capture response, note the following parameters:

   • pspReference: The PSP reference associated with this capture request. Note that this is different from the PSP reference associated with the pre-authorization request.
   • status: received.
   • reference: Your reference to this payment modification, for use in your reconciliation process.

3. Wait for a webhook message with the eventCode CAPTURE. This informs you whether the final amount has been captured.
   If success is false then your capture request failed. Review the reason you received in the webhook message, fix the issue, and submit the capture request again.

Recover failed payments

If the authorization adjustment fails for any reason, for example because of a technical issue or insufficient funds on the cardholder’s bank account, there are several things you can do:

• Send the capture request to collect the pre-authorized amount.
• Make a recurring online payment for the remaining amount using the token you created in the pre-authorization payment request.
• Send a payment link for the remaining amount to the shopper's email or phone number that you collected before the shopper entered the store.

You can also enable our Auto Rescue feature that automatically retries shopper-not-present card transactions when they are refused.

If all rescue attempts fail, you can put the card alias on the not-allowed list in your system to prevent the card from being used to enter the store again.

See also