Sobre as assinaturas

Este tópico descreve como processar eventos de ciclo de vida da assinatura, como renovações e expirações. Ele também descreve outros recursos de assinatura, como oferecer promoções e permitir que os usuários gerenciem as próprias assinaturas.

Se você não configurou produtos por assinatura para seu app, consulte Criar e configurar seus produtos.

Visão geral das assinaturas

Uma assinatura representa um conjunto de benefícios que os usuários podem acessar durante um determinado período. Por exemplo, uma assinatura pode dar ao usuário o acesso a um serviço de streaming de música.

É possível ter várias assinaturas no mesmo app para representar conjuntos de benefícios diferentes ou níveis diferentes de um único conjunto de benefícios (por exemplo, nível prata ou ouro).

Usando os planos básicos e as ofertas, é possível criar várias configurações para um mesmo produto por assinatura. Por exemplo, você pode criar uma oferta introdutória para usuários que nunca compraram uma assinatura no seu app ou uma oferta de upgrade para usuários que já têm uma assinatura.

Para saber mais sobre produtos por assinatura, planos básicos e ofertas, consulte a documentação na Central de Ajuda do Play Console.

Integração de planos pré-pagos

Os planos pré-pagos não são renovados automaticamente após o vencimento. Para estender o direito de assinatura sem que haja interrupção, o usuário precisa recarregar o plano pré-pago dessa assinatura.

Para recargas, inicie o fluxo de faturamento da mesma maneira que você faria para uma compra. Não é necessário indicar que a compra é uma recarga.

As recargas de planos pré-pagos sempre usam o modo de substituição CHARGE_FULL_PRICE. Não é necessário definir esse modo explicitamente. O usuário é imediatamente cobrado por um período de faturamento completo, e o direito de acesso é estendido pelo prazo especificado na recarga.

Após a recarga, os seguintes campos no objeto de resultado Purchase serão atualizados para refletir a compra de recarga mais recente:

  • ID do pedido
  • Horário da compra
  • Assinatura
  • Token da compra
  • Confirmação

Os campos Purchase a seguir sempre contêm os mesmos dados encontrados na compra original:

  • Nome do pacote
  • Estado da compra
  • Produtos
  • Renovação automática

Confirmação de compra de planos pré-pagos

Assim como nas assinaturas de renovação automática, é necessário apresentar uma confirmação de compra para os planos pré-pagos. Tanto a primeira compra quanto todas as recargas posteriores precisam ser confirmadas. Para ver mais informações, consulte Como processar compras.

Alguns planos pré-pagos podem ter prazos de duração curtos. Por isso, é importante confirmar a compra o mais rápido possível.

Planos pré-pagos com prazo de uma semana ou mais precisam ser confirmados dentro de três dias.

Planos com prazo menor que uma semana precisam ser confirmados até metade do período de assinatura do plano. Por exemplo, para um plano pré-pago de três dias, os desenvolvedores têm até um dia e meio para enviar a confirmação.

Usar links diretos para permitir que os usuários gerenciem uma assinatura

Seu app precisa incluir um link em uma tela de configurações ou preferências que permitindo que os usuários gerenciem as assinaturas, que você pode incorporar à aparência natural do app.

É possível incluir um link direto do seu app para a central de assinaturas do Google Play para assinaturas não vencidas, que você pode determinar usando o campo subscriptionState do recurso de assinatura. Com base nisso, há várias maneiras de criar links diretos para a central de assinaturas da Play Store.

Use o URL abaixo para direcionar os usuários à página que mostra todas as assinaturas, conforme mostrado nas figuras 1 e 2:

https://play.google.com/store/account/subscriptions
A tela de assinaturas da Play Store mostra o status de todas as assinaturas faturadas do Google Play de um usuário.
Figura 1. A tela de assinaturas da Play Store mostra o status de todas as assinaturas faturadas do Google Play de um usuário.


Toque em uma assinatura para consultar mais detalhes.
Figura 2. Toque em uma assinatura para consultar mais detalhes.

Esse link direto pode ser útil para ajudar um usuário a restaurar uma assinatura cancelada na central de assinaturas da Play Store.

Para vincular diretamente à página de gerenciamento de uma assinatura não vencida, indique o nome do pacote e o productId associados a ela. Para determinar o productId de uma assinatura de forma programática, consulte o back-end do app ou chame BillingClient.queryPurchasesAsync() para uma lista de assinaturas associadas a um usuário específico. Cada assinatura contém o productId correspondente como parte das informações de status da assinatura. Cada objeto SubscriptionPurchaseLineItem associado a uma compra de assinatura contém o valor de productId associado à assinatura que o usuário comprou nesse item de linha.

.

Use o URL abaixo para direcionar os usuários a uma tela específica de gerenciamento de assinaturas, substituindo "your-sub-product-id" e "your-app-package" pelo productId e o nome do pacote do app, respectivamente:

https://play.google.com/store/account/subscriptions?sku=your-sub-product-id&package=your-app-package

O usuário pode gerenciar as formas de pagamento e acessar recursos, incluindo cancelamento, nova assinatura e pausa.

