O primeiro chargeback que perdi caiu às 23h40 de um sábado. Só sei disso porque fui cavar os logs do Pub/Sub na segunda-feira e encontrei a notificação parada em um tópico que ninguém estava consumindo.
Isso foi antes de 3 de agosto de 2026. Naquela época, perder um chargeback custava apenas a venda e pouco mais.
Agora o Google Play transfere os custos de chargeback para os desenvolvedores em pedidos feitos após essa data. Você absorve o valor do pedido menos a taxa de serviço deles, mais uma taxa da bandeira do cartão de $15 a $25 por caso. Em troca, eles também deram algo: a API Review Refund e cerca de 24 horas para enviar evidências.
Então a questão não é se você trata chargebacks. É o que os trata à meia-noite. A configuração está em Google Play chargeback defense. Esta é a versão longa: quatro opções, duas das quais eu desaconselharia para a maioria das equipes.
Principais conclusões
O tratamento de chargebacks do Google Play tem um único ponto de entrada: a API ReviewRefund, dentro de 24 horas após uma Pending Refund Review Notification.
O Google registra sua primeira chamada e ignora as demais, mesmo retornando OK. Uma única chance, sem correções.
Somente chargebacks são contestáveis. Reembolsos de suporte, reembolsos do Play em 48 horas e testes gratuitos não confirmados são decididos sem você.
Quatro alternativas reais: construir você mesmo, usar sua plataforma de assinaturas, comprar um software ou absorver a perda.
A conta mudou em 3 de agosto de 2026. Perca uma janela em um plano anual de $99 e isso custa o pedido mais uma taxa de bandeira.
Como é o tratamento manual na prática
Para ser justo, "manual" abrange um espectro. De um lado, é uma caixa de entrada compartilhada e alguém verificando o Play Console quando se lembra. Do outro, é uma escala de turnos, um canal no Slack, uma planilha de pedidos contestados.
Essa segunda versão é melhor. Ainda assim falha, por motivos que não têm nada a ver com esforço.
Primeiro, você não vê o relógio correndo. As 24 horas começam quando uma PendingRefundReviewNotification chega ao seu tópico do Pub/Sub. Nunca ativou as notificações de desenvolvedor em tempo real? Nada avisa que há uma revisão aberta, e o Play Console não vai sinalizar isso.
Segundo, e isso surpreende as pessoas: o Google registra sua primeira chamada ReviewRefund e ignora todas as seguintes, continuando a retornar OK. Parece que funcionou. Alguém digitando uma resposta em um script às 9h, com dados coletados manualmente, é assim que você acaba com um campo errado sem possibilidade de desfazer.
Se esforçar mais não resolve nenhum dos dois problemas.
O processo de chargeback do Google Play
Vale a pena detalhar, porque a janela é menor do que as pessoas imaginam.
O cliente contesta a cobrança com o banco dele. Não com você, não com o Google.
O Google marca o pedido para revisão e envia uma PendingRefundReviewNotification via RTDN, trazendo um pendingRefundToken, o orderId, um refundReason igual a 7 (que é CHARGEBACK) e o seu obfuscatedAccountId, caso você tenha definido um na compra.
Você tem cerca de 24 horas para chamar ReviewRefund com uma preferência e as evidências que conseguir reunir.
O Google usa isso para argumentar o caso com o banco.
Se perder, e em pedidos feitos após 3 de agosto de 2026, o custo é seu.
Uma assimetria que vale a pena considerar. A Apple pergunta sobre reembolsos comuns por meio do CONSUMPTION_REQUEST. O Google Play só abre revisões para chargebacks. Tudo o mais é resolvido sem você, e você fica sabendo por meio de uma compra anulada. Mecânica completa: Google Play chargebacks explicados.
Opção 1: construir o manipulador você mesmo
Um tópico Pub/Sub. RTDN ativado em Monetize, depois em Monetization setup. Um endpoint push que verifica a mensagem antes de confiar nela. Depois, decodificar o campo data em base64, ramificar de acordo com qual dos cinco objetos de notificação apareceu, associar o pedido a um usuário, reunir evidências e chamar ReviewRefund com um token OAuth com escopo definido.
Construir isso não é a parte cara. Duas semanas, se você já tem experiência com a parte técnica de webhooks.
O segundo ano é a parte cara. O Google muda um campo. Um refresh token OAuth expira silenciosamente num domingo. Seu manipulador morre na mesma noite em que chega uma contestação de $200, e por algum motivo é sempre assim que acontece. Você vai querer observabilidade, tratamento de replay e testes para formatos de notificação que você ainda não viu.
Se você mantém um backend e os reembolsos representam uma linha real de receita, construa. Eu prefiro que você faça isso. Se você é uma pessoa só lançando produto, é um mau uso do seu mês.
Opção 2: use a plataforma de assinaturas que você já paga
Verifique isso antes de escrever qualquer código. A RevenueCat adicionou a Review Refund API do Google dentro do Refund Control, e a Adapty tem o Refund Saver do lado da Apple.
O apelo: seus recibos, entitlements e mapeamento de clientes já estão lá, então as evidências estão mais à mão e a correspondência de contas já está resolvida.
O limite: a resposta a reembolsos é um recurso para eles, não o produto principal. Espere uma preferência e algumas flags, não 1.000 eventos de uso com endereços IP. Para muitos apps, isso é suficiente. Para disputas carregadas de fraude, não é.
Opção 3: software dedicado para gestão de chargebacks do Google Play
Essa categoria praticamente não existia antes de 3 de agosto, o que mostra como o incentivo é recente.
O formato é consistente. O serviço se inscreve na sua RTDN, envia uma recomendação de recusa com evidências de entrega e engajamento dentro da janela, e acompanha o resultado de cada caso.
Refund Sensor faz isso para o Google Play e a App Store a partir de uma única conta. Faça login com o Google, conceda duas permissões do Play Console (visualizar dados financeiros, gerenciar pedidos e assinaturas) e ele mesmo provisiona o tópico Pub/Sub. Sem SDK, sem mudanças de código, nada para reenviar.
A troca: mais um fornecedor, mais uma linha mensal. O que você ganha em troca é não precisar ser a pessoa que tem que estar acordada.
Opção 4: absorver o prejuízo
É legítimo para alguns apps, e não vou fingir o contrário. Venda um item consumível de $1.99, tenha quatro chargebacks por ano, e duas semanas de engenharia nunca se pagam.
Mas faça as contas primeiro. Um chargeback perdido em um plano anual de $99 custa o valor do pedido menos a taxa de serviço do Google, mais uma taxa de bandeira de $15 a $25. Dois desses em um trimestre mudam a resposta.
Como automatizar o tratamento de chargebacks do Google Play
Se você optou pela opção um, aqui está a ordem de construção. A sequência importa mais do que as pessoas imaginam.
Ative o RTDN no Play Console, crie o tópico Pub/Sub. Clique em Send Test Message antes de confiar no canal.
Decodifique o campo data e ramifique de acordo com qual objeto de notificação chegou. Apenas um vem por mensagem. Na pendingRefundReviewNotification, armazene o pendingRefundToken e inicie um temporizador. Não um e-mail. Um temporizador.
Associe o orderId a um usuário. obfuscatedAccountId é o caminho mais rápido, o que já é motivo suficiente para começar a defini-lo na compra.
Reúna evidências: sampleContentProvided, consumptionPercentageMilliunits (45200 significa 45.2 por cento), e até 1.000 consumptionUsageEvents com timestamps e endereços IP.
Chame orders.reviewrefund uma vez, com um refundPreference de APPROVE, DECLINE ou NEUTRAL. Registre a chamada, o payload, a resposta.
Separadamente, trate a voidedPurchaseNotification para remoção de acesso, e execute a Voided Purchases API todas as noites para reconciliar. Ela tem um limite de 6.000 chamadas por dia.
Essa última etapa é a que todo mundo pula. Eu pulei por meses. Notificações se perdem durante interrupções, e a pull API é como você descobre o que chegou enquanto estava fora do ar. Voided Purchases API versus notificações de desenvolvedor em tempo real explica o que cada fluxo faz.
Prevenção de chargebacks do Google Play
Mais barato do que qualquer uma das opções anteriores, e funciona em disputas que você nunca vê chegar.
Um cliente que chega ao seu suporte não chega ao banco dele. Um caminho de contato visível dentro do app, mais uma resposta em até um dia, elimina uma parcela surpreendente das disputas antes que elas comecem.
Depois, deixe a renovação óbvia: preço, período e data de renovação na mesma tela do botão de compra. Surpresa gera mais disputas do que qualquer outra coisa que já vi.
Mais dois pontos que não recebem atenção suficiente. Observe as compras não confirmadas, porque testes gratuitos que convertem sem serem notados se transformam em chargebacks um mês depois. E use o voidedReason como sinal de fraude. Ele traz nove valores, incluindo fraud, friendly_fraud e chargeback, e essas contas se repetem. Marque-as antes de oferecer outro teste gratuito.
Mantenha sua taxa abaixo do limite do Google. Problemas persistentes afetam a reputação da conta, o que é pior do que qualquer reembolso isolado.
Fontes
Perguntas frequentes
Um reembolso passa pelo Google, decidido pelo Google ou por você no Play Console. Um chargeback é o cliente indo até o banco dele, o que coloca o caso sob as regras da bandeira do cartão. Somente o chargeback abre uma revisão que você pode responder, e somente o custo dele é repassado a você.
Cerca de 24 horas a partir da PendingRefundReviewNotification. O relógio começa a contar na entrega da notificação, não quando você percebe.
O Google argumenta o chargeback sem suas evidências, que é a posição mais frágil possível. Em pedidos feitos após 3 de agosto de 2026, uma perda custa o valor do pedido menos a taxa de serviço, mais uma taxa de bandeira.
Não. O Google registra sua primeira chamada ReviewRefund e ignora as demais, mesmo continuando a retornar OK. Teste contra uma compra de teste antes que isso se aproxime da produção.
Qualquer um que envie a resposta sem que você precise estar acordado. Se você mantém um backend, construir é um projeto razoável. Se não, um software de gestão de reembolsos do Google Play que se conecta por meio das permissões do Play Console é melhor do que escrever um consumidor de Pub/Sub para um caso extremo isolado.
Não. Você está fazendo uma recomendação por meio da própria Play Developer API do Google, apoiada em evidências de entrega e consumo. Esse é o canal que o Google construiu exatamente para isso.
