A maioria das listas de "melhores ferramentas de reembolso" é escrita por pessoas que nunca implementaram uma na prática. Aqui está a versão que eu gostaria de ter encontrado, baseada no que cada plataforma realmente envia ao Google e no que ela discretamente deixa passar.
Um contexto rápido, porque isso confunde muita gente. Um evento de reembolso de assinatura do Google Play e um chargeback seguem dois conjuntos de regras diferentes, e a maioria das plataformas trata bem um deles e apenas parcialmente o outro. Você só pode contestar o chargeback. Tudo o mais, você só pode detectar.
Se preferir pular a comparação, Defesa contra chargeback no Google Play é a página do nosso próprio produto e a versão resumida deste post.
Principais Conclusões
O Google só permite contestar chargebacks, pela Review Refund API, em cerca de 24 horas. Todas as plataformas aqui mencionadas trabalham dentro dessa limitação.
O Google aceita três preferências: APPROVE, DECLINE, NEUTRAL. Não há reembolsos parciais pela API, em nenhuma plataforma.
O verdadeiro diferencial são as evidências. Algumas ferramentas enviam dados de uso. Outras enviam apenas uma preferência e um único booleano.
O Google nunca informa o resultado. As plataformas fazem consultas periódicas para descobri-lo, então os relatórios de taxa de sucesso sempre chegam com atraso.
A detecção é a maior lacuna. Reembolsos sem revogação de acesso, reembolsos parciais e compras não confirmadas permanecem invisíveis para a maioria das stacks.
O Que Realmente Comparar
Quatro coisas. Todo o resto é ruído de página de preços.
Ela envia evidências de consumo, ou apenas uma preferência? Esse é o ponto central da Review Refund API. O Google pediu o estado de entrega e o consumo do item para poder argumentar seu caso com o banco. Uma ferramenta que só envia APPROVE ou DECLINE está usando talvez um terço do canal.
Ela precisa de um SDK? Se sim, você está acoplando a defesa contra reembolsos à sua infraestrutura de assinaturas. Uma decisão real, e nem sempre ruim.
O que ela detecta? Contestar é metade da gestão de reembolsos do Google Play. Saber que um reembolso aconteceu, e revogar o acesso, é a outra metade.
Ela cobre a Apple também? A maioria das equipes opera nas duas lojas. Ter dois fornecedores para uma única tarefa é como as coisas acabam sendo negligenciadas.
RevenueCat Refund Control
A opção mais forte se suas assinaturas já passam pelo RevenueCat, o que acontece com muitos apps.
O Refund Control usa políticas em nível de projeto, avaliadas de cima para baixo. A primeira política correspondente prevalece. Você escolhe entre Prefer full refund, Prefer no refund, Send consumption data only ou Do not respond. Ele chama o endpoint orders.reviewrefund do Google para você.
Aqui está a parte que vale a pena ler duas vezes. Segundo a própria documentação do RevenueCat, o corpo que eles enviam ao Google contém três campos: pendingRefundToken, sampleContentProvided definido como true, e o seu refundPreference. Eles afirmam claramente que ainda não enviam porcentagens de consumo nem eventos de uso. Ou seja, você tem o canal de preferência, não o canal de evidências.
Eles também são honestos sobre os limites de detecção. Um reembolso emitido no Play Console sem marcar a caixa de revogação não será detectado. Reembolsos parciais não são capturados, e reembolsos de compras não confirmadas também não são identificados. Qualquer reembolso concedido pelo Google, em vez de por você, pode levar até 24 horas para aparecer.
Onde o RevenueCat realmente se destaca é em algo que nenhum outro aqui faz: você mesmo pode emitir um reembolso de assinatura do Google Play, pelo dashboard ou por um endpoint REST, e ele revoga o acesso na mesma chamada. Se o suporte lida diretamente com reembolsos, isso importa.
Adapty Refund Saver
O Refund Saver agora cobre o Google Play, não só a Apple, e vem ativado por padrão se você já o usava no iOS.
Ele realmente envia evidências de uso nas revisões de chargeback, o que o coloca na frente do RevenueCat naquilo que de fato influencia o resultado. O suporte ao Google Play chegou depois que a mudança de 3 de agosto tornou os chargebacks caros.
Dois limites honestos, ambos vindos da própria documentação da Adapty. O Google aceita apenas decline, approve ou no preference, então a opção Grant prorated do lado da Apple não tem equivalente no Google, e a Adapty envia No preference nesse caso. E como o Google não notifica ninguém quando uma revisão é resolvida, a Adapty consulta periodicamente o status do pedido até que ele se resolva. Os resultados do Play aparecem mais tarde do que os da Apple.
A verdadeira barreira de entrada é o SDK. O Refund Saver é um recurso da plataforma, não um produto independente. Se você não usa a Adapty para assinaturas, vai precisar trocar de plataforma para ter acesso a ele. Para algumas equipes, essa troca vale a pena. Para a maioria, não.
Refund Sensor
Somos nós, então leve isso em conta na sua avaliação.
Sem SDK. Faça login com o Google, conceda duas permissões do Play Console (visualizar dados financeiros, gerenciar pedidos e assinaturas) e ele provisiona o tópico Pub/Sub e a assinatura push no seu próprio projeto do Google Cloud. Nada para colar no Play Console, nenhuma nova versão do app.
Ele envia uma recomendação de decline com evidências de entrega e engajamento pelo orders.reviewrefund dentro das 24 horas, e, separadamente, rastreia os reembolsos que você não pode contestar, que é a parte sobre a qual a maioria das equipes não tem nenhuma visibilidade. As duas lojas ficam em um único dashboard.
Lacunas honestas: é mais novo que o RevenueCat ou a Adapty, e não há paywalls, testes A/B ou analytics de assinatura, porque esse não é o produto. Precisa de infraestrutura de assinaturas? Você vai querer também um dos outros.
RefundHalt
Vale a pena conhecer se você quer regras caso a caso em vez de uma preferência genérica. Sem SDK, nas duas lojas, e ele extrai evidências de uso de um endpoint no seu servidor, então as evidências são suas, e não inferidas.
Uma ressalva. Algumas das comparações publicadas por eles são anteriores ao suporte do Refund Saver ao Google Play, então verifique a documentação atual, e não as páginas de comparação.
Construindo Você Mesmo
Razoável, e mais barato do que parece se você já tem um backend em operação.
Você precisa ativar o RTDN em Monetize, depois em Monetization setup. Um tópico Pub/Sub. Um consumidor que decodifica o campo data em base64 e trata cada um dos cinco possíveis objetos de notificação. No pendingRefundReviewNotification, você armazena o pendingRefundToken e corre contra um prazo de 24 horas. Depois, uma chamada ao orders.reviewrefund.
A parte que não cabe em um fim de semana: ter dados reais de consumo para uma assinatura comprada há sete semanas, mais idempotência, porque o Google faz novas tentativas, mais uma verificação noturna de Voided Purchases para capturar o que as notificações deixaram passar. Voided Purchases API versus notificações de desenvolvedor em tempo real explica qual feed faz o quê.
Essa também é a resposta honesta para como os desenvolvedores automatizam reembolsos do Google Play quando não querem depender de um fornecedor. É um consumidor de webhook, um timer e um problema de dados.
Então, Qual Escolher
Já usa o RevenueCat e precisa principalmente de detecção mais uma preferência? Refund Control. Ative hoje mesmo.
Já usa a Adapty e quer que as evidências sejam enviadas sem trabalho extra? Refund Saver. Provavelmente já está ativado.
Não usa nenhum dos dois e não quer trocar de plataforma para defender reembolsos? Refund Sensor ou RefundHalt.
Suas disputas tendem para fraude e você quer lógica caso a caso? RefundHalt, ou construa você mesmo.
Nenhum dos dois, e os reembolsos são triviais? Não faça nada por enquanto, mas configure o RTDN de qualquer forma. É gratuito, e você vai querer o histórico quando o volume aparecer.
A Parte Que Toda Página de Plataforma Ignora
Como automatizar reembolsos de assinaturas do Google Play é a primeira pergunta errada para a maioria dos apps. Os reembolsos do Google Play para desenvolvedores se dividem entre o que você pode influenciar e aquilo a que só pode reagir, e a segunda lista é maior.
Você pode contestar uma revisão de chargeback. É isso. Reembolsos feitos pelo suporte, reembolsos de 48 horas do Play e conversões de teste não confirmadas são todos decididos sem você. A única automação disponível nesses casos é detectá-los rapidamente e revogar o acesso.
O que significa que a automação de reembolsos do Google Play é, na verdade, dois produtos vestindo o mesmo casaco: um mecanismo de resposta para chargebacks e um mecanismo de detecção para tudo o mais. A maioria dos fornecedores é forte em apenas um deles. Verifique qual deles você está comprando. O próprio anúncio do Google sobre proteção contra reembolsos e custo de chargebacks vale a leitura antes de escolher, porque explica por que o lado da resposta passou a importar tanto.
Fontes
Perguntas frequentes
Apenas o subconjunto de chargebacks. O Google abre uma revisão quando um cliente contesta com o banco, e você tem cerca de 24 horas para responder pela Review Refund API. Todos os outros tipos de reembolso são decididos sem você, e só podem ser detectados.
Depende do que você já usa. RevenueCat se suas assinaturas já estão lá. Adapty se você usa o SDK deles e quer enviar evidências de uso automaticamente. Refund Sensor ou RefundHalt se você quer defesa contra reembolsos sem trocar de plataforma.
Não. O Google aceita APPROVE, DECLINE ou NEUTRAL pela API. Reembolsos proporcionais existem no lado da Apple, mas não têm equivalente no Google, então as plataformas que oferecem essa opção enviam No preference no Play.
Ou você constrói isso você mesmo com base no RTDN e no orders.reviewrefund, ou usa um serviço que se conecta por meio de permissões do Play Console e um projeto do Google Cloud. Nos dois casos, você evita alterar o binário do app.
Lentamente. O Google não notifica ninguém quando uma revisão é resolvida, então as plataformas consultam o status do pedido periodicamente. Espere que os dados de resultado demorem a chegar, e avalie uma ferramenta pelo fato de ela ter enviado a resposta dentro do prazo, não pela taxa de sucesso no mesmo dia.
Desde 3 de agosto de 2026, um chargeback perdido custa o preço da compra menos a taxa de serviço do Google, mais uma taxa bancária. Em um produto barato, só essa taxa pode superar o valor da venda. Faça as contas com os valores dos seus próprios pedidos antes de decidir.