Permitir que os usuários façam upgrade e downgrade ou modifiquem a assinatura

Você pode oferecer aos assinantes várias opções para mudar o plano de assinatura para melhor atender às necessidades deles:

  • Se você vende diversos níveis de assinatura, como "básica" e "premium", permita que os usuários mudem de nível comprando o plano básico ou uma oferta de assinatura diferente.
  • Você pode permitir que os usuários mudem o período de faturamento atual, por exemplo, passando do plano mensal para o anual.
  • Também é possível permitir que eles alternem entre os planos pré-pago e com renovação automática.

Você pode incentivar qualquer uma dessas mudanças com ofertas de assinatura que dão desconto a usuários qualificados. Por exemplo, é possível criar uma oferta com 50% de desconto no primeiro ano ao mudar do plano mensal para o anual e limitar essa oferta aos usuários inscritos em um plano mensal e que ainda não aceitaram essa oferta. Saiba mais sobre os critérios de qualificação da oferta na Central de Ajuda.

A Figura 3 mostra um app de exemplo com três planos diferentes:

Este app tem três níveis de assinatura.
Figura 3. Este app tem três níveis de assinatura.

Seu app pode mostrar uma tela semelhante à Figura 3, oferecendo aos usuários opções para mudar a assinatura. Em todos os casos, precisa ficar claro para os usuários qual é o plano de assinatura atual e quais opções eles têm para mudá-lo.

Quando os usuários decidem fazer upgrade, downgrade ou mudar a assinatura, você especifica um modo de substituição que determina como o valor proporcional do período de faturamento pago atual é aplicado e quando qualquer mudança de deireito de acesso ocorre.

Modos de substituição

A tabela a seguir lista os modos de substituição disponíveis e exemplos de uso.

Modo de substituição

Descrição

Exemplo de uso

WITH_TIME_PRORATION

A assinatura recebe upgrade ou downgrade imediatamente. Qualquer tempo restante é ajustado com base na diferença de preço e creditado à nova assinatura, adiando a próxima data de faturamento. Esse é o comportamento padrão.

Upgrade para um nível mais caro sem nenhum pagamento extra imediato.

CHARGE_PRORATED_PRICE

A assinatura recebe upgrade imediatamente, e o ciclo de faturamento permanece o mesmo. A diferença de preço referente ao período restante é cobrada do usuário.

Observação: essa opção está disponível apenas para um upgrade de assinatura, em que o preço por unidade de tempo aumenta.

Upgrade para um nível mais caro sem mudar a data de faturamento.

CHARGE_FULL_PRICE

O upgrade ou downgrade da assinatura é feito, e o usuário recebe a cobrança imediata do preço total pelo novo direito de acesso. O valor restante da assinatura anterior é transferido para o mesmo direito de acesso ou um valor proporcional ao tempo é transferido ao mudar para outro.

Observação: se a nova assinatura tiver um teste sem custo financeiro ou uma oferta inicial, o usuário vai receber uma cobrança de US$ 0 ou o preço da oferta inicial, o que for aplicável, no momento do upgrade ou downgrade.

Upgrade do período de faturamento mais curto para o mais longo.

WITHOUT_PRORATION

A assinatura recebe upgrade ou downgrade imediatamente, e o novo preço é cobrado quando a assinatura é renovada. O ciclo de faturamento permanece o mesmo.

Upgrade para um nível de assinatura mais alto e manutenção do período sem custo financeiro restante.

DEFERRED

A assinatura só recebe upgrade ou downgrade quando é renovada. No entanto, a nova compra é emitida imediatamente com uma data de início no futuro para o novo direito de acesso. Assim, o desenvolvedor pode permitir que os usuários façam outras mudanças, se quiserem. Por exemplo, eles podem voltar ao plano original ou iniciar uma nova mudança de plano adiada.

Downgrade para um nível mais barato.

Para saber mais sobre as diferentes aplicações de upsell e recuperação de assinaturas com ofertas de upgrade ou downgrade, leia o guia de ofertas e promoções.

Definir o modo de substituição para uma compra

Você pode usar diferentes modos de substituição para diversos tipos de transições de assinatura de acordo com as suas preferências e a lógica de negócios. Esta seção explica como definir um modo de substituição para uma mudança em uma assinatura e as limitações aplicadas.

Renovar assinatura ou mudar de plano na mesma assinatura

É possível especificar um modo de substituição padrão no Google Play Console. Essa configuração permite escolher quando cobrar os assinantes se eles comprarem um plano básico ou uma oferta diferente para a mesma assinatura ou se eles fizerem a renovação após um cancelamento. As opções disponíveis são Cobrar imediatamente, que equivale a CHARGE_FULL_PRICE, e Cobrar na próxima data de faturamento, equivalente a WITHOUT_PRORATION. Esses são os únicos modos de substituição relevantes ao mudar de plano básico na mesma assinatura.

