Como reduzir o churn involuntário na App Store: billing retry e período de carência

Na App Store, é a Apple que cobra o cliente, é a Apple que faz as novas tentativas de pagamento e é a Apple que controla o botão de cancelar. Não pode repetir uma cobrança, mudar o cartão de um cliente nem ver o seu endereço de email. Isso não significa que não possa fazer nada: o que controla é durante quanto tempo o cliente mantém o acesso, o que a sua app lhe diz e como reage a cada notificação.

Este guia cobre o billing retry, o Billing Grace Period, as App Store Server Notifications V2 que lhe dizem o que aconteceu, o que a sua app pode fazer, as ofertas de reconquista (win-back offers) e os pedidos de reembolso. Baseia-se na documentação da Apple: Reducing involuntary subscriber churn, Enable Billing Grace Period, a referência de notificationType, a mensagem billingIssue, Supporting win-back offers in your app e Send Consumption Information (todos consultados em novembro de 2026).

O que a Apple faz quando uma renovação falha

Quando uma renovação falha por um problema de faturação, a subscrição entra no estado de billing retry. A documentação da Apple diz que a App Store tenta então cobrar o pagamento durante até 60 dias.

• Se a Apple recuperar o pagamento durante o billing retry, a subscrição renova. Sem período de carência, a nova data de faturação passa a ser a data da recuperação, por isso as renovações seguintes mudam de data.
• Se o período de billing retry terminar sem sucesso, a subscrição expira.

Não escolhe o calendário das novas tentativas e não pode desencadear uma nova tentativa. A Apple diz, no entanto, que quando o cliente atualiza os dados de pagamento, a App Store tenta renovar de imediato. Por isso, o mais útil que pode fazer é levar o cliente a corrigir o método de pagamento.

Billing Grace Period

Por predefinição, um cliente em billing retry perde o acesso. O Billing Grace Period permite-lhe manter acesso total durante algum tempo enquanto a Apple tenta cobrar. Ativa-se no App Store Connect, na secção Subscriptions da sua app. Segundo a página de ajuda da Apple:

Período de carência escolhido	Subscrições semanais	Subscrições mensais e anuais
3 dias	3 dias	3 dias
16 dias	6 dias	16 dias
28 dias	6 dias	28 dias

Outros pontos da mesma página:

• A definição aplica-se a todas as subscrições com renovação automática da app; não pode ser definida por produto.
• Escolhe se se aplica a todas as renovações (incluindo testes gratuitos e ofertas gratuitas que passam a pagas) ou apenas a renovações de pago para pago.
• Pode ativá-la primeiro só em sandbox e depois em produção.
• As alterações podem demorar até 24 horas e aplicam-se apenas às renovações seguintes.
• Não se aplica a subscrições mensais com compromisso de 12 meses.
• A sua app tem de continuar a verificar o estado da renovação e dar o serviço completo durante o período de carência.

A diferença conta para a receita: se a Apple recuperar o pagamento dentro do período de carência, os dias de serviço pago do cliente e a sua receita não são interrompidos, e a subscrição mantém a data de faturação original. Uma recuperação depois do período de carência, mas ainda dentro do billing retry, renova na data da recuperação.

As notificações a tratar

As App Store Server Notifications V2 informam o seu servidor de cada etapa. A referência de notificationType lista estes eventos de faturação:

Evento	notificationType	subtype
A renovação falha, a subscrição entra em billing retry	DID_FAIL_TO_RENEW	nenhum
A renovação falha, billing retry com Billing Grace Period	DID_FAIL_TO_RENEW	GRACE_PERIOD
A subscrição sai do período de carência (o billing retry continua)	GRACE_PERIOD_EXPIRED	nenhum
O billing retry recupera a subscrição	DID_RENEW	BILLING_RECOVERY
O billing retry termina sem recuperação	EXPIRED	BILLING_RETRY
O cliente desativa a renovação automática	DID_CHANGE_RENEWAL_STATUS	AUTO_RENEW_DISABLED
O cliente volta a ativar a renovação automática	DID_CHANGE_RENEWAL_STATUS	AUTO_RENEW_ENABLED
A subscrição expira depois de o cliente ter cancelado	EXPIRED	VOLUNTARY

Note que GRACE_PERIOD_EXPIRED não significa que o cliente se foi embora. A Apple continua a tentar; apenas deixa de dar acesso.

Também pode pedir o estado atual com o endpoint Get All Subscription Statuses da App Store Server API. O seu campo status vale 1 (ativa), 2 (expirada), 3 (billing retry), 4 (Billing Grace Period) ou 5 (revogada). A informação de renovação inclui também isInBillingRetryPeriod, gracePeriodExpiresDate e um expirationIntent, em que 2 significa um erro de faturação e 1 significa que o cliente cancelou.

Trate AUTO_RENEW_DISABLED como um aviso precoce

DID_CHANGE_RENEWAL_STATUS com AUTO_RENEW_DISABLED é o mais próximo de um cancelamento na App Store: o cliente mantém o acesso até ao fim do período, mas não vai renovar. Não é uma falha de pagamento, mas é o melhor momento para uma mensagem de retenção, porque a subscrição ainda está ativa.

O que a sua app pode fazer

A Apple é explícita quanto às ferramentas que tem.

