O abuso reiterado de reembolsos custa a você duas vezes, veja como as lojas deixam você reagir

Um único reembolso é um custo de fazer negócios. A mesma conta reembolsando pela quarta vez, depois de usar o que comprou a cada vez, é abuso de reembolsos, e é um padrão que você só consegue ver se cada compra carrega uma identidade que você controla. Apple e Google dão a você essa identidade, e ambos dão uma janela estreita para colocá-la diante da loja antes que um reembolso ou estorno seja decidido. Perca a janela, ou nunca anexe a identidade, e um reembolsador reincidente parece exatamente igual a um cliente insatisfeito de primeira viagem. Veja como distingui-los, e quanto vale essa diferença em dinheiro.

Por que o abuso de reembolsos é um problema de identidade, não de reembolso

A loja decide o reembolso. Você não consegue impedir um cliente de pedir, e na maioria dos fluxos não consegue impedir a loja de conceder. O que você pode fazer é decidir se uma determinada conta já fez isso antes, e se o conteúdo que ela comprou foi de fato entregue e usado. Ambas são perguntas sobre identidade: qual dos seus usuários está por trás desta transação, e qual é o histórico dele. Se suas compras não carregam um identificador estável de volta aos seus próprios registros de usuário, você não consegue responder nenhuma das duas, e cada reembolso chega sem contexto.

Essa é a verdadeira lacuna. A mecânica do reembolso é fixada pela política. As provas que você traz para ela são inteiramente suas para construir, e começam no momento da compra, não no momento do reembolso.

As duas janelas em que as provas mudam o resultado

Existem exatamente dois fluxos em que algo que você envia pode mover uma decisão. O CONSUMPTION_REQUEST da Apple dispara quando um cliente pede reembolso de um consumível ou de uma assinatura de renovação automática, e você tem 12 horas para responder. A revisão de estornos do Google Play dispara quando um usuário contesta uma cobrança com o banco, e você tem 24 horas para responder por meio da Review Refund API. Todo outro reembolso, o reembolso de autoatendimento de 48 horas do Play, um reembolso concedido pelo suporte, um reembolso automático por compra não reconhecida, é decidido sem você.

Ambos os canais de prova são muito mais fortes quando a transação já carrega seu identificador. As informações de consumo da Apple podem incluir o appAccountToken junto com o histórico e o gasto da conta, e a revisão do Google pode se apoiar no ID de conta ofuscado que ela vem observando desde a compra. Uma conta sem identificador é uma conta sem histórico para apresentar.

Os dois campos de identidade, lado a lado

Apple e Google resolveram o mesmo problema de maneira quase idêntica, com nomes diferentes e regras diferentes. Ambos permitem que você marque uma compra com um valor que aponta de volta ao seu próprio registro de usuário. Nenhum está ativo por padrão. Ambos são inúteis se você não os define no momento da compra.

Apple: appAccountToken

appAccountToken é um UUID que você gera e passa quando uma compra começa. O StoreKit o associa à transação resultante, e ele aparece nos dados da transação que seu servidor verifica e nas informações de consumo que você devolve durante um CONSUMPTION_REQUEST. Como é o seu valor, ele mapeia uma transação da loja diretamente para a conta no seu banco de dados, sem e-mail nem nome envolvidos. Ele precisa ser um UUID real, e qualquer outra coisa é rejeitada. A Apple depois adicionou um endpoint Set App Account Token que pode anexar ou atualizar o token em transações passadas, incluindo compras feitas fora do seu app, como resgates de códigos de oferta.

Google Play: o ID de conta ofuscado

O equivalente do Google é o setObfuscatedAccountId, uma string opcional vinculada à conta compradora. A própria documentação do Google é direta sobre seu propósito: o Google Play o usa para detectar atividade irregular, como muitos dispositivos fazendo compras na mesma conta em um curto período, e para bloquear algumas transações fraudulentas antes que se completem. É limitada a 64 caracteres, e não deve carregar dados pessoais em texto puro. Guarde ali um e-mail sem tratamento e o Google bloqueia a compra imediatamente, porque o campo espera um valor criptografado ou um hash unidirecional. Um campo irmão, setObfuscatedProfileId, existe para apps em que uma conta contém vários perfis.

Quanto realmente custa um reembolso de um abusador reincidente

