Split de pagamento para marketplace e SaaS no Brasil — guia técnico 2026

Em 2026, qualquer plataforma digital brasileira que transfira valores entre terceiros — marketplace de produto, marketplace de serviço, SaaS com revenue share, agência com repasse a fornecedor — opera sob obrigações de subadquirente definidas pela Circular BACEN 3.886/2018. Quem ultrapassa R$ 500 milhões em movimentação anual de crédito precisa liquidar via Câmara Interbancária de Pagamentos (CIP) com agenda unitária por seller; quem não chega a esse patamar ainda assim deve formalizar a função no contrato com o adquirente ou gateway, sob risco de classificação inadequada na cadeia de responsabilidades. Split de pagamento é o mecanismo técnico que materializa essa exigência regulatória — dividir um único pagamento de comprador em N partes destinadas a N recebedores, com agenda, antecipação e responsabilidades preservadas por seller.

A tese contraintuitiva é a seguinte: a maioria das plataformas brasileiras que oferece split como "feature" está implementando split errado. O modelo correto não é "marketplace recebe e repassa", é "comprador paga e cada seller recebe seu pedaço diretamente do arranjo de pagamento". A diferença é jurídica e tributária — no modelo correto, o marketplace não fica com receita que não é dele (não inflando MRR, não pagando ISS sobre transit revenue, não precisando provisionar contas a pagar de terceiros), e cada seller mantém titularidade dos seus recebíveis para fins de antecipação cross-adquirente.

Split mal implementado é o jeito mais elegante de transformar um marketplace de média escala em instituição financeira não-autorizada. A função regulatória de subadquirente existe justamente para você não precisar ser banco para repassar dinheiro de terceiros.

Tabela canônica — modelos de split em 2026

Fonte: regulação BACEN vigente em maio de 2026 (Circular 3.886/2018, Resolução BCB 80/2021, Resolução BCB 264/2022), documentação oficial dos gateways (acessada em maio de 2026) e observação de implementações de campo em marketplaces brasileiros.

Como o split nativo funciona — quatro engrenagens regulatórias e técnicas

A primeira engrenagem é o arranjo de pagamento e a CIP centralizada. Quando um marketplace é classificado como subadquirente nos termos da Circular 3.886/2018, e ultrapassa R$ 500 milhões em volume anual de crédito, todos os seus recebíveis precisam liquidar via Câmara Interbancária de Pagamentos. A CIP mantém agenda unitária por seller, o que significa que cada UR (Unidade de Recebível) de cartão é registrada com identificação clara do credor final. O efeito prático é que o seller pode ceder ou antecipar o recebível individualmente sem que a operação dependa de aprovação do marketplace — é a base da Resolução BCB 264/2022 e do mercado de antecipação cross-adquirente.

A segunda engrenagem é a estrutura de recipient e split rule no gateway. Em Pagar.me v5, o fluxo canônico é: criar um Recipient para cada seller (com dados bancários, CPF/CNPJ, KYC validado), e ao criar um Order passar um objeto split com array de regras. Cada regra define recipient_id, amount (ou percentage), type, e flags de responsabilidade — charge_processing_fee (quem paga a taxa do gateway), charge_remainder_fee (quem absorve diferença de arredondamento) e liable (quem responde por chargeback).

POST /core/v5/orders
{
  "items": [
    { "amount": 50000, "description": "Camiseta", "quantity": 1 }
  ],
  "customer": { "name": "Comprador", "email": "cliente@exemplo.com", "document": "12345678909", "type": "individual" },
  "payments": [
    {
      "payment_method": "credit_card",
      "credit_card": {
        "operation_type": "auth_and_capture",
        "installments": 1,
        "card": { "number": "4000000000000010", "holder_name": "COMPRADOR", "exp_month": 12, "exp_year": 2030, "cvv": "123" }
      },
      "split": [
        {
          "amount": 45000,
          "type": "flat",
          "recipient_id": "rp_seller_acme_42",
          "options": { "charge_processing_fee": true, "charge_remainder_fee": true, "liable": true }
        },
        {
          "amount": 5000,
          "type": "flat",
          "recipient_id": "rp_marketplace_house",
          "options": { "charge_processing_fee": false, "charge_remainder_fee": false, "liable": false }
        }
      ]
    }
  ]
}

A terceira engrenagem é o webhook por seller. Quando o pedido é pago, o gateway emite eventos por charge — charge.paid com referência ao order_id, payment_id e split breakdown. Cada seller pode opcionalmente ter webhook próprio (em arquiteturas multi-tenant) ou o marketplace consolida e dispara notificação interna. A consequência operacional é que conciliação deixa de ser planilha e vira tabela relacional: transaction_id → charge_id → split_id → recipient_id, com e2e_id ou tid (transaction ID da bandeira) preservado em todo o caminho.

