O tratamento de reembolsos falha de formas silenciosas, então teste os reembolsos de compras no aplicativo no sandbox antes que um cliente real faça isso

Seu tratamento de reembolsos é o único caminho de código que só é executado depois que o cliente já foi embora. Nada no seu QA normal o toca, porque para chegar a ele você tem que realmente ser reembolsado. Então ele vai para produção sem teste, fica em silêncio por meses e depois falha em um reembolso real, onde a falha custa dinheiro em vez de um teste em vermelho. A solução é parar de tratar um reembolso como algo que acontece com você e começar a disparar um de propósito. Tanto a Apple quanto o Google permitem disparar um reembolso em um ambiente de teste e observar seu servidor reagir. Veja como testar os reembolsos de compras no aplicativo na App Store e no Google Play antes que um cliente pagante prove que seu tratador estava quebrado.

Os três ambientes em que um reembolso pode disparar, e apenas um é produção

Há três lugares separados onde um reembolso da Apple ou do Google pode ser disparado enquanto você desenvolve, e eles não são intercambiáveis. Dois deles são seus para disparar quando quiser. O terceiro é produção, onde você nunca quer encontrar um erro de reembolso pela primeira vez. A armadilha é supor que o fácil, o teste local no Xcode, prova todo o seu pipeline. Ele prova o seu aplicativo. Não diz nada sobre o seu servidor.

O teste de StoreKit do Xcode é local, então ele exercita seu aplicativo e nada mais

O teste de StoreKit integrado do Xcode roda contra um arquivo de configuração no seu Mac, sem ida e volta à Apple. Abra o StoreKit Transaction Manager na barra de depuração, selecione uma transação comprada e clique na seta curva de reembolso. A transação muda para reembolsada e o listener Transaction.updates do seu aplicativo dispara, exatamente como faria no mundo real. Você também pode chamar beginRefundRequest para apresentar a folha de reembolso real, e no ambiente do Xcode o problema que você escolhe corresponde um para um a um RevocationReason, com o reembolso aplicado imediatamente. Esta é a forma mais rápida de provar que seu cliente corta o acesso no momento em que revocationDate deixa de ser nulo. É também tudo o que o teste local pode lhe dizer, porque nada aqui chega aos servidores da Apple, então nenhuma App Store Server Notification é enviada. Seu backend não fica sabendo de nada.

O sandbox é onde seu servidor finalmente fica sabendo de um reembolso

Para testar a metade da sua integração que decide dinheiro, o seu servidor, você precisa do sandbox da Apple. Configure uma URL de App Store Server Notifications V2 de sandbox no App Store Connect, faça login com um tester de sandbox em um dispositivo e compre. Agora um reembolso no sandbox entrega uma notificação REFUND real ao seu backend, e uma solicitação de reembolso em um consumível ou renovável automaticamente entrega um CONSUMPTION_REQUEST, o mesmo payload assinado que seu servidor de produção receberá. Antes de disparar qualquer coisa, chame o endpoint Request a Test Notification. Ele diz ao servidor da App Store para enviar uma notificação do tipo TEST para a URL que você configurou e lhe entrega um testNotificationToken, que você passa para Get Test Notification Status para confirmar a entrega. Se essa ida e volta não funcionar, nenhuma notificação real vai funcionar também.

Como testar os reembolsos de compras no aplicativo na App Store

Execute nesta ordem, da verificação barata do cliente até a ida e volta completa do servidor. Cada etapa exercita uma peça diferente, e as posteriores são as que a produção realmente cobra de você.

• Crie uma chave de In-App Purchase em Users and Access, Integrations, In-App Purchase no App Store Connect, e use-a para assinar suas chamadas à App Store Server API.
• Aponte sua URL de App Store Server Notifications V2 de sandbox para o seu backend, depois chame Request a Test Notification e confirme que o payload TEST chega e é verificado contra a cadeia de certificados da Apple.
• No Transaction Manager do Xcode, reembolse uma compra e confirme que seu aplicativo remove o direito no instante em que revocationDate é definido.
• Faça login com um tester de sandbox, compre um consumível, solicite um reembolso e confirme que seu servidor recebe o CONSUMPTION_REQUEST e consegue montar e enviar uma resposta Send Consumption Information bem dentro da janela de 12 horas.
• Reembolse uma compra de sandbox e confirme que a notificação REFUND chega ao seu servidor, que você revoga o acesso ou deduz o saldo do consumível, e que uma entrega repetida da mesma notificação não é aplicada duas vezes.

