A maioria dos guias sobre como lidar com solicitações de reembolso começa na notificação. A Apple te avisa, o Google te avisa, aqui está o que enviar de volta. Justo, mas quando o aviso chega, o trabalho útil já foi feito ou já foi perdido, porque o que você pode dizer sobre uma compra depende do que você registrou quando ela aconteceu.
Por isso, este post começa mais cedo, no checkout. Quais dados de compra importam quando uma solicitação de reembolso chega, onde guardá-los e como eles se transformam em uma resposta que a loja de fato vai considerar. Se você nunca anexou um identificador a uma compra, leia primeiro nosso post sobre appAccountToken e defesa de reembolso, porque tudo abaixo pressupõe que você consegue conectar um ID de transação a uma pessoa.
Principais conclusões
Tanto a Apple quanto o Google decidem os reembolsos por conta própria, e ambos agora pedem seus dados de compra primeiro. A Apple dá 12 horas, o Google 24.
As lojas querem fatos gerais, não logs. Se foi entregue, quanto foi usado, se o cliente recebeu uma amostra e qual é a sua preferência.
Você precisa armazenar quatro coisas por compra: quem, quando foi entregue, quando foi usado e se você já reembolsou essa conta antes.
A Apple diz que a maioria das solicitações de reembolso chega em até 30 dias da compra. Mantenha os dados pelo menos por esse período, na prática 90 dias.
Apps que começam a responder veem a taxa de reembolso cair cerca de um terço, mas só se houver algo registrado para dizer.
O que as lojas realmente pedem de você
O pedido da Apple é pequeno. Quando um cliente solicita reembolso de uma compra no app, você recebe um CONSUMPTION_REQUEST e responde pelo endpoint Send Consumption Information com cinco campos. Se o cliente consentiu que você compartilhasse dados, se a compra foi entregue, qual porcentagem foi consumida (em milliunits, então 100,000 representa o total), se ele teve uma amostra gratuita ou teste antes, e sua preferência de reembolso. A Apple costumava pedir uma dezena de campos e eliminou a maioria deles, o que eu interpreto como a Apple decidindo que já conhece o histórico do cliente melhor do que você.
A versão do Google é para chargebacks, e é um pouco mais detalhada. Uma notificação de revisão de reembolso pendente chega pelo Real-time Developer Notifications com um token. Você envia um post para orders.reviewrefund com esse token, a mesma flag de conteúdo de amostra, uma preferência DECLINE, APPROVE ou NEUTRAL, uma porcentagem de consumo opcional e até 1,000 eventos de uso com timestamps. Isso importa mais agora que o Google cobra dos desenvolvedores por chargebacks em pedidos feitos após 3 de agosto de 2026.
Nenhuma das duas lojas quer sua exportação de analytics. Elas querem entrega, consumo, amostragem e preferência, e tudo o mais que você armazena existe para preencher isso de forma verdadeira e rápida.
Histórico de compras para reembolsos: o que manter e por quanto tempo
O mínimo:
Um identificador no checkout. appAccountToken na Apple, obfuscatedAccountId no Google. Sem ele, uma solicitação de reembolso menciona uma transação e você não tem ideia de quem é. Os engenheiros da Apple também recomendam manter pelo menos um originalTransactionId por usuário, porque, com qualquer um deles, você pode chamar Get Transaction History e obter todo o histórico de compras daquele cliente no seu app, esteja ele instalado ou não.
Um registro de entrega. Quando você concedeu as moedas ou desbloqueou o nível, com um timestamp e um resultado. Se a entrega falhou, diga isso. É o único caso em que você deveria querer que o reembolso fosse concedido, e afirmar o contrário queima uma credibilidade que você vai precisar depois.
Eventos de consumo. Não cada toque, só os que significam que a compra foi usada: moedas gastas, capítulo aberto, exportação executada. O Google aceita até mil deles. A Apple só quer uma porcentagem, mas você não pode calcular uma que nunca registrou.
Uma flag de amostra por produto. Esse cliente teve um teste, uma pré-visualização, um nível gratuito? Um sim ou não em ambas as lojas, e as pessoas esquecem isso constantemente.
Reembolsos anteriores na conta. A Apple avalia o histórico de reembolsos por conta própria de qualquer forma, mas você vai querer isso para suas próprias regras.
Sobre retenção, a Apple disse que a maioria das solicitações de reembolso chega em até 30 dias e que os dados de consumo devem ser armazenados de acordo. Nós mantemos por 90 dias, em parte porque os chargebacks do Google podem demorar mais para aparecer, e em parte porque armazenamento é barato e argumentar de memória não é.
Como o histórico de compras ajuda com reembolsos
Uma vez que isso esteja implementado, a solicitação deixa de ser uma decisão subjetiva e se torna uma consulta.
Entregue, totalmente consumido, sem amostra, sem reembolsos anteriores: esse é o caso para DECLINE. Entregue, praticamente não usado, solicitado em até um dia: GRANT_FULL custa pouco e a alternativa parece mesquinha. A entrega falhou do seu lado: conceda o reembolso e corrija o bug. Usado parcialmente ao longo de várias semanas: a Apple tem o GRANT_PRORATED para isso, e no Google a porcentagem de consumo faz o mesmo trabalho.
Os números confirmam isso. A Dipsea, um app de áudio por assinatura, começou a responder às solicitações da Apple no final de 2024, e sua taxa de reembolso caiu de 3% para 1.9% em cerca de duas semanas. Sobre chargebacks, a Appcharge disse à PocketGamer que disputas sem assistência vencem de 20% a 30% das vezes, enquanto as apoiadas por evidências vencem mais de 80%. Entre os mais de 800 apps no Refund Sensor, 77% das solicitações elegíveis foram defendidas, e as que perdemos geralmente não tinham nada registrado.
O que o histórico de compras não faz é permitir que você ganhe argumentos que não deveria ganhar. Se os dados do cliente mostram que ele abriu o app uma vez, a resposta honesta é o reembolso.
Como processar solicitações de reembolso dentro do prazo
O processo de solicitação de reembolso em ambas as lojas tem prazo fixo, então isso é mais encanamento do que julgamento. A notificação chega em um endpoint que você registrou. Você verifica a assinatura, recupera o ID da transação, consulta os registros de entrega e consumo do usuário, calcula a porcentagem, escolhe a preferência com base em uma regra que você definiu com antecedência, e envia. Registre o que você enviou e quando, depois espere o resultado, que na Apple é uma notificação REFUND ou REFUND_DECLINED. Em caso de REFUND, revogue o acesso na mesma hora, porque um cliente reembolsado que mantém o conteúdo tende a voltar para pedir mais.
Duas coisas costumam confundir as pessoas. Consentimento: a Apple não aceita o envio a menos que customerConsented seja true, então a permissão para compartilhar dados de uso precisa estar nos seus termos antes da primeira solicitação. E o tempo: os relógios não pausam nos fins de semana, e uma parcela surpreendente das solicitações chega durante a madrugada. A gestão de solicitações de reembolso é, em grande parte, garantir que algo esteja ativo. Nosso guia de gestão de solicitações de reembolso da Apple aprofunda o lado operacional.
Software de processamento de reembolsos para desenvolvedores, ou seu próprio código
Com uma equipe de backend, o pipeline acima é uma semana de trabalho e depois uma obrigação contínua, e essa obrigação é a parte cara.
Se você usa RevenueCat ou Adapty, ambos respondem às solicitações de consumo da Apple com os dados de uso que seus SDKs já coletam, e a Adapty também cobre a revisão do Google. Uma opção padrão razoável se o SDK já está no app de qualquer forma.
O Refund Sensor faz a mesma coisa sem um SDK. Você conecta uma chave de API do App Store Connect e uma URL de notificações, e ele recebe as solicitações, envia a resposta dentro do prazo e mantém uma linha do tempo por caso. A configuração leva poucos minutos e o preço é fixo. Os detalhes estão no site do Refund Sensor.
O que quer que você escolha, incluindo nada, a camada de dados é sua. Nenhum software de processamento de reembolsos para desenvolvedores consegue inventar um registro de entrega que você não guardou.
Conclusão
A defesa de reembolsos costuma ser tratada como um problema de resposta, mas na verdade é consequência de um problema de registro. As lojas fazem quatro perguntas específicas, e sua capacidade de responder depende de decisões tomadas no checkout e na entrega, muito antes de alguém querer o dinheiro de volta.
Anexe um identificador, registre entrega e consumo com timestamps, sinalize amostras e mantenha tudo por 90 dias. Com isso implementado, o processamento de solicitações de reembolso se torna uma regra e um cron job, e a taxa de reembolso tende a se resolver por conta própria.
Perguntas frequentes
A Apple dá a você 12 horas a partir do CONSUMPTION_REQUEST. O Google dá 24 horas a partir da notificação de revisão de reembolso pendente para um chargeback. Ambos decidem sem você se o prazo for perdido.
Cinco campos: consentimento do cliente, status de entrega, porcentagem de consumo em milliunits, se uma amostra foi fornecida e sua preferência de reembolso. Campos mais antigos, como tempo de conta e gasto total, não existem mais.
Em grande parte, além de mais detalhes se você os tiver. O Google aceita uma porcentagem de consumo e até 1,000 eventos de uso com timestamp, e suas opções de preferência são DECLINE, APPROVE ou NEUTRAL.
Na Apple, sim. O envio é rejeitado a menos que customerConsented seja true, então a permissão precisa estar nos seus termos antes que a solicitação chegue.
Não. Ambas as lojas tratam sua preferência como apenas um dado de entrada, e ambas veem o histórico completo do cliente. Recusar quando seus próprios dados mostram falha na entrega ou uso quase nulo custa sua credibilidade nos casos que realmente importam.
