Stateless carts.

By Filippo Conforti on April 11, 2023

Did you ever experience a situation where you wanted to share a shopping cart, but you couldn't? Don't you find that annoying? There are many ecommerce websites that don't offer this capability, or at least not in an intuitive manner.

The main reason why you are not able to share a shopping cart is because most shopping carts are designed like monolithic stateful applications. In a monolithic ecommerce website, shopping cart and checkout are strictly tied to the website’s product discovery functionality. From other channels, all you can do is create a link to a product page, so that the customer can initiate a new shopping session by adding the product to cart.

This is not ideal and has a bad impact on customer experience and conversions. Having the option to share a shopping cart is not just a nice "share with a friend" feature. If you look at it from an architecture perspective, a shareable cart allows you to implement a true omnichannel experience across all your sales channels. It enables marketing automation workflows such as abandoned cart recovery, and provides sales assistants with a powerful tool to help them convert sales beyond the .com website.

A shareable cart is stateless. You can unlock great functionality by making your cart stateless. Stateless carts make your ecommerce stack more scalable, reliable, and future-proof. The purpose of this article is to explain what “stateful” and “stateless” mean (at least in this context), how to go stateless, and why it must be your first step if you’re considering a transition to headless commerce.

Stateful vs stateless

"Stateful" and "stateless" are terms used to describe two types of network protocols that differ in how they maintain the "state" of client sessions. A stateful application requires the specific state of each user to function properly. Responses from the server change depending on who made the request, so different users with different sessions receive different responses. Here is an example of a URL that could be used to get a shopping cart’s page:

A stateful cart URL
A stateful cart URL.

Using this URL, two different users will see two different carts, since the cart content is determined based on the user's session, which is different from one user to another. Therefore, you cannot share a cart URL, and you cannot link your cart directly from another website.

Unlike stateful applications, stateless applications do not depend on the user session. Every time a user sends a request, each operation must be performed from scratch. Here is an example of a stateless cart URL:

A stateless cart URL.
A stateless cart URL.

The URL above will display the content of the cart identified by ID 1234. The cart content will be the same for two different users who visit that URL, regardless of their session. By using that URL, any user can share their cart content.

Even if flexible, this approach poses a security risk. It would be very easy for a malicious user to guess any shopping cart ID and alter the content of another user's cart by simply changing the cart ID in the URL. To avoid this problem, the cart IDs should be obfuscated by using UUIDs or Hash IDs instead of numeric, sequential IDs. Furthermore, you may also choose to lock the URL with an access token that grants access to only those users who add a valid token as a URL parameter:

A stateless and secure cart URL.
A stateless and secure cart URL.

In other words, every request in a stateless application must be authenticated in order to function in a secure way. This is exactly what happens when a REST API is combined with a Bearer token authentication system. In fact, even though it is definitely possible to develop stateless carts as monolithic, independent applications, most of the time "stateless" is synonymous with "headless" and going stateless works much better when you approach it with an API-first strategy.

Going stateless

Imagine you're running an ecommerce website on a monolithic platform and you want to decouple your shopping cart. To do this, you need to remove all shopping cart functionality from your website and connect a stateless cart application instead.

Decoupling the shopping cart from a monolithic ecommerce application.
Decoupling the shopping cart from a monolithic ecommerce application.

The website is no longer monolithic, but instead consists of two parts: an application for product discovery experience and a transaction system, represented by the stateless cart application. As a result, the website becomes just one of many possible sales channels. The same cart and checkout can be used by other channels, such as a mobile app, a marketing microsite, or an in-store QR code.

A stateless and omnichannel shopping cart.
Stateless carts are omnichannel by definition.

Based on the branding requirements and level of development effort, each channel can integrate the shopping cart in different ways. The easiest option is to share a hosted cart microfrontend. In order to improve the user experience, an embeddable version of the microfrontend (i.e. without any header, footer, or fixed screen dimensions) could be used to embed the cart into any website as an iFrame. Lastly, if the cart application is headless, you can integrate the shopping cart API directly to create a completely custom experience.

It is important to note that all these options require a shopping cart API to implement the add to cart functionality. Moreover, these three options are not mutually exclusive. Your website and app could use the API approach, but your sales assistants could use the hosted cart microfrontends as simple URLs they could send via email, SMS, or WhatsApp to customers.

Stateless carts allow you to centralize control of transactions while keeping the customer experience tailored to each channel. Shopping cart and checkout are no longer just the final steps of your ecommerce website, but rather a shared service for your organization that enables any customer interaction to become a shoppable moment.

From stateless to headless

As a matter of fact, there is no way to go headless without creating a stateless cart first. When you introduce a headless CMS to decouple the frontend from the backend of your website, you will need a commerce API to power all of the transactions. It is therefore essential that the first step of your headless journey involves decoupling your shopping cart from any monolithic platform you are using.

You need to go stateless before going headless.
You need to go stateless before going headless.

By following this pattern, you will also have an immediate ROI by enabling new revenue streams from other sales channels, and your cost of going headless will go from an expense to a profitable investment.

Enjoy the reading?

Subscribe to the newsletter and get a new article delivered to your inbox every week.