Vendre des abonnements

Cet article explique comment gérer les événements du cycle de vie des abonnements, tels que les renouvellements et les expirations. Il décrit également d'autres fonctionnalités d'abonnement, comme offrir des promotions et permettre aux utilisateurs de gérer leurs propres abonnements.

Si vous n'avez pas configuré de produits sur abonnement pour votre application, consultez Créer et configurer vos produits.

Aperçu des abonnements

Un abonnement représente un ensemble d'avantages auxquels les utilisateurs peuvent accéder pendant une période donnée. Il peut, par exemple, donner à un utilisateur l'accès à un service de streaming musical.

Plusieurs abonnements peuvent être proposés dans la même application, soit pour représenter des avantages complètement différents, soit pour différents niveaux d'un même ensemble d'avantages (niveaux "Silver" ou "Gold", par exemple).

Grâce aux forfaits de base et aux offres, plusieurs configurations sont possibles pour le même produit sur abonnement. Par exemple, vous pouvez créer une offre de bienvenue pour les utilisateurs qui ne se sont jamais abonnés à votre application. Parallèlement, vous pouvez créer une offre de mise à niveau pour les utilisateurs déjà abonnés.

Pour découvrir une présentation détaillée des produits sur abonnement, des forfaits de base et des offres, consultez la documentation correspondante dans le Centre d'aide de la Play Console.

Intégration des forfaits prépayés

Les forfaits prépayés ne sont pas renouvelés automatiquement à l'expiration. Pour prolonger l'accès à son abonnement sans interruption, l'utilisateur doit recharger son forfait prépayé pour le même abonnement.

Pour les recharges de forfait, lancez le processus de facturation comme vous le feriez avec l'achat d'origine. Vous n'avez pas besoin d'indiquer que l'achat correspond ici à une recharge de forfait.

Les recharges de forfait prépayé utilisent toujours le mode de calcul au prorata IMMEDIATE_AND_CHARGE_FULL_PRICE, et vous n'avez pas besoin de définir ce mode explicitement. L'utilisateur paie immédiatement pour une période de facturation complète, et son droit d'accès est prolongé pour la durée spécifiée dans la recharge.

Après une recharge, les champs suivants de l'objet de résultat Purchase sont mis à jour pour refléter l'achat de la recharge de forfait la plus récente :

• ID de commande
• Heure d'achat
• Signature
• Jeton d'achat
• Confirmation

Les champs Purchase suivants contiennent toujours les mêmes données que celles de l'achat d'origine :

• Nom du package
• État de l'achat
• Produits
• Renouvellement automatique

Confirmation d'achat prépayé

Comme pour les abonnements à renouvellement automatique, vous devez confirmer les forfaits prépayés après l'achat. L'achat initial et les recharges de forfait doivent être confirmés. Pour en savoir plus, consultez Traiter les achats.

En raison de la courte durée des forfaits prépayés, il est important de confirmer l'achat dès que possible.

Les forfaits prépayés d'une durée minimale d'une semaine doivent être confirmés dans un délai de trois jours.

Les forfaits prépayés d'une durée inférieure à une semaine doivent être confirmés dans un délai correspondant à la moitié de la durée du forfait. Par exemple, les développeurs ont 1,5 jour pour confirmer un forfait prépayé de trois jours.

Permettre aux utilisateurs de gérer un abonnement à l'aide de liens profonds

En tant que développeur, vous devez permettre aux utilisateurs de gérer facilement leur abonnement, généralement à l'aide d'un lien sur l'écran des paramètres ou des préférences de votre application. Consultez la figure 4 pour voir un exemple.

Dans le gestionnaire de clics de ce lien, ajoutez la logique nécessaire pour déterminer si l'utilisateur possède des abonnements n'ayant pas encore expiré pour votre application, où expiryTime correspond à une date à venir ou autoRenewing est défini sur true.

L'attribut productId de chaque abonnement correspond à l'ID produit que vous lui avez attribué lors de sa création dans la Play Console. Pour déterminer de manière programmatique le productId d'un abonnement existant, interrogez le backend de votre application afin d'obtenir la liste des abonnements associés à un utilisateur particulier.

