Revogar Acesso Após um Reembolso: A Etapa que Apple e Google Não Fazem por Você

Aprovar um reembolso e remover o acesso são duas etapas separadas, e apenas uma delas acontece automaticamente. Desenvolvedores que presumem que um reembolso processado equivale a uma compra revogada estão errados nas duas principais lojas, de formas diferentes e por motivos diferentes. Saber exatamente onde a automação para é o que é preciso para revogar o acesso após um reembolso, em vez de descobrir meses depois que isso nunca aconteceu.

Por que um reembolso não revoga o acesso por padrão

Apple e Google tratam o dinheiro e o acesso como duas operações diferentes. O lado financeiro é política da loja: uma vez aprovado o reembolso, ele é final e o registro é atualizado. O lado do acesso é opcional, ou é trabalho do desenvolvedor, ou ambos, dependendo da plataforma e do tipo de compra. Nenhuma das lojas presume que você quer o acesso removido no instante em que o reembolso é concluído, porque muitos casos legítimos (um reembolso parcial, um crédito de cortesia, um gesto de suporte) não devem retirar o produto de forma alguma.

Google Play: a caixa de seleção que ninguém percebe

No Play Console, reembolsar um pedido é um formulário em duas partes: escolher o valor do reembolso e depois decidir separadamente se marca "Remove entitlement". Deixar essa opção desmarcada é o caminho padrão que a maioria dos agentes de suporte segue, porque a maior parte dos pedidos de reembolso são gestos de boa vontade em que o cliente mantém o que comprou. O problema é que nada na tela de confirmação do reembolso avisa que é assim também que um cliente mantém uma assinatura ou item dentro do aplicativo depois de um reembolso que você pretendia ser definitivo.

O caminho da API tem a mesma armadilha

A mesma escolha existe no código. O endpoint orders.refund aceita um parâmetro de consulta opcional chamado revoke; quando é true, o acesso ao item é encerrado imediatamente, e no caso de uma assinatura recorrente todo pagamento futuro é cancelado junto. Omitir o parâmetro faz com que ele assuma false por padrão: o reembolso é registrado, o registro da compra é atualizado, e o usuário continua usando o produto exatamente como antes.

Essa última linha é a que pega as integrações de surpresa. A Voided Purchases API existe para permitir que você construa um pipeline de revogação sem verificar o Play Console manualmente, mas ela só lista pedidos que foram efetivamente anulados com revogação. Um reembolso processado sem a caixa marcada, ou sem revoke=true, é invisível para esse feed por design, não por falha.

Lendo o campo voidedReason Quando uma compra aparece como anulada, o campo voidedReason informa o motivo, em uma escala de nove valores: other, remorse, not_received, defective, accidental_purchase, fraud, friendly_fraud, chargeback e unacknowledged_purchase. Isso não é apenas controle contábil. Remorse e accidental_purchase são reembolsos comuns. Fraud, friendly_fraud e chargeback são os que valem a pena encaminhar para uma fila de análise de fraude, em vez de um simples caminho de revogar e esquecer, porque a mesma conta tem estatisticamente mais chance de repetir o comportamento.

Um detalhe operacional importa se você construir integrações diretamente sobre esse feed: purchases.voidedpurchases.list tem um limite de 6.000 consultas por dia e 30 consultas em qualquer janela de 30 segundos. Um design que faz polling em loop apertado atinge esse limite rapidamente; o padrão pretendido é uma busca agendada com tokens de paginação, não polling contínuo.

Apple: a App Store pode revogar uma licença, mas não um item consumível

As App Store Server Notifications V2 da Apple enviam uma notificação REFUND no momento em que um reembolso é concluído, tanto para consumíveis quanto para não consumíveis, assinaturas de renovação automática e assinaturas sem renovação. O que acontece depois dessa notificação depende inteiramente do tipo de compra, porque o próprio mecanismo de revogação do StoreKit cobre apenas dois dos quatro tipos.

Por que os itens consumíveis são a exceção

Um item não consumível ou uma assinatura tem um direito permanente que os sistemas da Apple conseguem desativar. Um item consumível não: uma vez utilizado, é considerado entregue, e não sobra nada no StoreKit para revogar. Se um cliente comprou 500 moedas, gastou-as e recebeu um reembolso, as moedas já se foram do ponto de vista da Apple. O único registro que ainda as tem é o seu. A notificação REFUND é o seu único sinal para encontrar o ID da transação original correspondente e deduzir esse saldo dos seus próprios registros; nada do lado da Apple vai fazer isso por você.

A notificação que quase ninguém trata

REFUND_REVERSED é a que a maioria das integrações ignora completamente, porque descreve a Apple desfazendo sua própria decisão, um caso para o qual poucos desenvolvedores planejam na primeira tentativa. Quando ela chega, revocationDate na transação volta para null: no que diz respeito à Apple, a compra é válida novamente. Se o seu servidor apagou um direito de acesso, cancelou o registro de uma assinatura ou zerou um saldo consumível quando o REFUND original chegou, REFUND_REVERSED é o sinal para desfazer tudo isso.

Como fechar essa lacuna, passo a passo

• No Google Play, configure todo caminho de reembolso para usar revoke=true por padrão, seja pelo Play Console ou pela API, a menos que um caso específico de suporte exija que o cliente mantenha o acesso.
• Faça polling em purchases.voidedpurchases.list em um cronograma com tokens de paginação, não em loop apertado, e fique abaixo de 6.000 requisições por dia e 30 a cada 30 segundos.
• Encaminhe valores de voidedReason como fraud, friendly_fraud e chargeback para uma fila de análise, em vez de um revoke-and-close automático.
• Na Apple, inscreva-se nas App Store Server Notifications V2 e revogue o acesso de itens não consumíveis e assinaturas no momento em que uma notificação REFUND os mencionar.
• Armazene o ID da transação original para cada compra consumível, para que uma notificação REFUND consiga encontrar o saldo exato a deduzir sem uma busca manual.
• Trate REFUND_REVERSED explicitamente e registre cada revogação vinculada ao seu ID de transação ou pedido, para que uma reversão possa restaurar precisamente o que foi removido.

O que essa lacuna realmente custa

Nada disso tem a ver com justiça para o cliente; tem a ver com o que continua rodando depois que o dinheiro já se foi. Uma assinatura reembolsada que continua chamando sua API, armazenando dados e consumindo processamento não é um problema moral, é um item de custo: você está pagando a conta de infraestrutura por uma compra cuja receita você já devolveu. As lojas não rastreiam esse custo para você, porque do lado delas o reembolso está concluído no momento em que o dinheiro se move. O lado do acesso é inteiramente sua conta para controlar.

Esse é o mesmo motivo pelo qual a RefundHalt trata a revogação como parte do pipeline de reembolso, e não como uma reflexão tardia: um evento REFUND e uma mudança de acesso são registrados como uma única ação, e um evento REFUND_REVERSED restaura o estado automaticamente, em vez de esperar que alguém perceba que o cliente ainda está bloqueado de algo que a Apple já devolveu.