Desenvolvimento de Marketplace B2B em 2026: Plataformas

Construir um marketplace B2B em 2026 significa resolver problemas que uma loja B2C nunca tem: contas empresariais com vários compradores, preços negociados, cotações, prazo de pagamento, pedidos em volume e cadeias de aprovação. Você pode lançar em um SaaS de marketplace (Mirakl, Sharetribe, CS-Cart), estender um motor de comércio headless (Medusa, Saleor) ou construir sob medida. A escolha da plataforma importa menos do que três coisas: a profundidade de fluxo que seus compradores esperam, como você trata pagamentos e repasses aos vendedores, e como faz as primeiras cem transações passarem pelo sistema.

Como marketplaces B2B diferem dos B2C

A maior parte dos softwares de marketplace foi desenhada em torno de um consumidor comprando um item com cartão. O comércio B2B quebra quase todas as premissas desse modelo.

Contas, não usuários. O cliente é uma empresa. Ela tem vários compradores, cada um com um papel: solicitante, aprovador, financeiro, admin. Pedidos e faturas pertencem à conta, não à pessoa que clicou em "comprar". Seu modelo de dados precisa de organization, member e role desde o primeiro dia; encaixar isso depois em um schema de usuário único é doloroso.

Preço negociado. O preço de lista é só o ponto de partida. Os preços reais vêm de contratos, faixas de volume, grupos de clientes e acordos com prazo definido. Um mesmo SKU pode ter um preço diferente para cada conta, e o financeiro espera uma trilha de auditoria de quem acordou o quê e quando.

Cotações e RFQs. Pedidos grandes ou fora do padrão começam como uma solicitação de cotação. O comprador pergunta, um ou mais vendedores respondem, o comprador aceita, e só então existe um pedido. É um fluxo assíncrono, em várias etapas, com mensagens e ofertas versionadas, não um carrinho.

Prazo de pagamento e faturamento. Muitos compradores B2B não pagam no checkout. Compram na conta, recebem uma fatura e pagam em 30 ou 60 dias. O marketplace precisa de limite de crédito, geração de faturas, régua de cobrança e, em um cenário multivendedor, uma forma de conciliar quanto cada vendedor recebe quando o comprador liquida.

Pedidos em volume. Compradores sobem planilhas, repetem a lista do mês passado ou digitam SKU e quantidade em um formulário de pedido rápido. Quantidade mínima, tamanho de embalagem e conversão de unidade de medida (caixa com 12, palete com 48 caixas) são o normal.

Catálogos por cliente. Uma conta pode enxergar só o sortimento que está autorizada a comprar, com códigos de SKU e preços próprios. A visibilidade do catálogo vira um problema de permissão, e a busca precisa respeitar isso.

Fluxos de aprovação. Pedidos acima de um limite aguardam um gestor. Algumas contas exigem número de ordem de compra em todo pedido. A integração punchout (o comprador navega no seu marketplace de dentro do sistema de compras dele) é comum em procurement corporativo.

Se você avalia uma plataforma e ela trata os sete itens nativamente, é uma plataforma B2B. Se trata dois ou três, orce o restante como desenvolvimento sob medida.

Comparativo de plataformas de marketplace B2B

As opções se dividem em quatro grupos: SaaS corporativo de marketplace, SaaS genérico de marketplace, motores de comércio headless que você estende, e desenvolvimento sob medida. O Shopify B2B aparece porque surge em toda avaliação, embora seja um canal de atacado com um único vendedor, e não um marketplace multivendedor.

