What is SalesLife Headless Commerce?

Headless commerce in plain language

Every commerce system has two halves. The front end is what a customer sees and touches: a till screen, a mobile app, a web page, a chat conversation. The back end is where the real work happens: the product catalogue, prices and promotions, stock, customer and loyalty records, orders, payments, tax and the posting of everything to finance.

In a traditional, tightly coupled system, the two halves are built together. You get one storefront, designed by the vendor, and changing it means working inside the same system that runs your stock. In a headless system, the front end is detached. The back end exposes its capabilities through interfaces, and any front end can use them. The "head" can change, or you can have several at once, without rebuilding the engine.

Coupled, headless and composable

Approach	How it works	Strength	Watch out for
Coupled	Storefront and engine are one product	Simple to start	Hard to add channels or change the experience
Headless	One engine, any number of front ends through APIs	Freedom to add channels without duplicating the back end	You own more of the front-end work
Composable	Each function, such as search, payments and loyalty, comes from a different best-of-breed service	Maximum flexibility	Integration effort and many vendors to manage

Most retailers do not need a fully composable stack. They need one dependable engine and the ability to add channels around it. That is the headless sweet spot.

Why this matters for African retail

Customers reach a retailer through more doors than ever. A shopper might walk into a store, order through a branded app, message the branch on WhatsApp, or buy through a delivery partner on the same day. A stockist may place a repeat order from a phone. A van sales driver may invoice at a kerb.

If each channel has its own stock count, its own prices and its own loyalty balance, the business drifts into chaos. Promotions disagree. Orders are accepted for stock that is not there. Finance reconciles five systems. Headless commerce solves this by giving every channel the same source of truth.

It also suits mobile-first markets. Many customers will never open a desktop website. They will use an app, a chat window or a phone call. Being able to build those experiences without touching the engine is a real advantage.

The retail engine is the hard part

The glamorous part of commerce is the storefront. The hard part is the engine behind it. For a retailer, a trustworthy engine has to deliver:

One product master. Items, barcodes, categories and attributes, defined once.
Prices and promotions that apply the same way in every channel and every branch.
Real-time stock across branches, so an order is only accepted when it can be fulfilled.
Loyalty and customer data with consent, shared across channels.
An order lifecycle that works the same whether the order began in a store, an app or a chat.
Payments and reconciliation for cash, cards and mobile money, matched to settlements.
Tax and fiscal compliance built in, such as KRA eTIMS in Kenya.
Clean posting to the ERP, with an audit trail. See our guide to POS and ERP integration.

If any of these are weak, a beautiful new front end makes the problem more visible, not less.

What SalesLife Headless Commerce means

SalesLife Headless Commerce is the way SalesLife is built to run omnichannel retail: SalesLife HQ is the engine, and every channel is a head.

HQ already holds the master data that powers the tills: catalogue, pricing and promotions, customers and loyalty, and the online order queue. It validates, stages and posts to Dynamics 365 Business Central or SAP Business One, and it is the only path from branches to the ERP and cloud services. Branch POS never holds ERP credentials.

The SalesLife Customer App already works this way. It draws live catalogue, prices, promotions and stock-aware offers from HQ, shares loyalty with the till and sends orders into the branch fulfilment queue. Other channels can use the same engine in the same way.

Head	What it uses from the engine
Branch POS, self-checkout and handhelds	Catalogue, prices, stock, loyalty, tenders, tax signing
Branded web store	Catalogue, search, availability, pricing, checkout and order tracking
Whitelabel Customer App	Catalogue, promotions, loyalty, M-Pesa pay-now, order queue
WhatsApp	Receipts, ordering, payment requests, order updates and loyalty
Call centre	Telephone orders, order changes, returns and service
Delivery partners and marketplaces	Availability and orders, mapped to POS customers for settlement
Trade and stockist portal	Buyer accounts, price lists, credit limits, quotations and reorder

The point is not the number of heads. It is that adding one does not mean copying your stock, prices or loyalty into a new system.

What SalesLife Commerce includes

Unified pricing and promotions that every channel follows.
A branded e-commerce storefront and the APIs to build your own front end.
Omnichannel fulfilment: click and collect, curbside, ship from store, delivery and endless aisle.
Order management and sourcing rules that choose the right store and reserve stock at order time.
Returns across channels, with the correct refund and restock.
Customer 360 and clienteling, so store associates see history and loyalty.
Search, discovery and AI recommendations.
B2B commerce with buyer accounts, price lists, credit limits and quotations.
Contact-centre ordering and customer service on the same order model.
Payments across M-Pesa, Airtel Money, cards, pay at pickup, vouchers and gift cards.

See the full list on the SalesLife Commerce page.

Design principles behind it

One source of truth. Products, prices, stock and customers live in HQ, not in each channel.
Channel-agnostic orders. An order is an order, whatever its origin. The same states, the same fulfilment queue and the same posting.
Idempotent by design. A retried message never creates a second order or a second payment.
Offline-first in the store. Branches keep selling when the network drops and catch up later. Read more in offline-first retail systems.
Consent and security. Marketing consent is recorded on the customer, and no channel holds ERP credentials.
Human in the loop. Automation proposes and people approve where money or prices are involved.

Headless use cases for retailers

Click and collect. Order in an app or chat, pick at the branch, collect without queuing.
WhatsApp ordering and updates. See our guide to WhatsApp use cases for retail.
A branded web store for your best-selling ranges, fed from the same catalogue and stock.
Delivery partners receiving accurate availability and settling cleanly.
Stockist and trade ordering with the right price lists, credit limits and quotations.
Kiosks and in-store ordering for deli, bakery or made-to-order items.

Pitfalls to plan for

Overselling. Decide how stock is reserved when an order is placed and when it is released.
Price drift. Never let a channel set its own price. Pull it from the engine.
Returns across channels. A product bought online and returned in store must refund the right tender and restock correctly.
Front-end ownership. Headless gives you freedom, and you or a partner must build and maintain each head.
Performance and search. Web heads need fast pages and good search, which are separate engineering concerns.
Governance. Decide who approves new channels, templates and promotions.

Questions to ask any vendor

Is there a single product, price and stock master that every channel uses?
What is the order lifecycle, and is it the same for every channel?
How are stock reservations and oversell handled?
Which interfaces are available to our own front ends, and who supports them?
How do payments from each channel reconcile?
How do orders from every channel reach the ERP?
What happens to a channel when the network or a third party is down?

How to start

Pick one new channel with a clear customer benefit, such as WhatsApp order updates or click and collect.
Define the order lifecycle from request to fulfilment to posting.
Pilot in one branch with a limited range.
Measure order accuracy, fulfilment time, payment success and repeat purchases.
Add the next head only when the first is stable.