Headless Commerce Explained: An Interview with Fabric

Headless Commerce Explained: An Interview with Fabric

Image source: Fabric

The COVID-19 pandemic is reshaping consumer behavior and disrupting every part of the buying journey — from how shoppers engage with your e-commerce store to the channels you need to be visible on, and the payment methods you accept. To meet the new needs of customers, businesses need to extend their backend. Headless commerce provides the flexibility to do this.

You’ve heard about headless commerce. But maybe you’re not quite sure what this e-commerce buzzword means? This technology that separates your e-commerce frontend and backend is here to stay and understanding its components is important.

That’s why we spoke about all things headless commerce with the team at Fabric.

Fabric’s headless commerce APIs let you seamlessly scale your commerce experience. Its goal is to take the burden away from engineers so that mid-market and enterprise companies can implement the technical solutions they need to compete, quickly and at scale.

In this article, you’ll learn what headless commerce is, the benefits of headless commerce, and how it can improve payment security. 

MONEI (M): In your words, what is headless commerce? 

Fabric (F): Headless commerce is an approach to commerce architecture where the frontend presentation layer that powers buying experiences is separated from the backend layer that contains datastores and services. This separation is important because it allows businesses to fully customize buying experiences across channels. Headless commerce is scalable, too. The addition of a new sales channel does not require the addition of a new backend. APIs enable this.

That said, the term headless commerce is outdated. The phrase was first used in reference to computer systems where the monitor wasn’t built into the server. The main concept still applies to commerce architecture but decoupling an e-commerce system is much more nuanced than detaching a monitor from a server. 

At Fabric, we prefer the term modular commerce as it does a better job implying that the headless architecture is made up of individual components (aka modules) that are able to operate independently of each other.

M: How does headless commerce work? 

F: Headless commerce works by separating the frontend and backend of your commerce architecture.

  • The frontend is where you make changes to how the storefront and products appear on different types of devices. Every device has its own frontend, built using its own codebase and programming language. 
  • The backend includes datastores like order management systems and product information managers along with services such as shopping carts, personalization engines, and payment gateways. Because they are “stateless,” these services are not dependent on each other.

The way all the different pieces of the headless architecture work together is through application programming interfaces (APIs). A frontend communicates with different backend services via APIs and all the individualized backend services communicate with each other through APIs as well.

For example, say you have a mobile shopping app and a customer completes a purchase from the checkout page. The frontend presentation layer sends an API call to the payment gateway to process the payment. Once the payment is processed more API calls go out to the order management system and other backend services to ensure all data is updated in real-time.

M: What are the main differences between headless commerce and traditional commerce? 

F: The biggest difference between headless and traditional commerce is that with traditional architecture, all logic, data, and process exist within the same codebase. This means there is a single backend database that stores both content and the code for its layout. As a result, you are limited to how much you can customize the appearance of your frontend presentation layers. 

Another major difference is scalability. Traditional commerce is hard to scale because you cannot make changes to the backend and frontend independently. Development costs are high and go-to-market timelines are slow. With a headless architecture, developers can make changes to each layer independently enabling rapid deployment of new features.

M: What are the key benefits of using headless commerce? 

F: To start, headless commerce allows companies to “future-proof” their business. If you ask yourself what the world of commerce will be like 3 to 5 years from now, chances are it looks vastly different than it does today. New sales channels will emerge, customer behavior will shift, and technology will continue to evolve. 

Making quick changes is difficult when you are using a legacy commerce platform. But, with headless commerce, you can seamlessly make adjustments on the fly. If there is a new device (sales channel), you simply use your APIs to integrate your products and create a frontend experience unique to that device. If you need to replace one of your backend services with a better option you can simply plug it in without having to uproot the whole system.

This is what you see with Amazon who is the pioneer of headless commerce. They have a huge advantage in time to market and the ability to implement new ideas. Other retailers still using monolithic systems are 10X slower in adapting their shopping experience for changes in consumer behavior, which is why Amazon continues to dominate online retail in the United States.

Another headless commerce benefit is better performance and faster content delivery. The main reason for this is that resources aren’t shared the same way they are in a monolithic system. Frontends can make API calls to pull the content that is needed and nothing else. The APIs aren’t weighed down by other processes and can push and pull data with greater efficiency.

