Adobe Commerce vs. CWS Platform: What Architecture Does a B2B Marketplace With Sellers Require?

Editorial note: an architecture comparison between Adobe Commerce and the CWS Platform for a B2B marketplace with third-party sellers. Every statement about Adobe Commerce comes from its public documentation, with the source linked alongside it.

Adobe Commerce vs. CWS Platform is a decision about where commercial policy should live in a B2B marketplace with sellers. The central issue is not publishing more products. It is enabling manufacturers, distributors, and dealers to sell through the same channel while preserving their own pricing, inventory, credit, and fulfillment policies within the governance defined by the marketplace operator.

For the Head of Commerce, the architecture must turn independent sellers into a coherent buying experience. For the CEO, it must support a network in which the operator, sellers, and buyers all recognize value. For the CFO, it must make commissions, credit, payments, seller payouts, and order accountability traceable parts of each transaction.

The useful question, therefore, is not which platform has more features. It is which one organizes the operation’s real complexity: multiple inventory owners, distinct commercial policies, competing offers for the same item, credit extended by different parties, and the risk of channel conflict between direct sales and the marketplace.

69s

The scenario: multiple sellers, one buying experience, and distributed commercial policies

A governed B2B marketplace does not emerge simply because a company decides to onboard suppliers. It takes shape when an existing operation can distribute its selling and negotiation processes through a shared channel without forcing every commercial variation into a single centralized price table. The marketplace is an outcome of digitizing the value chain, not an isolated goal.

In this scenario, the operator brings together manufacturers, distributors, and dealers. Each seller may have its own inventory, ship-from entity, payment terms, credit limit, service territory, discount policy, and logistics capabilities. The buyer, however, expects to find comparable products, understand which offer can actually be fulfilled, and complete a coherent transaction—even when the cart includes items from different sellers.

The architectural tension exists because governance does not mean uniformity. If the operator centralizes every decision, it reduces the economic autonomy that makes the network attractive. If each seller can act without shared boundaries, the channel loses consistency across pricing, delivery, credit, and service. The platform must turn the operator’s commercial strategy into executable parameters while preserving room for each participant’s policies.

Viability depends on explicit economic rules, sellers that can deliver on the promise, demand that recognizes the channel’s value, and operational execution connected to the order. Technology organizes these conditions, but it does not replace any of them. Discovery should therefore begin with the decision flow, not the appearance of the storefront.

The six decisions this scenario requires

The decisions below form the evaluation framework for this scenario. Together, they reveal whether the marketplace will be merely a catalog aggregation or a distributed commercial operation with clear accountability in every transaction.

1. Who owns each seller’s pricing. Every offer needs an identifiable policy owner. Centralizing all pricing under the operator simplifies publishing, but it can erase differences in cost, origin, volume, lead time, and seller strategy. Distributing that decision requires shared boundaries, buyer context, and an audit trail for changes.

2. How the operator charges fees and pays sellers. Monetization must be defined as part of the order. When commissions, splits, and payout obligations are recorded only afterward, reconciliation must reconstruct logic that should already have been known when the order was placed. The transaction design should preserve the relationship among the parent order, each seller’s operational portion, and the operator’s compensation.

3. Who extends payment terms to the buyer. Terms are a risk decision, not simply a checkout option. The architecture must identify the party assuming the exposure, retrieve the applicable terms, and evaluate the purchase against the credit policy before confirming the commitment. That decision may vary by seller, buyer, order value, and cart composition.

4. Who owns the inventory shown to the buyer. Availability must be tied to the source that will actually fulfill the order. An offer without an operational connection to inventory creates a commercial promise without the ability to execute it. When multiple sources are available, selection must also consider region, shipping cost, lead time, and tax rules.

5. How multiple seller catalogs become one. Product governance must separate item identity from offer identity. The buyer should recognize that different offers refer to the same product, while the operation preserves each alternative’s seller, price, availability, and delivery terms. Creating nearly identical duplicate product records merely transfers complexity to search, navigation, and customer service.

6. How the direct channel coexists with the marketplace. Coexistence depends on channel rules defined before participants begin competing for the same buyer. Account ownership, territory, demand source, pricing policy, commissions, and sales-rep participation must guide the flow. The digital channel should reduce the cost of serving the value chain, not create uncontrolled competition among its participants.

What operators say is broken today

