Web teams owned the browser. Retail teams owned the POS. Mobile teams emerged later and typically lived inside product or innovation groups. Marketplaces were either not considered or treated as operational exports.
Those days are gone.
Commerce today isn’t “web-first” or “mobile-first.” It’s channel-agnostic, because customers don’t behave in channels. They behave on journeys.
A user might:
Browse on mobile,
Add to cart on desktop,
Scan in-store,
Checkout via app,
Return via a portal,
Reorder through a B2B interface.
The problem isn’t the user flow - it’s the architecture. Traditional platforms assumed one channel = one storefront = one rendering layer. Multi-channel breaks that assumption instantly and engineering teams feel the pain.
The False Assumption: The Storefront is the Commerce System
Most legacy ecommerce platforms were built with a tight coupling between:
The storefront template engine,
The catalogue model,
The cart session,
and the checkout pipeline.
That coupling made sense when commerce meant “browsers and carts.” It makes no sense when commerce includes:
Native mobile apps,
Mobile wallets,
Kiosks,
POS systems,
Partner order portals,
B2B procurement systems,
And Marketplace integrations.
In multi-channel commerce, the “storefront” stops being a channel and becomes a client. Each client demands a different UX but the same business logic.
This is where many teams realise the platform isn’t the blocker - the coupling is.
Multi-Channel Isn’t About Rendering, It’s About Shared Commerce Primitives
A modern commerce backend needs to answer the same set of questions regardless of channel:
Catalog
What is this product?
What variants/options exist?
What media, attributes, and metadata apply?
Pricing
What price applies to this customer?
What promotions, tiers, or contracts apply?
Inventory
Where is the stock and is it reservable?
What fulfilment options exist by location?
Checkout & Order
How do we capture payment, tax, and shipment details?
How do we convert this basket into an order?
How do we emit events for fulfilment, accounting, fraud etc.?
Those questions do not change between:
A React storefront,
A native iOS cart,
A self-checkout kiosk,
Or A B2B purchase order screen.
Multi-channel commerce fails when each channel tries to reimplement those primitives separately.
How Most Teams Get Multi-Channel Wrong
There are two common anti-patterns in multi-channel architecture:
Anti-Pattern 1: “Clone the Platform”
This is when each channel becomes its own mini e-commerce implementation:
Mobile has its own cart logic,
The kiosk has its own checkout flow,
POS has its own inventory logic,
Partner apps calculate pricing independently.
Everything works until the business changes something - promotions, inventory rules, pricing tiers and now four systems must be updated at once.
This is how technical debt becomes operational debt.
Anti-Pattern 2: “Middleware Heroics”
This is the “headless gone wrong” pattern.
The platform still owns domain logic, but teams create:
BFF (Backend For Frontend) services,
GraphQL wrappers,
Edge caches,
Sync queues,
Custom orchestration layers,
to mask the platform’s limitations.
This works - until you hit high traffic or add a new channel. Then engineering becomes a feature bottleneck instead of an enabler.
The Architecturally Correct Path: Commerce as a Shared API Backend
The shift to multi-channel doesn’t start at the frontend. It starts at the domain boundary.
A real multi-channel architecture exposes commerce as stateless, channel-neutral APIs:
GET /catalogue
GET /pricing
GET /inventory
POST /carts/:id/items
POST /checkout
GET /orders/:id
Each client web, mobile, kiosk, POS and marketplace - consumes the same contracts.
The rendering logic changes.
The UX changes.
The orchestration changes.
But commerce stays consistent.
Why Channels Diverge (and Why Backends Shouldn’t)
Frontends diverge because they are optimised for context:
POS prioritises speed over visuals.
Mobile prioritises session persistence and push.
Kiosks prioritise touch-first UX and payments.
B2B portals prioritise bulk ordering and contracts.
Marketplaces prioritise structured feeds and SLAs.
None of these are storefront concern. They are client concerns.
Backend domains - pricing, catalogue, inventory, checkout, order - should not change because a screen size or input method changed.
The teams that understand this gain enormous leverage.
Where Commerce Engine Enables Multi-Channel Without Replatforming
Commerce Engine exposes commerce as domain APIs:
/catalog
/pricing
/inventory
/carts
/checkout
/orders
These APIs don’t care if the calling client is:
Next.js storefront
React Native app
Swift/Kotlin native app
In-store POS tablet
Kiosk touchscreen
Partner integration
B2B portal
Marketplace adapter
Each channel becomes an interface, not a fork.
Real-World Examples of Multi-Channel Architecture
Here are the patterns we see most often among mid-market and enterprise teams:
1. Web + Mobile App
Shared catalog
Shared pricing
Shared checkout
Shared order loop
Device-specific UX
Checkout becomes a workflow, not a theme.
2. Web + POS
Web renders customer pricing
POS supports offline cache + fast SKU lookup
Inventory sync stays centralised
Orders flow into the same OMS/WMS
POS no longer needs a separate pricing engine.
3. Marketplace + D2C
Inventory reserves come from /inventory
Orders route back via /orders
Pricing exposes MAP/contract pricing rules
Fulfilment emits events to WMS
The backend becomes the source of truth instead of spreadsheets.
4. B2B Portals + B2C Storefronts
B2B and B2C often diverge most in:
Catalog visibility
Pricing contracts
Order minimums
Fulfillment SLAs
With Commerce Engine:
Catalogue is filterable by role/permission
Pricing is contextual by customer/group
Checkout enforces business rules via API
Orders still land in the same system
This avoids building two commerce stacks.
5. Kiosks + Self-Checkout
Kiosks require:
No login UX
Fast barcode/scanner integration
Inventory checks
Payment capture
None of these requires a theme engine. They require APIs.
Why This Matters for Engineering Velocity
When multi-channel works at the architecture layer, teams gain:
Channel autonomy (frontends can evolve independently)
Unified data models (catalogue/pricing/inventory consistent)
API-driven experimentation (UI isn’t locked to themes)
Operational observability (orders/inventory/events traceable)
Less integration glue code
Less rework when channels change
The business gains capability mobility, adding a new channel becomes a UI problem, not a platform problem.
The Teams Moving This Direction Aren’t Just Digital Natives
It’s not just D2C brands doing this. We’re seeing adoption across:
Global retailers adding mobile self-checkout
Grocery chains with real-time inventory
Apparel brands syncing online + in-store POS
B2B distributors offering procurement portals
Automotive/electronics brands enabling kiosk browsing
Hospitality chains integrating loyalty apps
Pharma and med supply B2B ordering portals
All with the same architectural insight:
Commerce isn’t a storefront. Commerce is a backend.
The Takeaway
Multi-channel commerce fails when businesses try to duplicate commerce logic per channel. It succeeds when commerce becomes a shared domain of APIs that any client can consume.
Framework choice (Next.js, Remix, React Native, Swift, kiosk UI) becomes an implementation detail — not a platform constraint.
Commerce Engine provides the domain APIs that make that separation possible, enabling teams to build once and deploy everywhere without falling into platform lock-in or integration debt.
In multi-channel commerce, the winning strategy isn’t more channels. It’s fewer assumptions.