Plataforma	Melhor para	Customização	Custos / licença	Tempo de lançamento	Multivendedor	Pagamentos e repasses divididos
Mirakl	Grandes varejistas, distribuidores e fabricantes que adicionam um marketplace de terceiros a um canal existente	Configuração mais APIs; os fluxos centrais são fixos	Licença corporativa, precificada por escala	Meses, a maior parte em integração	Nativo, com onboarding de vendedores, pontuação de qualidade e gestão de ofertas	Via PSPs parceiros; suporta cotações B2B e multimoeda
CS-Cart Multi-Vendor	Marketplaces de médio porte que querem uma plataforma on-premise em PHP com licença barata	Add-ons e acesso ao código-fonte	Licença única ou assinatura por edição	Semanas a poucos meses	Nativo, com planos e repasses para vendedores	Integrado a vários gateways; repasses divididos pelos PSPs suportados
Sharetribe	Startups validando um marketplace de nicho rapidamente	Builder no-code mais template web customizável e API	Assinatura mensal mais percentual sobre transações nos planos menores	Dias a semanas	Nativo	Stripe Connect embutido; recursos B2B limitados (sem faturamento, sem prazo de pagamento)
Medusa / Saleor (headless)	Times com engenheiros que querem um núcleo de comércio moderno e controle total do front-end e da lógica de negócio	Total: plugins/módulos (Medusa, Node.js) ou apps e extensões (Saleor, Python/GraphQL)	Open source; hospedagem em nuvem paga opcional	Meses; multivendedor e B2B ficam por sua conta, construídos ou montados a partir de módulos	Não é nativo; viável por módulos ou serviços próprios	Qualquer PSP; repasses divididos implementados por você sobre Stripe Connect, Adyen ou Mangopay
Shopify B2B	Uma marca ou distribuidor existente vendendo no atacado para os próprios clientes	Tema, apps e Functions	Assinatura Shopify Plus mais taxas por transação	Semanas	Não (vendedor único); existem apps de marketplace, mas limitados	Shopify Payments; prazo de pagamento, contas empresariais, listas de preço e regras de quantidade inclusos
Sob medida	Marketplaces em que o fluxo (RFQ, contratos, compliance, acoplamento com ERP) é o produto	Ilimitada	Custo de engenharia, sem licença	Seis meses ou mais até um MVP real	O que você desenhar	Qualquer PSP; o ledger e a lógica de repasse são seus

Algumas observações práticas sobre a tabela:

• O Mirakl resolve a operação de vendedores em escala melhor do que qualquer outra opção da lista, mas pressupõe que você já tem loja, PIM e sistema de gestão de pedidos. É um back office de marketplace, não uma stack completa.
• O Sharetribe é a forma mais rápida de testar se um mercado de dois lados existe. Não é a plataforma em que você ainda estará quando as contas pedirem prazo de pagamento e catálogo por cliente.
• Medusa e Saleor não são marketplaces de fábrica. São núcleos de comércio sólidos (catálogo, carrinho, pedidos, precificação, regiões) com pontos de extensão. Uma camada multivendedor por cima é um projeto de verdade, mas você deixa de escrever os 60% chatos.
• O Shopify B2B fechou boa parte da lacuna no atacado com vendedor único. Se você tem um vendedor e muitas empresas compradoras, olhe aqui primeiro.

Para uma visão mais ampla do trade-off entre construir e comprar no comércio, veja plataformas de e-commerce sob medida vs SaaS.

Arquitetura de uma plataforma de marketplace B2B

Seja qual for a escolha, um marketplace B2B se decompõe nos mesmos domínios. Trate-os como serviços separados ou como módulos bem isolados em um monolito; as fronteiras importam mais do que o estilo de deploy. Os trade-offs estão em microsserviços vs monolito.

Catálogo e PIM

Os vendedores sobem catálogos em CSV, XLSX ou por API. Uma camada de informação de produto os normaliza em uma taxonomia canônica, com templates de atributos por categoria, unidades de medida e hierarquias de embalagem. Mantenha o produto canônico separado da oferta do vendedor (preço, estoque, prazo de entrega, MOQ): um produto, muitas ofertas. Catálogos por cliente são uma regra de visibilidade avaliada sobre as ofertas, não uma cópia do catálogo por conta.

Busca

Indexe documentos de oferta desnormalizados no OpenSearch, Elasticsearch, Typesense ou Meilisearch. Facetas por atributo, regras de sinônimos para o jargão do setor, busca por número de peça com correspondência tolerante e, o mais crítico, filtragem pelo que a conta atual pode ver e pelo preço que pode ver. Pré-calcule os preços efetivos por grupo de preço quando as regras forem pesadas; calcule por conta no momento da consulta quando o conjunto de regras for pequeno.

Precificação e cotações

Um serviço de precificação avalia preço de lista, grupos de preço, preços de contrato, faixas de volume e promoções em uma ordem definida e devolve um resultado explicável ("contrato X, faixa 3"). O serviço de cotações é dono do ciclo de vida da RFQ: rascunho, enviada, respostas dos vendedores, revisões, aceita, expirada. Aceitar uma cotação cria um pedido com as linhas cotadas congeladas.