1. Deixe o StoreKit mostrar a mensagem de faturação. Quando uma subscrição está em billing retry, a App Store envia uma mensagem billingIssue. O StoreKit mostra uma folha Billing Problem quando a sua app arranca (ou quando o pede), e o cliente pode corrigir o método de pagamento sem sair da sua app. A Apple documenta a frequência: a cada 24 horas nos dias 1 a 3, a cada 72 horas nos dias 4 a 16, a cada 96 horas nos dias 17 a 30 e a cada 120 horas nos dias 31 a 60. Pode atrasá-la ou suprimi-la, mas se não tiver uma mensagem melhor, deixe-a aparecer.
2. Mostre a sua própria mensagem na app. O guia da Apple sobre churn involuntário diz que a sua app pode dizer aos utilizadores que podem evitar perder o acesso resolvendo o erro de faturação, e pode ter um deep link para a página Manage Payments da conta deles. Verifique primeiro o expirationIntent, para não mostrar uma mensagem de faturação a quem cancelou.
3. Coloque um link para a gestão de subscrições. showManageSubscriptions(in:) (ou manageSubscriptionsSheet em SwiftUI) abre a mesma folha que as Definições, onde o cliente pode ver, alterar ou cancelar a subscrição.
4. Contacte o cliente pelos seus próprios canais. Se o cliente tem conta consigo e lhe deu um email, pode enviar-lhe um email. A Apple não partilha o email do cliente, por isso tem de associar a transação da App Store ao seu próprio utilizador, por exemplo com um appAccountToken definido na compra.
5. Restaure o acesso depressa. Depois de uma recuperação, o StoreKit adiciona a transação de renovação à fila. A Apple nota que, se a sua app já estiver a correr, o observer pode não ser chamado e a app só fica a saber no arranque seguinte. Normalmente, o seu servidor sabe primeiro, pelo DID_RENEW.

O que não pode fazer: repetir a cobrança, mudar o método de pagamento por si, prolongar o billing retry ou remover a opção de cancelamento da própria Apple.

Ofertas de reconquista

Quando uma subscrição já terminou (data de expiração no passado e renovação automática desativada), a Apple permite-lhe propor uma win-back offer: um período gratuito ou com desconto para antigos subscritores elegíveis. Segundo o guia da Apple:

• Configura as ofertas e as regras de elegibilidade no App Store Connect: duração da subscrição paga, tempo desde a expiração e tempo entre ofertas resgatadas.
• Os clientes podem encontrá-las na App Store, nas definições de subscrição da sua conta e na sua app, onde o StoreKit pode mostrar por predefinição uma folha com a oferta de reconquista.
• O App Store Connect dá a cada oferta um link direto que pode enviar pelos seus próprios canais, como o email. Antes de o enviar, chame Get All Subscription Statuses e verifique o array eligibleWinBackOfferIds, e envie o link apenas a clientes elegíveis.
• Um resgate depois da expiração gera SUBSCRIBED com o subtype RESUBSCRIBE; as transações resgatadas com uma win-back offer têm offerType 4.

Para subscritores ativos, as ferramentas equivalentes são as promotional offers e os offer codes da Apple (o resgate envia OFFER_REDEEMED).

Pedidos de reembolso e CONSUMPTION_REQUEST

Os clientes pedem reembolsos à Apple, não a si, e é a Apple que decide. Quando um cliente pede um reembolso, a App Store envia uma notificação CONSUMPTION_REQUEST. Se o cliente consentiu partilhar os seus dados com a Apple, pode responder com o endpoint Send Consumption Information no prazo de 12 horas. A Apple diz que usa esta informação para fundamentar as suas decisões de reembolso. É responsável por obter um consentimento válido, e a Apple diz para não usar o pedido de App Tracking Transparency para isso. Se não tiver consentimento, não responda.

Quando a Apple reembolsa, recebe REFUND; quando recusa um reembolso pedido através da sua app, REFUND_DECLINED; e se um reembolso for revertido, REFUND_REVERSED.

Uma checklist

• As App Store Server Notifications V2 estão ativas e o seu servidor trata os eventos de faturação acima.
• O Billing Grace Period está ativado, testado em sandbox e depois ativado em produção.
• A sua app dá acesso durante o período de carência e retira-o com GRACE_PERIOD_EXPIRED.
• A mensagem de faturação do StoreKit pode aparecer, ou é substituída pela sua.
• O seu ecrã de definições tem um link para a gestão de subscrições.
• Cada compra leva um appAccountToken, para que possa contactar o cliente.
• As win-back offers estão configuradas e são enviadas apenas a clientes elegíveis.
• Os pedidos de consumo são respondidos em 12 horas quando o cliente consentiu.

Fazer isto com o NoChurn

A Apple fica com os pagamentos, as novas tentativas, o período de carência e o botão de cancelar; o NoChurn não muda isso. O NoChurn lê as suas App Store Server Notifications, associa cada subscrição ao seu utilizador através do appAccountToken e coloca problemas de faturação, alterações da renovação automática e reembolsos na cronologia do cliente e num score de churn de 0 a 100. Onde a Apple o permite, age: mensagens na sua app ou por email com link para as definições de subscrição da Apple, um fluxo de cancelamento que a sua app mostra através da API headless antes de remeter para a Apple, emails de reconquista aos 30, 60 e 90 dias consoante o motivo do cancelamento, e respostas aos pedidos de consumo a partir dos seus próprios dados de utilização. Veja NoChurn + App Store.