Como validar uma compra de teste Google Play com RevenueCat

Validar uma compra no app não é a mesma coisa que apertar o botão e ver créditos aparecerem.

Em Android, o caminho passa por três sistemas diferentes:

• Google Play processa a compra.
• RevenueCat valida o recibo e atualiza o estado comercial.
• Sentry mostra se o fluxo gerou erro real no app.

Se você olhar só um deles, pode fechar o teste com um ponto cego.

1. Primeiro prove que o produto carrega

O primeiro sinal é a loja dentro do app mostrar o produto com preço localizado.

Isso prova que:

• O app está falando com o billing client.
• O produto existe para aquela conta/faixa.
• A oferta está disponível para o país do testador.

Mas isso ainda não prova credencial do RevenueCat. Preço visível deve vir do provider de compras, não de copy hardcoded no app. Ainda assim, não significa que o recibo será validado depois do checkout.

2. Faça a compra com cartão de teste

No checkout, confirme que a folha é do Google Play e que o método é de teste.

O objetivo do teste não é receita. É atravessar o mesmo caminho operacional de uma compra real sem cobrar o cartão do testador.

Depois da confirmação, o app deve aplicar o benefício apenas se a compra foi concluída. Para consumíveis, como pacotes de créditos, esse ponto é especialmente importante: compra cancelada, indisponível ou com erro não deve conceder recompensa.

3. Não pule Google Cloud

O erro de credenciais costuma nascer antes da compra: a service account ainda não tem o caminho completo entre Google Cloud, Play Console e RevenueCat.

O mínimo seguro é:

• Ter um projeto Google Cloud dedicado ou claramente identificado para billing do app.
• Ativar a Google Play Android Developer API, usada para validar e consumir compras.
• Ativar Cloud Pub/Sub se você vai usar Google developer notifications.
• Criar uma service account para o RevenueCat.
• Gerar a chave JSON e fazer upload apenas no RevenueCat.
• Conceder permissões suficientes para essa service account no Play Console.

A parte delicada é a chave. Ela não deve ir para Git, blog, ticket ou print compartilhado. Documentação pública recebe o processo e os sintomas. O segredo fica no Google Cloud e no RevenueCat.

4. Confira o pedido no Play Console

O lugar mais direto para confirmar a venda de teste é:

Play Console > Gerenciamento de pedidos

Procure o pedido mais recente do app e confira:

• Data e hora compatíveis com o teste.
• Produto correto.
• Tipo Produto único, quando for compra avulsa.
• Status Processado.
• Total com o preço esperado.

Em compra de teste, Receita estimada pode aparecer como 0,00. Isso não invalida o teste. O ponto importante é o pedido estar processado e associado ao produto certo.

5. Valide as credenciais no RevenueCat

Depois de conectar a service account do Google Play ao RevenueCat, use a validação da própria tela do app Android no RevenueCat.

Os checks importantes são:

subscriptions_api_permissions: SUCCESS
inapp_products_permissions: SUCCESS
monetization_api_permissions: SUCCESS

Mesmo que o app não use assinaturas, o check de subscriptions pode aparecer porque o RevenueCat valida permissões amplas da integração Play Developer API. Se ele falhar, revise as permissões da service account no Play Console e espere a propagação do Google.

Foi esse tipo de falha que apareceu no teste: o produto existia e o checkout abria, mas o RevenueCat ainda não tinha permissão suficiente para completar a validação da compra.

6. Encontre a compra sandbox no RevenueCat

Compras de teste podem existir no RevenueCat e ainda assim parecerem ausentes se você olhar só listas agregadas.

O caminho mais confiável é capturar o App User ID que o SDK usou. Em um app instrumentado, procure nos logs algo como:

[store/revenuecat] purchase completed ... "appUserId":"$RCAnonymousID:..."

Depois, abra o perfil desse customer no RevenueCat e ative Show sandbox data.

Para consumíveis, não espere entitlement ativo. Um pacote de créditos pode aparecer como:

• Histórico: Made a purchase of Small credits pack.
• Produto solto: Unattached products.
• Contador: Purchased 2x.

Esse detalhe evita falso diagnóstico. A compra não está necessariamente ausente; ela pode estar escondida na visão sem dados sandbox ou fora do resumo agregado.

7. Teste reembolso com remoção de titularidade

Reembolso de compra não consumível tem uma pegadinha: devolver o dinheiro não é sempre a mesma coisa que remover o acesso. No Play Console, a tela de reembolso pode avisar que o cliente será reembolsado, mas continuará com o produto ou assinatura. Para testar revogação de um item como noads.lifetime, marque também Remover titularidade.

Depois disso, valide em três lugares:

• Play Console: o pedido precisa aparecer como reembolsado/cancelado.
• RevenueCat: o customer correto não deve mais listar o entitlement ativo.
• App: o benefício precisa sumir depois de uma atualização de customer.