A quarta engrenagem é a agenda de recebíveis e antecipação por seller. Cada seller mantém agenda própria — visível no painel ou via API — e pode antecipar seus próprios recebíveis sem que isso afete o marketplace. No Pagar.me, a antecipação é nativa via Stone (D+1 com taxa percentual sobre valor antecipado); em outros gateways, depende do parceiro financeiro embutido. Sellers com volume relevante também conseguem ceder UR para antecipação cross-adquirente com bancos de terceiros, dado que a CIP expõe a titularidade do recebível.

Quem deve operar split nativo via gateway versus alternativas

Operar split nativo via Pagar.me, Mercado Pago ou Adyen MarketPay faz sentido quando:

1. O marketplace tem mais de 50 sellers ativos por mês e crescimento mensal acelerado. Abaixo desse volume, a sobrecarga operacional do KYB por seller (cada seller precisa ter Recipient cadastrado com documentação completa) supera o ganho.
2. O modelo de cobrança envolve cartão de crédito como meio principal — split por Pix direto via E2E ID resolve casos de pagamento à vista entre poucos sellers sem complexidade técnica equivalente.
3. O marketplace precisa separar liability por chargeback entre vendedor e plataforma. Sem split nativo, todo chargeback recai sobre o adquirente único, que cobra do marketplace que precisa cobrar do seller — fluxo lento, conflituoso e frequentemente caloteiro.
4. A plataforma quer oferecer antecipação como produto sem virar instituição financeira. Com split nativo, cada seller acessa antecipação D+1 do gateway diretamente sem que o marketplace precise originar crédito.

Não opere split nativo quando:

1. Marketplace ainda em validação de tese (menos de 10 sellers). Use cobrança simples no marketplace, repasse manual mensal via TED ou Pix com nota fiscal. Quando atingir 20-30 sellers, migre para split nativo.
2. Marketplace B2B com pagamento por boleto registrado — o boleto é emitido em nome do seller diretamente, dispensa split de cartão.
3. Plataforma de serviço onde o "seller" é prestador autônomo CPF e o marketplace prefere assumir a relação CLT/PJ — neste caso o marketplace é a contraparte, não há terceiro a quem repassar.

O erro mais comum é tratar split como decisão técnica quando é, antes de tudo, decisão regulatória e contratual. Antes de escrever a primeira linha de código de Recipient, valide com advogado especializado em pagamentos se o seu modelo de negócio configura subadquirência e em qual patamar regulatório você opera.

Developer Experience comparada — Pagar.me, Mercado Pago, Stripe Connect, Adyen

Para plataformas com perfil PT-BR e foco em time-to-market, a hierarquia prática em maio de 2026 é:

1. Pagar.me — DevEx mais consistente para Brasil. Recipient API estável, split documentado com exemplos em PHP/Node/Python, antecipação D+1 nativa, suporte de engenharia que entende contexto brasileiro. Curva de aprendizado: 1-2 semanas para integração básica, 4-6 para produção com webhook idempotente, retry de transação e fluxo de chargeback.
2. Mercado Pago — documentação extensa em mercadopago.com.br/developers, ecossistema enorme, mas split historicamente menos flexível em casos de N-recipient + responsabilidade granular. Forte para marketplace C2C e B2C com sellers pequenos.
3. Adyen MarketPay — capacidade enterprise (Mercado Livre, iFood histórico usaram). Onboarding pesado, contrato típico exige volume mínimo. Não é opção para PME média.
4. Stripe Connect — referência mundial, mas tem restrições no Brasil. Account Type Custom funciona para casos com sellers PJ brasileiros, mas onboarding é mais longo que Pagar.me e há limitações de payout em moeda local. Faz sentido quando o marketplace tem sellers fora do Brasil.

Veja comparativo numérico detalhado em Pagar.me vs Mercado Pago vs Stripe.

Compliance, KYB e responsabilidade por chargeback

Split nativo amplifica responsabilidade de compliance. Para cada seller, o marketplace precisa cumprir KYB equivalente ao que o gateway exige: validação de CNPJ ativo na Receita Federal, análise de QSA, comprovante de endereço, conta bancária PJ, verificação de PEP e atividade econômica compatível com o que o seller declara vender. Sob Circular 3.978/2020 do BACEN, instituições de pagamento são obrigadas a manter procedimentos de KYC e KYB documentados, com escalonamento de risco e atualização periódica. Marketplace que opera via gateway delega parte do KYB ao gateway mas mantém responsabilidade solidária — não é "tudo culpa do Pagar.me se o seller é fraudulento".

A LGPD adiciona camada extra. Cada Recipient registrado é uma operação de tratamento de dados pessoais (CPF do sócio, CNPJ, endereço, dados bancários, biometria opcional). A base legal típica é execução de contrato (Art. 7º, V) combinada com cumprimento de obrigação legal (Art. 7º, II) — o marketplace tem que tratar o dado para cumprir o KYC regulatório. O contrato com cada seller precisa explicitar finalidade, prazo de retenção (mínimo 10 anos para registros financeiros conforme Lei 9.613/1998 de prevenção a lavagem) e responsabilidade do seller pela acurácia dos dados informados.

