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 a que os usuários têm acesso durante um determinado período, como um serviço de streaming de música, por exemplo.

É 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.

Integração de assinaturas em parcelas

As parcelas são um tipo de assinatura em que os usuários pagam pelo em várias parcelas ao longo de um período, em vez de pagar toda a taxa de assinatura antecipadamente.

Outras considerações para assinaturas parceladas:

• Disponibilidade por país: o recurso de assinaturas em parcelas está disponível apenas no Brasil, na França, na Itália e na Espanha (consulte o Console para conferir a disponibilidade mais recente).
• Definição do preço: ao definir o preço de uma assinatura parcelada no console, o preço representa o valor do pagamento mensal. Isso, combinado com o período de compromisso definido, gera o valor total para a assinatura na tela de compra.
• Período de compromisso: a duração total da assinatura inicial de serviço, o que exige pagamentos mensais. Por exemplo, se um plano básico tem um período de compromisso de 15 meses, o usuário fará 15 pagamentos ao longo desse período.
• Renovações: no contexto de parcelas, "renovação" significa a conclusão de um período de compromisso, seja o período de compromisso inicial período de compromisso subsequente. Após a inscrição inicial, a primeira renovação ocorre após a conclusão de todo o período de compromisso inicial. Depois as renovações ocorrem após o cumprimento de cada período de compromisso subsequente. A os tipos de renovação para parcelas podem ser "renovação automática todo mês" ou "renova automaticamente pela mesma duração". Para "renovação automática todo mês", não há compromisso subsequente, e o plano se comporta como uma assinatura mensal, na qual cada cobrança mensal de assinatura constitui uma renovação.
• Período de faturamento: no contexto de parcelas, isso se refere ao intervalo recorrente em que os pagamentos individuais são feitos, conforme especificado no plano básico.
• Mudança no plano x comportamentos de mudança de preço: para mudanças de preço e cancelamentos, o compromisso é firme. Isso significa que, se um usuário quiser cancelar ou se um desenvolvedor quiser alterar o preço, a alteração entrará em vigor em o fim de um período de compromisso. Para mudanças de plano, o compromisso não é firme. Isso significa que a mudança do plano não precisa esperar até o fim de um período de compromisso, ele entra em vigor imediatamente ou no próximo pagamento baseada no modo de substituição definido.
• Mudança do plano básico de parcelas: mudança do plano para um plano básico sem parcelas do mesmo produto por assinatura não é permitido.

• Notificações do desenvolvedor em tempo real (RTDNs, na sigla em inglês): uma SUBSCRIPTION_CANCELLATION_SCHEDULED As RTDNs são enviadas imediatamente após Cancelamento iniciado pelo usuário quando os pagamentos restantes para o período de compromisso. O cancelamento está pendente e entrará em vigor somente no final da período de compromisso. Então, se não for restaurado pelo usuário, SUBSCRIPTION_CANCELED e SUBSCRIPTION_EXPIRED RTDNs são enviadas no fim do período de compromisso.

• Pagamentos / realização de receita: os pagamentos aos desenvolvedores serão feitos à medida que os usuários fizerem com os pagamentos mensais, sujeito aos mesmos termos de todas as outras assinaturas. Os desenvolvedores não são pagos antecipadamente quando o usuário se inscreve para o parcelamento assinatura.

• Coletas de pagamento perdidas: se um usuário não efetuar uma parcela pagamentos de assinatura, nem o Google nem o Desenvolvedor tentarão coletar quaisquer pagamentos em aberto ou pendentes do usuário, exceto que o Google pode repetir periodicamente o pagamento durante qualquer período de carência ou Período de suspensão da conta de acordo com as práticas normais de novas tentativas de pagamento. O Google não será responsável perante o Desenvolvedor por nenhum pagamento restante em pagamentos parcelados.

• Disponibilidade da Biblioteca Play Faturamento: o campo installmentDetails fica apenas disponível para a Biblioteca Play Faturamento 7 ou posterior. Para a Biblioteca Play Faturamento 5 e versões mais recentes, a parcela uma assinatura é retornada usando queryProductDetails(), mas a não vai incluir informações detalhadas da parcela, como a contagem de pagamentos confirmados do plano.

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 para que os usuários possam gerenciar as assinaturas deles. Esse link pode ser incorporado à 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.

Link para a central de assinaturas

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

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