Por exemplo, se você estiver implementando uma oferta de recuperação para o mesmo plano depois do cancelamento do usuário, mas antes do término da assinatura, será possível processar a nova compra como normal sem indicar valores em SubscriptionUpdateParams. O sistema usa o modo de substituição padrão configurado na assinatura e processa automaticamente a transição do plano da compra antiga para a nova.

Trocar de plano entre assinaturas ou modificar o modo de substituição padrão

Se o usuário estiver mudando de assinatura de produtos (comprando uma assinatura diferente) ou se você quiser trocar o modo de substituição padrão por qualquer motivo, especifique a taxa de cálculo proporcional no momento da execução como parte dos parâmetros do fluxo de compra.

Para fornecer SubscriptionUpdateParams corretamente como parte da configuração do fluxo de compra no ambiente de execução, observe estas restrições:

  • Ao fazer upgrade ou downgrade ou mudar uma mesma assinatura de um plano pré-pago ou com renovação automática para um plano pré-pago, o único modo de cálculo proporcional permitido é CHARGE_FULL_PRICE. Se você especificar qualquer outro modo de cálculo proporcional, a compra vai falhar e um erro será mostrado ao usuário.
  • Ao mudar de plano dentro da mesma assinatura de um plano pré-pago ou com renovação automática para um plano com renovação automática, os modos de cálculo proporcional válidos são CHARGE_FULL_PRICE e WITHOUT_PRORATION. Se você especificar qualquer outro modo de cálculo proporcional, a compra vai falhar e um erro será mostrado ao usuário.

Exemplos e comportamentos de substituição

Para entender como cada modo de cálculo proporcional funciona, considere o seguinte cenário:

Paulo tem uma assinatura de conteúdo on-line do app Country Gardener. Essa é uma assinatura mensal da versão de Nível 1 do conteúdo, que tem apenas texto. A assinatura custa R$ 2/mês e é renovada no primeiro dia do mês.

Em 15 de abril, Paulo decidiu fazer upgrade para a versão anual do Nível 2, que inclui vídeos com novidades e custa R$ 36/ano.

Ao fazer upgrade da assinatura, o desenvolvedor seleciona um modo de cálculo proporcional. A lista a seguir descreve como cada modo de cálculo proporcional afeta a assinatura de Paulo:

WITH_TIME_PRORATION

A assinatura do Nível 1 de Paulo termina imediatamente. Como o pagamento vale por um mês inteiro (de 1º a 30 de abril), mas Paulo usou apenas metade desse período, metade da assinatura de um mês (R$ 1) é aplicada à nova assinatura. No entanto, como a nova assinatura custa R$ 36 por ano, o saldo de crédito de R$ 1 paga por apenas 10 dias (16 a 25 de abril). Então, no dia 26 de abril, serão cobrados R$ 36 por uma nova assinatura e outros R$ 36 em 26 de abril de cada ano seguinte.

Chame o PurchasesUpdatedListener do app no momento em que a compra for concluída para recuperar a nova compra como parte de um queryPurchasesAsync(). Seu back-end recebe imediatamente uma Notificação do desenvolvedor em tempo real SUBSCRIPTION_PURCHASED.

CHARGE_PRORATED_PRICE

Esse modo pode ser usado porque o preço da assinatura do Nível 2 por unidade de tempo (R$ 36/ano = R$ 3/mês) é maior que o preço da assinatura do Nível 1 por unidade de tempo (R$ 2/mês). A assinatura do Nível 1 de Paulo termina imediatamente. Como ele pagou por um mês inteiro, mas usou apenas metade disso, metade da assinatura de um mês (R$ 1) é aplicada à nova. No entanto, como essa nova assinatura custa R$ 36 por ano, os 15 dias restantes custam R$ 1,50. Assim, ele recebe a cobrança da diferença de R$ 0,50 pela nova assinatura. Em 1º de maio, são cobrados R$ 36 pelo novo nível da assinatura, e outros R$ 36 no dia 1º de maio de cada ano.

Chame o PurchasesUpdatedListener do app no momento em que a compra for concluída para recuperar a nova compra como parte de uma chamada de queryPurchasesAsync(). Seu back-end recebe imediatamente uma Notificação do desenvolvedor em tempo real SUBSCRIPTION_PURCHASED.

WITHOUT_PRORATION

A assinatura do Nível 1 de Paulo recebe imediatamente upgrade para o Nível 2, sem nenhum custo extra. Em 1º de maio, são cobrados R$ 36 pelo novo nível de assinatura e outros R$ 36 no dia 1º de maio de cada ano.

Chame o PurchasesUpdatedListener do app no momento em que a compra for concluída para recuperar a nova compra como parte de uma chamada de queryPurchasesAsync(). Seu back-end recebe imediatamente uma Notificação do desenvolvedor em tempo real SUBSCRIPTION_PURCHASED.

DEFERRED

A assinatura do Nível 1 de Paulo continua até o vencimento, em 30 de abril. No dia 1º de maio, a assinatura do Nível 2 entra em vigor, e Paulo recebe uma cobrança de R$ 36 pelo novo nível de assinatura.

