Marque cada compra do Google Play com um id de conta ofuscado, ou um estorno chega sem forma de rastreá-lo

Uma revisão de estorno do Google Play aparece nomeando um pedido e um token de compra. Ela não diz quem é o cliente. Se você nunca estampou seu próprio identificador nessa compra, agora está combinando um simples id de pedido com sua tabela de usuários sob um relógio de 24 horas, e precisa responder com evidência de uso que talvez não consiga encontrar. O id de conta ofuscado é a solução. É uma string curta que você anexa no checkout que o Google Play armazena com a compra e devolve a você mais tarde, de modo que cada pedido pode ser rastreado até o usuário exato que o realizou. Aqui está o que é o campo, por que ele decide se você consegue responder a uma disputa, e quanto custa ignorá-lo agora que um estorno perdido é uma conta.

O que o id de conta ofuscado realmente é

O id de conta ofuscado é uma string opcional que você passa para o fluxo de faturamento do Google Play quando um cliente compra algo. Você o configura com setObfuscatedAccountId no construtor de BillingFlowParams, e o Google o armazena ao lado da compra. Não é o nome do cliente, nem o e-mail dele, nem a conta do Google dele. É o seu próprio identificador para o seu próprio usuário, escrito em uma forma que o Google pode guardar sem saber quem é a pessoa.

É uma string que você configura no checkout, não um nome

Nas palavras do Google, setObfuscatedAccountId especifica uma string ofuscada opcional que está associada de forma única à conta de usuário do comprador no seu app. A palavra ofuscada cumpre um papel real. O Google não quer o seu id de usuário em bruto nem nada que identifique a pessoa. Ele quer um token estável que mapeie um para um a um usuário do seu lado, e nada mais. O campo é limitado a 64 caracteres, o que acomoda um hash confortavelmente e pouco mais.

O Google o lê primeiro para a própria triagem de fraude

Antes de ser útil para você, o campo cumpre uma tarefa para o Google. A documentação de faturamento diz que o Google Play pode usar esse valor para detectar atividade irregular, como muitos dispositivos fazendo compras na mesma conta em um curto período, e que o Google usa esses dados para detectar comportamento suspeito e bloquear alguns tipos de transações fraudulentas antes que sejam concluídas. Então o primeiro benefício de configurá-lo está a montante, em compras mais limpas e menos daquelas fraudulentas que se transformam depois em anulações e disputas. O Google lista o id de conta ofuscado e a Voided Purchases API juntos como suas duas ferramentas centrais contra abuso por um motivo.

Por que importa quando uma revisão de estorno chega

Um reembolso que você vê chegando é fácil. O caso difícil é o estorno bancário, porque ele não começa com o seu cliente falando com você. Começa com o banco, e o Google Play o encaminha a você como uma revisão com um relógio anexado.

A disputa nomeia um pedido, não uma pessoa

Quando um cliente contesta uma cobrança com o banco dele e o Google precisa da sua contribuição, o Google Play envia uma PendingRefundReviewNotification. Essa mensagem identifica o pedido. Ela não carrega o seu id de usuário, porque o Google nunca teve o seu id de usuário. Ele só tinha o que você estampou na compra. Se isso foi nada, agora você está buscando ao contrário um simples id de pedido e token de compra em seus próprios registros, esperando ter registrado o token no momento da compra e esperando que a correspondência seja inequívoca. Se você configurou um id de conta ofuscado, a compra carrega o seu próprio hash, você busca o usuário em uma única consulta, e passa a construir evidência em vez de caçar identidade.

O que orders.reviewrefund realmente pede de você

Responder à disputa significa chamar o método orders.reviewrefund dentro de 24 horas. O Google registra a sua primeira chamada e ignora o resto, então a primeira resposta é a única resposta. Estes são os campos que ele quer, e cada um dos campos de evidência assume que você já sabe a qual usuário o pedido pertence.

Quanto realmente custa ignorá-lo

Durante a maior parte da história do Google Play, um estorno que você não podia defender era uma venda perdida e um dar de ombros. Isso mudou. Para pedidos feitos a partir de 3 de agosto de 2026, um estorno perdido cobra do desenvolvedor o preço de compra menos a taxa de serviço do Google, mais a taxa de estorno do banco. A disputa que você não pode responder é agora um item de despesa.

