What is headless e-commerce?
In a classic store, the catalogue, the cart and the website pages form a single block. In headless commerce, the commerce part becomes an API: products, stock, orders and payments are handled by a dedicated engine, and the website is just an interface that queries it. You can then have several sites, a mobile app or kiosks selling from the same catalogue.
I use Saleor, an open source e-commerce engine written in Python with a GraphQL API. It handles several sales channels, currencies and warehouses, and extends through apps that react to signed events.
A real case: two brands, one engine
For Eco-Actives, I set up a single Saleor instance serving two brands through two sales channels: Eco-Actives, for companies, and Ti Kosmeo, for natural cosmetics workshops. One warehouse, tracked stock for physical products and untracked stock for workshops, a gift card with several amounts, and an idempotent catalogue import that can be replayed without duplicates.
Around Saleor, a FastAPI app adds what the engine cannot do: payment with Stancer, a French provider, through a hosted payment page, and a scheduling service that guarantees a booked slot hides the other workshops offered at the same time. This project is under development.
When WooCommerce is enough
Headless has a cost: two applications to maintain instead of one. For a store with a simple catalogue and no special sales rule, WooCommerce is often the right choice. With the Arbre Agile studio, I took part in launching Pousses et Plantes, a multi producer marketplace for French plants built on WordPress, WooCommerce and Dokan, containerised and load tested before opening.
I help you choose by looking at your catalogue, pricing rules, sales channels and who will run the store day to day.
Payments, stock and back office
I prefer payment pages hosted by the provider, which keep card data away from your site. The Stancer integration was written from its official OpenAPI specification and checked against a real Saleor instance, which revealed and fixed three gaps between the webhook documentation and actual behaviour.
Every event received from the engine is verified by its signature before processing, so a third party cannot trigger a payment or a booking in your name.
The Saleor dashboard covers orders, refunds and the catalogue. What is specific to your business, such as exclusive workshop slots, lives in a separate app, tested on its own, that engine upgrades do not break.
A fast, well ranked storefront in front of the store
In headless commerce, the storefront is a site like any other, so everything I apply to marketing sites applies to it. Category and product pages are prerendered, each with its own title, description and product structured data that Google can display. Images are generated at several widths so a phone never receives a 1,600 pixel photo, and measurement scripts load after the first interaction.
When the store replaces an existing site, I treat the migration as a redesign: inventory of the addresses that receive visits, permanent redirects to the new product pages, online checks after opening. For Ti Kosmeo, the workshop brand that will eventually sell through the Eco-Actives Saleor engine, 55 old WordPress addresses have already been redirected that way, and booking affiliate links were kept identical so commission tracking was not lost.
And after opening?
A store needs more follow up than a marketing site: engine updates, changing payment methods, new shipping or pricing rules, traffic peaks during the holidays. Before Pousses et Plantes opened, load scenarios simulated browsing, product page views and account creation to check the site would hold. I can handle that follow up over time, or train the person who will run the store day to day on its back office.
What I do not do
I do not run your ad campaigns or paid search, and I do not produce your product photos. I do not recommend headless for a first store testing a market: a hosted solution costs less until sales are confirmed.