Dinheiro: custódia, split e carteira

Esta página explica o que acontece com o dinheiro de uma venda: quem o guarda, como ele é dividido entre as partes e o que é o saldo que aparece na carteira. Há um princípio que atravessa tudo e vale ler antes de qualquer detalhe: a Lootfy nunca custodia dinheiro. Ela orquestra e reflete status, mas o dinheiro em si vive, o tempo todo, no provedor de pagamento.

A Lootfy está fora do fluxo de fundos

Quem custodia o dinheiro é o PSP (o provedor de pagamento, a Pagar.me). A Lootfy apenas emite comandos à API dele e reflete o status que ele devolve por webhook. Isso não é um detalhe de implementação: é uma decisão de desenho com consequências regulatórias. Uma plataforma que retém saldo de terceiros teria implicações junto ao Banco Central que a Lootfy escolhe não ter. Por isso, toda retenção, liberação e devolução é sempre um comando ao PSP, nunca uma movimentação na conta da Lootfy.

Custódia com saída controlada por comando

O mecanismo é o split nativo do PSP com saída controlada por comando. O que a plataforma controla não é a entrada do valor no recebedor — essa é imediata, no pagamento — e sim a saída: nenhum recebedor tem transferência automática ligada, e todo pagamento para fora só acontece por comando explícito. “Escrow” serve como sinônimo conceitual na primeira menção, mas quem detém o saldo é o PSP, não a Lootfy.

O split de três destinos

Quando o comprador paga, o valor bruto é dividido entre até três destinos, segundo uma regra fixada na criação da cobrança. Para não-programadores: pense no bruto como o bolo, do qual saem duas fatias de comissão antes do que sobra ir para o vendedor.

comissao_plataforma = valor_bruto × pct_comissao_plataforma_do_servidor
comissao_servidor   = valor_bruto × pct_comissao_servidor
valor_vendedor      = valor_bruto − comissao_plataforma − comissao_servidor

Vendedor

Recebe o bruto menos as duas comissões. É sempre um destino do split.

Plataforma

Recebe valor_bruto × %plataforma. Um recebedor único, o mesmo para todos os servidores.

Servidor do jogo

Recebe valor_bruto × %servidor — creditado no recebedor do gestor daquele servidor.

Dois pontos merecem atenção especial.

A taxa do próprio PSP sai da fatia da plataforma. Vendedor e servidor recebem percentuais limpos sobre o bruto; é a plataforma que absorve o custo operacional do PSP. A taxa é puramente percentual (medida em 1,00% do bruto, sem parte fixa), o que significa que não há piso de valor por motivo econômico — a fatia da plataforma e o custo crescem juntos.

Destino cuja fatia dá zero não entra no split. Isso acontece quando uma comissão está configurada em 0% ou quando o arredondamento para baixo, em valor pequeno, zera a fatia. Por isso o split é de até três destinos, não exatamente três. O vendedor, esse, é sempre destino.

O servidor do jogo não tem recebedor próprio

A fatia “servidor” não cai numa entidade servidor: ela é creditada no recebedor do gestor daquele servidor — o mesmo recebedor que o gestor usa quando vende itens próprios. Como cada servidor tem exatamente um gestor, o destino dessa fatia é sempre único e conhecido no instante da cobrança, que é o que o split do PSP exige. Consequência: um servidor sem gestor, ou com gestor sem recebedor aprovado, não vende — a fatia do servidor não teria destino.

Os percentuais são por servidor e são congelados na criação da transação: o split, montado depois na cobrança, usa os valores gravados na transação, não os que estiverem vigentes no servidor naquele momento. Sem isso, uma edição de comissão mudaria retroativamente o resultado de transações já criadas. Todos os valores são inteiros, em centavos.

O recebedor

O recebedor (recipient) é a identidade financeira de uma pessoa dentro do PSP — um por pessoa. É para o recebedor que a fatia do split é direcionada, e é a partir dele que um saque é pago. Cada vendedor pessoa física tem o seu, criado e ativado após o KYC do provedor. Ter um recebedor aprovado é justamente o que torna alguém um vendedor: sem ele, o vendedor não anuncia (é uma das três pré-condições do vendedor) e a transação não nasce.

Como o recebedor é um por pessoa e não um por papel, um gestor que também vende itens próprios recebe as duas receitas no mesmo lugar — a comissão do servidor e as vendas dele. As duas se distinguem no ledger da Lootfy, não no PSP.

A carteira

A carteira que você vê na plataforma é um espelho contábil (um ledger) do saldo do recebedor no PSP. Ela não é dinheiro guardado pela Lootfy. Ela expõe o saldo disponível, o saldo a receber e o histórico, mas a verdade financeira está sempre no PSP. Como os webhooks do PSP podem atrasar, a carteira pode estar temporariamente defasada em relação ao saldo real — a Lootfy nunca garante saldo por conta própria; divergências são corrigidas por um job de conciliação.

O ponto mais importante da carteira liga-se ao ciclo de vida da transação: o valor de uma venda só vira sacável depois que a entrega é confirmada pelo seu servidor. Antes disso, o valor aparece como retido — creditado no recebedor, porém marcado como não sacável no ledger. A transição de entrega não move dinheiro; ela muda a elegibilidade ao saque.

O saque

Planejado — ainda não disponível

A execução do saque (solicitar e aprovar um payout a partir do recebedor) ainda não está implementada. O modelo já está desenhado — um saque é um payout do PSP a partir do saldo sacável do recebedor, sujeito a um conjunto de pré-condições (o “gate de saque”: e-mail e telefone confirmados, identidade verificada, conta bancária cadastrada e recebedor ativo no PSP). Mas não há hoje endpoint para executá-lo. Trate o saque como conceito planejado; nenhum passo a passo é possível ainda.

Próximo: estoque estimado Como a Lootfy estima o estoque de um anúncio e por que essa estimativa só recusa, nunca autoriza.