Apple e Google permitem estender a data de renovação de uma assinatura após uma queda, e os limites de cada um não têm nada a ver

Uma queda dá a cada assinante o argumento de reembolso mais limpo que existe, e você não consegue impedir que ele o use. O que você pode fazer é devolver os dias perdidos antes que alguém peça. As duas lojas de apps permitem estender a data de renovação de uma assinatura para que o cliente ganhe tempo grátis em vez de dinheiro. A Apple limita cada extensão a 90 dias e permite duas por ano. O Google deixa você adiar a cobrança em até um ano por chamada. A burocracia, as notificações e a conta por trás são diferentes o bastante para que um único plano para quedas não sirva para as duas.

O que uma queda faz com sua exposição a reembolsos

Quem decide os reembolsos são as lojas, não você. Na App Store, o cliente pede à Apple e a Apple decide. Você pode receber uma notificação CONSUMPTION_REQUEST e ter 12 horas para enviar dados de consumo via Send Consumption Information. Essa é toda a sua participação.

No Google Play, um comprador pode conseguir reembolso em até 48 horas após a compra sem que ninguém pergunte a você. Depois disso, os pedidos chegam até você. O único fluxo do Google que pede suas evidências é um chargeback marcado para revisão do desenvolvedor, que você responde via orders.reviewrefund em até 24 horas. A decisão do banco sobre um chargeback é definitiva.

Ou seja, nenhuma das lojas oferece um jeito de bloquear um reembolso. O que você controla é se o assinante continua se sentindo lesado quando o serviço volta. Tempo extra na assinatura, concedido rápido e anunciado com clareza, é a ferramenta que as duas lojas criaram exatamente para isso.

Como estender a data de renovação de uma assinatura na App Store

A App Store Server API tem dois endpoints para isso. Extend a Subscription Renewal Date atua sobre uma assinatura, que você identifica pelo originalTransactionId. Extend Subscription Renewal Dates for All Active Subscribers atua sobre todos os assinantes elegíveis de um productId, e você pode limitá-lo com storefrontCountryCodes quando a queda atingiu só algumas regiões.

Cada requisição leva três coisas: extendByDays, um número de 1 a 90; um extendReasonCode; e um requestIdentifier que você gera. O código de motivo 3 significa problema ou queda no serviço. O código 1 é satisfação do cliente, o código 2 é outros motivos e o código 0 é não declarado.

Quais assinaturas a Apple estende

Só se qualificam assinaturas autorrenováveis ativas com pelo menos um período pago anterior. A Apple ignora estas:

• Assinaturas em período de oferta gratuita, como um teste grátis.
• Assinaturas inativas em estado de nova tentativa de cobrança.
• Assinaturas em período de carência de cobrança cuja data de expiração já passou.
• Assinaturas que já receberam duas extensões da data de renovação nos últimos 365 dias.
• Assinaturas expiradas.

O Compartilhamento Familiar vem junto de graça. Quando a Apple estende uma assinatura comprada que suporta Compartilhamento Familiar, as assinaturas dos membros da família também são estendidas. Você não pode mirar diretamente a assinatura de um membro da família.

A requisição em massa é lenta, então fique de olho nas notificações

A Apple diz que uma requisição para estender todos os assinantes ativos pode levar horas, ou até dias, dependendo de quantos assinantes você tem. Uma resposta 200 só significa que a Apple está processando. As App Store Server Notifications V2 dizem como foi:

Para cada FAILURE, pegue o originalTransactionId da transação assinada no payload e tente de novo com o endpoint de assinatura individual. Se preferir consultar, Get Status of Subscription Renewal Date Extensions informa se a requisição foi concluída e quantas extensões deram certo ou falharam.

Como funciona o adiamento de cobrança do Google Play

A versão do Google é purchases.subscriptionsv2.defer, chamada uma vez por token de compra. O corpo da requisição traz um deferralContext com três campos. O etag vem de purchases.subscriptionsv2.get, e a chamada falha se ele não bater com o etag mais recente da assinatura. O deferDuration diz quanto empurrar a data. E validateOnly, quando true, executa a requisição como simulação sem mexer na assinatura.

O guia de faturamento do Google define o intervalo de um dia a um ano por chamada de API. Para ir além, chame de novo antes que a nova data de expiração chegue. Em uma assinatura com renovação automática, o adiamento move a próxima data de renovação. Em um plano pré-pago, move o horário de expiração. Em uma assinatura com complementos, todos os itens são adiados pela mesma duração. A resposta lista o novo expiryTime de cada item.

