commercetools vs Commerce Layer vs Elastic Path: Enterprise MACH Engines Compared (2026)
Every MACH vendor uses the same four words, API first, cloud native, headless, composable, and the words tell you almost nothing about which one fits your business, because the three leading enterprise engines interpret composable in three genuinely different ways. commercetools gives you the widest commerce domain out of the box, a deep catalog, cart, and order model that you then assemble a frontend and supporting services around. Commerce Layer gives you the thinnest transactional core deliberately, a commerce API designed to bolt onto a content stack you already run, which is either exactly right or exactly wrong depending on whether that stack exists. Elastic Path gives you the heaviest B2B machinery, complex catalogs, account hierarchies, and quoting, aimed at businesses whose commerce is complicated in ways direct to consumer never is. Picking among them is not a feature checklist exercise. It is a question of what shape your commerce actually is, and the wrong answer shows up a year into a build when the platform is fighting the way your business works. This is a comparison of the three by domain scope, integration model, and where each one bills you at scale.
commercetools vs Commerce Layer vs Elastic Path: Enterprise MACH Engines Compared
Three vendors, one vocabulary. commercetools, Commerce Layer, and Elastic Path all describe themselves as API first, composable, MACH aligned commerce engines, and if you read their homepages side by side you would struggle to tell them apart. The differences are real and they are architectural, not cosmetic. Each one draws the boundary of the commerce domain in a different place, expects a different amount of the surrounding stack to already exist, and bills for scale on a different axis. The mistake enterprises make is comparing them on feature grids, where they all check the same boxes, instead of on shape, where they diverge completely. This is a comparison built on that shape question, because it is the one that determines whether the platform helps your build or fights it.
Three interpretations of composable
commercetools is the broadest of the three and the closest to a complete commerce backend. Its domain model covers products with flexible typed attributes, carts, orders, customers, discounts, and a mature set of APIs in both REST and GraphQL. It assumes you will bring a frontend and plug in the other MACH categories, search, CMS, payments, but within the commerce core itself it gives you a great deal, including sophisticated product modeling and both B2C and B2B capabilities. The strength is completeness. The cost is a steep learning curve and a product model powerful enough to model your catalog several wrong ways before you find the right one.
Commerce Layer is the thinnest by design, and that is its entire thesis. It provides the transactional core, prices, inventory, carts, orders, fulfillment, across multiple markets and currencies, and it deliberately does not try to own your product content or your presentation. It expects a CMS or a PIM to hold the content and a frontend to render it, and it slots commerce underneath as an API. If you already run a strong content stack and want to add real commerce to it without adopting a heavy platform, Commerce Layer is the cleanest fit in the category. If you do not have that content stack, its thinness becomes work you now have to do elsewhere.
Elastic Path is the heaviest on the dimensions that direct to consumer businesses rarely touch and enterprise B2B lives on. Complex hierarchical catalogs, account based buying with organizational hierarchies, and configure price quote style flows are where it concentrates, and it pairs the commerce engine with an orchestration layer for assembling and governing the composed stack. If your commerce involves negotiated pricing, large account structures, or product complexity beyond a flat catalog, Elastic Path is built for exactly that world. For a straightforward B2C catalog it is more machinery than the job needs.
Domain scope at a glance
| Capability | commercetools | Commerce Layer | Elastic Path |
|---|---|---|---|
| Product catalog and modeling | Deep, flexible typed attributes | Minimal, expects external content | Deep, built for complex and B2B catalogs |
| Cart and order APIs | Complete | Complete, the core focus | Complete |
| Multi market and multi currency | Strong | Strong, a headline feature | Strong |
| B2B account hierarchies and quoting | Supported | Limited | Deepest in the group |
| Content and presentation | Bring your own | Bring your own, assumed | Bring your own, with orchestration |
| Learning curve | Steep | Moderate | Steep |
Read the top and bottom rows together. commercetools and Elastic Path both give you a deep catalog and both cost you a steep ramp, but Elastic Path spends its depth on B2B complexity while commercetools spends it on general flexibility. Commerce Layer keeps its learning curve moderate precisely because it declined to own the catalog and content, which is a feature when you have those elsewhere and a gap when you do not.
The integration question decides the build
The engine you choose sets the shape of every integration that follows, and the honest way to compare the three is to ask what you have to assemble around each one.
With commercetools you are integrating a frontend, a search provider, a CMS, and payments around a commerce core that is itself substantial, so the integration work is real but the core carries most of the commerce logic. With Commerce Layer you are integrating a commerce API into an existing content and presentation stack, so the platform is light but you are the systems integrator holding the content, the catalog source of truth, and the storefront together. With Elastic Path you are integrating around an engine plus its orchestration tooling, which can reduce the glue you write for complex composed stacks but adds its own model to learn. None of these is less work than a monolith; they trade the ceiling of a monolith for integration ownership, which is the same trade every composable build makes, and the same one that separates these enterprise engines from the open source headless engines where you also own the hosting.
Where the cost actually lands
| Decision factor | Choose commercetools | Choose Commerce Layer | Choose Elastic Path |
|---|---|---|---|
| You need the widest commerce core out of the box | Yes | No | Partial |
| You already run a strong CMS or PIM stack | Workable | Ideal | Workable |
| Your commerce is complex B2B or CPQ heavy | Workable | No | Ideal |
| You want the lightest engine to bolt onto a frontend | No | Yes | No |
| Your catalog is large and deeply structured | Yes | No | Yes |
| Your team is a small integration group, not a platform team | No | Yes | No |
Pricing follows the same logic and should be modeled before commitment, not after. These platforms tend to bill on consumption and scale, whether that is orders, GMV, API volume, or a combination, and the axis they bill on interacts with your business model in ways a list price never reveals. A high volume low margin catalog and a low volume high value B2B relationship stress a consumption model very differently, so the platform that looks cheapest in a demo can be the most expensive at your actual scale. Get a projection against your real order and traffic profile from each vendor before you choose, because the billing axis is as much a fit question as the feature set.
When this applies to your stack
Match the engine to the shape of your commerce, not to the length of its feature list. Choose commercetools when you want the most complete commerce core and have a platform team that can absorb its depth. Choose Commerce Layer when you already run strong content infrastructure and want to add real multi market commerce underneath it without adopting a heavy platform. Choose Elastic Path when your commerce is genuinely complex in the B2B sense, hierarchical accounts, negotiated pricing, or intricate catalogs, because that is the complexity it was built to carry. Across all three, model the pricing against your real volume before you sign, and treat the integration ownership as part of the total cost, because a composable engine is a commitment to be your own systems integrator regardless of which one you pick. The comparison against a suite like Shopify Plus, covered in the commercetools versus Shopify Plus breakdown, is a useful sanity check on whether you need a composable engine at all before you choose among them.
Selecting the right engine, modeling its cost against your actual volume, and executing the migration onto it without a broken quarter is the headless commerce work Contra Collective does when an enterprise decides its platform is finally the thing holding it back. If you are weighing a replatform, the migration cutover patterns guide covers the mechanics of getting there without downtime.
FAQ
What is a MACH commerce engine? MACH stands for Microservices, API first, Cloud native, and Headless, and a MACH commerce engine is a commerce backend built on those principles rather than as a monolith. commercetools, Commerce Layer, and Elastic Path all qualify, but they differ in how much of the commerce domain each one owns and how much of the surrounding stack you assemble yourself.
Which is best for B2B commerce? Elastic Path is the strongest of the three for complex B2B, because it concentrates on hierarchical account structures, negotiated pricing, and configure price quote flows that most direct to consumer platforms treat as afterthoughts. commercetools also supports B2B and is a reasonable choice for less complex cases, while Commerce Layer is the least suited to heavy B2B.
When does Commerce Layer make sense over commercetools? Commerce Layer makes sense when you already run a strong CMS or PIM and want to add commerce underneath it rather than adopt a platform that owns the catalog and content. Its deliberate thinness is a strength in that situation and a gap if you do not already have the content stack, in which case commercetools' broader core does more of the work for you.
How should I compare the pricing of these platforms? Model each vendor's billing against your real order volume, GMV, and API traffic rather than comparing list prices, because these platforms bill on consumption and scale. The axis a vendor bills on interacts with your margins, so a platform that looks affordable at demo volume can become the most expensive at your actual scale. Ask each vendor for a projection on your numbers before committing.
Are these the same as open source headless engines like Medusa or Vendure? No. commercetools, Commerce Layer, and Elastic Path are managed enterprise platforms you pay for and integrate against, while open source engines add the responsibility of hosting and operating the platform yourself. The composability tradeoff of owning your integrations is similar, but the operational ownership is different, which is a separate decision covered in the open source engine comparison.
More from the lab.
Adobe's 275 Billion Dollar 2026 Holiday Forecast: Is Your Commerce Stack Ready for Peak Season
Adobe's 2026 holiday forecast puts US online sales at 275.1 billion dollars between November 1 and December 31, up 6.7 percent year over year. The bigger number in the report is not the top line: AI referred traffic to retail sites is projected to grow 130 percent, with spikes to 159 percent on Thanksgiving alone. Most teams are reading this as a marketing story. It is an infrastructure story.
Shopify Lets Meta's Muse Check Out, Amazon Blocks It: The Platform Split Over AI Shopping Agents
On September 22, Shopify and Meta announced that Muse, Meta's AI shopping agent, can search Shopify merchant catalogs and complete purchases through Shop Pay. Within days, Amazon blocked the same agent from its marketplace, citing unauthorized agent access, identity concealment, and credential collection. Two platforms, the same AI agent, and two opposite bets on what agentic commerce should look like.
Mastercard Agent Pay, Visa TAP, and ACP: The Agentic Payments Protocol Map for Merchants (October 2026)
On October 1, 2026, Mastercard added a probability score and a set of trust and intelligence signals to Agent Pay, its framework for telling issuers whether a transaction was actually initiated by an AI agent, built in partnership with agent identity provider Skyfire and with Cloudflare on the data side. The same day, trade press mapped out eight separate protocols now live in agentic commerce: MCP, A2A, ACP, UCP, AP2, TAP, Agent Pay, and MPP, backed by Anthropic, Google, OpenAI, Stripe, Shopify, Visa, and Mastercard respectively or in combination. None of them has lost. They are stacking, not competing, which is both good news and a real integration problem for anyone who is not Shopify.