Si l'abonnement de l'utilisateur n'a pas expiré, vous pouvez rediriger celui-ci vers une URL semblable à la suivante, en remplaçant "your-sub-product-id" et "your-app-package" par l'ID d'abonnement et le package de votre application :

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

Si tous les abonnements ont expiré dans votre application, utilisez l'URL suivante pour rediriger l'utilisateur vers la page présentant tous ses autres abonnements, comme illustré dans les figures 5 et 6 :

https://play.google.com/store/account/subscriptions

Vous trouverez un exemple de code pour la logique du lien d'abonnement dans l'application exemple Classy Taxi.

Autoriser les utilisateurs à changer d'abonnement (pour passer à un forfait supérieur ou inférieur)

Vous pouvez proposer aux utilisateurs différents niveaux d'abonnement, tels qu'un niveau de base et un niveau Premium. La figure 7 présente un écran proposant deux niveaux d'abonnement :

Les utilisateurs doivent pouvoir accéder à un écran semblable à la figure 7 pour passer à un forfait supérieur ou inférieur. Dans ce cas, vous pouvez définir le mode de calcul au prorata, qui déterminera l'impact de ce changement sur vos abonnés.

Le tableau suivant répertorie les modes de calcul disponibles :

Si l'utilisateur change de forfait, vous devez spécifier le taux de prorata au moment de l'exécution. Pour permettre le changement de forfait, vous ne pouvez pas spécifier de mode de calcul du prorata par défaut via la Google Play Console.

Si l'utilisateur ne modifie pas les droits d'abonnement, vous pouvez utiliser le mode de calcul au prorata par défaut configuré dans la Play Console. Vous pouvez également remplacer ce comportement en spécifiant un mode de calcul au prorata dans SubscriptionUpdateParams. Notez les restrictions suivantes :

• En cas de passage à un abonnement de niveau supérieur ou inférieur, ou en cas de changement de forfait sans modifier le niveau de l'abonnement (passage d'un certain type de forfait prépayé à un autre ou d'un forfait à renouvellement automatique à un forfait prépayé), le seul mode de calcul au prorata autorisé est IMMEDIATE_AND_CHARGE_FULL_PRICE. Si vous spécifiez un autre mode de calcul au prorata, l'achat échoue, et une erreur s'affiche.
• Lorsque vous changez de forfait dans un même abonnement et que vous passez d'un forfait prépayé au renouvellement automatique, les modes de calcul au prorata valides sont IMMEDIATE_AND_CHARGE_FULL_PRICE et IMMEDIATE_WITHOUT_PRORATION. Si vous spécifiez un autre mode de calcul au prorata, l'achat échoue, et une erreur s'affiche.

Exemples de calcul au prorata

Pour comprendre le fonctionnement de chaque mode de calcul au prorata, prenons le scénario suivant :

Samuel a souscrit un abonnement au contenu en ligne de l'application Jardiniers en herbe. Il dispose actuellement d'un abonnement mensuel au niveau 1 dont le contenu se limite à du texte. Cet abonnement coûte 2 € par mois. Il est renouvelé le premier du mois.

Le 15 avril, Samuel choisit de passer à la version annuelle de l'abonnement de niveau 2, qui inclut du contenu vidéo et coûte 36 € par an.

Lors du changement d'abonnement, le développeur sélectionne un mode de calcul au prorata. La liste suivante décrit l'impact de chaque mode de calcul au prorata sur l'abonnement de Samuel :

IMMEDIATE_WITH_TIME_PRORATION

L'abonnement au niveau 1 de Samuel prend fin immédiatement. Étant donné qu'il a payé pour un mois complet (du 1er au 30 avril), mais qu'il s'est abonné à un forfait supérieur en plein milieu de la période d'abonnement, 1 € (qui correspond à la moitié restante du mois) est appliqué à son nouvel abonnement. Toutefois, comme ce nouvel abonnement coûte 36 € par an, le solde de 1 € ne couvre que 10 jours (du 16 au 25 avril). Par conséquent, le 26 avril, il sera facturé 36 € pour le nouvel abonnement et 36 € supplémentaires le 26 avril de chaque année par la suite.

