A Apple pode reverter um reembolso que já concedeu, e um reembolso revertido que seu servidor ignora bloqueia um cliente que pagou

Um reembolso nem sempre é a palavra final. A App Store pode reverter um reembolso que já concedeu, depois de o cliente contestá-lo, e quando esse reembolso revertido chega ao seu servidor ele traz uma instrução: devolva o acesso. A maioria das equipes conecta a notificação REFUND simples, corta o cliente e para por aí. Nunca constroem a outra metade. Então, quando a reversão chega, nada roda, e um cliente que está pagando de novo fica bloqueado, sem o que comprou. Veja como funciona o conjunto completo de notificações de reembolso na App Store e no Google Play, e quanto cada uma custa quando você a ignora.

A App Store envia três notificações de reembolso, não uma

A maior parte do tratamento de reembolso é construída para um único evento: o dinheiro voltou, corte o cliente. O feed do App Store Server Notifications V2 na verdade carrega três resultados de reembolso distintos, e eles pedem três coisas diferentes. Dois deles mudam o que um cliente pode acessar. Um deles desfaz o primeiro. Aqui está o conjunto completo, nas próprias palavras da Apple.

REFUND, a que toda equipe trata

Quando a App Store processa um reembolso, ela envia uma notificação REFUND para a URL que você configura, e a definição da Apple é clara: ela 'indica que a App Store reembolsou com sucesso uma transação de um In-App Purchase consumível, um In-App Purchase não consumível, uma assinatura de renovação automática ou uma assinatura sem renovação.' Você armazena a transação reembolsada, revoga o que quer que ela tenha comprado, e a Apple pede que você diga ao cliente o que mudou com mensagens contextuais no app. Esta é a notificação que todos conectam primeiro, e muitas vezes a única.

REFUND_DECLINED, a que não precisa de nada de você

REFUND_DECLINED significa exatamente o que diz: 'a App Store recusou um pedido de reembolso.' O cliente pediu, a Apple disse não, e a transação permanece. Nada sobre o acesso do cliente muda, então sua lógica de direitos de acesso não faz nada aqui. O valor desta notificação é de registro. Ela fecha o ciclo de um pedido de reembolso que você talvez tenha respondido com um CONSUMPTION_REQUEST, e confirma que o cliente ainda tem o que pagou. Trate-a como um registro, não como uma ação.

REFUND_REVERSED, a que pega as equipes de surpresa

Esta é a notificação que a maioria dos pipelines de reembolso nunca trata. A definição da Apple é inequívoca: REFUND_REVERSED 'indica que a App Store reverteu um reembolso concedido anteriormente devido a uma contestação levantada pelo cliente. Se o seu app revogou conteúdo ou serviços como resultado do reembolso relacionado, é preciso restaurá-los.' Leia isso duas vezes. A Apple deu um reembolso ao cliente, você revogou o acesso, então a Apple decidiu que o reembolso não deveria valer e o retirou. A cobrança está ativa de novo. O cliente pagou, e se o seu servidor só sabe revogar, ele continua bloqueado. Um reembolso revertido é o único evento de reembolso que devolve acesso, e é aquele para o qual quase ninguém constrói.

Quanto um reembolso revertido realmente custa a você

Uma reversão perdida não é um erro de arredondamento. Percorra o dinheiro nas duas direções, porque errar qualquer uma das metades tem um preço.

Perca a reversão e você mantém um cliente pagante bloqueado. A Apple restabeleceu a cobrança, então o cliente está sem o dinheiro de novo, e seu app está negando a ele o que comprou. O custo imediato é tempo de suporte e um reembolso de boa vontade que talvez você mesmo emita agora, desta vez sem comissão da loja voltando para amenizar. O custo mais lento é a avaliação e o churn, e no Google Play essa mesma frustração de bloqueio é exatamente o que vira um chargeback.

Perca o reembolso original e você continua atendendo um cliente que não pagou nada. O erro espelhado é nunca revogar. Um cliente reembolsado que ainda gera imagens, chama suas APIs e enche seu armazenamento acumula custo real contra uma venda que foi revertida. A computação, as chamadas de terceiros e o armazenamento são dinheiro que você já gastou, e nada disso volta com o reembolso.

• Custo de suporte: uma pessoa respondendo a um chamado por um acesso que o seu próprio código removeu e nunca restaurou.
• Reembolsos de boa vontade: devolver dinheiro a um cliente que você bloqueou por engano, sem comissão da loja retornada em um gesto manual.
• Gasto desperdiçado: computação, chamadas de API e armazenamento consumidos por uma conta reembolsada que você nunca cortou.
• Risco de chargeback: no Google Play, um cliente que se sente cobrado em dobro pode contestar, e uma contestação perdida agora recai sobre você.

