Alguém que pede reembolso pela quarta vez não é um cliente insatisfeito. Essa pessoa está executando uma rotina, e isso custa a você a receita devolvida mais tudo o que foi gasto para cumprir o pedido. A Apple e o Google expõem, cada um, um campo de identidade, o appAccountToken de um lado e o obfuscated account ID do outro, que transforma esses incidentes isolados em um padrão visível.
Principais conclusões
Evidências enviadas por você chegam a uma loja em exatamente duas situações: o CONSUMPTION_REQUEST da Apple, que pode ser respondido em até 12 horas, e a revisão de chargeback do Google Play via Review Refund API, respondível em até 24 horas. Tudo o mais é decidido sem você.
Na Apple, um UUID gerado por você acompanha a compra como appAccountToken. O StoreKit o fixa à transação, o que significa que qualquer reembolso posterior se resolve em uma conta identificável nos seus próprios registros.
O equivalente do Google é uma string com hash de no máximo 64 caracteres. O próprio Google a lê, usando esse campo para identificar comportamento irregular, como uma única conta comprando em um número implausível de dispositivos em um intervalo curto.
Dados pessoais em texto claro nesse campo do Google fazem as compras serem bloqueadas imediatamente. É necessário um valor criptografado ou um hash unidirecional. Um endereço de e-mail bruto não serve.
O voidedReason do Play distingue friendly_fraud e fraud de um reembolso comum por mudança de ideia, o que te dá base para enviar reincidentes a uma fila de revisão em vez de seguir o caminho padrão de reembolsar e seguir adiante.
O Google relata ter bloqueado mais de US$ 2 bilhões em transações fraudulentas e abusivas durante 2022. Essas defesas funcionam a partir de sinais de identidade que só existem se suas compras os carregarem.
Acesso que sobrevive a um reembolso continua consumindo armazenamento, processamento e orçamento de API pelos quais você já não está sendo pago, e quem pede reembolso deliberadamente está construindo exatamente esse resultado, repetidas vezes.
Introdução
Reembolsos acontecem, e um deles é simplesmente um custo operacional. O que muda o quadro é a mesma conta voltando pela quarta vez, tendo consumido o produto em cada ocasião anterior. Esse comportamento só fica visível para você se cada transação chegar carregando um identificador que você atribuiu. As duas plataformas oferecem um. As duas também abrem uma janela de resposta estreita antes de o resultado ser definido. Pule o identificador, ou perca a janela, e quem está manipulando o sistema fica indistinguível de alguém de primeira vez com uma reclamação genuína. O que separa os dois casos, e o que essa diferença vale em dinheiro, é o que vem a seguir.
Abuso de reembolso é, na verdade, um problema de identidade disfarçado de reembolso
As decisões de reembolso pertencem à loja. Os clientes vão pedir, e na maioria dos fluxos a loja vai concordar, sem nenhuma possibilidade de você interferir. Sua influência está em outro lugar: estabelecer se essa conta específica tem histórico de fazer isso, e se o que ela comprou foi, de fato, entregue e usado. As duas perguntas são perguntas de identidade. Qual usuário está por trás dessa transação, e o que ele já fez antes. Compras que não carregam um vínculo estável com os seus registros de usuário deixam as duas perguntas sem resposta, de modo que todo reembolso chega desprovido de contexto.
Essa é a lacuna que vale a pena fechar. A política define a mecânica, e você não pode alterá-la. As evidências, porém, são suas para reunir, e essa reunião começa no checkout, não no reembolso.
Duas janelas em que o que você envia realmente importa
Apenas dois fluxos tratam sua entrada como entrada de fato. Um cliente solicitando reembolso de um consumível ou de uma assinatura de renovação automática aciona o CONSUMPTION_REQUEST da Apple, e sua resposta deve ser enviada em até 12 horas. Um cliente contestando uma cobrança junto ao banco aciona a revisão de chargeback do Google Play, respondível pela Review Refund API em até 24 horas. Fora desses dois casos, a decisão acontece sem você: o autoatendimento de reembolso de 48 horas do Play, um reembolso concedido pelo suporte, um reembolso automático para uma compra que você nunca confirmou.
Os dois canais ficam consideravelmente mais precisos quando a transação já carrega seu identificador. As informações de consumo enviadas à Apple podem incluir o appAccountToken junto com o histórico e os gastos dessa conta, enquanto a revisão do Google recorre a um obfuscated account ID que ele vem observando desde que a compra foi concluída. Onde não há identificador, não há histórico a enviar.
Os dois campos de identidade, comparados
As duas empresas chegaram a soluções quase idênticas, com nomes diferentes e restrições diferentes. Cada uma permite marcar uma compra com um valor que remete de volta ao seu próprio registro de usuário. Nenhuma delas vem ativada para você. As duas são inúteis a menos que sejam definidas enquanto a compra está acontecendo.
Apple: appAccountToken
Gere um UUID, passe-o no início da compra, e o StoreKit o vincula à transação resultante. Ele então aparece nos dados da transação que seu servidor verifica, e novamente nas informações de consumo que você devolve durante um CONSUMPTION_REQUEST. Como o valor se originou com você, ele associa uma transação da loja a uma linha do banco de dados sem envolver nenhum nome ou e-mail. Apenas UUIDs reais; qualquer outra coisa é rejeitada. Desde então, a Apple lançou um endpoint Set App Account Token capaz de gravar ou atualizar o token em transações que já aconteceram, incluindo resgates de código de oferta e compras semelhantes feitas fora do app.
Google Play: o obfuscated account ID
setObfuscatedAccountId é a versão do Google, uma string opcional vinculada à conta que realiza a compra. A documentação do Google declara seu propósito sem rodeios: o Play usa o valor para detectar atividade irregular, sendo o exemplo dado muitos dispositivos transacionando em uma única conta dentro de uma janela curta de tempo, e para bloquear algumas compras fraudulentas antes que sejam concluídas. O limite é de 64 caracteres, e dados pessoais em texto claro são proibidos. Coloque um e-mail bruto ali e a compra será bloqueada, porque o que o campo espera é um valor criptografado ou um hash unidirecional. Apps em que uma única conta contém múltiplos perfis têm um campo complementar, o setObfuscatedProfileId.
appAccountToken é o campo da Apple. Precisa ser um UUID e nada mais, seu código o define durante o checkout, e ele fica ausente a menos que você o adicione. A Apple o usa para ancorar a transação ao seu usuário, e ele reaparece nos payloads de transação e de consumo.
obfuscatedAccountId é o campo do Google Play. Ele aceita uma string com hash de no máximo 64 caracteres, seu código o define durante o checkout, e também fica ausente por padrão. O Google o alimenta na detecção de atividade irregular e o usa para bloquear algumas compras fraudulentas antes que sejam concluídas.
Uma assimetria importa enormemente. O Google não oferece nenhum tipo de preenchimento retroativo. Uma compra do Play concluída sem o identificador fica permanentemente anônima, e marcar compras futuras é o único remédio disponível. O endpoint Set App Account Token da Apple pode reparar o histórico, o que o torna a exceção, não a regra.
Calculando o custo de um reembolso de quem faz isso repetidamente
A receita devolvida é a parte visível, e também a menor parte. Conceder um reembolso devolve o preço da venda, o que seu livro contábil registra. Ausente dessa linha está tudo o que foi gasto produzindo aquilo que o cliente agora mantém de graça.
Considere um consumível que põe trabalho real em movimento: imagens geradas, uma série de chamadas a um provedor de modelo, um vídeo exportado, um pagamento liberado para um criador. Esse processamento foi pago no momento do uso. Reembolsar recupera o preço da venda e deixa a fatura do provedor exatamente onde estava. Quem percebeu que o produto sobrevive ao reembolso simplesmente repete a sequência, comprando, consumindo, reembolsando, e cada repetição cobra de você o custo de entrega outra vez.
Há também a plataforma transferindo custos para você. A partir de 3 de agosto de 2026, o Google Play atribui tanto o preço da compra quanto as taxas de chargeback do banco aos desenvolvedores, para pedidos feitos a partir dessa data. Disputas que antes eram, em grande parte, despesa do Google passam a ser sua receita perdida mais uma taxa, e quem faz chargeback com frequência eleva esse valor a cada tentativa. Os campos de identidade são o que torna possível entregar à Review Refund API algo que vale a pena ler dentro da janela de 24 horas.
O Google dimensiona o problema com um número: mais de US$ 2 bilhões em transações fraudulentas e abusivas bloqueadas durante 2022. Esse número existe porque os sinais subjacentes, o obfuscated account ID entre eles, foram de fato preenchidos. Enviar compras com esses campos vazios é uma decisão de ficar fora dessa proteção.
Identificando reembolsadores recorrentes antes que a loja decida
Marque toda compra com uma identidade que você controla
Nenhuma das plataformas deveria ver uma compra sem um identificador. Compras pelo StoreKit carregam o appAccountToken, compras pelo Play Billing carregam o setObfuscatedAccountId, e os dois valores se originam no seu próprio registro de usuário. A Apple espera um UUID genuíno mapeado para aquela conta, o Google espera a chave da conta com hash, de modo que nada pessoal viaje em texto claro. O checkout é o momento para os dois, e no Google esse momento não pode ser renegociado depois.
Mantenha um livro-razão indexado por essa identidade
Registre as entregas, os eventos de consumo, as compras e os reembolsos, todos arquivados sob esse identificador. Um CONSUMPTION_REQUEST ou uma revisão de chargeback então colocam todo o passado dessa conta, incluindo reembolsos anteriores, a uma única consulta de distância. As informações de consumo da Apple fornecem campos dedicados exatamente para esse material: consumptionStatus, deliveryStatus, playTime, accountTenure, lifetimeDollarsPurchased e o seu próprio refundPreference.
Trate o voidedReason como uma decisão de roteamento
Compras anuladas no Play carregam um voidedReason explicando a causa, e friendly_fraud e fraud são registrados separadamente do arrependimento comum. Esses casos merecem uma fila de revisão e uma política mais firme, em vez do tratamento automático que um reembolso de primeira vez recebe. A orientação do Google descreve respostas escalonadas: um aviso inicialmente, algo mais firme em caso de repetição, e compras desativadas para contas que persistem.
Nunca perca a janela
Evidência enviada atrasada praticamente não existe. Automatize a resposta ao CONSUMPTION_REQUEST para que seja despachada com folga dentro de 12 horas, e a revisão de chargeback dentro de 24. Um histórico de conta impecável enviado depois do prazo é um histórico que ninguém na loja vai abrir.
Para identificar uma conta transacionando em um número implausível de dispositivos ao mesmo tempo, apoie-se na detecção de atividade irregular do Google Play, que lê o obfuscated account ID.
Para ver um histórico de reembolsos anteriores nessa conta, apoie-se nos seus próprios registros, ou seja, no livro-razão que você indexou pelo identificador de qualquer uma das plataformas.
Para confirmar que o produto de fato chegou ao comprador e foi usado, apoie-se na Apple, onde consumptionStatus e deliveryStatus vivem dentro das informações de consumo.
Para flagrar uma disputa que, na verdade, é o comprador te fraudando, apoie-se no Google Play, onde o voidedReason retorna como friendly_fraud.
Onde as plataformas ajudam, e onde elas param
Vale a pena ser preciso sobre essa divisão de responsabilidade, porque é fácil assumir que as lojas lidam com o abuso, e elas raramente anunciam o ponto em que param de fazê-lo. O Google realmente lê o obfuscated account ID para bloquear algumas fraudes antes da compra, e sistemas no nível da plataforma interceptam um volume substancial. A Apple reserva para si toda decisão de reembolso e trata suas informações de consumo como evidência, não como voto. O que nenhuma das lojas faz é manter uma lista de abusadores em seu nome, creditar de volta ao seu saldo um consumível reembolsado, ou negar um reembolsador recorrente por você. Nas margens, a identidade é da loja agir sobre ela. Em todo o resto, é sua.
O Refund Sensor é arquitetado em torno dessa identidade pelo mesmo motivo. Um reembolso, uma revisão de chargeback e uma solicitação de consumo pertencentes a uma mesma conta se condensam em um único histórico, de modo que um padrão recorrente se torna visível já na segunda ocorrência, em vez de só depois que a quarta fatura já tiver sido paga.
Onde essas regras estão documentadas
Perguntas frequentes
Trata-se de um cliente que solicita reembolso repetidamente depois de receber e usar o que comprou, mantendo o benefício enquanto recupera o pagamento. No contexto de lojas de apps, isso costuma aparecer como uma mesma conta reembolsando consumíveis ou assinaturas repetidas vezes, ou como fraude amigável, em que uma cobrança válida é contestada junto ao banco em vez disso.
Na Apple, você gera um UUID, passa esse valor como appAccountToken no início da compra, e o StoreKit o anexa à transação resultante, de onde ele reaparece tanto nos dados da transação quanto nos dados de consumo. No Google, você chama setObfuscatedAccountId usando um valor hash derivado dessa conta. As duas abordagens associam uma transação da loja ao registro do seu próprio usuário sem expor nenhuma informação pessoal.
Nenhum dos dois faz isso, pelo menos não diretamente. O Google lê o obfuscated account ID para identificar atividade irregular e bloquear algumas fraudes antes da compra, e a Apple aceita o histórico da conta enviado durante uma solicitação de consumo, mas nenhuma das duas empresas devolve uma lista de reincidentes. Montar essa lista é responsabilidade sua, construída a partir dos registros que você arquivou sob esses identificadores.
O motivo costuma ser dados pessoais em texto claro dentro do obfuscated account ID. Colocar algo como um endereço de e-mail bruto ali faz o Play bloquear a compra imediatamente. Forneça, em vez disso, um valor criptografado ou um hash unidirecional, respeitando o limite de 64 caracteres.
Reduz o abuso, mas não o elimina. O CONSUMPTION_REQUEST é um dos únicos dois caminhos em que suas evidências chegam antes da decisão, e o histórico da conta combinado com dados de entrega e consumo ajuda a Apple a reconhecer abuso de devolução e fraude amigável. Ainda assim, a decisão final é da Apple, e o abuso que chega por fluxos que você não pode contestar permanece intocado.
