O DeviceCheck da Apple lembra o celular de quem abusa de reembolsos, mesmo depois de um cadastro com conta nova

Banir a conta não impede quem abusa de reembolsos de se cadastrar de novo no mesmo celular. O DeviceCheck da Apple e a recuperação de dispositivos (device recall) do Google Play existem exatamente para essa lacuna. Cada um permite que seu servidor associe alguns bits, com o significado que você definir, a um dispositivo físico. Eles ficam nos servidores da loja, então a marcação continua lá quando a pessoa volta com um novo endereço de e-mail. Nenhuma das ferramentas entrega um ID de dispositivo, e nenhuma consegue impedir um reembolso. O que elas fazem é avisar, no cadastro ou no paywall, que esse dispositivo já causou prejuízo antes.

Veja o que cada loja realmente armazena, a armadilha de tempo que decide se você consegue sequer definir a marcação e quanto custa um abusador reincidente antes de você identificá-lo.

Por que uma conta nova vence qualquer defesa no nível da conta

A maioria das defesas contra reembolso se baseia em uma conta. O appAccountToken da Apple vincula uma transação a um usuário no seu banco de dados. O ID de conta ofuscado do Google Play faz o mesmo no Android. Vale definir os dois em toda compra, e ambos descrevem a conta de uma pessoa, não o hardware que ela tem nas mãos. Basta excluir a conta e se cadastrar com um novo e-mail para que o seu histórico sobre essa pessoa recomece do zero.

As lojas não preenchem essa lacuna por você. Uma notificação de reembolso da App Store informa qual transação foi reembolsada. Uma compra anulada do Google Play informa o token de compra, o ID do pedido e um voidedReason. Nenhuma delas traz um identificador de dispositivo. Um desenvolvedor de app de namoro descreveu o resultado em um tópico dos Apple Developer Forums: perfis golpistas compravam repetidamente uma assinatura premium que depois era reembolsada, e banir os dispositivos com o método próprio do desenvolvedor não resolveu.

Uma conta nova reinicia o teste da própria loja?

Não na mesma Conta Apple. A documentação da Apple diz que ofertas introdutórias, incluindo testes gratuitos, são para clientes que ainda não receberam uma para aquele produto ou para qualquer produto do mesmo grupo de assinaturas. Então, um novo login dentro do seu app não garante um segundo teste da Apple. Uma nova Conta Apple garante, assim como tudo o que você mesmo oferece: créditos de cadastro, um teste bancado pelo seu servidor, um bônus por indicação. São esses os brindes que uma marcação de dispositivo protege.

O que o DeviceCheck da Apple realmente armazena

O DeviceCheck tem duas partes. No app, a classe DCDevice gera um token efêmero que identifica o dispositivo. No seu servidor, você envia esse token para a Apple com um JSON web token assinado por uma chave da sua conta de desenvolvedor, e a Apple permite consultar ou atualizar dois bits desse dispositivo. A resposta da consulta retorna bit0, bit1 e last_update_time, informado como ano e mês. Os exemplos de uso da própria Apple são um dispositivo que já aproveitou uma oferta promocional e um dispositivo que você determinou ser fraudulento.

A Apple guarda os bits, mas o significado é seu. A documentação diz que você é responsável por acompanhar o que os bits significam e por decidir quando redefini-los, e dá como exemplo um dispositivo vendido. Dois bits geram quatro estados, então um esquema simples é um bit para reembolsado após uso intenso e outro para já recebeu créditos gratuitos.

• O token é de uso único. A Apple diz que ele continua válido por tempo suficiente para repetir uma requisição, mas você deve gerar um novo a cada chamada.
• Builds de desenvolvimento se comunicam com api.development.devicecheck.apple.com. Em produção é preciso usar api.devicecheck.apple.com, ou suas marcações vão parar no lugar errado.
• A Apple descreve o DeviceCheck como um dos insumos de uma avaliação geral de risco, não como um veredito. Trate um bit definido como motivo para olhar com mais atenção.

O que a recuperação de dispositivos do Google acrescenta no Android

A versão do Google faz parte da Play Integrity API e ainda está em beta, com acesso por formulário de interesse. Depois de aprovado e de ativar o recurso no Play Console, cada veredito de integridade traz três bits personalizados para o dispositivo. Você os grava com uma chamada de servidor ao endpoint deviceRecall:write, usando um token de integridade que já verificou. O Google diz que os dados sobrevivem à reinstalação do app e à redefinição do dispositivo, porque ficam nos servidores do Google.

A documentação do Google é incomumente direta sobre o caso de uso. Ela cita dispositivos com evidência de abuso grave, dispositivos que já resgataram um item de alto valor, como um teste gratuito, e dispositivos usados repetidamente para criar novas contas com fins abusivos. E é igualmente direta sobre o limite: o device recall só pode ser usado para proteger a segurança do app e combater abuso, fraude e acesso não autorizado, nunca para identificar por impressão digital ou rastrear usuários individuais, e nunca para armazenar características sensíveis como idade, gênero ou localização.

O problema do tempo: os reembolsos chegam depois que o token já se foi

As duas ferramentas precisam de algo do próprio dispositivo antes que você possa marcá-lo. A Apple precisa de um token DCDevice novo. O Google precisa de um token de integridade daquele dispositivo com no máximo 14 dias. O reembolso, por sua vez, chega ao seu servidor por uma notificação da loja que não sabe nada sobre o dispositivo. Então a questão não é se você vai marcar um dispositivo. É se você ainda terá como alcançá-lo quando o reembolso chegar.

