B2B marketplace: OroCommerce or CWS Platform on the CFO's spreadsheet?

Editorial note: an architecture comparison between OroCommerce and CWS Platform for a B2B marketplace with third-party sellers, written for the CFO, who decides whether the numbers work. Every fact about OroCommerce comes from its public documentation, with the address next to it.

When a distributor decides to open its own platform to other sellers, the pitch usually talks about assortment and traffic. The CFO's spreadsheet talks about something else. It asks which software edition the model requires, what has to be provisioned before the first payment goes through, and whose percentage shows up in the split of every sale.

A B2B marketplace usually grows out of an operation that already sells. That is why the math is not only about new revenue: it is about what it costs to bring the first seller live and how much each party keeps when the order is paid.

This comparison looks at OroCommerce and CWS Platform from that angle only: edition, payment provisioning, and the split percentage. It is not a feature ranking. The math of a license tied to GMV bands, which applies to any channel, was covered in the comparison what goes into the bill when the digital channel grows.

55s

What OroCommerce does well

OroCommerce has a marketplace design documented in detail. According to the marketplace guide, OroMarketplace is an extension of OroCommerce Enterprise built on organizations: the operator is an organization of the General type, with global access, and each seller is an organization of the Marketplace Seller type, with access restricted to its own orders and inventory.

Sellers come in through three paths: a storefront form tied to a registration workflow, a manually created request, or direct creation of the organization in the back office. When a storefront registration is approved, the platform automatically creates a seller administrator, inventory control, and a default price list. Product creation by sellers is enabled by default.

At checkout, the buyer sees a single cart and a single invoice, and the engine splits line items by seller on the back end, routing each seller's order and fulfillment. The OroMarketplace features page adds that sellers can manage multiple warehouses and quote workflows, and that the operator's monetization can be set up through transaction fees, subscriptions, or additional services, with formulas configured per seller.

Where the architecture diverges

The divergence that matters to the marketplace math sits in two lines of the vendor's documentation, one about edition and one about the payment path:

• limitation recorded in the vendor's documentation, accessed on October 16, 2026: multi-website management is only available in the Enterprise edition ("Multi-website management is only available in the Enterprise edition.", https://doc.oroinc.com/user/back-office/system/websites/manage/).
• limitation recorded in the vendor's documentation, accessed on October 16, 2026: OroPay must be provisioned in the cloud environment and requires an approved Global Payments merchant account before configuration ("OroPay must be provisioned in your cloud environment, and you need an approved merchant account with Global Payments, before you can complete the steps below.", https://doc.oroinc.com/user/back-office/system/integrations/payment-integration/oropay/).

The first one sets the entry level. The marketplace is already an Enterprise extension, and an operator that wants one storefront for its own customers and another for the partner channel, each with its own domain, catalog, and payment methods, also needs the Enterprise edition to manage multiple websites. On the spreadsheet, the marketplace and multi-website come in through the same door.

The second one sets the order of steps. OroPay, which in OroCommerce acts as gateway, processor, and acquirer through Global Payments, is configured only after provisioning in the cloud environment and approval of the merchant account. When OroPay is the chosen method, that lands on the CFO's timeline: the first paid order depends on an underwriting process that runs outside the software project.

On CWS Platform, billing is a platform license plus an integration license, with no percentage of sales or GMV. In the marketplace, the percentage that shows up in the payment split is the marketplace owner's commission, not CWS's. The same order accepts more than one payment method, with rules combined in the CDL Workspace and maintained through an API, and the CDL Workspace is a single system for the entire ecosystem.

The financial decision is separating three lines that usually arrive bundled in a proposal: the software, payment underwriting, and the marketplace commission.

What changes in B2B marketplace operations

For the CFO, the difference shows up at three moments in the life of the marketplace.

The first is launch. Before the first seller sells, the model calls for a defined edition, a provisioned environment, and an underwritten payment method. It is worth putting the three dependencies side by side on the timeline. Payment method underwriting is a question for any vendor: who underwrites, with which acquirer, and how long it takes. On CWS, the same order accepts more than one payment method, with rules combined in the CDL Workspace.

The second is the margin on each order. In a marketplace, the buyer pays once and the amount is split between the seller and the operator. The CFO's question is whether, beyond the commission the operator itself set, any other percentage applies to the same sale. On CWS, billing is a platform license plus an integration license, and the split percentage is the marketplace owner's commission. A marketplace that grows out of an operation that is already digital is usually measured by the transaction cost it removes from the supply chain, and not only by the commission it generates.

The third is commercial policy across the ecosystem. With several sellers, one seller's promotion cannot break another's rule, and each customer's price table has to keep applying. On CWS, price tables, rules, and contracts are configurable on the platform and can come from the ERP or the CRM through an API, thousands of promotions can run at the same time, and commercial policy sits in parameters of the Commerce Rules Engine (CDL Workspace).

Three questions help bring this point into a negotiation with any vendor: which edition the marketplace requires and what else it changes in the contract; what has to be approved outside the project before the first payment; and who keeps each percentage of a split sale.

When to choose OroCommerce

OroCommerce fits scenarios with these characteristics:

An operator already on the Enterprise edition. Choose this architecture when the company already runs or will run Enterprise and wants the marketplace as an extension of it, with sellers as organizations, as the marketplace guide describes.

Operator monetization with a formula per seller. Choose this architecture when the operator's revenue model combines transaction fees, subscriptions, and services, configured seller by seller, as the OroMarketplace features page presents.

Payments concentrated in one acquiring partner. Choose this architecture when the company wants gateway, processing, and acquiring in a single service and accepts underwriting with Global Payments, as the OroPay integration describes.

When CWS Platform is the right choice in this scenario

CWS Platform is the right choice when the CFO wants to separate the software line from the marketplace commission and keep the whole ecosystem in a single system.

A commission that belongs to the marketplace owner. Choose this architecture when the marketplace math has to show that the split percentage is the operator's commission. CWS billing is a platform license plus an integration license, with no percentage of sales.

Payments by rule. Choose this architecture when an order needs to combine more than one payment method. The rules live in the CDL Workspace and are maintained through an API.

A single system for the ecosystem. Choose this architecture when operator, sellers, customers, and sales reps need to work in the same environment. The CDL Workspace is a single system for the entire ecosystem, and customer and sales rep use the same interface.

Commercial policy that coexists across sellers. Choose this architecture when the marketplace will run many promotions at once. Thousands of promotions can run at the same time, with commercial policy as parameters, on the principle of configuration over code.

Where to go from here

If the question is still which platform model fits your operation, before any vendor, the starting point is the three B2B commerce platform models.

If the decision depends on how much the marketplace should return to the operator and to the sellers, it is worth talking to a CWS Platform specialist and modeling, with your own numbers, the three lines: software, underwriting, and commission. The page When Selling More Doesn't Mean Earning More covers the pain behind this scenario in depth, without talking about any vendor.