Marketplace B2B com sellers: SAP Commerce Cloud ou CWS Platform?

Nota editorial: comparativo de arquitetura entre SAP Commerce Cloud e a CWS Platform no cenário Marketplace B2B com sellers. Todo fato sobre SAP Commerce Cloud vem da documentação pública dele, com o endereço ao lado.

Operar um marketplace B2B reúne múltiplos fornecedores, indústrias e distribuidores em um único canal transacional voltado a empresas e revendas. A complexidade do modelo não reside apenas em exibir produtos em uma vitrine compartilhada, mas em preservar a autonomia comercial de cada seller sem que o operador central perca a governança fiscal, financeira e logística da operação. Ao avaliar plataformas para essa jornada, executivos como Diretor de Commerce, CEO e CFO comparam abordagens distintas de arquitetura, contrapondo abordagens de arquitetura distintas, como a do SAP Commerce Cloud e a da CWS Platform.

O ponto de tensão central está em coordenar tabelas de preços customizadas, múltiplos estoques distribuídos, linhas de crédito corporativas e divisão de recebíveis no mesmo carrinho de compras. Quando a plataforma trata regras comerciais como cadastros estáticos, o operador se vê forçado a arbitrar concessões manuais ou a conviver com atritos constantes entre seus parceiros comerciais e a força de vendas interna.

A escolha arquitetural define se o marketplace conseguirá escalar com sustentabilidade operacional ou se gerará custos crescentes de transação a cada novo seller integrado à rede.

68s

O cenário: Marketplace B2B com múltiplos sellers e governança central

No modelo de marketplace B2B com sellers, o operador atua como o orquestrador de uma cadeia em que fabricantes e distribuidores comercializam insumos, peças ou mercadorias acabadas diretamente para clientes corporativos, cooperados ou oficinas. Cada seller possui realidades tributárias distintas, políticas de margem próprias, prazos de pagamento específicos e estoques físicos alocados em diferentes regiões do país. Para o cliente comprador, o portal precisa oferecer conveniência, busca unificada e previsibilidade de entrega.

Para o Diretor de Commerce, o desafio é manter a coerência da experiência digital sem engessar as condições comerciais dos vendedores cadastrados. O CEO precisa garantir que a expansão de sortimento não destrua o relacionamento da empresa com sua rede tradicional de distribuição, evitando a desintermediação predatória. O CFO, por sua vez, monitora a integridade da divisão de pagamentos, a concessão de crédito comercial com mitigação de risco e a ausência de passivos fiscais decorrentes de cruzamentos interestaduais incorretos.

A viabilidade da operação depende de equilibrar a descentralização de regras de negócio na ponta com a centralização da governança transacional no núcleo da plataforma.

As seis decisões que o cenário obriga

A estruturação de um marketplace com múltiplos sellers exige definições arquiteturais em seis decisões críticas de negócio:

1. Quem é dono do preço de cada seller. O sistema precisa processar matrizes de preço contextuais que considerem a origem do despacho, a tributação de destino, o perfil cadastral da pessoa jurídica e eventuais contratos prévios de cada seller. Se a plataforma impõe uma tabela estática centralizada, inviabiliza a participação de parceiros que operam sob margens estreitas e custos logísticos variáveis.

2. Como o operador cobra e repassa. A liquidação financeira deve calcular comissões, regras de repasse e a retenção do operador no momento exato em que o checkout ocorre. Transferir a divisão de valores para reconciliações manuais fora do fluxo digital eleva os custos operacionais e gera litígios com os parceiros integrados.

3. Quem concede o prazo ao comprador. A concessão de prazo de pagamento exige avaliação do saldo de limite de crédito do comprador no ato da transação, identificando se o risco é assumido pelo seller, pelo marketplace ou por agente financeiro. A ausência de validação transacional síncrona expõe a operação a compras que superam o limite disponível.

4. De quem é o estoque que o comprador vê. A visualização de inventário deve refletir o saldo real distribuído dos depósitos físicos de cada vendedor, sem depender de sincronizações em lote que gerem rupturas. Exibir dados defasados conduz ao cancelamento de pedidos corporativos e à quebra de confiança no portal.

5. Como o catálogo de vários sellers vira um só. A organização do catálogo exige consolidar itens idênticos sob um mesmo identificador técnico, viabilizando regras de concorrência por preço, proximidade física e prazo de despacho. A multiplicação desordenada de anúncios quase idênticos fragmenta a navegação e prejudica a localização de itens técnicos.