Sob a Lei 15.352/2026 que transformou ANPD em agência reguladora plena, multas chegam a 2% do faturamento limitadas a R$ 50 milhões — marketplace que falha em KYB de seller e expõe dados de comprador a fraudador opera em risco material. Detalhes em KYC e KYB de merchants para marketplace e antifraude 3DS e chargeback.

Próximo passo

Para implementar split nativo em 2026, o caminho técnico recomendado é: (1) validar com advogado especializado em pagamentos qual a sua classificação regulatória; (2) escolher gateway com base em volume projetado e perfil de sellers (Pagar.me para PT-BR puro, Stripe Connect para internacional, Mercado Pago para C2C); (3) modelar a tabela de Recipients com KYB completo desde o início — refatorar KYB depois é dor de cabeça inevitável; (4) implementar webhook idempotente para receber split breakdown; (5) homologar fluxo de chargeback antes do go-live, com fluxo de débito ao seller responsável.

Para entender webhook idempotente em profundidade, webhook idempotência. Para o motor de antifraude que evita chargeback no split, antifraude 3DS. Para o gateway Pagar.me em detalhe, Pagar.me gateway.

Perguntas frequentes

Qual a diferença entre split de pagamento e repasse manual?

Split de pagamento é a divisão técnica de um único pagamento em N partes destinadas a N recebedores diferentes, executada pelo arranjo de pagamento (gateway, adquirente, banco) com agenda unitária por recebedor na CIP. Repasse manual é o marketplace receber o valor cheio em conta própria e depois transferir aos sellers via TED ou Pix em lote. O split mantém a titularidade do recebível com cada seller desde a captura; o repasse manual transforma o marketplace em depositário, com efeitos tributários e regulatórios distintos. Em 2026, com Circular 3.886 plenamente vigente, repasse manual é juridicamente arriscado para marketplaces acima de R$ 500 milhões em volume anual.

Preciso ser instituição de pagamento autorizada pelo BACEN para fazer split?

Não necessariamente. Marketplaces abaixo de R$ 500 milhões em volume anual e R$ 50 milhões em saldo em conta de pagamento podem operar como subadquirente classificado pelo BACEN sem necessidade de autorização formal como IP — basta cumprir as obrigações de prevenção a lavagem (Circular 3.978/2020), KYB de sellers, e operar via subadquirente ou gateway autorizado. Acima desses patamares, há obrigação de pleito de autorização formal e adesão à CIP. Detalhes regulatórios em Circular 3.886/2018.

Posso fazer split entre Pix recebido para o marketplace?

Pix recebido pelo marketplace não pode ser "splitado" automaticamente pelo gateway no momento do recebimento — o Pix é P2P/B2B direto entre pagador e recebedor cadastrado na chave. Há dois caminhos: (a) gerar QR Pix por seller diretamente (o comprador escolhe para qual seller paga), o que não é split mas é split-equivalente; (b) usar Pix Cobrança via gateway, onde o gateway atua como recebedor de fato e em seguida distribui via TED ou Pix programado para cada seller. Esta segunda forma é menos elegante e tem custo operacional maior. A regulação do Pix está na Resolução BCB 80/2021 e atualizações.

Quem responde por chargeback em transação com split?

Depende da configuração do liable no objeto split. No Pagar.me v5, cada split rule pode marcar o recipient como liable: true ou liable: false. Quando true, o chargeback é debitado da agenda daquele recipient. Quando false, o chargeback é debitado do marketplace (recipient padrão). Em marketplaces bem-modelados, o seller responsável pelo produto entregue é marcado como liable: true para a parte dele do split, garantindo que o ônus operacional do chargeback siga a responsabilidade comercial real. Fluxo detalhado em antifraude 3DS.

Stripe Connect funciona bem no Brasil em 2026?

Funciona, mas com restrições. Stripe Brasil opera processamento de cartão local e oferece Connect com Account Type Custom para conectar sellers PJ brasileiros. As limitações são: (a) payout em moeda local funciona apenas para certas combinações de país do seller; (b) onboarding KYB de sellers via Stripe é mais longo que Pagar.me (5-15 dias úteis típicos); (c) tax automation para impostos brasileiros (ISS, PIS, COFINS sobre serviços) não é nativa, exigindo middleware. Stripe Connect faz sentido para SaaS B2B com sellers internacionais; para marketplace 100% Brasil, Pagar.me ou Mercado Pago geralmente vencem.

Stone não patrocina este conteúdo. Para o produto Pagar.me em detalhe, pagar.me. Para entender o ecossistema completo Stone, Stone vs Nubank PJ. Para o glossário canônico, glossário banco do empreendedor.