M: Can using a headless commerce solution enable merchants to offer customers more payment methods? 

F: Having a commerce architecture centered around APIs allows for better integration of all types of services, including payment gateways. Additional payment gateways can be added simply by using your headless APIs to make calls to the payment gateway.

M: Can headless commerce improve security around payments for e-commerce stores? 

F: With headless commerce, your e-commerce architecture as a whole is more secure. API layers are less vulnerable to attacks compared to a legacy platform where all the code and processes are coupled together. Because the distributed architecture relies on different systems working together, the potential of a single compromised account causing a catastrophic problem is eliminated. Also, with a headless CMS, functionality can be hidden under layers of code instead of being exposed as it commonly is with a traditional CMS.

M: What types of businesses use headless commerce? 

I should make it clear that headless commerce is not for everyone. If you are an enterprise business that needs to implement changes quickly or a mid-market company that is beginning to outgrow a platform like Shopify, headless commerce is the right choice.

Large retailers need a way to start competing with Amazon and this cannot happen without adopting headless commerce and microservices. Mid-market companies are at a phase in their business life cycle where they must expand beyond finding market fit. This means adding customer segments and sales channels which in turn leads to a more complex distribution system. Trying to handle all of this on a legacy platform is a nightmare. 

M: How can headless commerce benefit a merchant’s omnichannel selling strategy? 

F: By definition, omnichannel commerce requires selling through a variety of different frontends, but managing these frontends can be challenging. There needs to be consistency across every sales channel. Prices, product selection, product details, inventory counts, and content all must be accurate and up to date. Doing this at scale requires the ability for each frontend to communicate with the same databases and commerce services.

Using a headless architecture, APIs push and pull data to any channel including IoT devices, social networks, apps, and more. This enables retailers to provide a consistent experience across all these channels while ensuring that all data is coming from a single source of truth.

M: What obstacles might merchants face with a headless commerce platform? How can they overcome them? 

F: The first obstacle merchants tend to face is their own fear of migration. Given the old rip and replace method of replatforming, this is a legitimate concern. But with a headless platform like Fabric, the old way of replatforming is dead. There is no need to replace an entire system because you can gradually add piece by piece until you have created an entirely new architecture.

Another obstacle is the time and resources needed to create and maintain a truly headless architecture. To give you an idea of what it takes to have a headless architecture that functions well at scale, Amazon has tens of thousands of APIs and entire teams dedicated to making sure that every tiny detail of their shopping experience is optimized for their customers.

In the past, this was a serious barrier to both mid-market companies and enterprises that wanted to adopt headless commerce. Today, with SaaS and pre-built APIs, this is no longer an issue. You don’t need dedicated teams or tens of thousands of APIs because it is taken care of for you. The SaaS provider gives you the tech and APIs and you use them however you need to.

M: Is it easy to integrate/plugin headless commerce architecture with traditional commerce platforms? 

F: Headless commerce APIs work with your existing architecture to easily integrate any microservice without needing to make changes to your current setup. This touches on the idea I mentioned earlier that replatforming is dead. With headless services, you can add one component at a time to gradually move away from a monolithic system. 

For example, multi-billion dollar companies we work with are starting to move away from their monoliths. To do this, they choose one headless service from Fabric (like our product information manager), import data to it, then integrate it with their existing frontend and backend systems. This integration can usually be done via an API gateway but in some cases requires “glue code.”

M: How does Fabric differentiate itself from other headless commerce software?

F: Fabric distinguishes itself from other headless software in that our leaders truly know e-commerce and retail. With general manager-level experience at major companies like Amazon, eBay, and Staples, we know what it’s like to be a retailer in today’s world and understand what is needed in a commerce solution.

Our suite of headless tools includes everything fast-growing retailers need to scale: an OMS, PIM, pricing engine, digital experience platform (DXP), and more to come. With Fabric, you do not need to worry about piecing together dozens of different modules from dozens of providers (though you can if you want). We offer many of the core commerce modules you need. 

Moving Forward with Headless Commerce 

If you are a B2B distributor of a brand or a retailer doing more than $20 million in annual revenue, it’s time to think about headless commerce. At this stage of growth, the wheels fall off of platforms like Shopify and BigCommerce, and even Salesforce and Oracle.

MONEI newsletter signup

Online Payment Methods for Your E-commerce Business