Orquestração de pedidos

O carrinho de um comprador pode ter linhas de vários vendedores. O checkout o divide em um pedido por vendedor, mantém uma referência-pai para o comprador, aplica o fluxo de aprovação se a conta exigir e emite eventos. Fulfillment, faturamento e repasses assinam esses eventos. É um caso de livro-texto de arquitetura orientada a eventos: consumidores idempotentes, um log durável e ações compensatórias quando um vendedor cancela parte de um pedido.

Onboarding de vendedores

Cadastro, verificação da empresa (KYB), coleta de conta bancária, dados fiscais, aceite de contrato, importação de catálogo e um go-live em etapas em que o marketplace revisa os primeiros anúncios. A maior parte das etapas de KYB e banco pode ser delegada ao onboarding hospedado do provedor de pagamento.

Pagamentos e repasses

É aqui que a arquitetura de marketplace mais se distancia de uma loja com vendedor único. O marketplace recebe os fundos (cartão, débito SEPA, transferência bancária ou uma fatura paga depois), retém, guarda a comissão e paga cada vendedor. Fazer isso por conta própria significa custodiar dinheiro de terceiros, o que é atividade regulada. A resposta habitual é um PSP de plataforma:

• Stripe Connect: o mais rápido de integrar, onboarding de vendedores hospedado, destination e separate charges com transfers, boa cobertura de cartões e SEPA. Combina bem com Medusa, Saleor e stacks sob medida.
• Adyen for Platforms: forte para grandes volumes, muitos mercados e métodos de pagamento locais; mais esforço de integração e contrato comercial.
• Mangopay: construído em torno de e-wallets por vendedor e comprador, comum em marketplaces europeus, lida bem com fluxos tipo escrow e liquidação por fatura.

Seja qual for o escolhido, mantenha seu próprio ledger de pedidos, comissões, reembolsos e repasses. Os relatórios do PSP não são a sua contabilidade. Se você está desenhando essa camada, desenvolvimento de sistemas de pagamento cobre os detalhes de segurança e compliance.

Faturamento

Em um marketplace multivendedor, quem fatura o comprador? Existem três modelos: o vendedor fatura o comprador diretamente (o marketplace é um agente), o marketplace fatura em nome do vendedor (mandato de autofaturamento) ou o marketplace é o vendedor de registro e revende. A escolha define o tratamento de IVA, então decida com seu consultor tributário antes de escrever o serviço de faturamento. Seja qual for o modelo, suporte notas de crédito, faturas parciais para envios parciais e exportação para a contabilidade.

Integração com ERP

Compradores querem que os pedidos caiam no sistema de compras deles; vendedores querem os pedidos no ERP e o estoque fluindo de volta. Suporte as duas direções por uma API documentada, webhooks e alternativas baseadas em arquivo (SFTP com CSV ainda é a norma em muitos setores). Punchout (cXML, OCI) para compradores corporativos é um projeto à parte; planeje para a fase de escala. Os padrões de integração são os mesmos descritos em desenvolvimento de ERP sob medida.

Exponha tudo isso por uma única borda: um API gateway cuidando de autenticação, rate limits e chaves de API dos vendedores.

O problema da liquidez e como lançar

Um marketplace com vendedores e sem compradores é um catálogo. Com compradores e sem vendedores é uma lista de desejos. Liquidez, a probabilidade de um comprador encontrar uma oferta aceitável e de um vendedor receber pedidos, é a única coisa que importa no primeiro ano. Tecnologia não cria liquidez, mas o plano de lançamento errado pode impedi-la.

Estratégias que funcionam em B2B:

1. Domine a oferta primeiro. Distribuidores e fabricantes geralmente partem do próprio catálogo. Os compradores recebem um sortimento completo no primeiro dia; vendedores terceiros entram em um canal que já tem tráfego. É o playbook do Mirakl e o de menor risco.
2. Vendedores-âncora. Feche com três a dez vendedores que cubram a maior parte da demanda em uma categoria, com compromissos de completude de catálogo e tempo de resposta. Dê a eles condições favoráveis por um período fixo. Profundidade em uma categoria vale mais do que amplitude em vinte.
3. Traga os compradores que já tem. Se você opera uma equipe comercial, migre as contas que já atende por telefone e e-mail. As recompras delas dão o volume-base enquanto você recruta demanda nova.
4. Restrinja o escopo. Um vertical, um país, um idioma. Expanda só quando a taxa de recompra no primeiro segmento estiver saudável.
5. Não automatize o que dá para fazer à mão. Nos primeiros meses, faça o onboarding dos vendedores manualmente, responda às RFQs você mesmo quando um vendedor demorar e enriqueça os catálogos por eles. Automatize quando souber quais etapas são o gargalo.