IMMEDIATE_AND_CHARGE_PRORATED_PRICE

Ce mode peut être utilisé, car le prix par unité de temps de l'abonnement de niveau 2 (36 €/an = 3 €/mois) est supérieur à celui du niveau 1 (2 €/mois). L'abonnement au niveau 1 de Samuel prend fin immédiatement. Étant donné qu'il a payé un mois complet, mais n'en a utilisé que la moitié, le montant équivalant à la moitié restante (1 €) est appliqué à son nouvel abonnement. Toutefois, comme ce nouvel abonnement coûte 36 €/an, les 15 jours restants coûtent 1,50 €. La différence de 0,50 € lui est donc facturée pour son nouvel abonnement. Le 1er mai, Samuel sera facturé 36 € pour son nouveau niveau d'abonnement, et 36 € supplémentaires le 1er mai de chaque année par la suite.

IMMEDIATE_WITHOUT_PRORATION

L'abonnement au niveau 1 de Samuel est immédiatement remplacé par le niveau 2, sans frais supplémentaires. Le 1er mai, il est facturé 36 € pour son nouvel abonnement et devra payer 36 € supplémentaires le 1er mai de chaque année par la suite.

DEFERRED

L'abonnement au niveau 1 de Samuel continue jusqu'à son expiration le 30 avril. Le 1er mai, l'abonnement au niveau 2 prendra effet, et Samuel sera facturé 36 € pour son nouveau niveau d'abonnement.

IMMEDIATE_AND_CHARGE_FULL_PRICE

L'abonnement au niveau 1 de Samuel est immédiatement résilié. Son abonnement au niveau 2 commence aujourd'hui, et il doit payer 36 €. Étant donné qu'il a payé un mois complet, mais n'en a utilisé que la moitié, le montant équivalant à la moitié restante (1 €) est appliqué à son nouvel abonnement. Comme ce nouvel abonnement coûte 36 €/an, il reçoit 1/36e d'année en plus de sa période d'abonnement (ce qui correspond à environ 10 jours). La prochaine facture de Samuel devra donc être payée dans un an et 10 jours à partir d'aujourd'hui pour un montant de 36 €. Ensuite, il sera facturé 36 € chaque année.

Lorsque vous choisissez un mode de calcul au prorata, veillez à consulter nos recommandations.

Votre application peut proposer aux utilisateurs de changer de niveau d'abonnement en suivant la même procédure que pour le lancement d'un parcours d'achat. Toutefois, lors du passage à un niveau supérieur ou inférieur, vous devez fournir des informations sur l'abonnement actuel, l'abonnement futur (niveau supérieur ou inférieur) et le mode de calcul au prorata à utiliser, comme illustré dans l'exemple suivant :

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
            .setOldSkuPurchaseToken("old_purchase_token")
            .setReplaceSkusProrationMode(ProrationMode.IMMEDIATE_AND_CHARGE_FULL_PRICE)
            .build())
    .build();

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

// process purchase results from PurchasesUpdatedListener registered with BillingClient
public void onPurchaseUpdated(BillingResult billingResult, @Nullable List<Purchase> purchases) {
  // check BillingResult
  // process returned Purchase list, e.g. grant entitlement
}

Pour les modes de remplacement au prorata, votre application reçoit le nouvel achat dans PurchasesUpdatedListener. L'achat est également disponible dans BillingClient.queryPurchasesAsync(). Lorsque vous recevez le jeton d'achat, suivez le même processus de validation qu'avec un nouveau jeton. Confirmez ces achats avec BillingClient.acknowledgePurchase() depuis la bibliothèque Google Play Billing ou avec Purchases.subscriptions:acknowledge depuis l'API Google Play Developer.

L'API Google Play Developer renvoie un linkedPurchaseToken dans la ressource d'abonnement. Veillez à invalider le jeton fourni dans linkedPurchaseToken afin que l'ancien jeton ne soit pas utilisé pour accéder à vos services. Consultez Changements de niveau d'abonnement et réinscriptions pour en découvrir comment gérer les changements de niveau d'abonnement.