Como ensaiar um reembolso e um chargeback no Google Play

O Google Play não tem um modo local como o do Xcode. Tudo roda contra os servidores do Google, mas os license testers o mantêm gratuito e seguro. Adicione suas contas Google de teste como license testers no Play Console e elas recebem um conjunto de métodos de pagamento de teste que nunca cobram dinheiro de verdade. O Google marca cada compra de teste com um aviso no meio da caixa de diálogo de compra, e os impostos não são calculados. O que importa para testar reembolsos é qual instrumento de teste você escolhe, porque cada um leva a um resultado diferente.

Dispare um reembolso, um chargeback e o reembolso automático por falta de confirmação

• Compre com o cartão de teste approve-then-charge-back, e uma PendingRefundReviewNotification chega ao seu tópico de Real-time Developer Notifications momentos depois. Responda a ela com uma única chamada orders.reviewrefund, porque o Google mantém apenas a sua primeira resposta.
• Reembolse e revogue um pedido de teste na aba Orders no Play Console para disparar uma VoidedPurchaseNotification, e confirme que seu servidor remove o direito.
• Deixe de propósito a compra de um license tester sem confirmação. O Google a reembolsa automaticamente após 3 minutos em vez dos 3 dias que a produção permite, e envia a você por e-mail o cancelamento, então um caminho de confirmação quebrado aparece em minutos, não no quarto dia em produção.

O que uma rota de reembolso não testada realmente custa

Um tratador de reembolsos não é decoração. É o código que impede você de pagar para atender alguém que não paga mais você. Quando ele falha em silêncio, o reembolso ainda acontece, mas o acesso, o saldo e o gasto por trás deles não param.

Siga o dinheiro. Quando a Apple ou o Google reembolsa uma compra, você devolve o preço de venda e a loja devolve a comissão dela, até aqui o balanço fica equilibrado. O que não volta é tudo o que você já gastou entregando o produto: o processamento por trás de um resultado gerado, as chamadas à API do modelo, o armazenamento do que o usuário salvou, o pagamento que você já enviou a um criador. Um tratador de reembolsos que nunca revoga o acesso deixa um usuário reembolsado continuar gastando isso à custa do seu orçamento, sem nada no sistema para detê-lo.

As duas janelas de evidência tornam isso mais nítido. Um CONSUMPTION_REQUEST que você nunca exercitou no sandbox é uma resposta que você envia malformada ou atrasada, e a Apple muitas vezes concede o reembolso por padrão quando sua resposta não chega dentro de 12 horas. Uma resposta a um chargeback do Google Play que você nunca disparou com o cartão de teste é uma janela de 24 horas que você erra ao vivo, e a partir de 3 de agosto de 2026 um chargeback perdido no Play custa a você o preço da compra menos a taxa de serviço do Play mais a taxa de chargeback do banco. Cada uma dessas falhas é reproduzível de graça em um ambiente de teste primeiro. Nenhuma delas é barata em produção.

Uma lista curta antes de lançar o tratamento de reembolsos

Você não precisa de um laboratório. Você precisa ter visto cada evento chegar ao seu código uma vez.

• Seu aplicativo remove o acesso no momento em que uma transação do StoreKit mostra um revocationDate, confirmado no Transaction Manager do Xcode.
• A URL do seu servidor de sandbox recebe uma notificação TEST e a verifica contra os certificados da Apple.
• Um REFUND de sandbox revoga o acesso ou deduz o saldo, e uma entrega repetida não conta duas vezes.
• Um CONSUMPTION_REQUEST de sandbox produz uma resposta Send Consumption Information válida bem dentro de 12 horas.
• Uma PendingRefundReviewNotification do Google a partir do cartão de teste de chargeback produz exatamente uma chamada orders.reviewrefund.
• Uma compra de teste do Google Play não confirmada é reembolsada automaticamente em 3 minutos e sua reconciliação percebe.

Execute essa lista uma vez e o tratamento de reembolsos deixa de ser o código que você torce para funcionar. Ele se torna o código que você viu funcionar.