Receita construída como infraestrutura.
Uma stack única para cobrar, reconhecer e reconciliar receita dentro do seu app. Ledger auditável desde a primeira transação, integração pensada por quem cansou de reescrever webhook. Estamos escolhendo os primeiros casos de uso agora.
// API target shape · não é release
A IA construiu o produto.
Falta a fundação.
Construir software deixou de ser o gargalo. Um founder sozinho entrega em um fim de semana o que exigia um time por trimestre. Mas o que acontece depois do deploy, cobrar, reconciliar e provar cada centavo, continua exatamente tão difícil quanto era.
A velocidade parou no checkout
O produto nasce em dias. A monetização leva semanas de integração, homologação e reescrita de webhook. A curva de construção e a curva de cobrança deixaram de andar juntas.
DX ruim custa dinheiro
Documentação desatualizada, sandbox que não espelha produção, erro genérico truncado. Cada hora lendo manual de integração é uma hora não gasta no produto.
O ledger é sempre uma planilha
Quando chega auditoria, contador ou due diligence, a verdade financeira está espalhada entre extrato, planilha exportada e memória do founder. Ninguém projetou isso. Apenas aconteceu.
Receita não é um evento
Cobrar é um instante. Receita é cohort, recorrência, inadimplência, reconhecimento e reconciliação. A ferramenta que resolve o instante raramente resolve o sistema.
Não é mais um gateway.
É a camada de receita.
O mercado brasileiro tem gateway, tem plataforma de pagamento e tem planilha. O que falta é a camada onde receita nasce como registro contábil, não como evento de log. É essa camada que estamos construindo.
Gateway
Resolve a transação. Autoriza, captura, devolve um status. Onde a maior parte do mercado brasileiro opera hoje.
Plataforma de pagamento
Resolve o pagamento. Antifraude, split, recebíveis, gestão de conta. Amplia a transação, mas ainda a trata como fim.
Revenue OS
Trata a receita como sistema contábil vivo: cada movimento em dupla entrada, auditável desde a primeira cobrança. A camada que declaramos como alvo.
Uma camada acima muda o que o time de finanças abre segunda de manhã. Deixa de ser planilha reconciliando extrato e vira ledger com verdade única.
Quatro módulos.
Uma stack única.
Isto é um plano de construção, não um catálogo de produto disponível. Cada linha carrega a fase em que está.
Checkout
fase 1 · em construçãoA cobrança como primitiva. Uma chamada de API cria a cobrança e devolve o link pronto para o app. Idempotência por header impede cobrança duplicada. Página hospedada para quem quer ir ao ar sem front próprio.
- fase 1Pix one-shot com página de checkout hospedada
- fase 2Cartão via tokenização de parceiro certificado
- fase 2SDK Node, outras linguagens conforme demanda
- fase 3White-label e customização de marca
Subscriptions
fase 3 · roadmapRecorrência sem gambiarra. Cartão tokenizado com dunning inteligente. Proration de upgrade e downgrade tratado pelo motor, não pelo seu backend. Pix Automático entra quando a regulação abrir a janela.
- fase 3Recorrência via cartão tokenizado
- fase 3Proration, upgrade e downgrade de plano
- fase 3Dunning e retentativa de cobrança
- roadmapPix Automático, após habilitação regulatória
Ledger
fase 1 · em construçãoAuditável por design. Cada transação nasce em dupla entrada, com débito e crédito registrados no mesmo instante. Contador abre o CSV e a conciliação já está feita. Auditoria e due diligence deixam de ser projeto.
- fase 1Ledger double-entry interno, exportável em CSV
- fase 2Emissão de NFe via parceiro homologado
- fase 3Reconciliação bancária via Open Finance ou CNAB
Growth
fase 4 · roadmapReceita não é evento, é sistema. Cohort, LTV, movimentos de MRR, churn saudável ou podre. Quando os três primeiros módulos existem, o quarto vira leitura de negócio pronta, sem plugar BI externo.
- fase 4Cohort, LTV e movimentos de receita recorrente
- fase 4Alertas de inadimplência e churn
- fase 4Exportação para ferramentas de análise
A verdade financeira,
em uma tela.
Este é um mockup de conceito. Os campos estão vazios de propósito: preferimos mostrar a estrutura a inventar números que não existem.
example · mockup · nenhum dado real. cada linha do ledger nasce em dupla entrada.
Quatro números.
Todos verificáveis.
Concorrentes prometem taxas, uptime e latência antes de ter servidor ligado. Nós não. Cada número aqui você consegue conferir agora mesmo: no whois, no repositório, no plano de construção. Nenhum é chute.
O que você precisa saber.
Por que Revenue OS e não mais um gateway? +
Gateway resolve a transação e devolve status. Plataforma de pagamento amplia a transação. Nenhum dos dois trata receita como registro contábil. Quando chega auditoria ou due diligence, a verdade financeira está fora do sistema, em planilha. Nossa camada vira a fonte primária, com ledger de dupla entrada desde a primeira cobrança.
O que muda entrando na lista de fundadores agora? +
Estamos escolhendo os primeiros casos de uso da fase 1. Seu caso pode entrar na ordem de construção. Conversamos direto com quem está construindo, sem intermediário. Quem entra depois recebe o produto pronto. Quem entra agora decide o que fica pronto primeiro.
Dá para usar hoje? +
Ainda não. Checkout Pix one-shot e ledger interno estão em construção agora. A lista de fundadores é o caminho para quem quer influenciar a ordem, não para quem só quer ser notificado do lançamento.
Quais taxas vocês vão cobrar? +
Pricing em definição. Publicar taxa antes de operar seria promessa sem lastro, e essa não é a nossa forma de trabalhar. Fundadores recebem o pricing antes do público e discutem os termos direto com a gente.
Quando lança? +
Sem data pública. Cada módulo muda de fase quando há evidência registrada, não quando o calendário aperta. Fundadores recebem o cronograma real por dentro.
Vocês processam o pagamento? +
A liquidação usa parceiros regulados. Nossa camada é a orquestração, o ledger e a experiência de integração. Você fica com uma API única em vez de três SDKs empilhados.
Terei acesso aos dados? +
Sim. O ledger nasce exportável em CSV na fase 1. O dado é seu, e sai da plataforma quando você quiser. Sem lock-in de formato, sem obscuridade contábil.
E a LGPD? +
Tratamos a conformidade como construção contínua, com DPO designado. Os termos e a política de privacidade estão em elaboração e serão publicados antes de qualquer operação.
A marca vive em
dois endereços.
Registrados, ativos e renovados automaticamente até 2027. Nenhum outro endereço representa a podpagar.
Construa isso
com a gente.
Estamos escolhendo os primeiros casos de uso. Quem entra agora conversa direto com quem está construindo e influencia a ordem da fase 1.
Sem spam, sem venda de lista. Seus dados ficam restritos ao contato sobre a podpagar.