Pour le mode de remplacement différé, votre application reçoit un appel à PurchasesUpdatedListener avec l'achat du forfait d'abonnement d'origine et un état indiquant si le passage au niveau d'abonnement supérieur ou inférieur a abouti. BillingClient.queryPurchasesAsync() continue de renvoyer l'achat du forfait d'origine jusqu'à ce que le remplacement soit effectif. Une fois le nouveau forfait appliqué, queryPurchasesAsync() renvoie les données d'achat du nouvel abonnement, et une notification SUBSCRIPTION_RENEWED est envoyée à votre serveur backend sécurisé. Pour les remplacements différés, il est fortement recommandé d'écouter cette notification et de confirmer l'achat à l'aide de Purchases.subscriptions:acknowledge. Le jeton linkedPurchaseToken de la ressource d'abonnement peut servir à déterminer quel utilisateur, le cas échéant, doit recevoir le nouveau forfait dans votre backend d'abonnement. Votre application ne doit pas attendre que l'utilisateur y accède ou qu'il confirme le changement via BillingClient.acknowledgePurchase(), car il se peut qu'il n'ouvre pas l'application dans les trois jours suivant le changement de forfait.

Passer à un abonnement supérieur avec une offre d'essai gratuit ou une offre prix découverte

Les paramètres d'éligibilité à l'essai gratuit s'appliquent lorsqu'un utilisateur passe à un niveau d'abonnement supérieur ou inférieur. Vous pouvez modifier les paramètres d'éligibilité à l'essai gratuit dans la Google Play Console.

Remarques :

• Si les utilisateurs ne peuvent bénéficier que d'un seul essai gratuit pour tous les abonnements disponibles dans votre application, le forfait auquel passe un abonné n'offrira pas d'essai gratuit ni de prix découverte.
• Si vous proposez un essai gratuit par produit sur abonnement, il se peut que l'utilisateur puisse bénéficier d'un essai gratuit ou d'un prix découverte.

Dans le tableau suivant, vous trouverez la description du comportement de chaque mode au prorata si les nouveaux et les anciens forfaits incluent un essai gratuit, et que l'utilisateur passe à un forfait supérieur au cours de l'essai gratuit :

Pour comprendre le fonctionnement des transferts d'essai gratuit dans le cas par défaut d'un essai gratuit par application, prenons le scénario suivant :

Marie a souscrit un abonnement au contenu en ligne de l'application Jardiniers en herbe. Elle dispose actuellement d'un abonnement mensuel au niveau 1 dont le contenu se limite à du texte. Cet abonnement, qui coûte 10 €/mois, a commencé le 1er avril. En tant que nouvelle abonnée, elle bénéficie d'un essai gratuit de 30 jours. Son premier paiement est dû le 1er mai.

Le 15 avril, Marie choisit de passer à un abonnement de niveau 2, qui comprend du contenu vidéo et coûte 20 €/mois. Ce deuxième abonnement compte une période d'essai gratuit de 30 jours également.

La liste suivante décrit le transfert de l'essai gratuit pour chaque mode de calcul au prorata :

