Shopper journey<\/h2>\n
From the shopper's perspective, this Endless Aisle retail use case is as follows.<\/p>\n
In the store, it turns out that items that the shopper wants to purchase are not available at the location. Store staff helps the shopper to order the items online. If desired, the shopper can combine the order with purchasing items from the store that do not need to be ordered.<\/p>\n
The shopper presents their card on the payment terminal, and confirms or provides the delivery address. When the order is shipped, the payment is captured and the shopper receives the ordered goods.<\/p>\n
The following diagram illustrates this shopper journey.<\/p>\n
Considerations<\/h2>\n
Before you set up a flow for this use case, there are a couple of points that you must be aware of or make a decision on.<\/p>\n
Legal entity and location<\/h3>\n
In this use case, you use the payment terminal to authorize the online order.<\/p>\n
If you want to process your Endless Aisle online transactions over a different merchant account than the regular in-person transactions, ask your Ayden Account Manager or Implementation Engineer about Merchant Account Sharing<\/em>. With this, orders for both merchant accounts are processed on the same terminal, but kept separate. Enabling Merchant Account Sharing is subject to compliance approval. Terminals require a local legal entity.<\/p>\n If compliance approval is not given, you have other options to keep the transactions separate:<\/p>\n This use case requires specific procedures to capture the payment. You must enable and use manual capture, and contact our Support Team<\/a> to enable multiple partial captures.<\/p>\n For the ordered items, the amount is initially authorized, but not captured. When the items are shipped from the warehouse, you make a manual capture request. If all items are shipped together, you capture the full amount. If items are delivered in several partial shipments, you make a partial capture request for each shipment.<\/p>\n It depends on your other use cases whether it is best to enable manual capture for every payment, or in the API request for an individual payment.<\/p>\n If you want to support mixed baskets, where the shopper combines an online order with items that are available in the store, we recommend discussing your Adyen account structure and capture strategy with your Adyen implementation engineer or account manager.<\/p>\n You have the following options for capturing the payment:<\/p>\n One transaction with multiple partial captures: this option requires that online and in-store items are processed under the same merchant account. Two separate transactions: you authorize the online order and capture the amount later as ordered items are shipped. For the in-store items, you make a separate payment request and capture the amount immediately or with a capture delay.<\/p>\n<\/li>\n<\/ul>\n To get the delivery address you use a \"card acquisition\" request: the shopper presents their card or other payment instrument to the payment terminal. You then use the card alias or PAR from the response to look up the delivery address in your CRM system and add the address to the order.<\/p>\n To use card acquisition in this way, you must enable receiving shopper identifying data in API responses, and you must store the card alias and\/or PAR in the shopper's profile.<\/p>\n If the shopper wants the order to be delivered to a different address or does not have a record in your CRM system yet, the CRM must also support manual entry of shopper details and creation of a new CRM record.<\/p>\n You need to decide beforehand on how you will attribute the sale: if items are ordered in-store and the payment is captured upon shipment, is this an in-store sale or an ecommerce sale?<\/p>\n If the shopper does not want a delivered item, the item may be returned to the store or to the warehouse. Both systems must be able to look up the PSP reference for the order and issue a (partial) referenced refund. You need to support both:<\/p>\n If discounts are offered over the phone or chat, customer service agents must be able to trigger partial referenced refunds as well.<\/p>\n There are several Adyen API requests involved in the described shopper journey, as shown in the following diagrams for:<\/p>\n The next section, \"Instructions\", provides more details about the API flow.<\/p>\n We usually recommend delayed automatic capture for point-of-sale transactions. That is why the diagram shows automatic capture for the separate payment request related to the in-store items.<\/p>\n This section provides high-level instructions focusing on how to use the Adyen APIs and webhooks in the described shopper journey.<\/p>\n The code samples show the minimally required parameters. You can add more parameters.<\/p>\n<\/div>\n After the shopper has ordered the online items:<\/p>\n Make a Terminal API CardAcquisitionRequest<\/a> where the When you receive the CardAcquisitionResponse<\/a>, save the following information:<\/p>\n The following example shows the Use the card alias and\/or PAR from the card acquisition response to look up the shopper's delivery address in your ERP system.<\/p>\n<\/li>\n If the shopper is found in the ERP system, let the shop assistant verify the delivery address with the shopper. If the shopper is not found in the ERP system, add a record for the shopper to the ERP system with the card alias and\/or PAR from the card acquisition response, and the other details that you need, specifically the delivery address and the name of the shopper. You can collect those other details in various ways, for example:<\/p>\n Add the delivery address to the order.<\/p>\n<\/li>\n<\/ol>\n Make a Terminal API PaymentRequest<\/a> with:<\/p>\n When you receive the payment response, save the following details:<\/p>\n The payment date and time in the If you support mixed baskets as two separate transactions, make another Terminal API payment request for the in-store items. If you support mixed baskets as a single transaction, make a partial manual capture request for the in-store items immediately after the payment request (see the next step for an example).<\/p>\n<\/li>\n When the order is shipped from the warehouse, make a manual capture request for the amount due:<\/p>\n Send a POST request to the \/payments\/{paymentPspReference}\/captures<\/a> endpoint, where In your request, include:<\/p>\n\n
Capture settings<\/h3>\n
Mixed baskets<\/h3>\n
\n
\nYou authorize the full amount of both the online order and the point-of-sale items, and make a partial capture request for the in-store items. Later, you make one or more partial captures as the ordered items are shipped.<\/p>\n<\/li>\nDelivery address<\/h3>\n
Sale attribution<\/h3>\n
Refunds and discounts<\/h3>\n
\n
API flow<\/h2>\n
\n
No mixed basket or mixed basket as one transaction<\/h3>\n
Mixed basket as two transactions<\/h3>\n
Instructions<\/h2>\n
Delivery address<\/h4>\n
\n
CardAcquisitionTransaction<\/code> object contains the TotalAmount<\/code> field with the purchase amount for the ordered items and, if you support mixed baskets as a single transaction, any items from the store.
\n\n
AdditionalResponse.PaymentAccountReference<\/code>: the PAR, if present.<\/li>\nAdditionalResponse.alias<\/code>: the card alias.<\/li>\nTimeStamp<\/code> and TransactionID<\/code> from the POIData.POITransactionID<\/code> object. You need these values later, when you authorize the transaction.<\/li>\n<\/ul>\nAdditionalResponse<\/code> as a string of key-value pairs concatenated with an ampersand (&<\/strong>). It is possible you receive a Base64-encoded string instead, which you need to Base64 decode first.<\/p>\n
\nEnsure the shop assistant can:<\/p>\n\n
\n
Authorization<\/h4>\n
\n
\n
PaymentData.CardAcquisitionReference<\/code>: an object with the TimeStamp<\/code> and TransactionID<\/code> returned in the POIData.POITransactionID<\/code> object of the card acquisition response.<\/p>\n<\/li>\nPaymentTransaction.AmountsReq<\/code>: an object with the Currency<\/code> and the RequestedAmount<\/code>.
\nIf you support mixed baskets as a single transaction, use the total amount of the basket.
\nIf you support mixed baskets as two separate transactions, use only the amount of the ordered online items.<\/p>\n<\/li>\nSaleToAcquirerData<\/code>: a parameter with manualCapture<\/strong><\/span> set to true<\/strong><\/span> in one of the following formats:<\/p>\n\n
\n
POITransactionID.TransactionID<\/code>: The transaction ID in the format tenderReference.pspReference<\/code>, which includes the PSP reference. For example, in the transaction ID BV0q001765198054002.CWBC43ZX2VTFWR82<\/strong>, the PSP reference is CWBC43ZX2VTFWR82<\/strong>. The PSP reference is also provided in the AdditionalResponse<\/code>.<\/p>\n\n
POITransactionID.TimeStamp<\/code> field. You need the timestamp if the shopper returns items in-store.<\/p>\n<\/li>\n<\/ul>\n
\nIf your point-of-sale merchant account uses immediate or delayed capture by default (which we usually recommend), do not set manual capture in this payment request. Otherwise, see the next section, \"Capture\", and make a separate manual capture request for the in-store items.<\/p>\n<\/li>\n<\/ol>\nCaptures and refunds<\/h4>\n
\n
paymentPspReference<\/code> is the PSP reference of the authorization you want to capture.
<\/p>\n
![\"Required\"](\"\/user\/pages\/reuse\/image-library\/01.icons\/required\/required.svg?decoding=auto&fetchpriority=auto\")
<\/span><\/td>\n