Como a VendePay funciona hoje.

• A V1 aceita uma oferta principal e um plano principal por produto.
• Uma segunda criação ou identificador diferente recebe conflito 409.
• Preço mínimo equivalente a 10 na moeda base.
• Descritor de fatura é obrigatório.

Em novas compras avulsas e pagamentos iniciais de assinaturas no checkout com cotação travada, um produto de R$ 100 mantém R$ 100 como base das taxas, reserva e participações. O preço em moeda estrangeira inclui a conversão paga pelo comprador.

A Gestão separa o bruto comercial, o bruto recebido da Stripe e o adicional de conversão. O valor comercial não é uma promessa de líquido disponível. O histórico mantém a regra da compra. Preço contratado é o snapshot da compra, após descontos, nunca o preço atual do catálogo. Variação cambial é o bruto comercial registrado menos esse preço. Mostrar ambos e o bruto da cobrança em Seller e Gestão, preservando taxas, comissão, reserva e histórico. A primeira cobrança protegida tem variação comercial zero; a diferença do bruto observado na Stripe permanece separada. Em Assinaturas, cobranças pagas usam a liquidação da venda vinculada; preço contratado não substitui dinheiro liquidado. Sem observação, mostrar liquidação em apuração. Previsões não prometem o mesmo BRL nas renovações. Tentativas pendentes ou recusadas não ocultam o detalhamento das cobranças efetivadas. Se os valores registrados fecham exatamente, mas o arredondamento individual gera diferença na soma visível, mostrar uma nota com essa diferença, sem redistribuir centavos ou alterar o ledger.

Básico, Recursos, Preço, Funil, Afiliados e Links. Recorrência vive em Preço; o builder abre por Links.

Tracking é uma etapa própria com Meta, TikTok, Google Ads e UTMify.

Pixels novos começam em comissão. Em “Enviar valor”, a pessoa escolhe “Comissão” ou “Bruto”. Pixels existentes mantêm a escolha salva e pixels de afiliado continuam somente em comissão.

No Seller, a fórmula informa “9,9% + US$ 1,49 por cobrança”. Quando o total inclui mais de uma tarifa fixa registrada, mostrar “N tarifas fixas neste total. Principal e order bump compartilham uma tarifa; cada cobrança adicional tem a sua.” Contar somente tarifas positivas das cobranças incluídas no serviço exibido, nunca produtos ou itens. Sem dados completos das tarifas, omitir a contagem. No detalhe de uma cobrança isolada, não somar tarifas de outras cobranças. Valores, cotações e deduções históricas permanecem inalterados.

Com cupom e cotação travada, aplicar o desconto primeiro no bruto comercial BRL e depois converter o valor final para a moeda cobrada, arredondando para cima. Usar a prévia calculada pelo servidor no resumo e nas wallets. Renovar a cotação também revalida o cupom e exige nova confirmação. A prévia corresponde à oferta selecionada. Trocar a oferta ou a cotação bloqueia o pagamento, a abertura e a confirmação de wallets até revalidar o cupom.

Novas cobranças usam 9,9% sobre o bruto comercial mais US$ 1,49, convertido na moeda da liquidação pela cotação registrada na cobrança. Não há tarifa adicional de conversão de 3%. O histórico preserva os valores da compra.

No Seller, Valores mostra itens, descontos, Valor da venda, Serviço VendePay e Sua comissão. Reserva e prazo de liberação permanecem explícitos. A Gestão mantém a discriminação e a cotação da tarifa fixa para auditoria e QA da mesma venda.

O valor de Serviço VendePay deve ser o mesmo no Seller e na Gestão para a mesma cobrança, preservando as deduções históricas. Conversão paga pelo comprador fica separada. A Gestão apresenta VendePay antes dos custos e os custos observados do provedor, sem nova dedução dos participantes. O resultado após custos é da cobrança original, antes de reembolsos, contestações e outros custos; não representa saldo disponível, pagamento bancário ou lucro final. Só calcular quando o custo estiver informado, as moedas coincidirem e a distribuição completa fechar com o bruto recebido do provedor. Ausência de observação é indisponibilidade, nunca zero. O total do grupo VendePay no extrato é anterior aos custos.

A cotação de pagamento travada protege o bruto comercial BRL das novas avulsas e dos pagamentos iniciais no checkout, incluindo planos, trials pagos, bumps e ofertas recorrentes. A cotação pertence somente a esse pagamento. Renovações preservam o valor contratado na moeda do comprador e liquidam pelo câmbio efetivo da nova cobrança; não reutilizam a cotação vencida. Trials gratuitos não geram pagamento inicial. Uma mudança de cotação exige reconfirmação do preço atualizado.

Múltiplos order bumps, ramos de aceite/recusa, upsell e downsell, páginas hospedadas ou externas e planos recorrentes.

Ao salvar upsells e downsells, o aviso explica a causa e como corrigir: oferta repetida, conexões do funil, produto ou oferta indisponível, produtor, plano, preço, moeda base e URL da página própria. A mesma oferta não pode aparecer em duas etapas; a mensagem não bloqueia genericamente todo produto repetido. Motivos desconhecidos recebem orientação segura, sem IDs ou detalhes técnicos.