• IMMEDIATE_WITH_TIME_PRORATION : Marie passe immédiatement au niveau 2. Étant donné qu'elle a changé de niveau à la moitié de la période d'abonnement, un montant correspondant à la moitié de l'abonnement mensuel (à savoir 10 € pour une utilisation de 15 jours) est appliqué à son nouvel abonnement. Toutefois, comme ce nouvel abonnement coûte 20 €/mois, le solde pour 15 jours ne couvre que 7,5 jours. Marie ne peut pas bénéficier d'un autre essai gratuit pour le niveau 2. À partir du 22 avril, l'abonnement lui sera facturé 20 € par mois.
• IMMEDIATE_AND_CHARGE_PRORATED_PRICE : ce mode peut être utilisé, car le prix de l'abonnement du niveau 2 par unité de temps (20 €/mois) est supérieur à celui du niveau 1 (10 €/mois). L'abonnement de niveau 1 de Marie passe immédiatement au niveau 2 et elle perd son essai gratuit. Puisque la prochaine date de facturation de Marie est le 1er mai, 10 € sont facturés aujourd'hui pour la deuxième moitié du mois d'avril, puis elle devra payer 20 € par mois à partir du 1er mai.
• IMMEDIATE_WITHOUT_PRORATION : l'abonnement de niveau 1 de Marie est immédiatement remplacé par le niveau 2. Elle conserve son essai gratuit jusqu'au 30 avril et a désormais accès au contenu du niveau 2. À partir du 1er mai, elle sera facturée 20 € par mois.
• DEFERRED : l'abonnement de niveau 1 de Marie continue jusqu'au prochain paiement dû le 1er mai. Le 1er mai, l'abonnement au niveau 2 prendra effet, et Marie devra payer 20 € le premier de chaque mois.
• IMMEDIATE_AND_CHARGE_FULL_PRICE : l'abonnement de niveau 1 de Marie passe immédiatement au niveau 2 et elle perd son essai gratuit. Elle doit payer 20 € aujourd'hui. Comme il lui reste 15 jours d'essai gratuit, la prochaine date de facturation sera dans 1 mois + 15 jours, à savoir le 1er juillet. À partir du 1er juillet, elle sera facturée 20 € par mois.

La liste suivante décrit le fonctionnement des transferts d'essai gratuit si le développeur autorise un seul essai gratuit par abonnement :

• IMMEDIATE_WITH_TIME_PRORATION : Marie passe immédiatement au niveau 2. Étant donné qu'elle a changé de niveau à la moitié de la période d'abonnement, un montant correspondant à la moitié de l'abonnement mensuel (à savoir 10 € pour une utilisation de 15 jours) est appliqué à son nouvel abonnement. Toutefois, comme ce nouvel abonnement coûte 20 €/mois, le solde pour 15 jours ne couvre que 7,5 jours. Marie peut bénéficier d'un nouvel essai gratuit pour le niveau 2. Par conséquent, l'abonnement ne lui sera facturé qu'après 37,5 jours. À partir du 22 mai, elle sera facturée 20 € par mois.
• IMMEDIATE_AND_CHARGE_PRORATED_PRICE : ce mode peut être utilisé, car le prix de l'abonnement du niveau 2 par unité de temps (20 €/mois) est supérieur à celui du niveau 1 (10 €/mois). L'abonnement de niveau 1 de Marie passe immédiatement au niveau 2 et elle perd son essai gratuit. Puisque la prochaine date de facturation de Marie est le 1er mai, 10 € sont facturés aujourd'hui pour la deuxième moitié du mois d'avril, puis elle devra payer 20 € par mois à partir du 1er mai.
• IMMEDIATE_WITHOUT_PRORATION : l'abonnement de niveau 1 de Marie est immédiatement remplacé par le niveau 2. Elle conserve son essai gratuit jusqu'au 30 avril et a désormais accès au niveau 2.
• DEFERRED : l'abonnement de niveau 1 de Marie continue jusqu'au prochain paiement dû le 1er mai. Le 1er mai, l'abonnement au niveau 2 prendra effet, et Marie devra payer 20 € le premier de chaque mois.
• IMMEDIATE_AND_CHARGE_FULL_PRICE : l'abonnement de niveau 1 de Marie passe immédiatement au niveau 2 et elle perd son essai gratuit. Elle doit payer 20 € aujourd'hui. Comme il lui reste 15 jours d'essai gratuit, la prochaine date de facturation sera dans 1 mois + 15 jours, à savoir le 1er juillet. À partir du 1er juillet, elle sera facturée 20 € par mois.

Recommandations de calcul au prorata

Le tableau suivant présente les différents scénarios de calcul au prorata, ainsi que des recommandations pour chacun d'eux :

Gestion des utilisateurs

Le recours à des notifications en temps réel pour les développeurs vous permet de détecter en temps réel quand un utilisateur décide de résilier son abonnement. Lorsque cela se produit avant l'expiration de son abonnement, vous pouvez lui envoyer des notifications push ou des messages dans l'application pour lui proposer de se réabonner.

