Os motivos de cancelamento de assinatura costumam chegar antes do pedido de reembolso, e o Google Play entrega muito mais deles que a Apple

A maioria dos assinantes que acabam reembolsados cancela antes. Esse cancelamento vem com um motivo, e as duas lojas entregam quantidades bem diferentes dessa informação. O Google Play faz uma pesquisa rápida e repassa a resposta ao seu servidor, inclusive com texto livre. A Apple envia um código numérico que diz como a assinatura terminou, não por que o cliente quis sair. Leia os dois direito e você verá os pedidos de reembolso chegando enquanto ainda dá para fazer alguma coisa.

O que o Google Play informa sobre motivos de cancelamento

Quando um usuário cancela na central de assinaturas do Play, o Google pergunta o motivo. A resposta aparece no recurso de assinatura que você obtém com purchases.subscriptionsv2.get, dentro de canceledStateContext. Esse objeto só existe enquanto a assinatura está cancelada ou expirada, e diz quem encerrou a assinatura: o usuário, o sistema do Google, você ou uma substituição, como uma troca de plano.

Quando foi o usuário, o objeto userInitiatedCancellation tem dois campos. cancelTime diz quando ele cancelou. cancelSurveyResult guarda a resposta da pesquisa.

A coluna da direita é a nossa leitura, não a do Google. As duas primeiras colunas vêm direto da referência da API.

A notificação não traz o motivo

Uma assinatura cancelada dispara uma notificação do desenvolvedor em tempo real SUBSCRIPTION_CANCELED, type 3. O Google deixa claro que essas notificações só avisam que o estado da compra mudou. O payload traz um token de compra e nada mais útil, então seu handler precisa chamar purchases.subscriptionsv2.get para ler a resposta da pesquisa.

A visão do Play Console

Você não precisa de código para ver os totais. Os relatórios de assinaturas do Play Console incluem um card de cancelamentos que divide o churn em voluntário, involuntário e outro, e um card de respostas da pesquisa de cancelamento para os usuários que escolheram responder. As respostas em texto livre de quem escolheu outro podem ser baixadas como CSV no card de outras respostas. Esse download exige a permissão View financial data, a mesma que você daria a uma ferramenta que lê seus pedidos.

O que a Apple informa, e o que ela deixa de fora

A Apple não tem nenhuma pesquisa de cancelamento que chegue aos desenvolvedores. O campo mais próximo é expirationIntent, nas informações de renovação assinadas, e ele descreve como a assinatura terminou, não o que o cliente pensou.

O código 1 é o único que descreve uma escolha do cliente, e ele não diz nada sobre a motivação. Um cliente que saiu porque o app vivia travando e outro que simplesmente terminou um projeto parecem idênticos.

O sinal escondido em AUTO_RENEW_DISABLED

Uma notificação da Apple merece atenção especial. DID_CHANGE_RENEWAL_STATUS com o subtipo AUTO_RENEW_DISABLED normalmente significa que o cliente desativou a renovação automática. A documentação da Apple acrescenta um segundo caso: a App Store também desativa a renovação automática depois que o cliente pede reembolso.

Então, no iOS, um evento de renovação desativada pode ser o primeiro sinal de um pedido de reembolso. Se a compra for um consumível ou uma assinatura com renovação automática, um CONSUMPTION_REQUEST pode vir em seguida, e a partir daí você tem 12 horas para enviar os dados de consumo. Um evento de renovação desativada que chega sem nenhuma ação visível no seu app merece ser tratado como um aviso para deixar prontos os dados de uso daquela conta.

Apple e Google lado a lado

Onde um cancelamento vira reembolso

Um cancelamento interrompe a próxima cobrança. Ele não devolve a última. Se o dinheiro volta ou não depende de qual fluxo de reembolso o cliente alcança em seguida, e a maioria desses fluxos funciona sem você.

• No Google Play, o comprador pode conseguir sozinho um reembolso em até 48 horas após a compra, e quem decide é o Google.
• Reembolsos pelo suporte do Google ou da Apple são decididos pela loja.
• O CONSUMPTION_REQUEST da Apple pede seus dados de consumo, com prazo de 12 horas.
• A análise de chargeback do Google Play pede evidências via orders.reviewrefund, com prazo de 24 horas. A decisão do banco sobre um chargeback é definitiva.

Um motivo de cancelamento não muda nenhuma dessas regras. O que ele muda é quão cedo você sabe qual cliente está insatisfeito, e se suas evidências estão prontas quando chega um dos dois fluxos que as pedem.

Quanto cada motivo custa para você

A resposta da pesquisa também é um guia aproximado de quanto a conta já custou para ser atendida, que é o dinheiro que fica na sua mão quando há um reembolso.

Problemas técnicos

Este é o caro. O cliente usou o produto o bastante para encontrar problemas, então você já pagou a computação das sessões dele, as chamadas à API do modelo que as solicitações dele geraram, o armazenamento do que ele criou e qualquer repasse devido a um criador cujo conteúdo ele usou. Se depois ele conseguir um reembolso, o preço volta e esses custos ficam com você. Se ele recorrer ao banco no Google Play, um pedido feito depois de August 3, 2026 custa a você o preço da compra menos a taxa de serviço do Play, mais as tarifas do banco.

Questões de preço

Uma reclamação de preço custa menos do que parece, a não ser que esconda uma renovação inesperada. Essa é a história clássica de chargeback, então verifique se o cancelamento veio logo depois de uma cobrança de renovação e se seus lembretes de renovação foram enviados.

Pouco uso

Pouco uso significa custo baixo de atendimento, então um reembolso aqui devolve principalmente dinheiro que não custou muito para ganhar. É também o motivo em que dados de consumo honestos, se a Apple pedir, mostram exatamente o que o cliente usou e o que não usou.

Encontrou um app melhor

Esses clientes raramente contestam alguma coisa. Eles foram para um concorrente. O motivo é útil para decisões de produto e quase nunca para a defesa contra reembolsos.

Uma rotina para ler motivos de cancelamento

• A cada SUBSCRIPTION_CANCELED do Google Play, chame purchases.subscriptionsv2.get e salve canceledStateContext com o token de compra e cancelTime.
• Salve reasonUserInput literalmente quando o motivo for outro. É o único texto livre que qualquer uma das lojas entrega.
• A cada DID_CHANGE_RENEWAL_STATUS da Apple com AUTO_RENEW_DISABLED, registre o evento e puxe o uso daquela conta, caso venha um CONSUMPTION_REQUEST.
• A cada notificação EXPIRED da Apple, registre o subtipo e expirationIntent para que churn voluntário e falhas de cobrança não se misturem.
• Para cancelamentos do Google Play por problemas técnicos, confira seus logs de erro daquela conta e entre em contato antes que o cliente procure o banco.
• Mantenha logs de uso por conta, para que um CONSUMPTION_REQUEST seja respondido em menos de 12 horas e uma análise de chargeback em menos de 24.