- Merchant PAL webservice role<\/strong><\/li>
- Checkout webservice role<\/strong><\/li><\/ul>
If you have a Terminal API integration with cloud-based communications<\/a>, you can use the existing API key that you use for Terminal API requests.<\/td>\n<\/tr>\n\n Webhooks<\/a><\/strong><\/td>\n Listen for Standard webhook messages<\/a> with the following eventCode<\/code> values:- AUTHORISATION_ADJUSTMENT<\/strong><\/span><\/li>
- CAPTURE<\/strong><\/span><\/li>
- CAPTURE_FAILED<\/strong><\/span><\/li><\/ul><\/td>\n<\/tr>\n
\n Hardware<\/strong><\/td>\n Use a payment terminal model that is suitable for unattended use, like the P400 Plus<\/strong><\/span>, S1U2<\/strong><\/span>, or UX300<\/strong><\/span>.<\/td>\n<\/tr>\n \n Limitations<\/strong><\/td>\n Be aware of the following: - Support for authorization adjustment<\/a> is limited to specific payment methods and Merchant Category Codes (MCC). It is ultimately up to the issuing bank whether they allow it.<\/li>
- Pre-authorizations and authorizations eventually expire<\/a>. The length of an authorization's validity depends on the card scheme.<\/li><\/ul><\/td>\n<\/tr>\n
\n Setup steps<\/strong><\/td>\n Before you begin: - Contact our Support Team<\/a> to configure your payment methods. If you plan to use synchronous authorization adjustment, also ask them to enable this for you.<\/li>
- If you plan to use tokenization, enable receiving shopper identifiers<\/a> and check with our Support Team<\/a> if your account is correctly configured for your tokenization use case.<\/li>
- Enable manual capture<\/a>, either for your account or for individual transactions.<\/li><\/ul><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
How it works:<\/h2>\n
- \n
- You make a card acquisition request on the terminal to get the card details<\/a>.<\/li>\n
- The shopper presents their card to the payment terminal.<\/li>\n
- 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.<\/li>\n
- You send a payment request to pre-authorize an amount<\/a>.
\nWe 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.<\/li>\n- The shopper enters the store, takes items, and leaves the store.<\/li>\n
- If the purchase amount is different from the pre-authorized amount, you send an authorization adjustment request<\/a>, followed by a capture request<\/a>.<\/li>\n
- If the authorization adjustment fails for any reason, you can capture the pre-authorized amount. After that:\n
- \n
- If you tokenized the card, you can make a recurring online payment for the remaining amount.<\/li>\n
- If you collected the shopper's email or phone number, you can send them a payment link for the remaining amount.<\/li>\n<\/ul><\/li>\n<\/ol>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
1. Get the card details<\/h2>\n
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.<\/p>\n
- \n
- \n
Create a
SaleToPOIData<\/code> JSON object with:<\/p>\n- \n
Operation.Type<\/code>: Payment<\/strong><\/span><\/li>\nOperation.Variant<\/code>: PreAuthToEnterShop<\/strong><\/span>. Hides the pre-authorization amount specified inCardAcquisitionTransaction.TotalAmount<\/code> from showing on the initial screen. This is to prevent shoppers from thinking they need to pay to enter the store.<\/li>\n<\/ul>\n\n<\/code-sample>\n<\/div>\n<\/li>\n - \n
Encode the
Operation<\/code> JSON object to Base64. You will pass the resulting string inSaleData.SaleToPOIData<\/code>.<\/p>\n\n<\/code-sample>\n<\/div>\n<\/li>\n - \n
Create a
SaleToAcquirerData<\/code> JSON object with:<\/p>\n- \n
authorisationType<\/code>: PreAuth<\/strong><\/span>. Pre-authorizes the amount specified inCardAcquisitionTransaction.TotalAmount<\/code>.<\/li>\nrecurringProcessingModel<\/code>: UnscheduledCardOnFile<\/strong><\/span>. Enforces cardholder authentication during pre-authorisation (if configured by our Support Team<\/a>). To tokenize the card, include this field in both the card acquisition and the follow-up pre-authorization payment request.
\nIf the PSD2 SCA compliance rules<\/a> apply to your business, we recommend enforcing cardholder authentication. To enable this, contact our Support Team<\/a>.<\/div><\/div><\/li>\n<\/ul>\n\n<\/code-sample>\n<\/div>\n<\/li>\n - \n
Encode the JSON object to Base64. You will pass the resulting string in
SaleData.SaleToAcquirerData<\/code>.<\/p>\n\n<\/code-sample>\n<\/div>\n<\/li>\n - \n
Make a card acquisition request<\/a>, including:<\/p>\n
- \n
- \n
The CardAcquisitionRequest.SaleData<\/a> object with:<\/p>\n
- \n
- If you plan to use tokenization, enable receiving shopper identifiers<\/a> and check with our Support Team<\/a> if your account is correctly configured for your tokenization use case.<\/li>
- Pre-authorizations and authorizations eventually expire<\/a>. The length of an authorization's validity depends on the card scheme.<\/li><\/ul><\/td>\n<\/tr>\n
- CAPTURE<\/strong><\/span><\/li>
- Checkout webservice role<\/strong><\/li><\/ul>
![\"-white_check_mark-\"](\"\/user\/data\/smileys\/emoji\/white_check_mark.png\" "\\"-white_check_mark-\\"")
<\/td>\n