Une fois qu'un utilisateur a résilié son abonnement, vous pouvez essayer de le reconquérir dans votre application ou sur le Play Store. Le tableau suivant décrit plusieurs scénarios d'abonnement, ainsi que les actions que vous pouvez effectuer pour convaincre l'utilisateur de se réabonner, ainsi que les conditions requises dans l'application.

Avant l'expiration de l'abonnement (dans l'application)

Pour les abonnements qui ont été résiliés, mais qui n'ont pas encore expiré, vous pouvez autoriser les abonnés à restaurer leur abonnement dans votre application en appliquant le même parcours d'achat de produit intégré à l'application que pour les nouveaux abonnés. Assurez-vous que l'UI indique à l'utilisateur qu'il existe déjà un abonnement. Par exemple, vous pouvez afficher la date d'expiration actuelle et le prix récurrent correspondant à l'utilisateur à l'aide d'un bouton Réactiver.

La plupart du temps, il est préférable d'offrir à l'utilisateur le prix et le SKU auxquels il était déjà abonné. Pour ce faire, procédez comme suit :

• Initiez un nouvel abonnement avec le même SKU.
• Le nouvel abonnement remplace l'ancien et se renouvelle à la même date d'expiration. L'ancien abonnement est immédiatement marqué comme ayant expiré.
• Par exemple, Antoine dispose d'un abonnement à l'appli musicale XXX, lequel doit expirer le 1er août. Le 10 juillet, il se réabonne mensuellement au même prix. Le nouvel abonnement est calculé au prorata du crédit restant. Il est immédiatement actif et se renouvellera également le 1er août.

Si vous souhaitez proposer un autre prix, par exemple un nouvel essai gratuit ou une remise spéciale, vous pouvez proposer un autre SKU à l'utilisateur :

• Initiez le passage à un niveau supérieur ou inférieur avec cet autre SKU en utilisant le mode de calcul au prorata IMMEDIATE_WITHOUT_PRORATION.
• Le nouvel abonnement remplace l'ancien et se renouvelle à la même date d'expiration. Le prix du nouveau SKU (y compris le prix découverte) est facturé à l'utilisateur à la date d'expiration d'origine. Si l'ancien abonnement a été créé avec un ID de compte obscurci, ce même ID doit être transmis à BillingFlowParams pour les changements d'abonnement (passage à un niveau supérieur ou inférieur).
• Par exemple, Antoine dispose d'un abonnement à l'appli musicale XXX, lequel doit expirer le 1er août. Le 10 juillet, il se réabonne annuellement avec un prix découverte. Le nouvel abonnement est immédiatement actif, et le prix de lancement est facturé à l'utilisateur le 1er août.
• Si vous décidez d'inclure un essai gratuit ou un prix découverte dans le SKU visant à reconquérir un client, décochez l'option Autoriser un essai gratuit par application dans la Google Play Console pour que l'utilisateur ne soit plus limité à un seul essai gratuit par application.

Une fois le jeton d'achat reçu, traitez l'achat comme vous le feriez avec un nouvel abonnement. De plus, l'API Google Play Developer renvoie un linkedPurchaseToken dans la ressource d'abonnement. Veillez à invalider le jeton fourni dans linkedPurchaseToken afin que l'ancien jeton ne soit pas utilisé pour accéder à vos services.

Avant l'expiration de l'abonnement (sur le Play Store)

Tant que l'abonnement est résilié, mais qu'il reste actif, les utilisateurs peuvent le restaurer dans le centre d'abonnements Google Play. Pour ce faire, il leur suffit de cliquer sur Resubscribe (Se réabonner) (anciennement Restore (Restaurer)). Le même jeton d'abonnement et d'achat est alors conservé.

Pour en savoir plus sur la restauration d'abonnements, consultez la section Restaurations.

Après l'expiration de l'abonnement (dans l'application)

Pour autoriser les personnes dont l'abonnement est arrivé à expiration à se réabonner dans votre application, appliquez le même parcours d'achat de produit intégré que pour les nouveaux abonnés. Notez les points suivants :

• Pour offrir aux utilisateurs une remise, vous pouvez fournir un ID produit avec un tarif spécial pour votre abonnement, également appelé SKU spécial. Ce SKU vise à reconquérir un client. Vous pouvez proposer cette offre dans votre application ou en informer l'utilisateur en dehors de l'application, par exemple dans un e-mail.
• Pour lancer un abonnement visant à reconquérir un client, démarrez le parcours d'achat dans votre application Android à l'aide de la bibliothèque Google Play Billing. Le processus est le même que pour un nouvel abonnement, mais vous pouvez déterminer le SKU disponible pour l'utilisateur.
• Si vous décidez d'inclure un essai gratuit ou un prix découverte dans le SKU visant à reconquérir un client, décochez l'option Autoriser un essai gratuit par application dans la Google Play Console pour que l'utilisateur ne soit plus limité à un seul essai gratuit par application.
• Si l'utilisateur se réabonne au même SKU, il ne pourra plus bénéficier des essais gratuits ni du prix découverte. Assurez-vous que votre UI lui indique clairement cet état de fait.

Une fois le jeton d'achat reçu, traitez l'achat comme vous le feriez avec un nouvel abonnement. Vous ne recevrez pas de linkedPurchaseToken dans la ressource d'abonnement.

Après l'expiration de l'abonnement (sur le Play Store)

Si cette option est activée, les utilisateurs peuvent se réabonner au même SKU jusqu'à un an après l'expiration. Pour ce faire, il leur suffit de cliquer sur Resubscribe (Se réabonner) dans le centre d'abonnements Google Play. Un nouvel abonnement et un nouveau jeton d'achat sont alors générés.

Le réabonnement est considéré comme un achat hors application. Assurez-vous donc de suivre les bonnes pratiques pour gérer ces types d'achat.

Faire la promotion de votre abonnement

Vous pouvez créer des codes promotionnels afin d'offrir à des utilisateurs spécifiques un essai gratuit prolongé pour un abonnement existant. Pour en savoir plus, consultez Codes promotionnels.

Pour les essais gratuits, Google Play vérifie que l'utilisateur dispose d'un mode de paiement valide avant de commencer l'essai gratuit. Pour certains utilisateurs, cette vérification prend la forme d'une retenue ou d'un débit sur leur mode de paiement. Il s'agit d'une retenue ou d'un débit temporaire, qui sera annulé ou remboursé ultérieurement.

À la fin de la période d'essai, le montant total de l'abonnement est facturé sur le mode de paiement de l'utilisateur.

Si un utilisateur résilie un abonnement pendant l'essai gratuit, l'abonnement reste actif jusqu'à la fin de l'essai et n'est pas facturé à la fin de la période d'essai.

Résilier, rembourser ou révoquer un abonnement

Vous pouvez utiliser l'API Google Play Developer pour résilier, rembourser ou révoquer un abonnement. Cette fonctionnalité est également disponible dans la Google Play Console.

• Résiliation : les utilisateurs peuvent résilier un abonnement sur Google Play. Vous pouvez également leur proposer de le résilier dans votre application ou sur votre site Web. Votre application doit gérer ces résiliations comme décrit dans la section Révocations.
• Remboursement : lorsque vous remboursez un abonnement, l'utilisateur peut continuer à l'utiliser. Un remboursement peut avoir lieu, par exemple, si une erreur technique a empêché l'utilisateur d'accéder à votre produit, mais que l'erreur a été résolue. Notez que pour effectuer un remboursement supérieur au dernier paiement, ou si vous souhaitez réaliser un remboursement partiel, vous devez utiliser la Google Play Console.
• Révocation : lorsque vous révoquez un abonnement, l'utilisateur en perd immédiatement l'accès. Vous pouvez utiliser cette option si, par exemple, une erreur technique a empêché l'utilisateur d'accéder à votre produit et qu'il ne souhaite pas continuer à l'utiliser. Votre application doit gérer ces résiliations comme décrit dans la section Révocations.

Le tableau suivant illustre les différences entre la résiliation, le remboursement et la révocation.

Reporter la facturation d'un abonné

Pour avancer la prochaine date de facturation d'un abonnement à renouvellement automatique, utilisez Purchases.subscriptions:defer dans l'API Google Play Developer. Pendant la période de report, l'utilisateur reste abonné à votre contenu avec un accès complet, mais n'est pas facturé. La date de renouvellement de l'abonnement est mise à jour pour refléter la nouvelle date.

Pour les forfaits prépayés, vous pouvez utiliser l'API de facturation différée pour reporter la date d'expiration.

La facturation différée vous permet d'effectuer les actions suivantes :

• Proposer aux utilisateurs un accès gratuit en tant qu'offre spéciale, par exemple en leur offrant une semaine gratuite lorsqu'ils achètent un film
• Proposer un accès gratuit aux clients comme geste commercial

La facturation peut être différée pour une durée allant d'un jour à une année via un appel d'API. Pour différer davantage la facturation, vous pouvez appeler à nouveau l'API avant l'arrivée de la nouvelle date de facturation.

Par exemple, Isabelle dispose d'un abonnement mensuel au contenu en ligne d'une application de pêche. Elle est normalement facturée 1,25 € le premier de chaque mois. En mars, elle a participé à une enquête en ligne pour l'éditeur de l'application. Pour la remercier, l'éditeur lui offre six semaines gratuites et reporte le prochain paiement au 15 mai, soit six semaines après la date de facturation précédemment fixée au 1er avril. Isabelle ne devra rien payer en avril ni début mai, et conservera son accès au contenu. Le 15 mai, des frais d'abonnement standards de 1,25 € commenceront à lui être facturés de nouveau pour le mois. Le prochain renouvellement aura lieu le 15 juin.

Vous pouvez informer l'utilisateur par e-mail ou dans l'application que sa date de facturation a changé.

Gérer les refus de paiement

En cas de problème de paiement à la fin d'un cycle de facturation, Google tente régulièrement de renouveler l'abonnement pendant un certain temps avant de le résilier. Cette nouvelle tentative peut durer jusqu'à 30 jours, auxquels s'ajoute la durée du délai de grâce spécifié. Pendant ce temps, Google envoie également à l'utilisateur des e-mails et des notifications pour lui demander de mettre à jour son mode de paiement.

En cas de refus de paiement, l'abonnement est d'abord soumis à un délai de grâce, s'il est activé. Pendant ce temps, l'utilisateur conserve l'accès à l'abonnement.

À l'expiration du délai de grâce, l'abonnement est soumis à un blocage de compte pouvant durer jusqu'à 30 jours. Pendant le blocage de compte, vous pouvez empêcher l'accès à l'abonnement.

Pour optimiser les chances de récupération d'un abonnement en cas de refus de paiement, vous pouvez signaler le problème de paiement à l'utilisateur et lui demander de le résoudre.

Vous pouvez soit le faire directement, comme décrit dans les sections Délai de grâce et Blocage de compte, soit implémenter l'API de messagerie dans l'application, dans laquelle Google enverra un message aux utilisateurs de votre application.

Messagerie dans l'application

Si vous avez activé la messagerie dans l'application avec InAppMessageCategoryId.TRANSACTIONAL, Google Play présente aux utilisateurs un message par jour au cours du délai de grâce et du blocage de compte, et leur donne la possibilité de régler leur achat sans quitter l'application.

Nous vous recommandons d'appeler cette API chaque fois que l'utilisateur ouvre l'application pour déterminer si le message doit être affiché.

Si l'utilisateur a récupéré son abonnement, vous recevrez un code de réponse de SUBSCRIPTION_STATUS_UPDATED ainsi qu'un jeton d'achat. Vous devez ensuite utiliser ce jeton d'achat pour appeler l'API Google Play Developer et actualiser l'état de l'abonnement dans votre application.

Intégrer la messagerie dans l'application

BillingClient.showInAppMessages() permet de présenter la messagerie dans l'application aux utilisateurs.

Voici un exemple de déclenchement du flux de messagerie dans l'application :

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