Chame o PurchasesUpdatedListener do app no momento em que a compra for concluída para recuperar a nova compra como parte de uma chamada de queryPurchasesAsync(). Seu back-end recebe imediatamente uma Notificação do desenvolvedor em tempo real SUBSCRIPTION_PURCHASED. É necessário processar a compra da mesma forma que qualquer outra compra nova nesse momento. Mais especificamente, você precisa confirmar a nova compra. Observe que o startTime da nova assinatura é preenchido no momento em que a substituição entra em vigor, o que acontece quando a assinatura antiga vence. Quando isso acontecer, você vai receber uma Notificação do desenvolvedor em tempo real (RTDN, na sigla em inglês) SUBSCRIPTION_RENEWED para o novo plano de assinatura. Leia mais sobre o comportamento ReplacementMode.DEFERRED em Processar substituição adiada.

CHARGE_FULL_PRICE

A assinatura do Nível 1 de Paulo termina imediatamente. A assinatura do Nível 2 começa imediatamente com uma cobrança de R$ 36. Como ele pagou por um mês inteiro, mas usou apenas metade disso, metade da assinatura de um mês (R$ 1) é aplicada à nova assinatura. Como essa nova assinatura custa R$ 36/ano, ele receberia um período de 1/36 do ano adicionado ao período da assinatura (aproximadamente 10 dias). Portanto, a próxima cobrança de Paulo seria um ano e 10 dias após o dia atual, custando R$ 36. Depois disso, ele vai receber uma cobrança de R$ 36 para cada ano seguinte.

Ao escolher um modo de cálculo proporcional, leia nossas recomendações de substituição.

Acionar mudanças de assinatura no app

Seu app pode oferecer um upgrade ou downgrade aos usuários com as mesmas etapas utilizadas para iniciar um fluxo de compra. No entanto, ao fazer upgrade ou downgrade, você precisa fornecer detalhes sobre a assinatura atual, a assinatura futura (upgrade ou downgrade) e o modo de cálculo proporcional a ser usado, conforme mostrado no exemplo a seguir:

Kotlin

val offerToken = productDetails
        .getSubscriptionOfferDetails(selectedOfferIndex)
        .getOfferToken()

val billingParams = BillingFlowParams.newBuilder().setProductDetailsParamsList(
       listOf(
           BillingFlowParams.ProductDetailsParams.newBuilder()
               .setProductDetails(productDetails)
               .setOfferToken(offerToken)
               .build()
       )
       ).setSubscriptionUpdateParams(
           BillingFlowParams.SubscriptionUpdateParams.newBuilder()
               .setOldPurchaseToken("old_purchase_token")
               .setSubscriptionReplacementMode(
                 BillingFlowParams.ReplacementMode.CHARGE_FULL_PRICE
               )
               .build()
       ).build()

billingClient.launchBillingFlow(
    activity,
    billingParams
   )
// ...

Java

String offerToken = productDetails
    .getSubscriptionOfferDetails(selectedOfferIndex)
    .getOfferToken();

BillingFlowParams billingFlowParams = BillingFlowParams.newBuilder()
    .setProductDetailsParamsList(
        ImmuableList.of(
            ProductDetailsParams.newBuilder()
                // fetched via queryProductDetailsAsync
                .setProductDetails(productDetails)
                // offerToken can be found in
                // ProductDetails=>SubscriptionOfferDetails
                .setOfferToken(offerToken)
                .build()))
    .setSubscriptionUpdateParams(
        SubscriptionUpdateParams.newBuilder()
            // purchaseToken can be found in Purchase#getPurchaseToken
            .setOldPurchaseToken("old_purchase_token")
            .setSubscriptionReplacementMode(ReplacementMode.CHARGE_FULL_PRICE)
            .build())
    .build();

BillingResult billingResult = billingClient.launchBillingFlow(activity, billingFlowParams);
// ...

Recomendações de substituição

A tabela a seguir mostra diferentes cenários de cálculo proporcional e o que recomendamos para cada um deles:

Cenário Modo de substituição recomendado Resultado
Upgrade para um nível mais caro CHARGE_PRORATED_PRICE O usuário recebe acesso imediatamente, mantendo o mesmo período de faturamento.
Downgrade para um nível mais barato DEFERRED O usuário já pagou pelo nível mais caro, então vai manter o acesso até a próxima data de faturamento.
Upgrade durante o teste sem custo financeiro, mantendo o período de teste WITHOUT_PRORATION O usuário mantém o acesso ao teste sem custo financeiro, mas faz upgrade para um nível superior pelo restante do teste.
Upgrade durante o teste sem custo financeiro, encerrando o acesso a ele CHARGE_PRORATED_PRICE O usuário recebe acesso ao novo nível imediatamente, mas não tem mais o teste sem custo financeiro.

Processar compras de mudanças de assinatura

As mudanças de plano são novas compras para todos os termos e finalidades e precisam ser processadas e confirmadas assim que o fluxo de faturamento é concluído. Além de processar a nova compra corretamente, você precisa desativar a que está sendo substituída.

