But when you move from running a single-brand storefront to building a multi-seller marketplace, the dream starts to crack.
Why? Because a seller-led marketplace isn’t just a “frontend” or presentation challenge. It’s a complex systems problem — one that demands native support for multi-actor coordination, backend logic, financial flows and operational complexity.
And that’s where Commerce Layer for all its technical strengths falls short.
Headless ≠ Marketplace-Ready
Let’s start with definitions.
Headless commerce means the frontend (what customers interact with) is decoupled from the backend (where business logic and data live). This gives developers huge flexibility they can build web apps, mobile apps, kiosks, smart mirrors all drawing from the same backend APIs.
Commerce Layer offers excellent APIs for:
Inventory management
Pricing and promotions
Orders and checkout
Customer management
But here’s the critical point:
All of these APIs assume a single merchant or brand as the central actor.
That’s great when you’re Nike or Glossier, selling direct-to-consumer across 10 countries.
It’s a problem when you’re trying to build the next Etsy, Stockx, Farfetch or even a B2B wholesale marketplace.
In a marketplace, you’re no longer managing one actor (the merchant); you’re orchestrating many independent sellers each with:
Their product catalogue
Their pricing and tax rules
Their inventory
Their fulfilment and shipping methods
Their own refund, dispute and returns processes
Their commissions, payouts and financial records
None of this is native to Commerce Layer.
Yes, you can simulate marketplace behaviour by bolting on custom logic, but now you’re effectively building a parallel seller management system outside the core platform which defeats the purpose of using a headless commerce solution in the first place.
You’ll Be Building the Seller Layer From Scratch
Let’s get specific about what’s missing and why it matters.
Say you want to launch a multi-seller marketplace with Commerce Layer. Here’s what you’ll need to custom-build:
Seller onboarding, identity, and permissions:
Commerce Layer has no native concept of sellers as separate entities. You’ll need to create your own seller accounts, roles, and access management.
Seller-level catalogues and pricing:
You’ll have to slice and map products to sellers and apply seller-specific prices, tax rules, and promotions — all outside the platform.
Multi-seller cart and order splitting:
If a customer buys from three sellers, you’ll need to split that cart into three orders, route them to the right fulfilment paths, and track them independently.
Commissions, payouts, and financial flows:
Commerce Layer does not handle money movement — it stops at checkout. So, calculating seller commissions, issuing payouts, and managing financial reconciliation is entirely on you.
Refunds, returns, disputes per seller:
You’ll need to layer on custom workflows to manage post-order complexity at the seller level.
Seller dashboards, analytics and performance tracking:
All seller-facing reporting will need to be built from scratch.
The Big Question: What Are You Really Paying For?
At some point, you need to step back and ask:
If we’re managing sellers, orders, payouts, disputes, commissions, and analytics entirely outside Commerce Layer…
Why are we still using Commerce Layer?
You end up paying for a modern set of APIs but doing all the marketplace logic on your dime.
That’s not just expensive, it’s operationally risky. You’re now stitching together a patchwork of systems, extending timelines, increasing your technical debt, and building around (instead of on top of) the core commerce engine.
Commerce Layer Is Built for Brands, Not Platforms
To be clear: Commerce Layer is a fantastic product, but it was purpose-built for brands, not marketplaces.
It shines when:
You want to launch multiple regional storefronts.
You need to centralise product data across channels.
You’re orchestrating omnichannel experiences (buy online, pick up in store).
You’re optimising for API speed, scalability and modularity.
But marketplaces are fundamentally different from D2C brands.
They are platform businesses.
They are multi-actor ecosystems.
They need infrastructure that can natively handle seller complexity at scale.
Commerce Engine: Headless AND Seller-Native
Now, contrast that with Commerce Engine which was designed from the ground up for marketplace businesses.
Commerce Engine offers:
Full seller onboarding and permissioning
Seller-level inventory, pricing, and tax management
Auto-split orders across sellers with proper routing
Disputes, returns and refunds are tracked per seller
Built-in commission calculation and payouts
Seller analytics and dashboards exposed via API
The result? You get a modern, headless, API-first stack — without cobbling together the seller layer yourself.
Real-World Example
Imagine you’re building a fashion marketplace:
Each has its pricing, stock and tax setup.
A customer places one order with products from three designers.
The order is split, fulfilled and tracked per seller.
Refunds or disputes are resolved at the seller level.
You automatically calculate platform commissions and send payouts.
With Commerce Layer, you build 90% of this yourself.
With Commerce Engine, it’s all native.
Final Thought
Commerce Layer is a world-class tool for brands building global storefronts, but marketplaces are not just global.
They’re multi-actor systems with deep operational complexity.
If you’re serious about building a seller-first platform, don’t just evaluate whether a commerce solution is “headless.”
Make sure it’s seller-native.
