Como funciona o split de pagamentos para marketplaces — e por que a maioria das implementações está errada

O problema de pagamentos em marketplaces que ninguém menciona

Quando um comprador compra de múltiplos sellers em um único carrinho, a plataforma precisa dividir o pagamento, cobrar sua taxa e liquidar cada seller — atomicamente. Parece simples. Não é.

Eis o que realmente acontece quando um comprador gasta R$ 1.000 em um marketplace com 3 sellers:

• Seller A deve receber R$ 400
• Seller B deve receber R$ 350
• Seller C deve receber R$ 250
• A plataforma cobra 12% de MDR (R$ 120)
• Líquido para sellers: R$ 880 no total

Aritmética simples. Agora adicione complexidade do mundo real: Seller A tem liquidação D+0 (PIX instantâneo). Seller B tem D+14. Seller C tem D+30 porque é um seller novo com risco mais alto. O comprador pagou com cartão de crédito em 2 parcelas. Seller B tem um chargeback pendente da semana passada que precisa ser compensado contra os fundos entrantes.

É aqui que a maioria das implementações de split payment desmorona.

Por que implementações ingênuas quebram

O anti-pattern "transferir depois de liquidar"

A abordagem mais comum: receber o pagamento completo em uma conta, esperar a liquidação e depois transferir os fundos para cada seller. Parece lógico. Também está errado.

Problemas:

• Risco de float — A plataforma mantém os fundos do comprador na sua própria conta. Se a plataforma quebra entre o pagamento e a liquidação, os fundos dos sellers estão em risco. No Brasil, o BACEN considera isso "fundos de instituição de pagamento" e exige contas segregadas.
• Inferno de reconciliação — Agora você tem um problema de ledger. A plataforma recebeu R$ 1.000 mas deve R$ 880 para 3 entidades diferentes com 3 cronogramas de liquidação diferentes. Cada pagamento gera trabalho de reconciliação.
• Caos de chargebacks — Se o comprador disputa a cobrança 45 dias depois, qual seller absorve o chargeback? Como você recupera fundos de um seller que já recebeu liquidação D+0 e sacou o dinheiro?

O anti-pattern "múltiplas cobranças"

Outra abordagem comum: cobrar o comprador 3 vezes — uma por seller. Isso resolve o problema do split eliminando ele. Mas:

• UX terrível — O comprador vê 3 cobranças no extrato em vez de 1. Confusão gera disputas.
• Custos mais altos — 3 transações de gateway separadas. Triplo de taxas de processamento.
• Abandono de carrinho — Alguns métodos de pagamento (como PIX) geram um único QR code. Você não pode pedir para o comprador escanear 3 QR codes.

O anti-pattern "distribuição percentual"

Algumas plataformas definem splits como percentuais: "Seller A recebe 40%, Seller B recebe 35%, Seller C recebe 25%." Funciona até você encontrar arredondamento.

40% de R$ 1.000 = R$ 400,00. Beleza. Mas 40% de R$ 999,99 = R$ 399,996. Você não pode transferir R$ 399,996. Alguém fica com o centavo extra. Multiplique isso por milhões de transações e você tem uma discrepância material de reconciliação.

Como a Revenu resolve: splits atômicos com ledger de partida dobrada

Nossa API de split lida com distribuição N:N em uma única operação atômica. Eis o que acontece por baixo dos panos quando um split payment é processado:

Passo 1: Ingresso do pagamento

O comprador paga R$ 1.000. A Revenu recebe o pagamento e cria um único lançamento contábil:

DÉBITO: conta_pagamento_comprador R$ 1.000

CRÉDITO: conta_clearing_plataforma R$ 1.000

Os fundos caem em uma conta de clearing — não na conta operacional da plataforma.

Passo 2: Execução atômica do split

Na mesma transação de banco de dados (literalmente a mesma transação ACID), a Revenu executa o split:

DÉBITO: conta_clearing_plataforma R$ 400,00

CRÉDITO: escrow_seller_a R$ 400,00

DÉBITO: conta_clearing_plataforma R$ 350,00

CRÉDITO: escrow_seller_b R$ 350,00

DÉBITO: conta_clearing_plataforma R$ 250,00

CRÉDITO: escrow_seller_c R$ 250,00

DÉBITO: conta_clearing_plataforma R$ 120,00 (taxa plataforma — deduzida proporcionalmente)

CRÉDITO: conta_receita_plataforma R$ 120,00

Após essa transação, o saldo da conta clearing é exatamente R$ 0,00. Cada centavo está contabilizado. O ledger balanceia. Sempre.

Passo 3: Agendamento de liquidação por seller

Cada conta escrow de seller tem seu próprio cronograma de liquidação:

• Seller A (D+0): Fundos do escrow liberados imediatamente. Uma transferência PIX é iniciada em segundos.
• Seller B (D+14): Fundos ficam em escrow por 14 dias. Se um chargeback chega durante essa janela, os fundos são bloqueados automaticamente.
• Seller C (D+30): Perfil de risco de seller novo. 30 dias de escrow proporcionam máxima proteção contra chargebacks.

Cronogramas de liquidação são configurados por seller, por método de pagamento e podem ser sobrescritos por transação.

A arquitetura de escrow

Escrow não é apenas um período de retenção. É uma conta de ledger separada com suas próprias regras:

Estados do escrow

Cada entrada de escrow percorre uma máquina de estados:

• PENDING — Fundos recebidos, aguardando data de liquidação
• AVAILABLE — Data de liquidação alcançada, fundos podem ser liberados
• BLOCKED — Chargeback ou disputa recebida, fundos congelados
• SETTLED — Fundos transferidos para a conta operacional do seller
• REVERSED — Chargeback vencido pelo comprador, fundos devolvidos