O reembolso em si é a menor parte da conta. Quando uma loja concede um reembolso, você devolve a receita, e isso é o que fica visível no balanço. O que não está na linha do reembolso é tudo o que você gastou entregando o produto que agora é gratuito.

Imagine um consumível que dispara trabalho real: uma geração de imagens, um lote de chamadas à API de um provedor de modelos, uma exportação de vídeo, um pagamento a um criador. Você pagou por essa computação no momento em que o cliente a usou. O reembolso recupera o preço, mas não recupera a fatura do provedor. Um reembolsador reincidente é alguém que aprendeu que o conteúdo sobrevive ao reembolso, então repete o ciclo: compra, consome, reembolsa, repete. A cada ciclo, você arca com o custo de entrega uma segunda vez.

Depois há a própria transferência de custos da loja. A partir de 3 de agosto de 2026, o Google Play transfere o preço de compra e as taxas de estorno do banco para o desenvolvedor nos pedidos feitos após essa data. Um estorno que antes era em grande parte problema do Google passa a ser sua receita mais uma taxa, e um contestador reincidente aumenta esse número toda vez. Os campos de identidade são o que permite alimentar a Review Refund API com as provas para contestar uma disputa ilegítima dentro da janela de 24 horas.

O Google coloca a escala de forma clara: diz que bloqueou mais de US$ 2 bilhões em transações fraudulentas e abusivas em 2022. Esse número existe porque os sinais, o ID de conta ofuscado entre eles, estavam preenchidos. Um app que envia compras com campos de identidade vazios abre mão dessa proteção.

Como pegar reembolsadores reincidentes antes de a loja decidir

Marque cada compra com uma identidade que seja sua

Defina appAccountToken em cada compra do StoreKit e setObfuscatedAccountId em cada compra do Play Billing, ambos gerados a partir do seu próprio registro de usuário. Na Apple, use um UUID real mapeado para a conta. No Google, aplique hash à chave da conta para que nenhum dado pessoal trafegue em texto puro. Faça isso no momento da compra, porque no Google esse é o único passo que você não consegue recuperar depois.

Mantenha um registro com chave nessa identidade

Armazene cada compra, entrega, evento de consumo e reembolso contra o identificador. Quando um CONSUMPTION_REQUEST ou uma revisão de estorno chega, o histórico completo da conta, reembolsos anteriores incluídos, está a uma única consulta de distância. As informações de consumo da Apple têm campos explícitos exatamente para isso: consumptionStatus, deliveryStatus, playTime, accountTenure, lifetimeDollarsPurchased, e a sua refundPreference.

Leia o voidedReason e direcione os abusadores de forma diferente

Quando uma compra do Google é anulada, o campo voidedReason diz por quê, e friendly_fraud e fraud são valores separados de um reembolso comum do tipo remorse. Direcione esses para uma fila de revisão e uma política mais rígida, não para o mesmo caminho automático de um reembolso de primeira vez. A própria orientação do Google é um modelo de várias advertências: avise um primeiro infrator, tome medidas mais firmes com os reincidentes, e desative as compras para uma conta que insiste.

Responda à janela toda vez

As provas só contam dentro das duas janelas. Automatize a resposta do CONSUMPTION_REQUEST para que dispare bem dentro das 12 horas, e a revisão de estorno para que dispare dentro das 24. Um histórico perfeito que você envia atrasado é um histórico que a loja nunca lê.

O que as lojas farão e não farão por você

Vale ser preciso sobre a divisão de trabalho, porque é fácil supor que as lojas cuidam do abuso, e na maioria das vezes elas não avisam quando não cuidam. O Google usa ativamente o ID de conta ofuscado para bloquear parte da fraude antes de uma compra se concluir, e seus sistemas pegam uma grande parcela no nível da plataforma. A Apple decide cada reembolso por conta própria e trata suas informações de consumo como uma entrada, nunca um voto. Nenhuma loja mantém sua lista de abusadores por você, deduz um consumível reembolsado do seu saldo, nem diz não a um reembolsador reincidente em seu nome. A identidade é da loja para agir nas margens e sua para agir em todo o resto.

Essa é a mesma razão pela qual o RefundHalt baseia tudo na identidade da compra: um reembolso, uma revisão de estorno e uma solicitação de consumo para a mesma conta se resolvem em um único histórico, então um reembolsador reincidente aparece como um padrão na primeira vez que repete, não depois da quarta fatura que você já pagou.