Esse último ponto costuma enganar. Um aparelho que tocou em Restaurar compras pode atualizar imediatamente, enquanto outro aparelho aberto há horas ainda usa o customer cacheado localmente. O app não deve depender só do botão manual. Uma rotina leve de getCustomerInfo() no boot e quando o app volta para foreground reduz esse atraso e deixa reembolsos com remoção de titularidade aparecerem sem pedir que o usuário descubra um botão de suporte.

8. Use o Sentry como confirmação negativa

Depois de uma compra bem-sucedida, confira se o Sentry não recebeu um novo erro de compra.

Esse é um caso em que ausência de evento importa. Se a compra anterior gerava algo como [shop] purchase failed, o teste novo precisa passar sem criar uma regressão parecida.

O cuidado é não confundir issue antiga com teste atual. Olhe o horário do evento e compare com o horário da compra processada no Play Console.

9. Não encerre pelo dashboard errado

Dashboards agregados podem atrasar ou filtrar compras de teste. Se o overview do RevenueCat ainda não mostrar a transação, isso não é automaticamente falha.

Ordem de confiança para o smoke:

1. Pedido processado no Play Console.
2. Credenciais válidas no RevenueCat.
3. Customer profile do RevenueCat mostra a compra com Show sandbox data.
4. App concedeu o benefício correto.
5. Sentry não recebeu erro novo.
6. Dashboard agregado atualiza depois.

Checklist final

Antes de dizer que a compra de teste está validada:

• O app foi instalado pela Play Store.
• O produto apareceu com preço localizado.
• O preço mostrado veio do provider de compras e bateu com o checkout do Google Play.
• O checkout usou cartão de teste.
• Google Cloud tem Android Developer API e Pub/Sub quando usados pela integração.
• A service account foi criada, vinculada ao Play Console e enviada ao RevenueCat.
• O pedido apareceu no Play Console como Processado.
• O produto do pedido bate com o SKU esperado.
• RevenueCat mostrou credenciais válidas.
• O App User ID usado pelo SDK foi conferido nos logs.
• O customer profile do RevenueCat foi aberto com Show sandbox data.
• O app concedeu o benefício somente após compra concluída.
• Reembolso de não consumível foi testado com Remover titularidade, não apenas devolução de dinheiro.
• O app atualiza o customer no boot, no foreground ou em uma ação manual clara como Restaurar compras.
• Sentry não recebeu erro novo no horário do teste.

Esse checklist não substitui testes de restore, reembolso, cancelamento e indisponibilidade. Ele só fecha a pergunta mais básica: “uma compra feliz, vinda da Play Store, passa de ponta a ponta?”.

Não confie em um dashboard sozinho

Compras sandbox são ruidosas o bastante para que um dashboard raramente conte a história inteira. Play Console pode mostrar um pedido, RevenueCat pode mostrar um cliente, o SDK pode logar um app user ID e, ainda assim, o app pode falhar ao desbloquear localmente. A validação precisa conectar esses sinais.

Uma boa nota de compra deve responder quatro perguntas:

• A Google Play criou um pedido para o produto esperado?
• O RevenueCat recebeu ou atualizou a transação?
• Qual app user ID o SDK usou no aparelho?
• Que estado local de desbloqueio ou entitlement o app aplicou depois da compra?

Se alguma resposta está ausente, o teste está incompleto. Ele ainda pode ser útil, mas não deveria ser chamado de validado.

Armadilhas comuns do sandbox

A armadilha mais comum é testar com a conta Play errada. O app pode estar instalado, o produto pode parecer configurado e o billing ainda pode retornar indisponível porque a conta ativa da loja não é a tester convidada.

Outra armadilha é ler listas agregadas de clientes sem habilitar dados sandbox ou inspecionar o perfil exato. Consumíveis também podem aparecer diferente de entitlements, especialmente quando são entregues como produtos de uso único. Por isso a validação deve incluir pedido, perfil no RevenueCat, identidade do SDK e estado no app.

Trate caminhos negativos como primeira classe

Um fluxo de compra só é robusto quando estados de cancelamento, indisponibilidade, falha e erro de entrega são visíveis. O app não deve conceder benefício em finally, não deve tratar exceção do provider como sucesso e não deve esconder falha de entrega atrás de um toast genérico.

Para apps indie, isso é menos sobre arquitetura corporativa e mais sobre suporte. Quando um tester diz “comprei e nada aconteceu”, o time precisa de uma trilha que explique se a falha veio da loja, do provider, da identidade do SDK ou da entrega local.

Conclusão

Uma compra sandbox só está validada quando pedido da loja, cliente no RevenueCat, identidade do SDK e estado de entrega no app contam a mesma história. Menos que isso ainda pode ser pista útil, mas não deveria fechar o checklist.