Os reembolsos de 48 horas do Google cabem na janela de 14 dias

Os reembolsos por autoatendimento do Google Play só ficam disponíveis nas 48 horas seguintes à compra, bem dentro dos 14 dias em que um token de integridade continua válido para gravações. Faça uma verificação de integridade no momento da compra, guarde o token verificado junto ao ID do pedido e, quando chegar uma compra anulada desse pedido, você poderá gravar o bit na hora. Chargebacks são o caso mais difícil, já que uma contestação bancária pode chegar muito depois do 14º dia.

Os reembolsos da Apple dependem de o dispositivo voltar

Um reembolso da Apple pode chegar semanas depois da compra, e um token do DeviceCheck armazenado não foi feito para ser reutilizado. A resposta prática é marcar primeiro a conta e depois o dispositivo. Quando a notificação de reembolso chegar, marque a conta no seu banco de dados. Na próxima vez que essa conta abrir o app, solicite um token do DeviceCheck e defina o bit. Quem fica com o conteúdo depois de um reembolso costuma voltar, porque usá-lo era o objetivo.

• Na compra, registre a transação na sua própria conta por meio do appAccountToken ou do ID de conta ofuscado.
• Em um reembolso ou anulação, marque essa conta no seu servidor.
• Na próxima sessão da conta marcada, colete um token do dispositivo e defina o seu bit.
• Em todo cadastro, consulte os bits antes de conceder qualquer coisa que custe dinheiro para você.

Quanto custa um abusador reincidente de reembolsos

O preço reembolsado é a parte visível. O resto é tudo o que a compra já colocou em movimento. Se o seu app gasta dinheiro para entregar o que vende, cada ciclo de comprar, consumir e reembolsar deixa esse dinheiro gasto: tempo de GPU para imagens geradas, chamadas pagas a uma API de modelo ou de dados, armazenamento de exportações que o cliente mantém e repasses a criadores calculados sobre a venda. Uma conta nova reabre o ciclo, e sua contabilidade registra isso como um cliente totalmente novo.

Brindes gratuitos vazam da mesma forma, sem reembolso algum. Um dispositivo que acumula créditos de cadastro em dez contas consome dez vezes a capacidade de processamento que você orçou para um único teste. No Google Play, chargebacks de pedidos feitos após 3 de agosto de 2026 também custam o preço da compra menos a taxa de serviço do Google, mais as tarifas do banco, então quem contesta a partir de uma conta nova a cada vez custa a contestação inteira de novo.

O que fazer com um dispositivo marcado

Uma marcação responde a uma única pergunta: esse dispositivo deve ganhar algo de graça de novo? Mantenha uma resposta proporcional, porque um bit definido é um indício, não uma prova. Celulares são revendidos, famílias compartilham iPads, e o Google orienta expressamente a considerar ignorar ou redefinir dados antigos por esse motivo.

• Não conceda créditos de cadastro, o teste bancado pelo servidor ou o bônus por indicação a um dispositivo marcado, e ofereça o plano pago no lugar.
• Não assine uma oferta promocional para um dispositivo marcado. Na App Store, é o seu servidor que gera a assinatura que libera uma oferta promocional, então a escolha é sua.
• Exija a confirmação do pagamento antes de entregar consumíveis caros em um dispositivo marcado.
• Use o carimbo de data. Uma marcação feita no mês passado pesa mais do que uma feita há dois anos.
• Dê às pessoas um caminho até o suporte. Quem comprou um celular usado e foi marcado por engano merece uma resposta, e você pode redefinir os bits.

Dá para simplesmente banir o dispositivo?

Você pode recusar seus próprios extras gratuitos, e é aí que as marcações de dispositivo compensam. Um bloqueio total é mais arriscado. Quem está com o celular hoje pode não ser quem abusou dele, e os próprios termos do Google limitam o device recall à prevenção de abuso, não ao rastreamento de pessoas. Restrinja o que custa dinheiro e mantenha o caminho pago aberto.

E o Keychain (Chaves) ou um identificador de dispositivo?

Desenvolvedores costumam perguntar se uma marcação no Keychain ou um ID de hardware fariam o mesmo trabalho. Uma marcação que o seu app guarda no celular some após a redefinição do dispositivo, e a Apple não fornece aos apps um identificador de hardware estável para isso. DeviceCheck e device recall são as respostas aprovadas pelas lojas, justamente porque os bits ficam nos servidores da Apple e do Google, e não no celular.

Onde a loja ainda decide

Marcações de dispositivo mudam o que o seu app oferece de graça daqui para frente. Elas não afetam o reembolso que está diante de você. Apenas dois fluxos de reembolso permitem enviar evidências antes da decisão da loja. A Apple envia um CONSUMPTION_REQUEST e pede dados de consumo em até 12 horas. O Google Play abre uma revisão de chargeback que você responde em até 24 horas via orders.reviewrefund. Todo o resto, dos reembolsos de 48 horas do Google Play aos reembolsos pelo suporte e aos reembolsos automáticos de compras não confirmadas, é decidido sem você. Chargebacks são definitivos depois que o banco decide.

O RefundHalt responde a cada CONSUMPTION_REQUEST e a cada revisão de chargeback do Google Play dentro do prazo, com seus dados reais de uso, e vincula cada reembolso à conta que o fez, para que o seu servidor saiba qual dispositivo marcar na próxima vez que ele se conectar.