A comissão do afiliado pertence ao produto de entrada. Etapas marcadas herdam o percentual efetivo da venda principal; a configuração própria do produto adicional só vale quando ele é vendido como entrada.

Em Minhas afiliações, quando o percentual do acordo difere do padrão atual do produto, mostrar uma nota informativa com ícone e texto secundário legível distinguindo o padrão para novas afiliações da comissão preservada do afiliado. Manter o percentual do acordo em destaque nos itens do funil; omitir a nota para valores iguais, ausentes ou inválidos.

No editor, destaque essa regra junto à comissão padrão e mostre o percentual em cada etapa.

Trocar o produto ou o plano de uma etapa preserva a escolha de comissão já salva, inclusive ao selecionar uma assinatura.

Assinaturas de order bump, upsell e downsell herdam do produto de entrada a opção de comissão nas renovações. O contrato aceito congela essa escolha; desligá-la preserva a comissão inicial e não reescreve contratos anteriores.

O mesmo usuário não pode ser afiliado aprovado e coprodutor ativo do mesmo produto. Bloqueie o convite e revalide no aceite; bloqueie aprovação automática, manual e reaprovação da afiliação. Pedidos pendentes podem coexistir, mas não os dois vínculos ativos. Mostre o conflito no campo de e-mail e nas ações de aceite/aprovação. Preserve usuários distintos, produtos distintos e o histórico financeiro.

A prévia de coprodução fecha cada parcela na unidade da moeda; o produtor recebe o restante após a parcela do coprodutor.

Preserve Disponível, A liberar, Reservado e Em envio conforme o ledger comercial, sempre com a moeda explícita. O saldo atual independe do período selecionado e não é substituído por observação da Stripe.

Liberações comerciais, créditos, débitos, ajustes e dívidas continuam seguindo seus registros e datas no ledger. Reserva comercial e elegibilidade ainda não comprovada não são saldo retido pelo banco.

O extrato mantém créditos, débitos, liberações, ajustes e dívidas com motivo, valor, data e venda de origem. Um reembolso de R$ 18 permanece um único débito de R$ 18 na data de origem, mesmo que a compensação interna ocorra em partes; preserve o crédito e a reserva originais.

Use os filtros Débitos e Créditos. No drawer, mostre evento, data, venda, motivo, carteira e IDs de rastreabilidade; não crie histórico de compensações ou vendas financiadoras. Totais carregados excluem INFO, mantêm seu escopo e não substituem o saldo atual.

Reconheça a dívida integral. Disputa ganha reverte o valor recuperado e a dívida pendente cancelada, sem provar que o valor esteja disponível. Compensações internas não criam lançamentos adicionais.

Registre cada saque observado em wallet.statement_journal como WITHDRAWAL_OBSERVED, direção INFO, com amount (MoneyDto), detail.status e snapshot de detail.ledgerStatus. O registro informa a observação; não lança por si só crédito ou débito nem cria tabela financeira nova.

Mostre o estado informado pela Stripe em detail.status, separado da conciliação: pending, in_transit, paid, failed ou canceled. “Pago pela Stripe” descreve apenas o estado da Stripe; não confirma depósito bancário. Exiba arrival_date somente quando fornecida, separada de D5 e da data de liberação comercial.

Nos DTOs de /wallet/payouts e /admin/payouts, status e ledgerStatus ficam no topo; o card de conciliação usa ledgerStatus. Quando pendente, mostre “Conciliação do ledger pendente” mesmo se status for paid; isso não confirma chegada bancária nem aplica efeito financeiro.

Explique o motivo quando existir: composition_pending (composição em análise), composition_divergent (composição divergente) ou allocation_or_eligibility_unproven (alocação ou elegibilidade comercial aplicável não comprovada). Referências, composição, valores ou elegibilidade ainda não comprovados mantêm o efeito financeiro pendente.

Isso não cria espera por availableAt, D5 ou outra data local: pagamento paid totalmente comprovado pode ser baixado sem aguardar data local. Datas e condições comerciais e regras de dívida permanecem intactas.

A mudança para completed exige claim+complete atômico, payout com status=paid pela Stripe e elegibilidade comercial comprovada; use o estado do payout, não um snapshot histórico INFO. pending só se aplica enquanto o efeito financeiro ainda não foi comprovado. reversed só aparece após desfazer um efeito real. WITHDRAWAL_COMPLETED é saída apenas quando o efeito aconteceu; WITHDRAWAL_REVERTED é entrada apenas quando a reversão ocorreu.

Preserve o banco informado para aquele saque no snapshot histórico. Se não houver essa evidência, mostre “Banco não identificado”; nunca preencha pelo banco atual.

Componha a observação apenas com balance transactions explicitamente vinculadas ao saque. Relacione venda somente por referências comprovadas de origem, transfer e alocação do settlement; nunca infira vínculo por valor, data ou venda mais recente.