O reembolso revertido e o reembolso simples são o mesmo feed de webhook apontando em direções opostas. Trate um e pule o outro e você paga nas duas pontas.

Por que a Apple reverte um reembolso, e como ler o revocationReason

Uma reversão não é aleatória. A Apple a vincula a 'uma contestação levantada pelo cliente,' que é o cliente questionando a decisão de reembolso depois do fato. Quando o reembolso foi concedido pela primeira vez, a transação trazia um revocationDate e um revocationReason, e vale a pena ler esse motivo antes que qualquer coisa a jusante aja sobre ele.

• revocationReason 1: a App Store reembolsou 'devido a um problema real ou percebido dentro do seu app.' Isso é um sinal sobre o seu produto, não apenas sobre este cliente.
• revocationReason 0: a App Store reembolsou 'por outros motivos, por exemplo, uma compra acidental.' Sem nenhum sinal de qualidade do app associado.

Quando um REFUND_REVERSED chega para aquela transação, a revogação está sendo desfeita. Sua lógica de restauração deve buscar o id da transação original, confirmar que você a revogou, e recolocar o direito de acesso exatamente como estava.

O Google Play não envia uma reversão, então você reconcilia em vez disso

O modelo do Google Play é diferente, e a diferença importa se você roda as duas lojas por um único handler de webhook. Não há equivalente do Google para o REFUND_REVERSED. As notificações em tempo real para desenvolvedores do Google dividem os eventos de reembolso em duas mensagens, e as reversões são tratadas por reconciliação, não por um push.

A notificação de compra anulada

Quando uma compra do Google Play é anulada, seu servidor recebe uma VoidedPurchaseNotification. Ela nomeia o purchaseToken e o orderId, um productType de subscription ou one-time, e um refundType que é uma anulação completa ou um reembolso parcial baseado em quantidade em compras de múltiplas quantidades. O Google diz que esses dados bastam para encontrar a compra certa e ajustar o direito de acesso. Para qualquer coisa a mais, ele te aponta para a Voided Purchases API, um modelo pull que lista os pedidos anulados dentro de um intervalo de timestamp que você consulta.

A revisão de chargeback, e seu relógio de 24 horas

Os chargebacks chegam por uma mensagem diferente, a PendingRefundReviewNotification. Quando um cliente contesta uma cobrança com o banco, o Google Play envia esta notificação e inicia um relógio. Você tem 24 horas para chamar orders.reviewrefund com uma preferência de reembolso e qualquer evidência de uso, para que o Google possa contestar um chargeback ilegítimo em seu nome. O Google registra a sua primeira chamada e ignora as demais. Este é o paralelo do Google ao CONSUMPTION_REQUEST da Apple, a única janela em que o seu lado de uma contestação conta.

Como não há push de reversão, um chargeback que o Google contesta e vence não chega como um evento de restauração organizado. Você o reconcilia contra a Voided Purchases API e seus próprios registros. A lição é a mesma da App Store: um pedido anulado nem sempre é permanente, e o estado dos seus direitos de acesso precisa poder voltar, não só avançar.

Como tratar cada notificação de reembolso sem bloquear ninguém

Você não precisa de pipelines separados por loja. Você precisa de um handler que consiga mover um direito de acesso nas duas direções e trate cada mensagem como possivelmente duplicada.

• Construa a restauração, não só a revogação. Para cada caminho que remove acesso em um REFUND, escreva o inverso que o restaura em um REFUND_REVERSED, vinculado ao mesmo id de transação.
• Torne-o idempotente. As duas lojas podem entregar a mesma notificação mais de uma vez, então vincule cada revogação e restauração ao id da transação ou do pedido e faça de uma repetição um no-op.
• Leia o motivo antes de agir. Use o revocationReason para distinguir um reembolso de qualidade do app de um acidental, e encaminhe os de qualidade do app para quem é dono da qualidade do produto.
• Responda às janelas de evidência no prazo. Envie os dados de consumo da Apple dentro de 12 horas de um CONSUMPTION_REQUEST, e chame orders.reviewrefund dentro de 24 horas de uma PendingRefundReviewNotification.
• Armazene cada evento. Guarde o REFUND_DECLINED e as notificações brutas, para que uma reversão que chegue depois possa ser associada ao reembolso que ela desfaz.

Nada disso muda se um reembolso acontece. Muda se o cliente do outro lado de um reembolso revertido chega a notar que o seu servidor errou.