6. Como o canal próprio convive com o marketplace. A convivência entre a venda direta e o ecossistema de sellers demanda barreiras sistêmicas de carteirização e transparência operacional na transação. Sem mecanismos que protejam o papel do vendedor e do distribuidor regional, a iniciativa digital canibaliza a própria força comercial existente.

O que trava hoje, na voz de quem opera

O dia a dia de distribuidores e indústrias operando canais digitais revela os atritos práticos enfrentados pelos times de negócio:

“Cada cliente tem o preço dele, ninguém consegue colocar isso no site.”

“O cliente coloca tudo no carrinho e desiste no checkout porque não tem boleto a prazo.”

“O cliente pede, a gente não tem, e ele compra do concorrente. O item existe no meu fornecedor, mas não tem como eu vender.”

“O mesmo produto aparece com três preços diferentes: meu portal, meu D2C, o Mercado Livre.”

O que o SAP Commerce Cloud resolve bem neste cenário

Para marketplace, a resposta da SAP é o SAP Commerce Marketplace Management, extensão em modelo SaaS que requer a aplicação Mirakl, de terceiro, integrada ao SAP Commerce Cloud por interfaces e APIs padrão aprovadas pela SAP (SAP e Mirakl Marketplace Management). A SAP documenta para essa solução a automação do onboarding de sellers, com fluxos automáticos de aprovação e recusa e mapeamento de catálogo por arrastar e soltar; regras de negócio para gerenciar níveis de serviço, com remoção automática do estoque de sellers que operam fora do SLA; e, no checkout, divisão de pedidos (order splitting), retirada em loja e precificação e pagamentos granulares para fluxos B2B (SAP Commerce Marketplace Management).

O SAP Commerce Cloud opera como uma plataforma modular implantada exclusivamente sobre infraestrutura de nuvem pública na versão 2211, documentada na documentação do SAP Commerce Cloud. A sua arquitetura técnica é estruturada em extensões que encapsulam a lógica de negócio, definições de tipos de dados e personalizações do Backoffice, associadas a AddOns que inserem componentes de interface no storefront. A exposição de serviços de dados e transações ocorre prioritariamente por meio de APIs RESTful via Omni Commerce Connect (OCC), conforme detalhado no portal de arquitetura SAP Commerce Cloud.

Para a camada visual, a solução disponibiliza o SAP Commerce Cloud composable storefront, uma aplicação web JavaScript construída sobre Angular descrita na documentação do Composable Storefront. Essa aplicação opera de modo desacoplado, comunicando-se exclusivamente por meio da Commerce REST API e permitindo que o pipeline de integração contínua compile o storefront de forma independente sempre que o back-end não sofrer alterações de código, conforme documentado no guia de build do Composable Storefront.

A integração com o SAP S/4HANA ou o SAP ERP utiliza o SAP Cloud Integration por meio do pacote de integração documentado no portal de integração SAP Commerce com ERP. Esse pacote depende de extensões como odata2webservices e integrationbackoffice no arquivo localextensions.xml para receber condições de preço e desconto via adaptadores OData nos endpoints InboundPriceRow e InboundDiscountRow. Na gestão de pedidos e abastecimento, o módulo de sourcing e disponibilidade requer componentes adicionais, como registrado na documentação de integração do SAP Order Management.

No fluxo transacional e de liquidação, o Open Payment Framework oferece fluxos padronizados de autorização, captura, estorno e reautorização com ferramentas low-code para conexão com provedores de pagamento terceiros (pagamentos e promoções do SAP Commerce Cloud), enquanto a precificação de catálogo pode atuar síncrona ao back-end ou por replicação via uploads delta após desativar o parâmetro correspondente no cockpit administrativo, conforme a documentação de replicação de preços SAP.

Como a CWS Platform monta: governança distribuída e execução comercial no mesmo fluxo

A CWS Platform estrutura a operação de canais compartilhados a partir do Marketplace Management Platform (Marketplace Center), módulo responsável por gerenciar a entrada de parceiros, o modelo de buybox e a convivência entre sortimentos próprios e terceirizados. Em um portal de compras B2B com parceiros, a unidade fundamental de configuração é o armazém. Cada depósito tem frete e prazo de despacho próprios, as regras de preço podem ter escopo por estoque e cada loja configura seus pagamentos, sempre dentro dos critérios gerais definidos pelo dono do portal.