Comments from the field make visible the decisions that are usually hidden in spreadsheets, integrations, and commercial agreements.

“The customer asks for it, we don’t have it, and they buy from a competitor. My supplier has the item, but I have no way to sell it.” This reveals the decision about whose inventory is displayed and under which rules the operator may sell third-party availability.

“Every customer has negotiated pricing, and no one can put that on the website.” This reveals the decision about who controls pricing and discounts. It also shows why publishing a standard price list does not represent a contextual B2B negotiation.

“The customer puts everything in the cart and abandons checkout because net terms aren’t available.” This reveals the decision about who extends credit and when risk is evaluated. Checkout stops being merely a final screen and becomes a commercial decision point.

“The portal shows inventory that no longer exists.” This reveals the decision about which availability supports the promise made to the buyer. It also exposes the difference between copying an inventory balance and keeping the transaction connected to the operational source that will fulfill the order.

How Adobe Commerce structures this scenario

Adobe’s B2B architecture is enabled as a solution integrated with the platform and can coexist with a B2C operation. Its organizing unit is the company account, which brings buyers together and allows the company administrator to configure divisions, users, roles, and permissions for orders, quotes, purchases, credit, and profiles. The store administrator defines capabilities such as payment methods and pricing levels through the B2B configuration.

Commercial policy is expressed through shared catalogs, which apply product-level pricing to companies or customer groups. Negotiation can occur through a quote initiated by the buyer from the cart or by a sales representative in the administrative environment. Items, quantities, discounts, and messages can be revised until the parties reach an agreement within the documented workflow.

Purchase orders can be enabled at the company level, causing orders for that account to be created in purchase-order form and submitted to approval rules based on the user’s role and the order itself. This mechanism places the weight of governance on the buying company’s structure, its user permissions, and the procurement processes configured by the administrator for the B2B operation.

The payments layer centralizes payment and order data from the merchant’s storefronts in the admin dashboard. Deployment separates sandbox and production environments, payment-method availability varies by region, and services connect through the platform’s shared connector described in the payments guide.

To separate digital contexts, one instance is organized into websites, stores, and store views. The website level contains configurations such as shipping and payment. Stores can share a catalog, administration, and checkout, while store views control presentation elements, language, currency, and base URL within the site hierarchy.

For a marketplace with sellers, these mechanisms should be understood according to where they concentrate the modeling: company accounts represent buyers, shared catalogs distribute pricing by company, and the site hierarchy separates storefront contexts. The documentation also presents a prebuilt integration with an external order-management layer as part of the B2B architecture in the solution overview.

How the CWS Platform works: each seller’s policy within transaction governance

The CWS Platform starts with the seller as an operational participant in the channel. The Marketplace Management Platform (Marketplace Center) organizes assisted onboarding, configurable take rates, offer selection, seller health monitoring, commercial-relationship protection, and operational cart splitting. Child orders remain linked to the parent order, preserving each participant’s fulfillment accountability.

Policy is executed through the Commerce Rules Engine (CDL Workspace). Instead of turning differences among sellers into manual exceptions, rules determine what each context may sell, negotiate, approve, and route. Material changes include a reason and an author, allowing the operator to distribute autonomy without losing visibility into how each decision was made.

Contextual Pricing (Pricing Engine) treats price as the outcome of commercial context. Buyer identity, fulfillment source, volume, region, payment terms, and other variables can participate in the decision. Each seller can therefore maintain its own policy within the ecosystem’s boundaries, while the operator avoids letting a single price table erase different costs and strategies.

Credit-First B2B Checkout (Checkout & Payments) makes credit part of the purchase itself. Before a commitment is confirmed, the transaction validates inventory, price, credit, and tax within the same transaction. This connects the extension of terms to the seller, buyer, and applicable policy instead of reducing B2B payment to a user-interface choice.

The Order Management System (OMS / Seller Center) keeps the order and its related components in controlled operational states. Status, invoices and tax documents, payment, and tracking follow execution, while child orders preserve their connection to the original purchase. Commissions and operational splits no longer depend solely on after-the-fact reconstruction because the order structure already identifies the participants involved.

Product Catalog & MDM (Catalog Engine) governs item identity and product composition. The same product can have a shared identity while its offers preserve seller, source, price, and availability. The catalog-enrichment agent helps process attributes and images, reducing duplication caused by different supplier naming conventions.