Link para uma página específica de gerenciamento de assinaturas (recomendado)

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:

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. e o número de pagamentos considerados pagos.

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, downgrade ou iniciar uma assinatura da mesma assinatura, para uma um plano pré-pago de um plano pré-pago, com renovação automática ou parcelamento; o modo de substituição permitido é CHARGE_FULL_PRICE. Se você especificar qualquer outro modo de substituição, 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.
• Mudar de plano em parcelas no mesmo produto por assinatura para um plano básico sem parcelas.

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:

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
   )
// ...

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:

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:

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: 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 gratuito 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 gratuito ou preço inicial no SKU de recuperação, torne o usuário qualificado para isso desmarcando a caixa Permitir um teste gratuito por app no Google Play Console, que restringe o usuário a apenas um teste gratuito 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.

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 gratuito ou preço inicial no SKU de recuperação, torne o usuário qualificado para isso desmarcando a caixa Permitir um teste gratuito por app no Google Play Console, que restringe o usuário a apenas um teste gratuito por app.
• Se o usuário fizer uma nova assinatura do mesmo SKU, ele não estará mais qualificado para testes gratuitos 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.

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 gratuito 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 gratuito. 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 gratuito, 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 Cancelamentos.
• 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 precisa lidar com isso cancelamentos, conforme descrito nos Revogações.

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

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 grátis como uma oferta especial, por exemplo, oferecendo uma semana de uso gratuito 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 renová-la 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 período de carência, se configurado. Durante esse período, verifique se o usuário ainda tem acesso aos direitos de assinatura.

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

É possível especificar a duração do período de carência e de suspensão de conta de cada plano básico com renovação automática no Google Play Console. Especificar durações 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.

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:

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.
                }
            }
        })

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.
                }
            }
        });

Processar transações de assinatura pendentes

Transações pendentes podem acontecer na primeira compra, recarga, upgrade ou fazer downgrade. A compra da assinatura começa com o Estado SUBSCRIPTION_STATE_PENDING antes da transição para SUBSCRIPTION_STATE_ACTIVE. Se a transação tiver expirado ou for cancelada pelo usuário, ela vai para SUBSCRIPTION_STATE_PENDING_PURCHASE_EXPIRED. Você deve e só devem atualizar o direito do usuário depois que a transação for concluído.

A mudança do estado da assinatura para a compra inicial com transações pendentes é simples. O app recebe um Purchase com o estado PENDING quando o usuário inicia uma transação pendente. Quando a transação for concluída, o o app recebe o Purchase novamente com o estado atualizado para PURCHASED. Um A mensagem SubscriptionNotification com o tipo SUBSCRIPTION_PURCHASED foi enviada ao seu cliente de RTDNs. Siga o processo normal para confirmar a compra, forneça o acesso do usuário ao conteúdo e confirmar a compra. Se a transação expirar ou for cancelada, uma mensagem do SubscriptionNotification com o tipo SUBSCRIPTION_PENDING_PURCHASE_CANCELED é enviado ao seu cliente de RTDN. Dessa forma, casos, o usuário nunca deve ter acesso ao conteúdo.

Recarga, upgrade ou downgrade com transações pendentes envolvem alterações de estado para as assinaturas antigas e novas. Quando o usuário inicia uma ação recarga, upgrade ou downgrade, seu app vai receber um Purchase por a assinatura antiga com um objeto PendingPurchaseUpdate. Neste momento, o usuário ainda é o proprietário da assinatura antiga e não obteve a nova por enquanto. Ligando para getProducts() e getPurchaseToken() no O objeto PendingPurchaseUpdate retorna os IDs dos produtos e o token de compra de a nova assinatura. Quando a transação é concluída, o app recebe uma Purchase pelo token de compra de nível superior definido para a nova assinatura e o estado definido como PURCHASED. Uma mensagem SubscriptionNotification com tipo SUBSCRIPTION_PURCHASED é enviado ao seu cliente de RTDN. Apenas no momento, você deve substituir o token de compra antigo pelo novo e atualizar o acesso do usuário ao conteúdo. Se a transação expirar ou for cancelada, uma SubscriptionNotification mensagem com tipo SUBSCRIPTION_PENDING_PURCHASE_CANCELED é enviado ao seu cliente de RTDN. Dessa forma, casos, o usuário ainda terá acesso ao conteúdo da assinatura antiga.