Mantenha a conciliação pendente enquanto houver páginas faltantes ou cobertura incompleta do histórico necessário. Não declare divergência resolvida nem composição completa antes de conferir todas as páginas.

Mostre quando ocorreu a última observação bem-sucedida e indique falha ou desatualização da consulta. Em falha de leitura ou sincronização, preserve o snapshot e identifique que ele pode estar desatualizado. Preserve também completed e reversed; pending só representa efeitos ainda não comprovados. Falha de leitura nunca rebaixa o estado financeiro.

Sem observação, banco ou arrival_date, use “indisponível”, “Banco não identificado” ou “Previsão indisponível”, conforme o dado; ausência nunca é zero nem uma data inferida.

A experiência não oferece solicitação manual, cotação, aprovação, recusa ou cancelamento do saque. A conciliação acompanha o efeito real no ledger sem ação local para comandar ou bloquear o payout automático.

Na Gestão, Usuários → Plano e taxas permite consultar condições e histórico. Somente a permissão específica de gerenciar planos libera a edição.

Existem apenas Padrão e Personalizado para cartão de crédito. O Padrão atual começa com 9,90% mais fixa da moeda e reserva comercial de 7% por 90 dias nas novas vendas, sem exceção para valores pequenos. D5 é a referência comercial do plano. A previsão por cobrança Connect vem da conta de pagamento e não determina a chegada bancária. Pix entra em etapa futura do Mercado Nacional.

Nas vendas Stripe Connect, a previsão de liberação de USER/COMMISSION vem de available_on da transação validada do recebedor; a cobrança fornece previsão provisória enquanto essa transação não existe. Disponível exige status available na conta conectada, sem inferir pelo relógio. O país emissor vem de payment_method_details.card.country, nunca de endereço, IP ou moeda. Sem data conhecida, mostrar Aguardando previsão de liberação e manter o valor em A liberar. Aplicar em Dashboard, Vendas e renovações, Finanças, agenda, extrato, itens e exportações de Seller e Gestão. Datas previstas usam o dia UTC. Valores, taxas, reservas e histórico contábil permanecem preservados. arrival_date continua exclusivo da previsão bancária do payout. A disponibilidade do recebível permanece visível junto a A liberar mesmo com reserva positiva; a orientação da reserva fica separada. A Gestão preserva awaitingAvailability ao converter o saldo. Restituições de disputa usam a disponibilidade de sua própria transferência DISPUTE_RETURN, sem herdar a previsão da cobrança original.

Separe as datas de liberação comercial e de chegada bancária. Mostre arrival_date somente quando retornada para o payout; sem esse dado, não derive uma data fixa do país, da moeda ou de D5.

Nos planos Padrão e Personalizado, as reservas nacional e internacional exigem percentuais inteiros em todas as moedas. Valores fracionários bloqueiam a revisão e a gravação, com mensagem no campo; não são arredondados. Valores inteiros armazenados como 7.000 continuam válidos. Taxas comerciais podem ter casas decimais e o histórico mantém seus valores originais.

Em Gestão → Configurações, a equipe com permissão de gerenciar planos edita as condições globais do Padrão, com motivo, revisão antes de salvar e histórico. Em Usuários → Plano e taxas, cada campo negociado no Personalizado fica protegido da edição global. Se apenas a taxa fixa em USD foi personalizada, ela permanece enquanto as demais condições acompanham o Padrão vigente. No Seller, Configurações apenas consulta as condições vigentes; o vendedor não troca de plano.

Cada pagamento confirmado, inclusive renovação, usa o plano vigente naquele momento. Vendas e recebíveis anteriores mantêm suas condições comerciais; trocar o plano nunca recalcula o passado. A liberação comercial segue o ledger; estado Stripe e chegada bancária são observações separadas.

O vendedor escolhe o período. Destaque o valor bruto já cobrado e pago, antes de taxas e divisões; não é saldo disponível. Agendado e previsto, recuperação e ainda cobrável são indicadores secundários. Base ativa e MRR usam o fim do período limitado a hoje; churn usa a base inicial e LTV usa meses completos anteriores.

O afiliado da compra de origem acompanha todos os produtos, contratos e cobranças dessa compra, incluindo bump, funil e renovações sem comissão. Bruto é o valor completo da operação; líquido é somente a parte do usuário, podendo ser zero. Comissão não filtra a visibilidade. Permissões de reembolso, cobrança e cancelamento permanecem separadas e restritas aos papéis autorizados. Base e previsão são brutas, sem promessa de ganho. Linha e detalhe de cobrança usam o mesmo escopo, sem somar o upsell separado duas vezes.

Já cobrado mantém primeiras cobranças e renovações pagas no mês mesmo após cancelar a assinatura; cobranças fechadas sem pagamento não entram. Cancelamento remove valores agendados e em recuperação, sem apagar pagamentos anteriores. Uma cobrança compartilhada por principal e order bump entra uma única vez no total cobrado, mantendo a contagem de assinaturas.