O comportamento no aplicativo é o mesmo de qualquer nova compra. Seu app recebe o resultado da nova compra no PurchasesUpdatedListener, e ela está disponível no queryPurchasesAsync.

A API Google Play Developer retorna um linkedPurchaseToken no recurso de assinatura quando uma compra substitui uma existente. Invalide o token fornecido no linkedPurchaseToken para garantir que o token antigo não seja usado para acessar seus serviços. Consulte Upgrades, downgrades e novas assinaturas para informações sobre como processar compras de upgrade e downgrade.

Ao receber o token de compra, siga o mesmo processo usado para verificar um novo token de compra. Confirme essas compras com BillingClient.acknowledgePurchase() da Biblioteca Google Play Faturamento ou Purchases.subscriptions:acknowledge da API Google Play Developer.

Processar substituição adiada

O modo de substituição adiada permite que um usuário utilize o direito de acesso restante no plano antigo antes de começar o novo.

Ao usar ReplacementMode.DEFERRED para uma nova compra, queryPurchasesAsync() retorna um novo token de compra após o fluxo que permanece associado ao antigo produto até que a substituição adiada ocorra na próxima data de renovação. Após essa data, o novo produto é devolvido.

Antes, era possível ter essa experiência do usuário com o ProrationMode.DEFERRED, mas o uso do ProrationMode.DEFERRED foi descontinuado na Biblioteca Play Faturamento 6. Consulte a tabela a seguir para entender em que o comportamento difere:

Hora

ProrationMode.DEFERRED (descontinuado)

ReplacementMode.DEFERRED

Logo após a conclusão do fluxo de compra (app)

O PurchasesUpdatedListener é invocado após a compra com um status que indica se o upgrade ou downgrade foi concluído.

O direito de acesso ao plano antigo continua até a próxima data de renovação. Para garantir que o app conceda o direito correto, o queryPurchasesAsync() retorna um objeto de compra com o token de compra original e o direito original até que a substituição ocorra.

O novo token de compra não aparece, então não pode ser processado.

O PurchasesUpdatedListener é invocado após a compra com um status que indica se o upgrade ou downgrade foi concluído.

O queryPurchasesAsync() retorna a compra com o novo token imediatamente e o direito original associado a ela.

O novo token de compra é mostrado e precisa ser processado nesse momento, considerando quando a substituição deve ocorrer.

Logo após a conclusão do fluxo de compra (back-end)

A RTDN SUBSCRIPTION_PURCHASED não é enviada após o fluxo de compra. O back-end ainda não fica ciente da nova compra.

A RTDN SUBSCRIPTION_PURCHASED é enviada imediatamente depois do fluxo de compra do novo token.

Chamar o método purchases.subscriptionsv2.get com o novo token de compra retorna uma compra com dois itens de linha:

  • Um deles representa o direito de acesso atual, com um "expiryTime" no futuro e nenhuma flag de renovação automática.
  • O outro representa o direito de acesso novo, com renovação automática ativada e sem "startTime" por enquanto (ainda não iniciado).

SUBSCRIPTION_EXPIRED enviada para o token de compra antigo. Ao chamar o método purchases.subscriptionsv2.get com o token de compra antigo, ele aparece como expirado. O direito de acesso do plano antigo é transferido para a nova compra pelo tempo restante.

Na substituição: primeira renovação após o fluxo de compra (app)

queryPurchasesAsync() retorna um novo objeto de compra com o novo token de compra e direito de acesso.

O novo token de compra é mostrado e precisa ser processado.

O queryPurchasesAsync() retorna a compra com o novo token imediatamente e o novo direito de acesso associado a ela.

A nova compra já terá sido processada quando o fluxo de compra for concluído. Portanto, o app não terá nenhuma ação especial além de garantir que o direito correto seja concedido.

Na substituição: primeira renovação após o fluxo de compra (back-end)

A nova compra agora poderá ser processada e confirmada quando a primeira RTDN SUBSCRIPTION_RENEWED for enviada.

O linkedPurchaseToken no recurso de assinatura pode ser usado para determinar qual usuário no back-end da assinatura, se aplicável, será atualizado com o novo direito de acesso.

A nova compra foi processada e confirmada quando a RTDN SUBSCRIPTION_PURCHASED foi enviada para o novo token de compra.

Com ReplacementMode.DEFERRED, as primeiras renovações seguem o comportamento padrão de qualquer outra renovação, e você não precisa lidar com uma lógica especial para substituições quando esse evento acontece.

Ao chamar o método purchases.subscriptionsv2.get com o novo token de compra, uma compra é retornada com dois itens de linha:

  • Um representa o direito de acesso antigo, com um "expiryTime" no passado.
  • O outro representa o direito de acesso novo, com um "startTime" correspondente à data em que a substituição foi feita e um "expiryTime" no futuro.

O ReplacementMode.DEFERRED precisa ser usado daqui em diante no lugar do ProrationMode.DEFERRED descontinuado, já que apresenta o mesmo comportamento em relação às mudanças de direitos, mas oferece uma forma de gerenciar a compra de maneira mais consistente com os comportamentos para outras compras novas.

