When Integration Breaks Everything · October 16, 2026 · 6 min

The Three B2B Commerce Platform Models: Assemble, Buy Ready-Made, or Move Commercial Rules Into the Platform

Composable platform, ready-made B2B platform, or infrastructure with commercial rules in the platform: what each vendor's documentation records.

Executive standing beside a conference table, with two colleagues in the background discussing a diagram on a whiteboard.

Editorial note: a category guide for anyone evaluating B2B commerce platforms. Every fact about the vendors mentioned comes from each one's public documentation, with the address next to it.

Anyone shopping for a B2B commerce platform runs into three models, and they usually arrive mixed together on the same vendor shortlist. Each model answers the same question differently: where do the distributor's commercial rules live, and who pays to maintain them?

The first model is the composable platform you assemble: a set of APIs or modules on which the customer's team builds the storefront, the integrations, and the commercial rules. commercetools and Spryker sit here. The second is the ready-made B2B platform for distributors: B2B features out of the box, configured and connected to the ERP through an implementation project. Optimizely Configured Commerce and OroCommerce sit here. The third is B2B selling infrastructure with commercial rules inside the platform, as parameters changed by configuration. That is where CWS Platform sits.

This guide describes the three models by what each vendor's documentation records, so the choice starts with the architecture and not with the feature list.

Read more on The Cost of Selling Watch on YouTube Subscribe

Model 1: the composable platform you assemble

In a composable platform, the platform delivers building blocks and the customer's team decides how to put them together. commercetools offers APIs per domain, such as Business Units and Approval Rules. Spryker offers B2B modules, such as Company Account, and order state machines configured in the project's code.

Three models side by side: loose blocks to assemble, a ready-made box with a project wrench, and a box with a parameter panel.

The strength is control: the technical team chooses every piece. The cost is that commercial rules, the front end, and the integrations become the customer's code, and the commercial packaging and roadmap of each piece enter the math. Both vendors' documentation records examples:

limitation recorded in the vendor's documentation, accessed on October 16, 2026: functionalities annotated with a B2B label are subject to additional or different terms and pricing ("Functionalities annotated with a B2B label on the respective pages are subject to additional or different terms and pricing.", https://docs.commercetools.com/offering/order-form-definitions).
limitation recorded in the vendor's documentation on February 25, 2026: the App Composition Platform is being sunset and allows no additional activations or changes ("The Spryker App Composition Platform is being sunset. No additional activations or changes are allowed.", https://docs.spryker.com/docs/dg/dev/acp/app-composition-platform.html).

This model serves companies with a dedicated engineering team that wants to compose its own architecture and has the budget to maintain it.

Model 2: the ready-made B2B platform for distributors

In a ready-made platform, B2B features come out of the box. Optimizely Configured Commerce brings customer-specific pricing through the Price Matrix, quoting, and punchout. OroCommerce brings customer-specific price lists, quoting, and payment terms.

Timeline between the platform's out-of-the-box features and the ERP, with a wrench in the middle standing for the implementation project.

The strength is starting with the B2B essentials already in place. The cost sits in the project that connects the platform to the ERP and adapts the features to the distributor's policy, work that both vendors' documentation assigns to the partner and to implementation time:

limitation recorded in the vendor's documentation, accessed on October 16, 2026: for most connectors the implementation partner is responsible for evaluating, designing, developing, implementing and testing ("For most connectors, an implementation partner is responsible for evaluating, designing, developing, implementing, and testing the connector.", https://docs.optimizely.com/configured-commerce/docs/non-payment-connector-expectations).
limitation recorded in the vendor's documentation, accessed on October 16, 2026: the average implementation time is about six months ("The average implementation time is about six months.", https://oroinc.com/b2b-ecommerce/faq/).

This model serves distributors with a stable commercial policy that fits the out-of-the-box features and with an implementation partner already chosen.

Model 3: B2B selling infrastructure with commercial rules in the platform

In the third model, commercial rules are the center of the platform. On CWS Platform, price tables, rules, and contracts sit in parameters of the Commerce Rules Engine (CDL Workspace), configured on the platform or received from the ERP and CRM through an API, with customizable decimal places. The integration moves data in and out, and tax comes from the ERP or from the tax engine the customer already uses.

CDL Workspace is a single system for the entire ecosystem: one sales rep serves thousands of customers, and customer and sales rep use the same interface, on the same order. Net terms work with split shipments, scheduled deliveries, multiple ship-to addresses, and multiple ship-from locations, and thousands of promotions can run at the same time. All customers run the same version of the platform, and billing is a platform license plus an integration license, with no percentage of sales or GMV.

This model serves distributors and manufacturers whose commercial policy changes often and needs to be maintained through configuration, on the principle of configuration over code.

question	composable platform	ready-made B2B platform	commercial rules in the platform
Where commercial rules live	In the customer's code, on top of APIs or modules	In out-of-the-box features, configured during the project	In parameters changed by configuration
Who builds and maintains the integration	The customer's team	The implementation partner or the customer's team	REST APIs and webhooks, with a dedicated integration license
What drives cost over time	The team that maintains the code and the commercial packaging of each piece	The implementation project and adapting it to commercial policy	The platform and integration license, with no percentage of sales

How to choose the model before the vendor

Three questions separate the models before any demo: how many times a month your commercial policy changes, and who makes the change; who will build and maintain the ERP integration, and under which contract; and which variable should move the software line in the budget, the volume you sell or the scope of the platform.

A path that splits into three, with three questions on the trunk: how often policy changes, who builds the integration, and what moves the license.

If the policy rarely changes and there is an implementation partner, the ready-made platform is a natural path. If there is an engineering team that wants to compose the architecture, the composable platform is. If commercial policy is what sets the distributor apart and changes every week, the rules need to live in the platform.

Where to go from here

If your question is still which architecture fits your operation, the path is the seven questions that separate B2B commerce architectures.

If the decision depends on how your commercial policy works today, it is worth talking to a CWS Platform specialist to find out which of the three models it fits. The page When Integration Breaks Everything covers the pain behind this scenario in depth, without talking about any vendor.