Take rate e monetização podem esperar. Uma progressão típica é: gratuito ou quase para a primeira leva, depois comissão por transação, depois planos de assinatura para vendedores que querem analytics, anúncios patrocinados ou acesso à API. Defina o modelo antes do lançamento para que os contratos fiquem claros, mas não o otimize até haver volume para otimizar.

KPIs de um marketplace B2B

Acompanhe uma lista curta e revise semanalmente. Métricas de vaidade, como vendedores cadastrados, escondem o quadro real.

KPI	O que revela	Fique de olho em
GMV e número de pedidos por vendedor	Se a oferta está ativa ou apenas cadastrada	Uma cauda longa de vendedores com zero pedidos
Taxa de recompra por conta	Se o marketplace substitui o canal antigo de pedidos	Contas que compram uma vez e voltam para o e-mail
Taxa de busca com oferta	Cobertura do catálogo: com que frequência uma busca devolve uma oferta comprável	Buscas sem resultado por categoria
Tempo de resposta e taxa de aceite de RFQ	Engajamento dos vendedores e competitividade de preço	RFQs que expiram sem resposta
Tempo de onboarding de um vendedor	Atrito em KYB, importação de catálogo e revisão	Vendedores travados na importação de catálogo
Taxa de atendimento e entrega no prazo	Confiabilidade dos vendedores	Cancelamentos após o aceite
Take rate e margem de contribuição	Se o modelo de negócio se sustenta	Margem consumida por taxas de pagamento e incentivos
Prazo médio de recebimento (DSO)	Risco de crédito nos pedidos faturados	Faturas vencidas concentradas em poucas contas
Taxa de disputas	Qualidade dos dados de catálogo e do fulfillment	Disputas ligadas a erros de unidade de medida

Instrumente tudo isso desde a primeira release. Medir depois significa reconstruir o histórico a partir de logs.

Compliance: IVA, faturamento e GDPR

Compliance molda o modelo de dados, então pertence ao design, não a um checklist pré-lançamento.

IVA. Determine quem é o vendedor de registro em cada transação e onde o comprador está estabelecido. Vendas B2B intra-UE normalmente são reverse charge, o que exige validar o número de IVA do comprador (serviço VIES) no cadastro e guardar o resultado. Vendas transfronteiriças para compradores fora da UE, bens versus serviços e as regras de deemed supplier para certos fluxos voltados ao consumidor mudam o tratamento. Construa o motor tributário como um conjunto de regras plugável ou integre um serviço de impostos; não fixe alíquotas no código.

Faturamento. Vários países da UE estão implantando a fatura eletrônica B2B obrigatória e o reporte em tempo real em cronogramas nacionais, e o pacote VAT in the Digital Age da UE empurra a fatura eletrônica estruturada para transações transfronteiriças. Desenhe as faturas como dados estruturados (com um caminho de exportação UBL ou CII e a entrega via Peppol em mente) em vez de PDFs gerados a partir de HTML. Mantenha a numeração sequencial e imutável por entidade emissora e suporte autofaturamento se o marketplace faturar em nome dos vendedores.

Regulação de pagamentos. Reter fundos do comprador antes de pagar os vendedores é atividade regulada. Usar Stripe Connect, Adyen ou Mangopay deixa a licença com o provedor, mas as obrigações de KYB deles recaem sobre você: os vendedores precisam estar verificados antes de receber repasses, e você precisa de um processo para verificações rejeitadas ou incompletas.

GDPR. Compradores e contatos dos vendedores são pessoas. Você precisa de uma base legal para cada finalidade de tratamento, acordos de processamento de dados com o PSP, o provedor de busca e qualquer fornecedor de hospedagem, regras de retenção que distingam faturas (que você deve guardar) de dados comportamentais (que não pode guardar para sempre) e fluxos de exportação e exclusão que param no que a lei tributária obriga a reter. O quadro completo está em GDPR e desenvolvimento de software.

Checklist de decisão: SaaS, headless ou sob medida