Gestão de clientes

Com as notificações do desenvolvedor em tempo real, é possível detectar imediatamente quando um usuário decide cancelar. Quando um usuário cancela a assinatura antes da expiração, você pode enviar notificações push ou mensagens no app para pedir que ele a renove.

Depois que um usuário cancela a assinatura, você pode usar o app ou a Play Store tentar convencer ele a renovar a assinatura. A tabela a seguir descreve vários cenários de assinatura, com ações associadas de recuperação e requisitos de app.

Antes da expiração da assinatura Após a expiração da assinatura
No app Na Play Store No app Na Play Store
Recurso de recuperação Assinatura no app Restauração Assinatura no app Nova assinatura
O usuário percorre o fluxo de finalização da compra Sim Não Sim Sim
A assinatura do usuário permanece associada ao mesmo SKU O usuário pode se inscrever para um SKU igual ou diferente Sim O usuário pode se inscrever para um SKU igual ou diferente Sim
Cria um novo token de compra Sim Não Sim Sim
Ativado por padrão Não Sim, a compatibilidade é necessária para todos os desenvolvedores Não

Apps sem a Biblioteca Faturamento versão 2.0 ou mais recente: não.

Apps com a Biblioteca Faturamento versão 2.0 ou mais recente: sim. Os desenvolvedores podem desativar no console.

Quando o usuário é cobrado

Se usar o mesmo SKU: no fim do período de faturamento atual.

Se usar um SKU diferente: depende do modo de cálculo proporcional.

Fim do período de faturamento atual Imediatamente Imediatamente
Implementação necessária Fornecer uma IU de nova assinatura no seu app

Detectar mudanças no estado da assinatura

Link direto para a Play Store

Fornecer uma IU de nova assinatura no seu app Processar compras fora do aplicativo

Antes da expiração da assinatura: no app

Para assinaturas que foram canceladas, mas ainda não expiraram, é possível permitir que os assinantes restaurem as assinaturas no seu app aplicando o mesmo fluxo de compra de produto no aplicativo usado para novos assinantes. Verifique se a IU reflete que o usuário tem uma assinatura existente. Por exemplo, é possível exibir a data de validade atual do usuário e o preço recorrente com um botão Reativar.

Na maioria das vezes, convém oferecer ao usuário o mesmo preço e o mesmo SKU que ele já assinava, conforme mostrado a seguir:

  • Inicie uma nova compra de assinatura com o mesmo SKU.
  • A nova assinatura substitui a antiga e será renovada na mesma data de validade. A assinatura antiga será marcada imediatamente como expirada.
  • Por exemplo, Ana tem uma assinatura do app Example Music, e a assinatura expira no dia 1º de agosto. Em 10 de julho, ela refaz a assinatura de um mês pelo mesmo preço mensal. A nova assinatura é proporcional ao crédito restante, fica ativa imediatamente e ainda é renovada em 1º de agosto.

Se quiser oferecer um preço diferente, como um novo teste sem custo financeiro ou um desconto de recuperação, forneça uma SKU diferente ao usuário:

  • Inicie um upgrade ou downgrade com uma SKU diferente usando o modo de substituição WITHOUT_PRORATION.
  • A nova assinatura substitui a antiga e será renovada na mesma data de validade. O preço do novo SKU é cobrado do usuário, incluindo preços iniciais, na data de validade original. Se a assinatura antiga foi criada usando um ID ofuscado da conta, esse mesmo ID precisa ser transmitido para o BillingFlowParams para serem feitos upgrades e downgrades.
  • Por exemplo, Ana tem uma assinatura do app Example Music, e a assinatura expira no dia 1º de agosto. Em 10 de julho, ela refaz a assinatura anual com um preço inicial. A nova assinatura será ativada imediatamente, e o preço inicial do usuário será cobrado em 1º de agosto.
  • Se você decidir incluir um teste sem custo financeiro ou preço inicial no SKU de recuperação, torne o usuário qualificado para isso desmarcando a caixa Permitir um teste sem custo financeiro por app no Google Play Console, que restringe o usuário a apenas um teste sem custo financeiro por app.

Quando você receber o token, processe a compra como faria com uma nova assinatura. Além disso, a API Google Play Developer retorna um linkedPurchaseToken no recurso de assinatura. Invalide o token fornecido no linkedPurchaseToken para garantir que o token antigo não seja usado para acessar seus serviços.

Antes da expiração da assinatura na Play Store

Enquanto a assinatura está cancelada, mas ainda ativa, ela pode ser restaurada pelo usuário na central de assinaturas do Google Play, clicando na opção Renovar assinatura, antes chamada de Restaurar. Isso mantém o mesmo token de compra e assinatura.

Seção "Assinaturas" no app Google Play Store mostrando uma
            assinatura cancelada com um botão "Assinar novamente".
Figura 8. Seção Conta > Assinaturas no app Google Play Store mostrando uma assinatura cancelada com um botão Renovar assinatura.

Para mais informações sobre como restaurar assinaturas, consulte Restaurações.

Após a expiração da assinatura: no app

