Quando vale usar RevenueCat em vez de Google Play Billing direto?

Quando um app começa a vender uma opção “sem anúncios”, a primeira reação natural é tentar preservar cada ponto de margem. Se o Google Play já oferece Google Play Billing, por que colocar RevenueCat no meio?

A resposta curta: porque Google Play Billing processa a compra, mas não resolve sozinho toda a operação de monetização.

RevenueCat adiciona uma camada para gerenciar entitlements, restaurar compras, validar recibos, lidar com estados inconsistentes, acompanhar receita e deixar uma futura versão iOS menos trabalhosa. Isso tem custo. A pergunta correta é se esse custo é maior ou menor que o custo de construir e manter tudo por conta própria.

A conta simples

Vamos usar um produto simples: no ads por US$ 1.00.

Com uma taxa Google Play de 15%, uma compra de US$ 1.00 deixa aproximadamente US$ 0.85 antes de impostos, chargebacks, câmbio e contabilidade.

RevenueCat, no modelo considerado para esta decisão, custa US$ 0 até US$ 2,500 de Monthly Tracked Revenue. Acima desse limite, passa a cobrar cerca de 1% da receita bruta rastreada.

Na prática:

• Antes do limite gratuito: US$ 1.00 vira cerca de US$ 0.85.
• Depois do limite gratuito: US$ 1.00 vira cerca de US$ 0.84.

Ou seja, RevenueCat não muda a economia inicial do produto. Quando começa a cobrar, reduz cerca de 1 ponto percentual da receita bruta.

Projeção mensal

Com o produto a US$ 1.00, a conta fica assim:

Compras/mês	Receita bruta	Após Google Play	RevenueCat	Líquido aproximado
100	US$ 100	US$ 85	US$ 0	US$ 85
1,000	US$ 1,000	US$ 850	US$ 0	US$ 850
2,500	US$ 2,500	US$ 2,125	US$ 0	US$ 2,125
5,000	US$ 5,000	US$ 4,250	US$ 50	US$ 4,200
10,000	US$ 10,000	US$ 8,500	US$ 100	US$ 8,400

Essa tabela mostra a parte desconfortável: a taxa da loja pesa muito mais que RevenueCat. O custo de RevenueCat existe, mas ele fica pequeno perto da comissão da plataforma e, principalmente, perto do custo de errar uma compra.

O que parece barato pode sair caro

Integrar direto com Google Play Billing parece mais barato porque remove a taxa do intermediário. Mas a integração direta traz trabalho que precisa continuar correto depois do lançamento:

• Validar e persistir recibos.
• Restaurar compras em troca de aparelho ou reinstalação.
• Controlar entitlement local e remoto.
• Tratar reembolso, cancelamento e compra pendente.
• Ter alguma forma de auditoria operacional.
• Criar testes para caminhos felizes e negativos.
• Repetir boa parte do trabalho se o app chegar ao iOS.

Em um app pequeno, esse trabalho compete com produto, aquisição, ASO, analytics, anúncios e suporte. Economizar 1% de receita futura pode não compensar atrasar o aprendizado real do mercado.

O que RevenueCat não substitui

RevenueCat reduz trabalho operacional, mas não remove o Google Play do caminho crítico.

Ainda é preciso:

• Criar os produtos no Play Console.
• Configurar preços, regiões e tipo correto de produto.
• Cadastrar os produtos e packages no RevenueCat.
• Configurar Google Cloud para a integração do Play Developer API.
• Conectar uma service account do Google Play com permissões suficientes.
• Proteger a chave JSON da service account fora do repositório.
• Validar uma compra real de teste no Play Console.

Um detalhe que apareceu na prática: preços aparecendo na loja do app não significam que a credencial do RevenueCat está validada. A evidência melhor é a validação de credenciais no RevenueCat e um pedido de teste Processado no Play Console.

Essa é uma distinção importante. RevenueCat não cria automaticamente a ponte de confiança com o Google Play. Você ainda precisa criar ou escolher um projeto Google Cloud, ativar a Google Play Android Developer API, habilitar Pub/Sub se for usar Google developer notifications, criar a service account, subir a chave no RevenueCat e conceder permissões no Play Console. Se esse caminho ficar incompleto, a compra pode abrir no aparelho e ainda assim falhar na validação do recibo.

