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 :
Mode de calcul au prorata | Description |
---|---|
IMMEDIATE_WITH_TIME_PRORATION |
L'abonnement passe à un forfait supérieur ou inférieur immédiatement. Le temps restant est ajusté en fonction de la différence de prix, puis crédité sur le nouvel abonnement en repoussant la prochaine date de facturation. Il s'agit du comportement par défaut. |
IMMEDIATE_AND_CHARGE_PRORATED_PRICE |
L'abonnement passe à un niveau supérieur immédiatement, et le cycle de facturation reste le même. La différence de prix pour la période restante est ensuite facturée à l'utilisateur. |
IMMEDIATE_WITHOUT_PRORATION |
L'abonnement passe à un forfait supérieur ou inférieur immédiatement, et le nouveau tarif est facturé lors du renouvellement de l'abonnement. Le cycle de facturation reste le même. |
DEFERRED |
L'abonnement ne passe à un forfait supérieur ou inférieur qu'au moment du renouvellement. |
IMMEDIATE_AND_CHARGE_FULL_PRICE |
L'abonnement passe au forfait supérieur ou inférieur, et l'utilisateur paie immédiatement le tarif complet du nouveau forfait. La valeur restante de l'abonnement précédent est transférée sur le nouveau forfait ou calculée au prorata de la durée restante au moment du changement de forfait. |
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
etIMMEDIATE_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 :
Un essai gratuit par application | Un essai gratuit par produit sur abonnement | |
IMMEDIATE_WITH_TIME_PRORATION | L'utilisateur perd immédiatement l'accès à l'essai gratuit. La période restante de l'essai gratuit est convertie en période gratuite équivalente pour le nouveau niveau d'abonnement en tenant compte de la différence de prix. | L'utilisateur perd l'accès à l'essai gratuit précédent, mais entame immédiatement le nouvel essai gratuit. En outre, la période d'essai gratuit restante pour l'ancien niveau est convertie en période d'essai gratuit équivalente pour le nouveau niveau et est ajoutée au nouvel essai gratuit. |
IMMEDIATE_AND_CHARGE_PRORATED_PRICE |
L'utilisateur perd immédiatement l'accès à l'essai gratuit. La différence de prix pour la période restante est ensuite facturée à l'utilisateur. La date de facturation suivante reste inchangée. Remarque : Cette option n'est disponible que pour le passage à un abonnement de niveau supérieur, où le prix par unité de temps augmente. |
|
IMMEDIATE_WITHOUT_PRORATION | L'utilisateur passe immédiatement au nouveau niveau. Il conserve l'accès à l'essai gratuit pour le nouveau niveau jusqu'à la fin de la période de facturation précédente. | |
DEFERRED | L'utilisateur conserve l'accès à l'essai gratuit correspondant à l'ancien abonnement jusqu'à la prochaine date de facturation. | |
IMMEDIATE_AND_CHARGE_FULL_PRICE | L'utilisateur perd immédiatement l'accès à l'essai gratuit. Le prix du nouvel abonnement est ensuite facturé à l'utilisateur. La date de facturation suivante correspond à la nouvelle période d'abonnement, plus le temps restant avant la fin 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 :
Scénario | Mode de calcul au prorata recommandé | Résultat |
---|---|---|
Passer à un niveau d'abonnement plus cher | IMMEDIATE_AND_CHARGE_PRORATED_PRICE |
L'utilisateur reçoit l'accès immédiatement tout en conservant la même période de facturation. |
Passer à un niveau d'abonnement moins cher | DEFERRED |
L'utilisateur a déjà payé le niveau supérieur, qui est plus cher. Il conservera donc son accès jusqu'à la prochaine date de facturation. |
Modifier la période récurrente pour le même niveau (par exemple, passer d'une période mensuelle à annuelle) | DEFERRED |
L'utilisateur paiera le nouveau prix récurrent à la prochaine date de facturation. |
Passer à un niveau d'abonnement supérieur pendant un essai gratuit et conserver l'essai gratuit | IMMEDIATE_WITHOUT_PRORATION |
L'utilisateur conserve l'accès à l'essai gratuit, mais passe à un niveau supérieur jusqu'à la fin de l'essai. |
Passer à un niveau d'abonnement supérieur pendant un essai gratuit avec résiliation de l'essai gratuit | IMMEDIATE_AND_CHARGE_PRORATED_PRICE |
L'utilisateur a immédiatement accès au nouveau niveau, mais ne bénéficie plus d'un essai gratuit. |
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 | Après l'expiration de l'abonnement | |||
Dans l'application | Sur le Play Store | Dans l'application | Sur le Play Store | |
Fonctionnalité pour reconquérir les anciens abonnés | Abonnement via l'application | Restaurer | Abonnement via l'application | Se réabonner |
L'utilisateur passe par le processus de règlement | Oui | Non | Oui | Oui |
L'abonnement utilisateur reste associé au même SKU | L'utilisateur peut s'inscrire avec un SKU identique ou différent | Oui | L'utilisateur peut s'inscrire avec un SKU identique ou différent | Oui |
Crée un jeton d'achat | Oui | Non | Oui | Oui |
Activé par défaut | Non | Oui, prise en charge requise pour tous les développeurs | Non |
Applications sans bibliothèque Billing 2.0 ou version ultérieure : non Applications avec la bibliothèque Billing 2.0 ou version ultérieure : oui. Les développeurs peuvent désactiver cette option dans la console. |
Quand l'utilisateur est facturé |
Si vous utilisez le même SKU : fin de la période de facturation en cours. Si vous utilisez un autre SKU : dépend du mode de calcul au prorata. |
Fin de la période de facturation en cours | Immédiatement | Immédiatement |
Implémentation requise | Fournir une UI de réinscription dans votre application |
Détecter un changement d'état d'abonnement Créer un lien profond vers le Play Store |
Fournir une UI de réinscription dans votre application | Gérer les achats hors 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.
Met fin au renouvellement | Remboursement | Révocation de l'accès | |
Résiliation | Oui | Non | Non |
Remboursement | Non | Oui | Non |
Révocation | Oui | Oui | Oui |
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 :
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. } } });