É possível permitir que usuários com assinaturas expiradas refaçam a assinatura no app aplicando o mesmo fluxo de compra de produto no aplicativo usado para novos assinantes. Observe o seguinte:

  • Para dar um desconto aos usuários, ofereça um ID do produto com preços especiais para sua assinatura, também chamado de SKU de recuperação. Você pode disponibilizar a oferta no seu app ou notificar o usuário sobre a oferta fora do app, como por e-mail.
  • Para iniciar uma assinatura de recuperação, abra o fluxo de compra no seu app Android usando a Biblioteca Google Play Faturamento. Esse processo é igual ao de uma nova assinatura, mas você pode determinar o SKU disponível para o usuário.
  • Se você decidir incluir um teste sem custo financeiro ou preço inicial no SKU de recuperação, torne o usuário qualificado para isso desmarcando a caixa Permitir um teste sem custo financeiro por app no Google Play Console, que restringe o usuário a apenas um teste sem custo financeiro por app.
  • Se o usuário fizer uma nova assinatura do mesmo SKU, ele não estará mais qualificado para testes sem custo financeiros nem preço inicial. Garanta que a interface reflita isso.

Quando você receber o token, processe a compra como faria com uma nova assinatura. Você não receberá um linkedPurchaseToken no recurso de assinatura.

Após a expiração da assinatura: na Play Store

Se ativado, os usuários podem assinar novamente o mesmo SKU por até um ano após a validade. Basta clicar em Renovar assinatura na central de assinaturas do Google Play. Isso gera um novo token de compra e assinatura.

Seção "Assinaturas" no app Google Play Store mostrando uma
            assinatura cancelada e expirada com botões "Assinar novamente" e
            "Remover".
Figura 9. Seção Conta > Assinaturas no app Google Play Store mostrando uma assinatura cancelada e expirada com botões Assinar novamente e Remover.

A nova assinatura é considerada uma compra fora do app. Por isso, siga as práticas recomendadas para processar compras feitas fora do app.

Promover sua assinatura

Crie códigos promocionais para oferecer a alguns usuários um teste sem custo financeiro mais longo para uma assinatura já existente. Para saber mais, consulte Códigos promocionais.

O Google Play verifica se o usuário tem uma forma de pagamento válida antes de iniciar o teste sem custo financeiro. Alguns usuários podem ver essa verificação como uma retenção ou cobrança na forma de pagamento deles. A retenção ou cobrança é temporária e será revertida ou reembolsada posteriormente.

Após o término do período de teste, a forma de pagamento do usuário recebe uma cobrança referente ao valor total da assinatura.

Se um usuário cancela uma assinatura a qualquer momento durante o período de teste sem custo financeiro, ela permanece ativa até o final desse período e não é cobrada quando ele terminar.

Cancelar, reembolsar ou revogar

Você pode usar a API Google Play Developer para cancelar, reembolsar ou revogar uma assinatura. Essa funcionalidade também está disponível no Google Play Console.

  • Cancelar: os usuários podem cancelar uma assinatura no Google Play. Você também pode fornecer uma opção para os usuários cancelarem no seu app ou site. Seu app deve processar esses cancelamentos conforme descrito em Revogações.
  • Reembolsar: quando você faz um reembolso, o usuário pode continuar usando a assinatura. Os reembolsos poderão ser usados se, por exemplo, tiver ocorrido um erro técnico que impediu o usuário de acessar seu produto, mas o erro tiver sido resolvido. Para reembolsar mais do que o pagamento mais recente ou emitir um reembolso parcial, use o Google Play Console.
  • Revogar: quando você revoga a assinatura, o usuário perde imediatamente o acesso a ela. Isso poderá ser usado se, por exemplo, tiver ocorrido um erro técnico que impediu o usuário de acessar seu produto e ele não quiser continuar a usá-lo. Seu app deve processar esses cancelamentos conforme descrito em Revogações.

A tabela a seguir ilustra as diferenças entre cancelamento, reembolso e revogação.

Interrompe a renovação Reembolsa dinheiro Revoga o acesso
Cancelar Sim Não Não
Reembolsar Não Sim Não
Revogar Sim Sim Sim

Adiar o faturamento de um assinante

Você pode adiar a próxima data de faturamento de um assinante de um plano com renovação automática usando Purchases.subscriptions:defer da API Google Play Developer. Durante o período de adiamento, o usuário será assinante do conteúdo com acesso total, mas não será cobrado. A data de renovação da assinatura é atualizada para a nova data.

Para planos pré-pagos, é possível usar a API de adiamento de faturamento para adiar o prazo de vencimento.

O faturamento adiado permite:

  • Dar aos usuários acesso sem custo financeiro como uma oferta especial, por exemplo, oferecendo uma semana de uso sem custo financeiro para quem comprar um filme.
  • Dar acesso sem custo financeiro aos clientes para desenvolver um bom relacionamento.

O faturamento pode ser adiado de um dia a um ano por chamada de API. Para adiar ainda mais o faturamento, chame a API novamente antes da nova data de faturamento.