A decisão para um app indie

Para um app indie ou um MVP comercial, RevenueCat costuma ser uma troca razoável: pagar pouco ou nada no começo para reduzir risco operacional.

No caso do Daily Sudoku, a decisão foi manter RevenueCat enquanto o app valida receita. Google Play Billing continua sendo o processador da compra no Android, mas RevenueCat fica responsável pela camada de produto: quem comprou, o que está ativo, como restaurar e como observar problemas.

Isso não precisa ser uma decisão permanente. Se a receita de compras chegar a algo como US$ 10k-20k/mês, vale reabrir a conta:

• Quanto RevenueCat custa por mês?
• Quanto tempo a integração direta exigiria?
• O app já precisa de iOS ou assinaturas?
• Existe equipe para manter edge cases de pagamento?
• Dá para negociar condições melhores?

A decisão é menos sobre tamanho de SDK e mais sobre operação

Para um app pequeno, a comparação raramente é só “qual SDK é menor?” Google Play Billing dá controle direto e menos peças externas, mas também deixa mais trabalho operacional dentro do app e do backend. RevenueCat adiciona outro fornecedor, mas centraliza estado do cliente, restore, mapeamento de produtos, webhooks e ferramentas de suporte.

A pergunta certa não é se o wrapper é elegante. A pergunta é quem vai responder suporte quando uma compra existe no Play Console, mas o app não desbloqueia o recurso. Se essa pessoa também é desenvolvedor, designer, suporte e release manager, observabilidade pesa mais que pureza teórica.

Uma integração direta com Billing ainda pode ser a escolha certa quando o catálogo é mínimo e o app tolera um ciclo de suporte mais lento. RevenueCat fica mais atraente quando você precisa inspecionar perfis de cliente, suportar múltiplas lojas, lidar com recibos estranhos ou adicionar assinaturas depois.

O que validar antes de escolher

Antes de decidir, teste os caminhos chatos:

• produto indisponível porque a conta tester está errada;
• compra cancelada no meio;
• compra concluída, mas entrega da entitlement falha;
• restore em instalação limpa;
• visibilidade de dados sandbox no dashboard;
• identidade do cliente depois de reinstalar ou migrar o app.

Esses caminhos mostram o custo real de manutenção. Uma integração de compra que funciona só no caminho feliz não está pronta; é uma demo.

Um padrão conservador para apps indie

Nosso viés para apps indie é comprar clareza operacional quando o custo é razoável. Se compras são importantes para receita e o time é pequeno, dashboard e histórico do cliente não são luxo. Eles fazem parte do sistema de suporte.

Isso não significa que todo app precisa de RevenueCat. Significa que todo app precisa de um lugar claro para responder: o que a loja disse, o que o SDK recebeu, qual cliente identificamos e qual estado local desbloqueamos? Escolha a stack que deixa essas respostas mais baratas.

O formato do catálogo muda a resposta

Uma compra vitalícia, um pacote de créditos consumíveis e uma assinatura não são o mesmo problema operacional. Uma entitlement vitalícia precisa principalmente de restore confiável. Consumíveis precisam de rastreio de entrega e idempotência. Assinaturas precisam lidar com renovação, cancelamento, período de graça e estado da conta.

Esse formato de catálogo deve influenciar a escolha de ferramenta. Quanto mais o app depende de estado contínuo do cliente, mais valioso fica um backend dedicado de compras. Quanto mais simples o catálogo, mais fácil justificar ficar perto do Google Play Billing.

Por isso times também não deveriam desenhar monetização só pela UI. O modelo de compra precisa ser avaliado pelos caminhos de suporte e recuperação, não apenas pelo texto do botão na loja.

A melhor escolha é a que torna compras com falha explicáveis. Se uma ferramenta reduz o tempo entre uma mensagem de suporte e uma resposta confiante, essa economia entra na decisão, mesmo que não apareça na tabela de comparação de SDKs.

Conclusão

A pergunta “RevenueCat reduz minha margem?” tem resposta simples: sim, depois do limite gratuito.

Mas a pergunta melhor é: “essa redução de margem compra tempo, segurança e foco suficientes?”.

Para um app em validação, normalmente compra. Para um app já em escala, a decisão merece nova análise.