Como pagar comissão pra terceiros sem virar um marketplace (Venda de Gift Cards)

TL;DR

Estou construindo uma plataforma onde qualquer pessoa cria sua própria loja, escolhe produtos de um catálogo central e ganha comissão nas vendas.

Antes de implementar o checkout precisei escolher entre dividir o pagamento na hora da venda (split) ou receber tudo e repassar a comissão depois. Escolhi a segunda, e isso definiu o schema inteiro.

Ainda não escrevi uma linha da implementação, justamente pra poder mudar de ideia sem custo. Queria saber onde esse desenho quebra na prática.

Contexto

O Manifold é uma plataforma de lojas. Qualquer pessoa monta sua vitrine, escolhe quais produtos do catálogo central quer vender, personaliza a cara da loja e ganha comissão sobre cada venda. A missão é ser a Steam Open Source, mas no MVP eu vendo gift cards, com estoque vindo da API de um distribuidor. Escolhi gift card porque a entrega é digital e imediata, mas ela traz um problema específico: é irreversível.

Stack, pra quem se importa: Next.js com Pages Router, TypeScript e Postgres com Prisma.

O problema: quem recebe o dinheiro

Quando você deixa terceiros venderem e ganharem pela sua plataforma, existem dois caminhos.

Caminho A: split de pagamento. Stripe Connect com destination charges. A cada venda o dinheiro é dividido na hora, uma parte pra plataforma e outra pro dono da loja. Foi meu primeiro instinto, principalmente porque o Stripe cuidaria das transferências pra mim.

Caminho B: plataforma como merchant of record. A plataforma recebe 100% do pagamento, segura a comissão por um período e depois repassa em lote. É basicamente como a Steam paga os desenvolvedores: um pagamento periódico com extrato, e não uma divisão por transação.

Fui de B, por dois motivos.

O split acaba com a proteção contra chargeback

Gift card é entrega irreversível. O código é revelado, o consumidor usa, acabou. Não existe devolução.

Se um chargeback cai 20 dias depois da venda e a comissão já foi transferida, o prejuízo é meu. Tentar recuperar de uma conta com saldo zero não funciona na prática.

Ou seja: o período de retenção é a proteção contra chargeback, e o split elimina exatamente isso.

O split muda o papel do dono da loja

Esse foi o ponto que eu não tinha considerado.

Se o dono da loja recebe parte do valor no momento da transação, ele se parece com um vendedor recebendo pelo produto. Isso empurra a plataforma pra tratamento de marketplace e possivelmente pra obrigações de facilitador de pagamento, que é bem mais complexo de operar.

O modelo funciona porque o dinheiro é meu primeiro, e a comissão é uma despesa minha depois. Mas isso precisa ser verdade na prática, não só no contrato.

O detalhe do schema que sustenta isso: donos de loja escolhem quais produtos aparecem na vitrine, mas não definem preço. Sem controle de preço, sem posse do estoque e sem relação direta com o consumidor, o papel é de divulgação e não de revenda. Anotei como restrição no repositório, porque se um dia eu implementar preço por loja eu mudo de categoria sem perceber.

Uma confusão que me custou tempo

Stripe Connect e split de pagamento não são a mesma coisa.

O Connect são dois produtos separáveis. Um é o destination charge, que divide na hora. O outro é a infraestrutura de contas conectadas, com onboarding, verificação de identidade e dados bancários, que você pode usar com separate charges and transfers, disparando a transferência quando quiser.

Dá pra ter o Connect cuidando da parte chata sem abrir mão da retenção. Eu tinha assumido que era pacote fechado, e essa suposição quase me levou pro caminho A.

A consequência: a contabilidade passa a ser minha

Escolher o caminho B significa que ninguém divide o dinheiro por mim. Eu recebo tudo, seguro por 30 dias, e preciso saber a cada momento quanto devo pra quem, o que já venceu e o que foi estornado.

Consumidor paga o preço cheio
        ↓
Plataforma (merchant of record)
        ↓