Shipping & Fulfillment (Logistics Engine) calculates execution for carts with multiple origins. The operation can split fulfillment by seller or warehouse, calculate pricing by source, support different freight responsibilities, and allow partial deliveries. Offer selection therefore does not need to consider only the lowest published price, because deliverability and operating cost are also part of the commitment.

The direct channel coexists with the marketplace through policy. Rules covering demand source, account ownership, pricing, discounts, and sales participation can guide fulfillment, while relationship-protection mechanisms reduce incentives to move transactions outside the governed environment. The goal is to build a network in which the seller, operator, and buyer all have economic reasons to remain within the flow.

The CWS Platform has 11 modules, 6 AI Agents, and 1,029 configurable parameters. This composition places the emphasis on converting the operator’s commercial model into executable behavior. The rules-audit agent helps identify conflicts and changes, while the sales-support agent provides context for negotiations that require human intervention.

The final benchmark is the value chain’s transaction cost. A marketplace creates value when it reduces the work required to discover supply, validate terms, assume risk, divide accountability, and track execution. A broad catalog alone merely relocates complexity; the architecture must fit that complexity into a governed, repeatable decision.

Where the architectures truly diverge

One architecture expresses B2B policy primarily through the buyer’s company account, including its users, permissions, shared catalogs, quotes, and purchase orders configured within the B2B solution. The other places the seller, offer, warehouse, commercial rule, and child order at the center of marketplace operations.

In the first, digital contexts are separated through the website, store, and store-view hierarchy, with sharing or isolation determined by the selected level within the multi-site structure. In the second, the operational context combines seller, fulfillment source, catalog, price, credit, logistics, and the boundaries established by central governance.

The difference also appears at the payment control point. One architecture centralizes payment and order data from storefronts and separates service deployment between sandbox and production environments within the documented flow. The other treats credit, take rate, order splitting, and operational accountability as related components of the B2B transaction.

Adobe's own product description records how an order is counted in the license:

• limitation recorded in the vendor's documentation on April 30, 2026: every accepted order counts as a transaction, even if it is later refunded, returned, or charged back ("even if such order is later subject to a refund, return, chargeback", https://helpx.adobe.com/legal/product-descriptions/adobe-commerce-on-cloud.html).

The choice depends on the object the company needs to govern. If the core requirement is the procurement structure of large enterprise accounts, the company account guides the design. If the core requirement is allowing independent sellers to retain their own policies and execution within a common channel, the multi-seller transaction becomes the decisive unit.

When Adobe Commerce is the right choice for this scenario

Choose this architecture when the primary requirement matches the scenarios below. In each case, the decision centers on how well the documented mechanism fits the desired operating structure.

The buying process must reproduce the buyer’s formal organizational structure. Choose this architecture when a company account must organize buyers into divisions, subdivisions, users, roles, and permissions covering orders, quotes, purchases, credit, and profiles. The documented mechanism allows the administrator to configure that structure and control the capabilities available to each company.

The process requires role-governed purchase orders. Choose this architecture when every order from a specific company must begin as a purchase order and follow approval rules associated with the user’s role and the order itself. This flow is enabled at the company-account level and then governs purchases made by its users according to the B2B configuration.

The priority is operating brands, languages, or storefronts within a common hierarchy. Choose this architecture when the central need is to separate websites, stores, and store views within one instance while sharing or isolating catalogs, carts, checkout, shipping, payments, languages, and presentation according to the hierarchy level. The documented hierarchy is designed to organize these contexts within website and store administration.

The operation wants to centralize storefront payments in the commerce admin. Choose this architecture when the requirement is to connect payment services to the instance, test the configuration in a dedicated environment, and then process production payments with data centralized in the admin dashboard. The mechanism uses a connector shared by platform services and makes payment methods available by region in the deployment guide.

Personalization depends on a broad behavioral-data layer. Choose this architecture when the company wants to send storefront events, order history, profile data, and back-office information to a data platform and build segments for omnichannel journeys. The documented integration connects these signals to the data layer and journey tools to adapt campaigns, communications, and content to the customer’s context.

Where to go next

If your question is still which architecture fits your operation—not which vendor to select—continue with the seven questions that separate B2B commerce architectures.

If the immediate issue is the operational pain behind this scenario, When the Catalog Turns into Chaos and When Selling More Does Not Mean Earning More explore it in depth without discussing any vendor.