Don't customize, compose! Extending Commerce Layer.
Discover how Commerce Layer's extensible architecture lets businesses implement custom pricing, shipping, and business logic while keeping their commerce platform maintainable and upgradeable.
The best commerce platform isn't the one that promises to do everything. It's the one that lets you build exactly what your business needs, without getting in your way.
Traditional commerce suites offer a reassuring proposition: catalog, pricing, checkout, promotions, and order management, all in one system. The demo looks convincing. Everything works together, and most of what you need is already there.
But businesses rarely operate exactly as a platform expects them to.
What happens when prices need to change every hour? When shipping costs depend on which products can travel together? When hundreds of customers have their own negotiated prices?
These aren't theoretical edge cases. They're real requirements that Commerce Layer customers deal with every day. And that's exactly why you build around the platform, not inside it.
These aren’t theoretical edge cases. They’re real requirements that Commerce Layer customers deal with every day. And that’s exactly why you build around the platform, not against it — and why our architecture starts from that idea.
Your business logic shouldn't live in your commerce platform
In a traditional monolith, complex business requirements can lead to modifications deep inside the platform. Over time, those customizations become harder to maintain, test, and upgrade.
Commerce Layer takes a different approach.
Its API-first architecture lets you keep business-specific logic in external services, connected to the commerce engine through APIs, webhooks, and native integration points.
Commerce Layer handles the core commerce capabilities. Your services handle what makes your business unique.
This separation means you don't have to force every requirement into the platform's data model or replicate logic that already exists elsewhere. And the benefits become particularly clear when you look at real implementations.
Real businesses, real complexity, no platform modifications
Different businesses face different kinds of complexity, from prices that shift with the market to shipping rules and omnichannel consistency.
Here are four examples of how Commerce Layer helps solve these challenges through external services and integrations, without modifying the platform itself.
Prices that change every hour
One Commerce Layer customer operates in a highly competitive market where pricing needs to react quickly. Their system regularly scrapes competitors' websites, compares prices using an external pricing engine, and updates its pricing decisions every hour. Rather than rebuilding this sophisticated logic inside the commerce platform, the customer keeps it in a dedicated service.
Commerce Layer's external pricing integration allows the commerce flow to retrieve prices from that service when needed.
Shipping a fridge isn't the same as shipping a toaster
Another Commerce Layer customer sells home appliances, from small toasters to large refrigerators.Their shipping requirements are anything but standard. A toaster can be shipped alongside a refrigerator without significantly changing the delivery requirements. But the reverse isn't necessarily true: adding a refrigerator to a shipment containing only small appliances changes the logistics entirely. A refrigerator may require two people for delivery. Two refrigerators, however, don't necessarily require four.
Standard shipping rules based on weight, quantity, or cart value can't adequately express this complexity. The customer built a custom shipping calculation service that understands product combinations, delivery constraints, and the resources required to fulfill an order.
Commerce Layer integrates with that service through external shipping methods, allowing the customer to apply its own logistics intelligence without modifying the commerce engine.
One pricing service, every sales channel
A fashion retailer using Commerce Layer operates across multiple customer touchpoints: ecommerce websites, in-store sales applications, and iPads used by store associates. All these channels need access to consistent, up-to-date prices.
Instead of maintaining separate pricing logic for every application, the retailer built a centralized pricing service that acts as the source of truth across its sales ecosystem.
Commerce Layer's external pricing capabilities allow its commerce experiences to use that same service. Prices are managed in one place, while each channel can deliver the experience it needs.
Thousands of customer-specific prices, without hundreds of markets
For B2B businesses, pricing complexity can grow quickly.
One Commerce Layer customer has an extensive catalog with customer-specific prices managed in its ERP. Trying to represent every pricing variation through native market configurations would have meant creating hundreds of markets and maintaining an increasingly complex setup.
Instead, the business chose a much simpler architecture: one Commerce Layer market per currency, with customer-specific prices resolved externally. The ERP remains the source of truth for pricing, and Commerce Layer retrieves the appropriate price through its external pricing integration. No duplication of the entire price structure. No unnecessary proliferation of markets. No need to rebuild established ERP pricing logic inside the commerce platform.
Two ways to extend Commerce Layer
These examples share a common principle: business-specific logic lives outside the commerce engine.
Commerce Layer supports two complementary extension patterns:
- Synchronous integrations
Allow Commerce Layer to call external services during a commerce flow, when an immediate response is needed. External pricing, shipping costs, and order validation are examples. - Asynchronous integrations
Use webhooks and events to trigger actions after something happens in Commerce Layer, such as synchronizing orders with an ERP, updating a CRM, or orchestrating fulfillment workflows.
Both approaches allow developers to build focused services using the technologies and infrastructure they prefer. And because these services interact with Commerce Layer through documented interfaces, they can be developed, tested, and deployed independently of the platform's internal code.
Upgrade Commerce Layer, not your customizations
This separation has an important long-term consequence.
In a heavily customized monolith, platform upgrades can require reconciling custom code with changes to the underlying product. What begins as a small modification can eventually become an expensive maintenance commitment.
With Commerce Layer, custom logic doesn't need to be merged into the platform whenever it evolves.
Commerce Layer continuously improves its managed commerce infrastructure, while your extensions remain independently maintained through supported integration contracts. You can change your pricing algorithm without modifying your checkout engine. You can improve shipping calculations without touching order management. You can connect a new ERP without rebuilding your commerce platform.
Integrations still need testing and maintenance, particularly when APIs or dependencies evolve. But that work stays focused on the services you own, rather than on maintaining a private version of the commerce platform.
AI makes this architecture even more valuable
AI coding assistants are making small, well-defined services faster to build and maintain.
A pricing integration, a shipping calculation service, or an event-driven workflow has a clear purpose and a defined interface. These are exactly the kinds of components AI-assisted development can help teams implement, test, and evolve efficiently.
Instead of asking AI to modify a large, tightly coupled commerce application, developers can focus on independent services that interact with Commerce Layer through documented APIs. The platform stays stable. Custom logic stays manageable. And experimenting with new capabilities becomes easier.
One engine, endless business models
The four customers above have very different requirements.
- One needs prices that react to competitors every hour.
- Another needs shipping calculations that understand the physical realities of delivering appliances.
- A fashion retailer needs consistent pricing across channels.
- A B2B business needs to support extensive customer-specific pricing without an explosion of market configurations.
Commerce Layer doesn't need to have every one of these business rules built into its core.
That's the point.
Commerce Layer provides a reliable, extensible commerce engine and gives businesses the freedom to connect the systems, services, and logic that make them competitive.
You don't have to replace what already works. You don't have to compromise on your business requirements. And you don't have to maintain a customized version of your commerce platform.