Tratamento de chargebacks em split payments

Aqui é onde a maioria das implementações falha catastroficamente. Um comprador disputa uma cobrança de R$ 1.000. O chargeback é pelo valor total — as bandeiras de cartão não sabem dos seus splits internos.

A Revenu lida com isso assim:

1. Alocação proporcional — O chargeback de R$ 1.000 é alocado proporcionalmente: R$ 400 para Seller A, R$ 350 para Seller B, R$ 250 para Seller C.

2. Compensação de escrow — Se o seller ainda tem fundos em escrow, o chargeback é absorvido do escrow primeiro.

3. Saldo negativo — Se o seller já sacou os fundos (liquidação D+0), a conta dele fica negativa. Pagamentos futuros compensam o saldo negativo automaticamente.

4. Garantia da plataforma — A plataforma pode opcionalmente configurar uma política de garantia: "se o saldo negativo do seller exceder R$ 5.000, a plataforma absorve a diferença."

Tudo isso acontece automaticamente. Sem intervenção manual. Sem planilhas. Sem "deixa eu verificar com o financeiro."

Estornos parciais

Um comprador quer devolver apenas o item do Seller B (R$ 350). A Revenu:

1. Identifica qual recebedor do split é afetado

2. Reverte apenas aquela porção dos lançamentos contábeis

3. Inicia estorno para o comprador de R$ 350 (menos taxa da plataforma se configurada como não-reembolsável)

4. Debita o escrow ou conta operacional do Seller B

5. Sellers A e C não são afetados em absolutamente nada

O ledger permanece balanceado durante todo o processo. Zero reconciliação manual.

Opções de liquidação e otimização de fluxo de caixa

Cronogramas de liquidação

Sellers podem ser configurados para:

• D+0 — Liquidação PIX instantânea. Fundos disponíveis em segundos. MDR mais alto (tipicamente 1-2% a mais).
• D+1 — Próximo dia útil. Comum para sellers estabelecidos.
• D+2 — Liquidação padrão. Default para a maioria dos sellers.
• D+14 — Retenção estendida. Usado para bens digitais, serviços ou categorias de maior risco.
• D+30 — Proteção máxima. Sellers novos, itens de alto ticket ou categorias com alta taxa de disputas.

Cada seller pode ter um cronograma diferente. Cada método de pagamento pode sobrescrever o default. Cada transação pode sobrescrever o default do seller.

Antecipação de recebíveis

Sellers com liquidação D+14 ou D+30 podem solicitar antecipação — receber os fundos antes da data de liquidação em troca de uma taxa de desconto. A Revenu trata antecipação como uma operação de ledger:

DÉBITO: escrow_seller R$ 350,00

CRÉDITO: operacional_seller R$ 343,00 (após taxa de antecipação de 2%)

CRÉDITO: receita_antecipacao_plataforma R$ 7,00

A plataforma ganha receita adicional com antecipação. Sellers têm acesso mais rápido ao caixa. Todo mundo ganha.

Splits multinível: quando o seller também é um marketplace

Alguns marketplaces têm sub-sellers. Uma plataforma de delivery (Nível 1) contrata restaurantes (Nível 2) que têm entregadores (Nível 3). Um único pagamento do comprador precisa ser dividido em 3 níveis.

A Revenu suporta splits recursivos:

• Nível 1: Plataforma cobra 15% de taxa
• Nível 2: Restaurante recebe 70%, paga taxa de entrega
• Nível 3: Entregador recebe 15%

Cada nível tem seu próprio escrow, seu próprio cronograma de liquidação e suas próprias regras de chargeback. O ledger rastreia o fluxo completo de fundos do comprador até o recebedor final.

PIX split: distribuição em tempo real

PIX adiciona outra dimensão aos split payments. Quando um comprador paga via PIX:

1. Pagamento é recebido em tempo real (< 2 segundos)

2. Split é executado atomicamente na mesma transação

3. Sellers D+0 recebem sua parte via PIX em < 10 segundos

4. O comprador vê uma única transação PIX

5. Cada seller recebe um crédito PIX separado com metadados completos

Splits PIX também suportam o protocolo MED 2.0. Se fraude é detectada, a Revenu rastreia o fluxo de fundos através de todos os recebedores do split e executa bloqueio em cadeia automaticamente.

Os números de produção

Após processar mais de R$ 2 bilhões em split payments:

• Tempo de execução do split: < 15ms (p99)
• Discrepância de balanço do ledger: R$ 0,00 (sempre balanceado)
• Tempo de resolução de chargebacks: < 30 segundos (alocação automática)
• Processamento de estornos parciais: < 5 segundos
• Precisão de liquidação: 100% — zero reconciliação manual
• Recebedores de split suportados por transação: até 50

Por que isso importa para o seu marketplace

Se você está construindo um marketplace no Brasil, split payments não são opcionais — são o core do seu modelo de negócio. Sua taxa de plataforma, a experiência dos seus sellers, sua responsabilidade por chargebacks e seu compliance regulatório dependem de acertar os splits.

A diferença entre uma implementação ingênua e um split atômico baseado em ledger é a diferença entre um marketplace que funciona na escala de demo e um que funciona a R$ 1 bilhão de GMV.

Nós construímos isso porque vimos o que acontece quando splits quebram. Reconciliação manual. Sellers furiosos. Fundos perdidos. Auditorias regulatórias. Já vimos plataformas fecharem porque não conseguiam prestar contas de para onde o dinheiro foi.

A API de split da Revenu existe para que você nunca precise se preocupar com nada disso. Uma chamada API. N sellers. Execução atômica. Ledger perfeito. Toda vez.