Durante o adiamento o usuário continua assinante com acesso total e não é cobrado pelo tempo extra. O Google envia uma notificação do desenvolvedor em tempo real SUBSCRIPTION_DEFERRED. O antigo purchases.subscriptions.defer está obsoleto, então código novo deve usar o método v2.

O Google não avisa seu cliente, então você precisa avisar

A Apple envia um e-mail ao cliente após cada extensão bem-sucedida. O guia de faturamento do Google não descreve nenhuma mensagem ao usuário. Se o objetivo é se antecipar aos pedidos de reembolso, o assinante precisa saber que esse tempo extra existe. Avise você mesmo, no app e por e-mail, dizendo quantos dias e por quê.

Apple e Google lado a lado

Quanto custa uma extensão em comparação com um reembolso

Um reembolso e uma extensão tiram dinheiro de lugares diferentes. Um reembolso devolve o que o cliente pagou pelo período. Tudo o que você já gastou para atender esse cliente continua gasto: computação de cada sessão, chamadas à API do modelo, armazenamento e qualquer repasse a um criador cujo conteúdo ele usou.

Uma extensão mantém o pagamento. O custo é o serviço que você entrega sem uma renovação para pagar por ele. A cada dia adicionado, um assinante ativo continua gerando as mesmas contas. Para um usuário leve, isso é quase nada. Para um usuário intenso de um recurso de IA, 30 dias extras podem significar 30 dias de chamadas ao modelo sem receita correspondente. Dimensione a extensão pela queda, não pelo pedido de desculpas que você gostaria de fazer.

O custo de comissão na Apple

A Apple paga 70% de cada renovação durante o primeiro ano de serviço pago de um assinante e 85% depois disso. A página de assinaturas da Apple diz que os dias de extensão de renovação são excluídos dos dias de serviço pago. Então uma extensão de 30 dias adia em 30 dias a passagem desse assinante para 85%. Se você está no App Store Small Business Program, já recebe 85% e esse custo não se aplica.

O custo de chargeback no Google Play

Para pedidos feitos após 3 de agosto de 2026, um chargeback que o titular do cartão ganha custa a um desenvolvedor do Google Play o preço da compra menos a taxa de serviço do Play, mais as tarifas do banco. Uma queda é exatamente o tipo de evento que leva um cliente irritado ao banco. Um adiamento que chega até ele antes sai mais barato que uma disputa que você não consegue reverter.

Quando uma extensão não é a ferramenta certa

A compra não era uma assinatura

Extensões da data de renovação só se aplicam a assinaturas. Se uma queda quebrou um consumível ou um desbloqueio único, entregue o item de novo. Se a Apple enviar um CONSUMPTION_REQUEST sobre ele, informe o que aconteceu. O campo deliveryStatus da Apple tem um valor para isso, UNDELIVERED_SERVER_OUTAGE, e a Apple diz que qualquer status diferente de DELIVERED precisa vir com consumptionPercentage igual a 0.

O cliente já usou as duas extensões da Apple

O limite da Apple é de duas extensões por cliente em 365 dias. Duas quedas em um ano gastam as duas, e uma terceira deixa você sem nada a oferecer pela loja. Acompanhe quantas extensões cada originalTransactionId já usou, para que as notificações FAILURE da requisição em massa não peguem você de surpresa.

O cliente está em um teste grátis

A Apple não estende uma assinatura em período de oferta gratuita. Um usuário em teste perdeu dias grátis, não pagos, então o risco de reembolso é baixo. Se quiser compensá-lo, uma mensagem no app custa menos que qualquer chamada de API.

Um checklist para a próxima queda

• Registre quando a queda começou e terminou, e quais produtos e regiões ela atingiu.
• Escolha um número de dias que cubra o tempo perdido. Na Apple, use o código de motivo 3 e fique entre 1 e 90.
• Na Apple, envie uma requisição em massa por productId, limitada por storefrontCountryCodes quando só algumas regiões foram afetadas.
• Fique atento a RENEWAL_EXTENSION FAILURE e tente cada uma de novo com o endpoint de assinatura individual.
• No Google Play, percorra os tokens de compra ativos, leia cada etag, rode primeiro com validateOnly e depois adie de verdade.
• Avise você mesmo os assinantes do Google Play sobre o tempo extra, já que o Google não vai avisar.
• Atualize a expiração dos direitos de acesso a partir de RENEWAL_EXTENDED e SUBSCRIPTION_DEFERRED, não dos seus próprios cálculos de data.
• Mantenha logs de uso por conta, para que, se mesmo assim chegar um pedido de reembolso ou chargeback, suas evidências estejam prontas em até 12 horas para a Apple e 24 horas para o Google.