Vamos acompanhar um pedido. Um cliente contesta uma compra de $9.99 com o banco dele. O Google Play envia a revisão, e você tem 24 horas. Se você marcou a compra, encontra o usuário, vê que ele consumiu a maior parte do que comprou, e responde reviewrefund com uma preferência DECLINE e a evidência de consumo, dando ao Google um caso real para contestar uma disputa ilegítima. Se você não a marcou, ou não consegue identificar o pedido a tempo ou responde sem nada, a disputa é decidida sem o seu lado, e em um pedido posterior a 3 de agosto você paga os $9.99 menos a taxa do Google de volta, mais uma taxa fixa de estorno bancário que muitas vezes fica perto de $20. Em uma venda pequena, essa taxa fixa sozinha pode ser maior do que o que você ganhou líquido.

• A receita perdida: sua parcela líquida da venda, revertida.
• A taxa de estorno do banco: um custo fixo que a rede de cartões define, cobrado por cima em pedidos feitos após 3 de agosto de 2026, que um simples reembolso nunca carrega.
• O gasto desperdiçado: a computação, as chamadas de API de terceiros e o armazenamento que a conta já usou, perdidos independentemente de você conseguir responder.
• O padrão que você não consegue ver: sem um id de conta estável você também não consegue perceber que o mesmo usuário está contestando repetidamente, então o abuso em série se lê como perdas isoladas não relacionadas.

Como configurá-lo sem ter compras bloqueadas

Duas regras cobrem quase todos os erros que as equipes cometem com este campo. Aplique hash ao id, e configure-o em todos os lugares.

Aplique hash ao seu id de usuário, nunca envie PII

Não coloque um e-mail, um número de telefone ou qualquer dado pessoal em bruto neste campo. O Google é explícito que armazenar PII como e-mails em texto claro faz com que as compras sejam bloqueadas, e recomenda um hash unidirecional ou criptografia para gerar o valor. O padrão limpo é um hash unidirecional do seu id de usuário interno, calculado da mesma forma toda vez para que o mesmo usuário sempre produza a mesma string de 64 caracteres. Também não use o id de conta do Google da pessoa nem o seu id de desenvolvedor. O valor deve significar algo apenas para o seu sistema.

Configure-o em cada compra, e leia-o de volta no seu servidor

Anexe o id a cada fluxo de faturamento, tanto produtos de compra única quanto assinaturas, para que nenhuma compra fique sem rótulo. Após a compra, leia-o de volta em dois lugares. No cliente, Purchase.getAccountIdentifiers retorna um objeto cujo getObfuscatedAccountId dá a você a string que você configurou. No seu backend, o registro de compra do lado do servidor o carrega como o campo obfuscatedExternalAccountId, e a cópia do servidor é a que se deve confiar, porque uma disputa chega ao seu servidor, não ao dispositivo.

Use setObfuscatedProfileId quando uma conta tem muitos perfis

Se o seu app permite que uma conta tenha vários perfis, um lar de streaming ou um jogo com vários personagens, configure também setObfuscatedProfileId. É o mesmo tipo de string com hash, de 64 caracteres e sem PII, restrita ao perfil que fez a compra. O Google observa que configurar um id de perfil também exige que o id de conta seja passado, então envie ambos. O resultado é que uma disputa mapeia não apenas para a conta, mas para o perfil exato que gastou o dinheiro.

O paralelo do iOS, em uma linha

A App Store tem a mesma ideia sob um nome diferente. No iOS você anexa um appAccountToken, um UUID, a uma compra, e ele volta na transação e na CONSUMPTION_REQUEST que a Apple envia quando um cliente pede um reembolso. A forma do problema é idêntica nas duas lojas. O fluxo de disputa ou reembolso faz referência a uma transação, e o seu próprio identificador é o que a vincula de volta a um usuário cujo uso você pode reportar.

Nada disso é difícil de construir. É fácil de ignorar, porque o dia em que você escreve o código de checkout não é o dia em que um estorno chega, e o custo de ignorá-lo é invisível até então. O RefundHalt configura e rastreia o identificador de conta nas duas lojas, mantém o vínculo compra-usuário para que uma disputa sempre se resolva a um cliente real, e responde ao orders.reviewrefund do Google Play e à CONSUMPTION_REQUEST da Apple dentro das janelas deles com a evidência de consumo registrada no momento da venda. O relógio de 24 horas não é o momento de descobrir que você não consegue dizer quem comprou a coisa.