Por exemplo, Daniela tem uma assinatura mensal de conteúdo on-line do aplicativo Fishing Quarterly. Normalmente, ela recebe uma cobrança de R$ 1,25 no primeiro dia de cada mês. Em março, ela participou de uma pesquisa on-line para o editor do app. O editor a recompensou com seis semanas sem custo financeiro, adiando o próximo pagamento até 15 de maio, o que corresponde a seis semanas após a data de faturamento anteriormente agendada para 1º de abril. Daniela não é cobrada em abril nem no início de maio e ainda tem acesso ao conteúdo. Em 15 de maio, ela é cobrada pela taxa de assinatura normal de R$ 1,25 para o mês. Agora, a próxima data de renovação é 15 de junho.

Com o adiamento, você pode notificar o usuário por e-mail ou no aplicativo que a data de faturamento foi modificada.

Processar pagamentos recusados

Se houver problemas de pagamento com a renovação de uma assinatura, o Google vai tentar renovar periodicamente por algum tempo antes do cancelamento. Esse período de recuperação pode consistir em um período de carência, seguido por um período de suspensão de conta. Durante esse período, o Google envia e-mails e notificações solicitando que o usuário atualize a forma de pagamento.

Após a recusa do pagamento, a assinatura entra em um período de carência, se um estiver configurado. Durante esse período, verifique se o usuário ainda tem acesso aos direitos da assinatura.

Após qualquer período de carência, a assinatura entra em um período de suspensão de conta. Durante a suspensão de conta, verifique se o usuário não tem acesso aos direitos da assinatura.

É possível especificar a duração do período de carência e da suspensão de conta de cada plano básico com renovação automática no Google Play Console. Especificar comprimentos menores que os valores padrão pode reduzir o número de assinaturas recuperadas de pagamentos recusados.

Para maximizar a probabilidade de recuperação da assinatura durante uma recusa de pagamento, você pode informar o usuário sobre um problema de pagamento e pedir que ele o corrija.

Você pode fazer isso por conta própria, como descrito nas seções período de carência e suspensão de conta, ou implementar a API de mensagens no app, em que o Google mostra uma mensagem aos usuários no seu aplicativo.

Mensagens no app

Se você tiver ativado as mensagens no app com o InAppMessageCategoryId.TRANSACTIONAL, o Google Play vai mostrar as mensagens durante o período de carência e a suspensão de conta uma vez por dia, além de fornecer a eles uma oportunidade de corrigir o pagamento sem sair do app.

Snackbar notificando o usuário para que ele corrija o pagamento
Figura 20. Snackbar notificando o usuário para que ele corrija o pagamento.

Recomendamos que você chame essa API sempre que o usuário abrir o app para determinar se a mensagem vai ser exibida.

Se o usuário recuperar a assinatura, você vai receber um código de resposta de SUBSCRIPTION_STATUS_UPDATED com um token de compra. Use esse token de compra para chamar a API Google Play Developer e atualizar o status da assinatura no app.

Integrar mensagens no app

Para mostrar mensagens no app ao usuário, use BillingClient.showInAppMessages().

Veja um exemplo de como acionar o fluxo de mensagens no app:

Kotlin

val inAppMessageParams = InAppMessageParams.newBuilder()
        .addInAppMessageCategoryToShow(InAppMessageCategoryId.TRANSACTIONAL)
        .build()

billingClient.showInAppMessages(activity,
        inAppMessageParams,
        object : InAppMessageResponseListener() {
            override fun onInAppMessageResponse(inAppMessageResult: InAppMessageResult) {
                if (inAppMessageResult.responseCode == InAppMessageResponseCode.NO_ACTION_NEEDED) {
                    // The flow has finished and there is no action needed from developers.
                } else if (inAppMessageResult.responseCode
                        == InAppMessageResponseCode.SUBSCRIPTION_STATUS_UPDATED) {
                    // The subscription status changed. For example, a subscription
                    // has been recovered from a suspend state. Developers should
                    // expect the purchase token to be returned with this response
                    // code and use the purchase token with the Google Play
                    // Developer API.
                }
            }
        })

Java

InAppMessageParams inAppMessageParams = InAppMessageParams.newBuilder()
        .addInAppMessageCategoryToShow(InAppMessageCategoryId.TRANSACTIONAL)
        .build();

billingClient.showInAppMessages(activity,
        inAppMessageParams,
        new InAppMessageResponseListener() {
            @Override
            public void onInAppMessageResponse(InAppMessageResult inAppMessageResult) {
                if (inAppMessageResult.responseCode
                        == InAppMessageResponseCode.NO_ACTION_NEEDED) {
                    // The flow has finished and there is no action needed from developers.
                } else if (inAppMessageResult.responseCode
                        == InAppMessageResponseCode.SUBSCRIPTION_STATUS_UPDATED) {
                    // The subscription status changed. For example, a subscription
                    // has been recovered from a suspend state. Developers should
                    // expect the purchase token to be returned with this response
                    // code and use the purchase token with the Google Play
                    // Developer API.
                }
            }
        });