Para solucionar a divergência de valores e margens entre participantes, o Contextual Pricing (Pricing Engine) calcula em tempo real o preço líquido de cada SKU a partir de uma hierarquia determinística em que o contrato do cliente prevalece sobre a regra contextual e esta sobre a tabela base. As regras de preço podem ser elegíveis pelo par UF do depósito e UF de destino, pelo NCM da mercadoria e pelo CNAE do comprador, e os contratos podem ser limitados por marketplace, UF de destino e filiais. Quando múltiplos fornecedores oferecem o mesmo item, o Marketplace Management Platform (Marketplace Center) aplica a regra de buybox configurada para exibir a oferta vencedora por menor valor líquido ou por menor distância em quilômetros, mantendo as demais opções acessíveis em lista complementar.

A divisão transacional de recebíveis e o faturamento corporativo são executados pelo Credit-First B2B Checkout (Checkout & Payments). O valor é dividido entre as lojas conforme o contrato marketplace x loja, com percentual do marketplace por cenário de venda e comissão especial por SKU ou categoria. A plataforma trata o limite de crédito comercial como uma conta corrente associada ao cliente, permitindo compras com prazo faturado: com saldo suficiente o pedido é aprovado automaticamente e, sem saldo, a loja define por regra se ele fica pendente de aprovação. No carrinho com vários sellers, cada fornecedor configura seus pagamentos dentro dos critérios do dono do portal, e um mesmo pedido pode combinar limite de crédito com cartão ou boleto.

A logística multi-CD e multi-origem é orquestrada pelo Shipping & Fulfillment (Logistics Engine), que realiza a separação dos fretes e prazos de acordo com os pontos físicos de expedição. Concomitantemente, o Order Management System (OMS / Seller Center) garante a autonomia operacional de cada parceiro: o pedido do cliente se divide em pedidos filhos por loja e por depósito, só a credencial do seller que vendeu atualiza o status do seu pedido, cada lojista envia os e-mails de status dos seus itens e o cancelamento pelo seller depende de habilitação pelo marketplace. A sincronização com sistemas de retaguarda ocorre por meio de webhooks de eventos e APIs REST, assegurando que o status transacional permaneça consistente em toda a cadeia.

A arquitetura da CWS Platform coloca seu peso na redução do custo de transação da cadeia de distribuição: ao permitir que cada seller configure suas particularidades operacionais dentro de uma governança central automatizada, reduz-se o atrito administrativo e viabiliza-se a expansão sustentável da rede de parceiros.

Onde nascem as dores deste cenário, e como a arquitetura as resolve:

Onde as arquiteturas divergem de verdade

A divergência fundamental entre as abordagens reside em como a regra comercial de múltiplos atores é tratada pela arquitetura.

No SAP Commerce Cloud, a operação de sellers fica no SAP Commerce Marketplace Management, que requer a aplicação Mirakl integrada por APIs (SAP e Mirakl Marketplace Management), enquanto preço, pagamento e pedido seguem no Commerce Cloud e nas integrações com o ERP. São duas aplicações integradas, e vale levantar o que isso significa em contratos, implantação e sincronização de regras.

Na CWS Platform, seller, preço, crédito e pedido estão no mesmo núcleo: contratos de comissão, buybox, regras de preço e limite de crédito são configurados em telas do painel ou por API.

Os termos de licença do SAP Commerce Cloud registram dois limites que entram na conta de um marketplace:

• limitação registrada na documentação do fornecedor em 01/03/2026: a licença por GMV não abate devoluções, reembolsos nem cancelamentos ("will not reduce the GMV amount", https://assets.cdn.sap.com/agreements/product-use-and-support-terms/cls/en/sap-commerce-cloud-supplement-english-v3-2026.pdf).
• limitação registrada na documentação do fornecedor em 01/03/2026: memória e banco de dados têm teto por faixa de GMV ou de pedidos, e três meses seguidos acima dele obrigam a comprar add-ons de escala ou a faixa seguinte ("SAP will require the Customer to purchase", https://assets.cdn.sap.com/agreements/product-use-and-support-terms/cls/en/sap-commerce-cloud-supplement-english-v3-2026.pdf).

A decisão, portanto, é entre operar o marketplace como uma aplicação especializada integrada ao Commerce Cloud e ao ERP, ou ter seller, preço, crédito e pedido no mesmo núcleo transacional.

Quando o SAP Commerce Cloud é a escolha certa neste cenário

A arquitetura do SAP Commerce Cloud é indicada para cenários em que requisitos corporativos globais e infraestruturas técnicas pré-existentes direcionam a composição da solução:

Marketplaces em que o desafio principal é integrar e governar muitos sellers. Escolha essa arquitetura quando a prioridade é automatizar a entrada de sellers e o cumprimento de SLA. A SAP documenta, para o Marketplace Management com Mirakl, fluxos automáticos de aprovação e recusa de sellers, mapeamento de catálogo por arrastar e soltar e remoção automática do estoque de sellers fora do SLA (SAP Commerce Marketplace Management).

Organizações padronizadas no ecossistema SAP S/4HANA com contratos globais. Escolha essa arquitetura quando a organização já centraliza processos operacionais globais no SAP S/4HANA e demanda conectividade pré-configurada por pacotes oficiais da SAP Integration Suite. O pacote SAP Commerce Cloud Integration with ERP viabiliza o mapeamento direto de condições de preço complexas como PPR0 e KA02 via adaptadores OData e rotas documentadas no portal de integração SAP Commerce.

Projetos que exigem desenvolvimento de storefront desacoplado em Angular. Escolha essa arquitetura quando a governança de engenharia corporativa determina o uso obrigatório de componentes de interface mantidos internamente por equipes próprias de front-end. O Composable Storefront disponibiliza bibliotecas JavaScript de código aberto estruturadas em Angular que consomem dados de comércio exclusivamente por chamadas RESTful, conforme detalhado no guia de arquitetura do Composable Storefront.

Ambientes que operam módulos avançados de sourcing integrados ao SAP Cloud Application Event Hub. Escolha essa arquitetura quando a empresa requer a orquestração de pedidos corporativos distribuídos por meio da suíte SAP Order Management for Sourcing and Availability. Essa estrutura gerencia disponibilidade, roteamento de pedidos e reserva de estoque, e distribui eventos pelo SAP Cloud Application Event Hub, conforme as especificações descritas na documentação do SAP Order Management.

Quando a CWS Platform é a escolha certa neste cenário

A CWS Platform é a escolha adequada quando o marketplace necessita de autonomia operacional para sellers e redução do custo de transação sem exigir dependência contínua de ciclos de desenvolvimento.

Operações que exigem autonomia regional por armazém sem perda de controle central. Escolha essa arquitetura quando a rede de parceiros precisa atuar com autonomia em estoques locais, regras de frete e catálogos restritos. A filial, configurada como a origem do estoque, funciona como a unidade central do sistema, permitindo que cada fornecedor tenha regras regionais próprias enquanto a governança corporativa permanece unificada no motor de regras.

Marketplaces que demandam concessão de crédito comercial e múltiplos pagamentos no checkout. Escolha essa arquitetura quando a transação corporativa depender de limites de crédito próprios, boletos a prazo e divisão de faturas entre diferentes participantes. Um mesmo pedido pode combinar limite de crédito com cartão ou boleto, e o saldo da conta corrente de crédito é verificado no pedido conforme regras configuradas no painel.

Modelos em que a força de vendas interna e os parceiros colaboram no fechamento. Escolha essa arquitetura quando os consultores comerciais precisarem montar carrinhos em nome dos clientes, com as condições de cada um. O vendedor fica identificado no pedido, o carrinho pode ser compartilhado com o cliente para edição ou fechamento, e descontos acima da alçada seguem para aprovação em níveis.

Ecossistemas que integram fornecedores externos para eliminar rupturas de prateleira. Escolha essa arquitetura quando for necessário vender estoques de parceiros sem que a ausência física do produto no centro de distribuição próprio interrompa o fluxo comercial. Por meio de APIs REST e webhooks para sistemas de retaguarda, a plataforma roteia pedidos diretamente para a origem correta mantendo a integração fiscal necessária.

Operações que mantêm o ERP SAP como sistema de registro. Escolher a CWS para o marketplace não exige trocar o ERP. O pedido é enviado ao ERP por webhook logo após ser gerado, o limite de crédito pode ser concedido e atualizado pelo ERP via API, regras de preço aceitam IDs externos do ERP e o imposto por item pode ser calculado pela API de tributos do ERP antes de fechar o pedido. O SAP S/4HANA segue emitindo a nota e cuidando do financeiro, e a CWS opera a camada comercial multi-seller sobre ele.

Por onde continuar

Se a sua pergunta ainda é qual arquitetura serve à sua operação, e não qual fornecedor escolher, o caminho é as sete perguntas que separam as arquiteturas de comércio B2B.

Se o que trava hoje é a dor por trás deste cenário, as páginas Quando o Catálogo Vira Caos e Quando Vender Mais Não Significa Ganhar Mais tratam disso em profundidade, sem falar de fornecedor nenhum.