Escolha um SaaS de marketplace (Sharetribe, CS-Cart, Mirakl) quando:

• Você precisa validar a demanda ou lançar um canal em semanas, não meses.
• Seus fluxos são próximos do padrão: listar, buscar, pedir, pagar, enviar.
• Você tem verba para licença e um time de engenharia pequeno, ou (Mirakl) uma stack de comércio existente para plugar.

Escolha um motor headless (Medusa, Saleor) quando:

• Você tem engenheiros que serão donos da plataforma no longo prazo.
• Você precisa de controle total da experiência do comprador e das integrações, mas não quer escrever catálogo, carrinho e gestão de pedidos do zero.
• A lógica multivendedor e B2B é importante, mas não exótica; módulos e uma camada de serviços própria dão conta.

Escolha o Shopify B2B quando:

• Há um único vendedor: você, vendendo no atacado para contas empresariais.
• Prazo de pagamento, listas de preço e contas empresariais são os recursos B2B de que você precisa.

Escolha o desenvolvimento sob medida quando:

• O fluxo de RFQ, contrato ou compliance é o motivo pelo qual os compradores migrariam para você.
• O acoplamento com ERP nos dois lados é profundo e específico do seu setor.
• Você espera operar a plataforma por anos e o custo de licença superaria o custo de engenharia.
• Residência de dados, auditabilidade ou restrições regulatórias descartam SaaS multi-tenant.

Checklist de entrega em fases: do MVP à escala

Fase 1 — MVP (primeira release)

• Contas empresariais com membros e dois papéis (comprador, admin)
• Onboarding de vendedores com KYB hospedado no PSP; revisão manual dos primeiros anúncios
• Importação de catálogo por CSV com templates de atributos para as categorias de lançamento
• Busca com facetas e visibilidade por conta
• Listas de preço por grupo de clientes; preços de contrato para contas-âncora, mesmo que carregados manualmente
• Carrinho dividido em pedidos por vendedor; pagamento por cartão e SEPA pelo PSP de plataforma
• Cotações básicas: solicitação do comprador, resposta de um vendedor, aceite vira pedido
• Geração de faturas com tratamento de IVA correto para o país de lançamento
• Painel do vendedor: pedidos, repasses, status do catálogo
• Instrumentação de KPIs desde o primeiro dia

Fase 2 — Tração

• Fluxos de aprovação e exigência de número de OC por conta
• Prazo de pagamento com limites, pagamento por fatura, régua de cobrança
• RFQs em várias rodadas com vários vendedores e revisões
• Pedido rápido, upload de planilha, recompra a partir do histórico
• APIs para vendedores e compradores mais webhooks; fallback por SFTP
• Verificações automáticas de qualidade de catálogo e pontuação de vendedores
• Segundo país: moeda, regras de IVA, idioma

Fase 3 — Escala

• Punchout (cXML/OCI) para compradores corporativos
• Formatos de fatura eletrônica e entrega via Peppol onde for obrigatório
• Anúncios patrocinados, planos de assinatura para vendedores, produtos de analytics
• Recomendação e cross-sell com base no histórico de pedidos
• Hospedagem multirregião, réplicas de leitura, isolamento do cluster de busca para grandes contas
• SLAs formais para vendedores e compradores, com error budgets e plantão

Cada fase deve terminar com uma revisão da tabela de KPIs acima. Se a taxa de recompra estiver estagnada depois da Fase 1, a correção está em liquidez e cobertura de catálogo, não nas funcionalidades da Fase 2.

Recomendação

Se você é distribuidor ou fabricante com catálogo existente e quer vendedores terceiros nele, avalie o Mirakl contra uma construção headless; o fator decisivo é se o custo da licença é menor do que a engenharia que você gastaria em operação de vendedores. Se está começando um mercado de dois lados do zero, valide no Sharetribe ou em um SaaS semelhante e planeje a migração para uma plataforma headless ou sob medida para o momento em que as contas pedirem prazo de pagamento e catálogo por cliente. Se o fluxo de RFQ ou de contrato é o seu produto, construa sob medida sobre um núcleo headless, use um PSP de plataforma para os repasses desde o primeiro dia e mantenha seu próprio ledger. Na Arvucore, costumamos recomendar decidir o modelo de faturamento e a questão do vendedor de registro antes da primeira linha de código, porque é a única decisão que remodela tudo o que vem depois.