Fornecedor → código do gift card → Consumidor
        ↓
Lançamentos no ledger (append-only, soma zero)
        ↓
   [ retenção de 30 dias ]
        ↓
   chargeback? → lançamento reverso (negativo)
   limpo?      → saldo disponível
        ↓
   acima do mínimo? → lote de pagamento mensal

Fui de ledger append-only com partidas dobradas. Como o termo assusta mais do que devia, vale explicar.

A ideia central é que dinheiro nunca aparece nem some, ele só muda de lugar. Então todo evento é registrado como vários lançamentos ao mesmo tempo, que somados dão zero.

Alguém compra um gift card por 100 na loja de um afiliado. Paguei 80 pro fornecedor, devo 5 de comissão, sobram 15 pra mim:

cash                   +100   (entrou dinheiro)
supplier_cost           -80   (custo do código)
affiliate_commission     -5   (devo pro dono da loja)
platform_revenue        -15   (meu)
                      -----
                          0

Os sinais parecem estranhos no começo. Pensa que os 100 que entraram já estão todos comprometidos: nada é meu enquanto eu não disser de onde veio e pra onde foi.

O estorno é a parte que mais me convenceu. Chargeback 20 dias depois não apaga nem edita nada, escreve lançamentos novos com sinal invertido:

cash                   -100
supplier_cost           +80
affiliate_commission     +5
platform_revenue        +15
                      -----
                          0

A comissão do afiliado agora soma 5 + (-5) = 0. Ele não recebe, e o histórico mostra as duas coisas: que ele ganhou e que foi revertido. Com UPDATE eu teria perdido a informação de que a venda existiu, que é justamente minha evidência se eu precisar contestar o chargeback.

E a regra da soma zero é o que pega bug. Se um cálculo errado tentar gravar 100 de entrada contra 79 + 5 + 15 de saída, a soma dá 1 e a escrita falha na hora. Sem isso, esse 1 vira um centavo perdido por venda que só aparece meses depois quando a conta não fecha.

É contabilidade de 500 anos atrás. A parte de software é só: tabela append-only, nunca UPDATE, nunca DELETE, e validação de soma zero no insert.

Abrindo pra discussão

O que mais quero saber: esse desenho quebra onde?

As dúvidas que eu tenho hoje são se 30 dias é retenção suficiente pro tipo de produto que eu vendo, e se a distinção "afiliado que divulga" versus "vendedor que revende" aguenta na prática o crescimento, ou se em algum momento a pressão por preço por loja vai ser grande demais pra segurar.

Mas a que mais me tira o sono é o reembolso.

Quem já vendeu gift card ou chave digital: o quão ruim é na prática? O cenário óbvio é o cara comprar, revelar o código, resgatar de verdade, e aí pedir reembolso ou abrir chargeback. Do meu lado eu não tenho como desfazer nada, o saldo já foi pro cartão presente dele e o distribuidor não vai me devolver.

Minha ideia é registrar o momento exato em que o código foi revelado e exigir um aceite explícito na hora ("depois disso não tem reembolso"), usando isso como evidência na contestação. Mas eu não sei se isso segura de verdade quando o caso vai pra análise, ou se na prática a operadora do cartão dá razão pro consumidor quase sempre e isso vira só custo de operação que eu preciso embutir na margem.

Também não faço ideia de qual taxa de chargeback é normal nesse mercado. Se alguém tiver número real, mesmo que aproximado, ajuda muito a dimensionar se o negócio fecha.

Se você já montou repasse pra terceiros, seja marketplace, programa de afiliados ou split, queria muito ouvir onde isso te mordeu.

O plano é refinar publicamente e depois escrever um post com a solução final e o que eu errei no caminho.

O projeto é open source: https://github.com/pedromello/manifoldpowered.com

O plano de tarefas com os diagramas está em docs/payments-tasks.md, e a discussão na issue #177. Quem quiser contribuir, seja com código ou comentando na issue, é muito bem-vindo.