Before making a purchase, customers add items to their shopping carts. This moment marks the beginning of the order pipeline. Using a stateless shopping cart API, it is possible to embed an "add to cart" button anywhere, enabling true omnichannel commerce. In fact, the shopping cart analogy itself originated in the physical world, and it has been transferred to the digital realm with the rise of ecommerce.
The "add to cart" functionality follows some general rules regardless of the sales channel that is being used to make the purchase. In contrast, other aspects can vary from channel to channel. This article discusses how to implement an “add to cart” functionality on any channel, along with some best practices and considerations specific to each channel.
The add to cart action
Adding items to a shopping cart can be accomplished through HTML buttons on a website, UIButton controls on an iOS application, barcode scans on POS systems, QR code scans on billboards, voice commands on Alexa, and so on. This action adds a new item to a list, allowing the buyer to purchase more items together with a single payment.
Generally, items can only be added to a shopping cart if they are available for purchase. As you enter a grocery store, you pick products off the shelves and physically add them to your cart. Those items are available by definition, otherwise you wouldn't be able to pick them up.
Instead, if the product is a digital representation rather than the actual product, there's a chance that it might not be available. If this is the case, adding the item to the shopping cart shouldn't be allowed. It's important to keep in mind that there are different levels of availability. It is possible for a product to be available for purchase even if it is not in stock. For example, the item might be pre-ordered, back-ordered, or made to order.
Checking availability isn't the only validation. You might be allowed to purchase a certain quantity of a product under a B2B contract, or some products may only be available to certain customers (at a given price).
In a digital environment, an "add to cart" can trigger other actions. To begin with, it should launch the cart (draft order) creation process. Creating an empty cart is a waste of resources, so you should always create a cart when you have at least one item in it.
Promotions or tax calculations may also be triggered. Promotions can change based on the content of the cart, so whenever an item is added to the cart, the active promotions can change. Tax calculations can determine an additional line item that will be added to the order's total or be detailed just as a breakdown of the cart total if taxes have already been included in the prices.
Displaying an add to cart
An "add to cart" can look different depending on the sales channel and device. Anyhow, showing an “add to cart” call to action implies that the item can be purchased. It would be ideal if you only displayed the "add to cart" button if the product is available and the customer can purchase it.
When a product page features a single product or a bunch of related products, this calculation is quite simple, so you can enable the button only if all conditions are met. Unfortunately, it is not always that simple.
Suppose you have 50 or more products listed on your product listing page. When computing the availability and all validations upfront, before enabling each button, the page load time can be slowed down and the customer experience can be negatively impacted. If this is the case, it is recommended to follow an optimistic approach: assume that products are available without calculations and run validations only when the customer actually adds an item to their cart. The worst that can happen is showing a "not available" message to the customer after they click the button. This is, however, a good trade-off for the much faster experience that all of your customers will receive, also considering that 90% will never click that button.
There are some channels that do not even allow you to gray out the "add to cart" button when you are unable to purchase an item. Imagine a QR code on a physical product, or your Alexa device waiting for your next voice command.
Storing the cart content
The list of items in your cart needs to be stored somewhere. As a general rule, you have two options. First, the cart content can be stored locally, for example in the browser's local storage. As a second option, you can keep a reference of the cart (or order) ID in a local (or shared) storage and persist the cart content on the server.
Since there is no interaction or API call each time the cart content changes, storing a cart locally may optimize performance and server load. As soon as the customer proceeds to checkout and adds more information to the order, the cart content will be persisted. You may also choose to build more steps of the order pipeline locally and only persist orders when necessary. As an extreme example, you could collect all the checkout data locally and persist the order only when it’s ready to be placed.
Whether storing a cart locally (or building an entire order) is a viable option, there are some considerations to keep in mind. The order summary, promotions, and taxes, for example, must be calculated locally. This can lead to an inconsistency and create an unnecessary level of responsibility on the client's part. The alternative is to provide the customers with less information in the cart stage. In fact, if you have to call a promotions API or a taxes API every time you change your cart locally, you might as well persist the order from the beginning. Moreover, due to the fact that local orders are tied to a client's device and session, they cannot be easily shared or recovered.
By persisting the cart content starting at the first "add to cart" action, you gain data consistency, automatic promotion and tax calculations. Additionally, you can share and recover your order at any point, enabling cross-channel shopping and marketing opportunities. Overall, this seems to be the preferred approach, given your commerce API is fast and reliable enough.
Do you really need a cart?
The use of a shopping cart has become so common that it has become the standard method of building a shopping experience. Some scenarios, however, would benefit from not having a shopping cart at all, instead implementing "buy now" actions that take customers directly to checkout, skipping the shopping cart stage entirely.
For certain types of businesses, where the average order contains one or fewer items, this approach is more straightforward and makes sense. An order of luxury goods, for example, usually contains less than 1.2 items, indicating that four of five customers purchase one product and the fifth purchases two. When this happens, not having a shopping cart would be irritating for the minority of buyers who want to buy two products at once, but would greatly speed up the majority of buyers who buy one product at a time.
Instead, it would be very unlikely that you would purchase only one or two items at the grocery store, so scrapping the shopping cart stage in that situation doesn't seem like a great idea. In the end, it's about evaluating the best approach based on the actual use cases and making decisions based on data, rather than following an established convention.