Rappel : À compter du 2 août 2022, toutes les nouvelles applications devront utiliser la bibliothèque Billing version 4 ou ultérieure. D'ici le 1er novembre 2022, toutes les mises à jour apportées aux applications existantes devront utiliser la bibliothèque Billing version 4 ou ultérieure. En savoir plus

Vendre des abonnements

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

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.

Avant de lire cette rubrique, consultez la page Intégrer la bibliothèque Google Play Billing à votre application pour découvrir, dans les grandes lignes, comment vendre et gérer des produits dans votre application.

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.

Gérer le cycle de vie des abonnements

Une fois souscrit, un abonnement peut subir plusieurs changements d'état tout au long de son cycle de vie, changements auxquels votre application doit s'adapter. Pour vérifier l'état de l'abonnement, votre application peut interroger l'un des éléments suivants : BillingClient.queryPurchasesAsync() dans la bibliothèque Google Play Billing ou Purchases.subscriptionsv2:get dans l'API Google Play Developer.

BillingClient.queryPurchasesAsync() Purchases.subscriptionsv2:get
État Est renvoyé ? isAutoRenewing Est renvoyé ? expiryTime subscriptionState autoRenewing
Actif Oui Vrai Oui Date future SUBSCRIPTION_STATE_ACTIVE Vrai
Annulé Oui Faux Oui Date future SUBSCRIPTION_STATE_CANCELED Faux
En délai de grâce Oui Vrai Oui À venir (fin du délai de grâce) SUBSCRIPTION_STATE_IN_GRACE_PERIOD Vrai
En attente Non N/A Oui Date dépassée (fin du délai d'expiration attendu ou fin du délai de grâce, le cas échéant) SUBSCRIPTION_STATE_ON_HOLD Vrai
En pause Non N/A Oui Date dépassée SUBSCRIPTION_STATE_PAUSED Vrai
A expiré Non N/A Oui Date dépassée SUBSCRIPTION_STATE_EXPIRED Faux

Si votre application stocke l'état d'un abonnement sur un serveur backend sécurisé, vous devez écouter les changements d'état à l'aide des notifications en temps réel pour les développeurs afin de vous assurer que l'état reste synchronisé. Un élément SubscriptionNotification est envoyé pour les événements affectant l'état de l'abonnement, tels que les renouvellements et les annulations.

Votre application doit gérer les changements d'état décrits dans les sections suivantes.

Nouveaux abonnements

Assurez-vous de suivre nos recommandations pour gérer les nouveaux achats. Lorsqu'un abonnement est souscrit, il est renvoyé par BillingClient.queryPurchasesAsync(), et une notification SubscriptionNotification de type SUBSCRIPTION_PURCHASED est envoyée. Lorsque vous recevez cette notification, vous devez interroger l'API Google Play Developer pour obtenir le dernier état d'abonnement. La ressource d'abonnement ressemble à l'exemple suivant. Notez que son état acknowledgementState indique ACKNOWLEDGEMENT_STATE_PENDING tant que vous n'avez pas confirmé l'achat :

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  "startTime": "2022-04-22T18:39:58.270Z",
  "regionCode": "US",
  "subscriptionState": "SUBSCRIPTION_STATE_ACTIVE",
  "latestOrderId": "GPA.3333-4137-0319-36762",
  "acknowledgementState": "ACKNOWLEDGEMENT_STATE_PENDING", // need to acknowledge new purchases
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": next_renewal_date,
      "autoRenewingPlan": {
        "autoRenewEnabled": true
      }
    }
  ],
}

Renouvellements

Si un abonnement est renouvelé correctement, il continue d'être renvoyé par BillingClient.queryPurchasesAsync().

Une notification SUBSCRIPTION_RENEWED est également envoyée lors du renouvellement d'un abonnement. Votre application doit s'assurer que l'utilisateur a toujours accès à l'abonnement, puis mettre à jour son état de l'abonnement avec le nouveau délai d'expiration (expiryTime) fourni dans la ressource d'abonnement renvoyée par l'API Google Play Developer. La ressource d'abonnement ressemble à l'exemple suivant :

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  "startTime": "2022-04-22T18:39:58.270Z",
  "regionCode": "US",
  "subscriptionState": "SUBSCRIPTION_STATE_ACTIVE",
  "latestOrderId": "GPA.3333-4137-0319-36762",
  "acknowledgementState": "ACKNOWLEDGEMENT_STATE_ACKNOWLEDGED",
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": next_renewal_date,
      "autoRenewingPlan": {
        "autoRenewEnabled": true
      }
    }
  ]
}

Délais d'expiration

Une fois l'abonnement arrivé à expiration, il n'est plus renvoyé dans BillingClient.queryPurchasesAsync(), et l'utilisateur ne devrait plus y avoir accès.

Une notification SubscriptionNotification de type SUBSCRIPTION_EXPIRED est également envoyée lorsqu'un abonnement expire. Lorsque vous recevez cette notification, vous devez interroger l'API Google Play Developer pour obtenir le dernier état d'abonnement. La ressource d'abonnement ressemble à l'exemple suivant :

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  ...
  "subscriptionState": "SUBSCRIPTION_STATE_EXPIRED",
  ...
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": expiration_time_in_past,
      ...
    }
  ],
}

Résiliations

Un utilisateur peut résilier volontairement un abonnement sur le Play Store ou annuler automatiquement son abonnement s'il ne parvient pas à récupérer son compte après un blocage de compte. Lorsqu'un utilisateur résilie un abonnement, il conserve l'accès au contenu jusqu'à la fin du cycle de facturation en cours. L'accès est ensuite supprimé.

Lorsqu'un abonnement est résilié, mais qu'il n'est pas encore arrivé à expiration, il est renvoyé à partir de BillingClient.queryPurchasesAsync(). La résiliation d'un abonnement déclenche une notification SUBSCRIPTION_CANCELED. Lorsque vous recevez cette notification, l'état subscriptionState de la ressource d'abonnement renvoyée par l'API Google Play Developer est défini sur "SUBSCRIPTION_STATE_CANCELED", et la valeur expiryTime contient la date à laquelle l'utilisateur doit perdre l'accès à l'abonnement. Si la date d'expiration (expiryTime) est dépassée, l'utilisateur perd immédiatement ses droits d'accès. Dans le cas contraire, il conserve ses droits d'accès jusqu'à l'expiration de l'abonnement. La ressource d'abonnement ressemble à l'exemple suivant :

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  ...
  "subscriptionState": "SUBSCRIPTION_STATE_CANCELED",
  ...
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": expiration_time,
      ...
    }
  ],
}

Votre application peut consulter le motif de résiliation (cancelReason) dans la ressource d'abonnement renvoyée par l'API Google Play Developer. Vous pouvez ainsi déterminer pourquoi l'abonnement a été résilié (parce que l'utilisateur en a fait la demande ou parce qu'il a rencontré des problèmes de facturation, par exemple). Si l'abonnement a été résilié par l'utilisateur, vous pouvez consulter le champ cancelSurveyResult pour en découvrir la raison.

Votre application peut afficher un message pour informer l'utilisateur que son abonnement a été résilié (par exemple "Votre abonnement expirera le date). Votre application peut également ajouter un lien profond vers le Google Play Store pour permettre aux utilisateurs de restaurer leur abonnement.

Si vous affichez ce message, vous devez également permettre aux utilisateurs de l'ignorer définitivement.

Notez également que les messages de résiliation peuvent agacer les utilisateurs, en particulier ceux qui ont fait le choix de résilier leur abonnement par opposition à ceux dont l'abonnement a été résilié pour faute de paiement. Vous pouvez choisir de ne pas envoyer de notification aux utilisateurs qui ont résilié eux-mêmes un abonnement.

Révocations

Un utilisateur peut révoquer un abonnement pour diverses raisons, y compris lorsque votre application utilise Purchases.subscriptions:revoke pour le révoquer ou en cas de rejet de paiement de l'abonnement. Dans ce cas, votre application doit immédiatement révoquer les droits d'accès de l'utilisateur. Un abonnement révoqué n'est plus renvoyé par BillingClient.queryPurchasesAsync(). Une notification SubscriptionNotification de type SUBSCRIPTION_REVOKED est également envoyée. Lorsque vous recevez cette notification, l'état subscriptionState de la ressource d'abonnement renvoyée par l'API Google Play Developer indique "SUBSCRIPTION_STATE_EXPIRED", et expiryTime contient la date à laquelle l'utilisateur devrait cesser d'avoir accès à l'abonnement. La ressource d'abonnement ressemble à l'exemple suivant :

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  ...
  "subscriptionState": "SUBSCRIPTION_STATE_EXPIRED",
  ...
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": expiration_time,
      ...
    }
  ],
}

Blocage de compte

Le blocage de compte est un état d'abonnement qui commence lorsque le mode de paiement d'un utilisateur échoue et que le délai de grâce associé arrive à sa fin sans que le paiement n'ait eu lieu. En cas de blocage de compte, vous devez empêcher l'accès à votre contenu ou service. Le blocage de compte dure jusqu'à 30 jours.

Pendant un blocage de compte, l'abonnement n'est pas renvoyé par BillingClient.queryPurchasesAsync().

Pendant un blocage de compte, vous devez gérer les résiliations, les restaurations ou les rachats d'abonnements comme il se doit.

Lorsque le compte d'un utilisateur est bloqué, exploitez les notifications en temps réel pour les développeurs afin de l'informer que l'accès à son abonnement a été suspendu. Votre application doit afficher un message lui expliquant comment corriger le mode de paiement et récupérer l'accès à l'abonnement. Ce message doit inclure un lien vers les paramètres d'abonnement Google Play afin que l'utilisateur puisse mettre à jour son mode de paiement. Par exemple, vous pouvez utiliser un message semblable à celui-ci :

"There is a problem with your subscription. Click here to go to the
Google Play subscription settings to fix your payment method."

Si vos utilisateurs peuvent accéder au contenu des abonnements en dehors de votre application, vous pouvez leur envoyer une notification push ou un e-mail pour les informer que leur abonnement n'est plus actif.

Si l'utilisateur a pu résoudre son problème de paiement, vous pouvez afficher un message dans votre application pour l'informer que son abonnement a été restauré. Par exemple, vous pouvez utiliser un message semblable à celui-ci :

"Your form of payment was updated, and your subscription has
been recovered."

Avec les notifications en temps réel pour les développeurs, vous recevez une notification SubscriptionNotification de type SUBSCRIPTION_ON_HOLD lorsqu'un abonnement passe à l'état "Blocage de compte". Appelez l'API Google Play Developer depuis votre serveur backend sécurisé pour récupérer les nouvelles informations d'abonnement. Lors du blocage de compte, la date d'expiration (expiryTime) de la ressource d'abonnement est définie sur un horodatage passé :

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  ...
  "subscriptionState": "SUBSCRIPTION_STATE_ON_HOLD",
  ...
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": timestamp_in_past,
      ...
    }
  ],
}

Une fois que l'utilisateur a corrigé son mode de paiement, l'abonnement revient à un état actif. Vous devez ensuite restaurer l'accès au contenu abonné.

Si votre application s'appuie uniquement sur queryPurchasesAsync() pour déterminer si un utilisateur peut accéder à un abonnement, elle doit gérer automatiquement la récupération de l'abonnement à la suite du blocage de compte.

Si votre application synchronise l'état de l'abonnement avec un serveur, vous devez écouter la notification SubscriptionNotification de type SUBSCRIPTION_RECOVERED pour être notifié lorsqu'un abonnement est restauré et que l'utilisateur doit de nouveau pouvoir y accéder. Si vous interrogez un abonnement après avoir reçu cette notification, expiryTime est maintenant défini sur un horodatage futur :

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  ...
  "subscriptionState": "SUBSCRIPTION_STATE_ACTIVE",
  ...
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": next_renewal_date,
      ...
    }
  ],
}

Si l'utilisateur ne corrige pas son mode de paiement avant la fin de la période de blocage de compte, vous recevrez une notification en temps réel pour les développeurs SUBSCRIPTION_CANCELED. Pour découvrir comment gérer une résiliation, consultez la section Résilier des abonnements. Lorsque vous interrogez l'abonnement qui a été résilié de cette manière, la date d'expiration (expiryTime) renvoyée est définie sur un horodatage passé :

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  ...
  "subscriptionState": "SUBSCRIPTION_STATE_CANCELED",
  ...
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": timestamp_in_past,
      ...
    }
  ],
}

Accès à l'abonnement et récupération après un blocage de compte

L'exemple suivant montre la chronologie d'un abonnement qui passe à l'état "Blocage de compte", puis qui est restauré lorsque l'utilisateur corrige son mode de paiement.

Comme dans l'exemple précédent, cette chronologie représente un abonnement qui commence par un délai de grâce avant de passer au blocage de compte.

Remarques :

  • Pendant ce délai de grâce, l'utilisateur doit conserver l'accès aux avantages de l'abonnement.
  • Avant que l'abonnement ne passe à l'état "Blocage de compte", Google essaie une nouvelle fois de débiter votre mode de paiement sous 24 heures. Au cours de cette période, l'utilisateur conserve les avantages de l'abonnement. Une fois ce délai écoulé, l'abonnement est soumis à un blocage de compte, et l'utilisateur perd accès à tous les avantages de l'abonnement.
  • Lorsqu'un abonnement est récupéré au cours d'un délai de grâce, la date de renouvellement n'est pas réinitialisée.
  • Lorsqu'un abonnement est récupéré après le blocage de compte, la date de renouvellement est réinitialisée.

Délai de grâce

Si le délai de grâce est activé, les abonnements l'appliquent en cas de problème de paiement à la fin d'un cycle de facturation. Pendant ce temps, l'utilisateur conserve l'accès à l'abonnement pendant que Google Play tente de le renouveler. Vous pouvez spécifier la durée du délai de grâce dans les paramètres du produit intégré à l'application dans la Google Play Console.

Si votre application repose uniquement sur queryPurchasesAsync() pour vérifier si un utilisateur peut accéder à un abonnement, elle doit gérer automatiquement le délai de grâce, car queryPurchasesAsync() continue de renvoyer une annulation d'achat avant la date d'expiration.

Si votre application synchronise l'état de l'abonnement avec un backend, vous devez écouter la notification SubscriptionNotification de type SUBSCRIPTION_IN_GRACE_PERIOD pour être averti lorsque l'utilisateur est soumis à un délai de grâce. Pendant toute la durée du délai de grâce, la ressource d'abonnement contient autoRenewEnabled = true.

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  ...
  "subscriptionState": "SUBSCRIPTION_STATE_IN_GRACE_PERIOD",
  ...
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": timestamp_in_future,
      "autoRenewingPlan": {
        "autoRenewEnabled": true
      }
    }
  ],
}

Lorsqu'un utilisateur entre dans un délai de grâce, un message dans votre application doit lui indiquer comment corriger son mode de paiement. Dans le cas contraire, il perdra l'accès à son abonnement à la fin de ce délai. Ce message peut inclure un lien profond vers le Google Play Store afin d'aider l'utilisateur à gérer son abonnement.

Dès que l'utilisateur corrige son mode de paiement, l'abonnement est renouvelé, et votre application gérera le renouvellement comme décrit dans la section Renouvellements.

Si l'utilisateur ne modifie pas son mode de paiement pendant le délai de grâce, l'abonnement est soumis à un blocage de compte.

Délai de grâce : récupération et accès à l'abonnement sans blocage de compte

L'exemple suivant présente la chronologie d'un abonnement qui est soumis à un délai de grâce, puis qui est rétabli lorsque l'utilisateur corrige son mode de paiement. Dans cet exemple, l'abonnement ne permet pas le blocage de compte. Par conséquent, une fois le délai de grâce écoulé, l'utilisateur perd tous les avantages de l'abonnement.

Remarques :

  • Pendant ce délai de grâce, l'utilisateur doit conserver l'accès aux avantages de l'abonnement.
  • Lorsqu'un abonnement est récupéré au cours d'un délai de grâce, la date de renouvellement n'est pas réinitialisée.

Abonnements suspendus

Pour éviter la perte volontaire d'utilisateurs, autorisez-les à suspendre leur abonnement. Lorsque vous activez cette fonctionnalité, les utilisateurs peuvent choisir de suspendre leur abonnement pour une période allant d'une semaine à trois mois, en fonction de la période récurrente. Une fois activée, l'option de suspension apparaît à la fois dans le centre des abonnements et dans le processus de résiliation. Notez que les abonnements annuels ne peuvent pas être suspendus, et que les limites de suspension d'une semaine et de trois mois peuvent changer à tout moment.

Pour permettre aux utilisateurs de suspendre leur abonnement, procédez comme suit :

  1. Connectez-vous à la Google Play Console.
  2. Sélectionnez votre application, puis accédez à Présence sur le Play Store > Produits intégrés à l'application > Abonnements.
  3. Développez la section Paramètres d'abonnement.
  4. Cochez Activer la suspension.

La suspension d'un abonnement ne prend effet qu'à la fin de la période de facturation en cours. Lorsque l'abonnement est suspendu, l'utilisateur n'y a pas accès. À l'issue de la période de suspension, l'abonnement reprend, et Google tente de le renouveler. Si la réactivation aboutit, l'abonnement est réactivé. Si elle échoue en raison d'un problème de paiement, l'utilisateur passe à l'état "Blocage de compte", comme illustré dans la figure 1 :

Un utilisateur suspend son abonnement, puis est soumis à un blocage de compte.
Figure 1. Un utilisateur suspend son abonnement, puis est soumis à un blocage de compte.

Un utilisateur peut également choisir de réactiver manuellement un abonnement à tout moment au cours de la période de suspension, comme illustré dans la figure 2. Dans ce cas, la date de facturation est remplacée par la date de réactivation manuelle.

Un utilisateur suspend son abonnement, puis le réactive.
Figure 2. Un utilisateur suspend son abonnement, puis le réactive.

Lorsque l'abonnement d'un utilisateur est suspendu, il n'est pas renvoyé par queryPurchasesAsync(). Si l'abonnement est réactivé, il est renvoyé par queryPurchasesAsync().

Si votre application synchronise l'état de l'abonnement avec un serveur backend sécurisé, vous devez écouter les notifications en temps réel pour les développeurs afin de gérer l'état. Ces notifications vous permettent également d'informer les utilisateurs de votre application qu'ils ont suspendu leur abonnement et qu'ils n'y ont pas accès. Vous devez également permettre à l'utilisateur de réactiver manuellement l'abonnement via un lien profond vers Google Play.

Un message SubscriptionNotification de type SUBSCRIPTION_PAUSE_SCHEDULE_CHANGED est envoyé lorsque l'utilisateur suspend son abonnement. À ce stade, l'utilisateur doit conserver l'accès à son abonnement. La ressource d'abonnement contient autoRenewing = true ,paymentState = 1 (paiement reçu) et les valeurs futures correspondant à expiryTime et autoResumeTimeMillis.

Un message SubscriptionNotification de type SUBSCRIPTION_PAUSED est envoyé lorsque la suspension prend effet. À ce stade, l'utilisateur perd l'accès à son abonnement, et la ressource d'abonnement contient autoRenewing = true et paymentState = 0 (en attente), une valeur future pour autoResumeTimeMillis et une valeur passée pour expiryTime.

Un message SubscriptionNotification de type SUBSCRIPTION_RENEWED est envoyé si l'abonnement est réactivé automatiquement à la fin de la période de suspension ou si l'utilisateur choisit de réactiver manuellement l'abonnement. Cette opération doit être gérée comme décrit dans la section Renouvellements.

Un message SubscriptionNotification de type SUBSCRIPTION_ON_HOLD est envoyé en cas d'échec du paiement lors de la réactivation de l'abonnement. Cette opération doit être effectuée comme décrit dans la section Blocage de compte.

Restaurations

Un abonnement résilié reste visible dans l'application Play Store jusqu'à sa date d'expiration. Un utilisateur peut restaurer un abonnement résilié avant qu'il n'expire en cliquant sur Se réabonner (anciennement Restaurer) dans la section Abonnements de l'application Google Play Store.

Section "Abonnements" de l'application Google Play Store affichant un abonnement résilié avec le bouton "Se réabonner"
Figure 3. Section Compte > Abonnements de l'application Google Play Store affichant un abonnement résilié avec le bouton Se réabonner

Si votre application repose uniquement sur queryPurchasesAsync() pour déterminer si un utilisateur peut accéder à un abonnement, elle doit gérer automatiquement les restaurations, car queryPurchasesAsync() continue de renvoyer une annulation d'achat avant la date d'expiration. Un abonnement restauré continue à être renouvelé comme s'il n'avait pas été résilié.

Si votre application synchronise l'état de l'abonnement avec un backend, vous devez écouter une notification SubscriptionNotification de type SUBSCRIPTION_RESTARTED. Une fois cette notification reçue, votre application peut y répondre, enregistrer que l'abonnement est sur le point d'être renouvelé et cesser d'afficher des messages de restauration dans votre application. La ressource d'abonnement ressemble à cet exemple :

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  ...
  "subscriptionState": "SUBSCRIPTION_STATE_ACTIVE",
  ...
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": next_renewal_date
      ...
    }
  ],
}

Changements de niveau d'abonnement et réinscriptions

Lorsqu'un utilisateur passe à un niveau d'abonnement supérieur ou inférieur, ou lorsqu'il se réinscrit à partir de votre application avant l'expiration de l'abonnement, l'ancien abonnement est annulé, tandis qu'un autre abonnement est créé avec un nouveau jeton d'achat.

En outre, la ressource d'abonnement renvoyée par l'API Google Play Developer contient un jeton linkedPurchaseToken qui indique l'ancien achat à partir duquel l'utilisateur a changé de niveau d'abonnement ou s'est réinscrit. Vous pouvez utiliser linkedPurchaseToken pour rechercher l'ancien abonnement et identifier le compte utilisateur existant afin d'associer le nouvel achat au même compte.

Avant de proposer des options de changement de niveau d'abonnement ou de réinscription dans l'application, vous devez confirmer l'abonnement existant. Toute modification du forfait ou réinscription est bloquée si l'ancien abonnement est en attente de confirmation.

Après la modification du forfait ou la réinscription, vous devez également confirmer le nouvel abonnement. La méthode recommandée consiste à utiliser l'API Google Play Developer pour confirmer l'achat afin d'éviter son annulation. La ressource d'abonnement ressemble à l'exemple suivant :

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  ...
  "subscriptionState": "SUBSCRIPTION_STATE_ACTIVE",
  "linkedPurchaseToken": old_purchase_token,
  ...
  "lineItems": [
    {
      "productId": "sub_variant_plan01",
      "expiryTime": next_renewal_date,
      "autoRenewingPlan": {
        "autoRenewEnabled": true
      }
    }
  ],
}

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.

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.

Le bouton Abonnements Google Play illustré sur cette image est un exemple de lien permettant de gérer les abonnements.
Figure 4. Le bouton Abonnements Google Play est un exemple de lien permettant de gérer les abonnements

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 le rediriger 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
L'écran "Abonnements Play Store" indique l'état de tous les abonnements d'un utilisateur.
Figure 5. L'écran "Abonnements Play Store" indique l'état de tous les abonnements d'un utilisateur.
Appuyez sur une fiche pour afficher des informations supplémentaires.
Figure 6. Appuyez sur une fiche pour afficher des informations supplémentaires.

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

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 :

Cette application contient deux niveaux d'abonnement
Figure 7. Cette application comporte 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 prorataDescription
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 au sein d'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 :

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 en dehors de 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'interface utilisateur 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 Se réabonner (anciennement Restaurer). Le même jeton d'abonnement et d'achat est alors conservé.

Section "Abonnements" de l'application Google Play Store affichant un abonnement résilié avec le bouton "Se réabonner"
Figure 8. Section Compte > Abonnements de l'application Google Play Store affichant un abonnement résilié avec le bouton Se réabonner

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

Section "Abonnements" de l'application Google Play Store affichant les abonnements résiliés et arrivés à expiration avec les boutons "Se réabonner" et "Supprimer"
Figure 9. Section Compte > Abonnements de l'application Google Play Store affichant les abonnements résiliés et arrivés à expiration, avec les boutons Se réabonner et Supprimer

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 l'essai.

Résilier, rembourser ou révoquer un abonnement

Vous pouvez utiliser l'API Google Play Developer pour annuler, 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é.

Changer le prix des abonnements

Vous pouvez modifier le prix des forfaits de base et des offres d'abonnement. Par exemple, cela peut être utile si les prix de vos produits numériques nécessitent des ajustements annuels ou si vous apportez des modifications à l'ensemble des avantages du produit qui doivent se refléter dans le prix.

Pour découvrir comment modifier le prix des abonnements à l'aide de la Play Console, consultez la documentation dans le Centre d'aide de la Play Console.

Gérer les changements de prix pour les nouveaux achats

Lorsque vous modifiez le prix d'un forfait de base ou d'une offre, le nouveau prix prend effet en quelques heures pour tous les nouveaux achats, sans aucune action supplémentaire de votre part. Les nouveaux achats incluent les utilisateurs qui ne disposent d'aucun abonnement dans votre application, ceux ayant souscrit un forfait à renouvellement automatique et qui achètent un autre forfait (par exemple, une période de facturation plus longue ou un niveau de service supérieur), et ceux ayant souscrit un forfait prépayé et qui effectuent un achat. Vous traiterez ces nouveaux achats comme tout autre achat et vous seul verrez les nouveaux prix leur être appliqués.

Gérer les changements de prix pour les abonnements à renouvellement automatique existants

Les abonnements à renouvellement automatique peuvent passer par plusieurs phases de tarification sur Google Play Billing si vous proposez des offres spéciales pour vos forfaits de base. Vous pouvez modifier le prix d'une offre, par exemple des périodes d'essai gratuit et de remise, mais ces modifications ne s'appliquent pas aux abonnements existants. Les utilisateurs paieront les phases de tarification spéciales qu'ils ont vues lorsqu'ils ont souscrit leur abonnement.

Vous pouvez également modifier le prix du forfait de base à renouvellement automatique. Par défaut, les abonnés existants ne sont pas concernés. Ils continuent de payer le prix de leur forfait de base précédent lors du renouvellement et sont placés dans une cohorte d'anciens prix dans la Play Console. Si vous le souhaitez, vous pouvez ensuite mettre fin à la cohorte pour faire passer ces utilisateurs au tarif actuel du forfait de base.

Pour en savoir plus sur l'utilisation des cohortes d'anciens prix, veuillez consulter le Centre d'aide de la Play Console.

Modifier le prix des abonnements avec l'API Google Play Developer

Pour modifier de manière programmatique le prix du forfait de base, utilisez la méthode monetization.subscriptions.patch. Cette méthode reçoit un objet Subscription avec la configuration du produit sur abonnement en cours de modification. Définissez le nouveau prix dans l'objet RegionalBasePlanConfig sous le forfait de base approprié dans la collection basePlans de l'abonnement. Cela peut être très utile si vous possédez un vaste catalogue et devez apporter des modifications à tous vos produits sur une courte période, ou si vous disposez d'un système de gestion de catalogues de produits qui apporte automatiquement des modifications à vos produits sur abonnement Google Play Billing en cas de changement.

Pour modifier le prix du forfait de base dans la Play Console, consultez le Centre d'aide de la Play Console.

Mettre fin à une cohorte d'anciens prix

Si vous mettez fin à une cohorte d'anciens prix, les utilisateurs qui bénéficient d'anciens prix pour un forfait de base à renouvellement automatique paieront le prix actuel du forfait de base. Pour supprimer un ancien prix dans la Play Console, consultez le Centre d'aide de la Play Console.

Mettre fin à une cohorte d'anciens prix avec l'API Google Play Developer

Pour mettre fin à une cohorte d'anciens prix de manière programmatique, utilisez la méthode monetization.subscriptions.basePlans.migratePrices. Elle permet d'appliquer le prix actuel du forfait de base pour les abonnés bénéficiant d'un ancien prix d'abonnement dans la région spécifiée. Cette méthode déclenche l'envoi de notifications de changement de prix aux utilisateurs qui bénéficient actuellement d'un ancien prix antérieur au code temporel fourni. L'abonnement des utilisateurs qui n'acceptent pas le nouveau tarif sera résilié au prochain renouvellement.

Prise d'effet des changements de prix

Lorsque vous mettez fin à une cohorte d'anciens prix, un processus s'enclenche afin que le tarif actuel du forfait de base s'applique pour ces utilisateurs. Play les informe du changement de prix à venir, qu'il s'agisse d'une hausse ou d'une baisse de tarif.

Baisses de prix

Si le prix actuel du forfait de base est inférieur au tarif normalement appliqué, Play avertit les utilisateurs par e-mail. Ils paieront la première échéance au tarif réduit à la prochaine date de renouvellement.

Hausses de prix

Si le prix actuel du forfait de base est supérieur au tarif normalement appliqué, Play avertit les utilisateurs par e-mail et via des notifications push. Pour la première échéance, le prix plus élevé est facturé aux utilisateurs à la première date de renouvellement après une période d'avis préalable. Cette période varie selon les régions et dure 37 ou 67 jours.

Les utilisateurs doivent accepter le prix plus élevé pendant la période d'avis préalable sur le Play Store avant le premier prélèvement au nouveau prix. Dans le cas contraire, Play annulera automatiquement leur abonnement. Play avertit les utilisateurs par e-mail et via des notifications push 1 jour, 30 jours et, dans certaines régions, 60 jours avant le premier prélèvement.

Communiquer les changements de prix à l'utilisateur

Vous devez informer vos abonnés existants chaque fois que vous modifiez le prix de leur forfait de base et mettez fin à leur cohorte d'anciens prix. En cas de hausse du prix, vous devez envoyer un avis préalable aux utilisateurs et les informer de la nécessité d'accepter cette augmentation.

Lorsque vous augmentez le prix d'un abonnement, vous disposez d'au moins sept jours après avoir mis fin à une cohorte d'anciens prix pour informer les abonnés existants du changement de prix avant que Google Play les prévienne directement. Pendant cette période, vous pouvez annuler une hausse de prix en attente en rétablissant le prix d'origine. Vous pouvez également informer les utilisateurs concernés avant que Play ne s'en charge.

Dans votre application, nous vous recommandons de prévenir les utilisateurs concernés et de fournir un lien profond vers l'écran d'abonnement du Play Store pour les aider à accepter facilement le nouveau prix s'ils le souhaitent.

Les utilisateurs peuvent vérifier la hausse du prix sur l'écran d'abonnement du Play Store, sur lequel une boîte de dialogue semblable à la figure 13 s'affiche.

Boîte de dialogue générique informant l'utilisateur du changement de prix de son abonnement
Figure 13. Exemple de boîte de dialogue informant l'utilisateur d'un changement de prix de son abonnement

Exemples

Exemple 1 (abonnement mensuel) : Nous sommes le 3 mars. SuperStreamz va augmenter le prix de SuperStreamz Pro, son offre premium pour le streaming vidéo. Elle passera de 1 € à 2 € par mois. Ce changement de prix prendra effet le 9 avril (37 jours après le 3 mars).

  • Le prochain renouvellement d'Alice aura lieu le 5 mars. Son premier renouvellement après l'entrée en vigueur du changement de prix interviendra le 5 mai. Elle renouvellera donc son abonnement le 5 mars et le 5 avril à l'ancien tarif (1 €). Lors du renouvellement du 5 mai, l'abonnement lui sera finalement facturé au nouveau tarif (2 €). Elle commencera à recevoir des notifications concernant le changement de prix le 5 avril, soit 30 jours avant la première date de renouvellement au nouveau prix.
Chronologie générique du changement de prix d'un abonnement mensuel se renouvelant le 5 mars
Figure 14. Exemple de chronologie du changement de prix d'un abonnement mensuel se renouvelant le 5 mars
  • Le prochain renouvellement de Bob aura lieu le 29 mars. Son abonnement sera renouvelé le 29 mars à l'ancien tarif (1 €), car le changement de prix ne sera pas encore effectif. Lors du renouvellement du 29 avril, le nouveau tarif (2 €) lui sera facturé. Il commencera à recevoir des notifications le 30 mars, soit 30 jours avant la première date de renouvellement au nouveau prix.
Chronologie générique du changement de prix d'un abonnement mensuel se renouvelant le 29 mars
Figure 15. Exemple de chronologie du changement de prix d'un abonnement mensuel se renouvelant le 29 mars

Exemple 2 (abonnement de 3 mois) : Nous sommes le 3 mars. FindMyLove souhaite augmenter le prix de l'abonnement de 3 mois de 1 € à 2 € pour FindMyLove Premium. Ce changement de prix prendra effet le 9 avril (37 jours après le 3 mars).

  • Le prochain renouvellement d'Alice aura lieu le 5 mars. Son abonnement sera renouvelé le 5 mars à l'ancien tarif (1 €), car le changement de prix ne sera pas encore effectif. Lors du renouvellement du 5 juin, le nouveau prix (2 €) lui sera facturé. Elle commencera à recevoir des notifications le 6 mai, soit 30 jours avant la première date de renouvellement au nouveau prix.
Chronologie générique du changement de prix d'un abonnement de 3 mois se renouvelant le 5 mars
Figure 16. Exemple de chronologie du changement de prix d'un abonnement de 3 mois se renouvelant le 5 mars
  • Le prochain renouvellement de Bob aura lieu le 11 avril. Son abonnement sera renouvelé le 11 avril au nouveau tarif (2 €), car il interviendra après l'entrée en vigueur du changement de prix. Bob commencera à recevoir des notifications le 12 mars, soit 30 jours avant la première date de renouvellement au nouveau prix.
Chronologie générique du changement de prix d'un abonnement de 3 mois se renouvelant le 11 avril
Figure 17. Exemple de chronologie du changement de prix d'un abonnement de 3 mois se renouvelant le 11 avril

Exemple 3 (abonnement hebdomadaire) : Nous sommes le 3 mars. CutePetsNews souhaite que l'abonnement hebdomadaire à Weekly Dog Alerts passe de 1 € à 2 €. Ce changement de prix prendra effet le 9 avril.

  • Le prochain renouvellement hebdomadaire d'Alice aura lieu le 6 mars. Son abonnement sera renouvelé le 6, le 13, le 20 et le 27 mars, ainsi que le 3 avril à l'ancien tarif (1 €), car le changement de prix ne sera pas encore effectif. Lors du renouvellement du 10 avril, le nouveau prix (2 €) lui sera facturé. Elle commencera à recevoir des notifications le 11 mars, soit 30 jours avant la première date de renouvellement au nouveau prix.
Chronologie générique du changement de prix d'un abonnement hebdomadaire se renouvelant le 6 avril
Figure 18. Exemple de chronologie du changement de prix d'un abonnement hebdomadaire se renouvelant le 6 avril

Exemple 4 (abonnement mensuel, plusieurs changements de prix) : Un développeur peut appliquer deux changements de prix. Voici ce qui se passerait dans ce cas.

Nous sommes le 3 mars. SuperStreamz va augmenter le prix de SuperStreamz Pro, son offre premium pour le streaming vidéo. Elle passera de 1 € à 2 € par mois. Le 10 mars, le développeur va ensuite effectuer un deuxième changement de prix. Celui-ci passera de 2 € à 3 € par mois.

Le premier changement de prix prendra effet le 9 avril (37 jours après le 3 mars). Le second prendra effet le 16 avril (37 jours après le 10 mars).

  • Le prochain renouvellement d'Alice aura lieu le 5 mars. Son premier renouvellement après l'entrée en vigueur du changement de prix interviendra le 5 mai. Elle renouvellera donc son abonnement le 5 mars et le 5 avril à l'ancien tarif (1 €). Lors du renouvellement du 5 mai, l'abonnement lui sera finalement facturé au nouveau tarif (2 €). Elle commencera à recevoir des notifications concernant le changement de prix le 5 avril, soit 30 jours avant la première date de renouvellement au nouveau prix.
Chronologie générique du changement de prix d'un abonnement mensuel avec plusieurs modifications du tarif
Figure 19. Exemple de chronologie de plusieurs changements de prix d'un abonnement mensuel se renouvelant le 5 mars

Gérer la confirmation du changement de prix par l'utilisateur

Si l'utilisateur accepte l'a hausse du prix de l'abonnement, vous recevrez une notification SubscriptionNotification de type SUBSCRIPTION_PRICE_CHANGED_CONFIRMED. En cas de baisse du prix ou de renouvellement après augmentation du prix de l'abonnement, les développeurs reçoivent une notification SubscriptionNotification de type SUBSCRIPTION_RENEWED qu'ils peuvent traiter comme tout autre renouvellement.

Gérer les cas où une hausse du prix n'est pas acceptée

Si l'utilisateur n'accepte pas la hausse du prix avant le changement de prix officiel, il est automatiquement désabonné et vous recevez une notification SubscriptionNotification de type SUBSCRIPTION_CANCELED Cet événement peut être géré comme indiqué dans Résiliations.

Changement de prix accidentel

Si vous avez accidentellement modifié le prix d'un abonnement, annulez-le immédiatement. Tant que le prix est rétabli dans un délai de sept jours, les abonnés existants n'auront pas connaissance de cette erreur. Notez toutefois que les nouveaux abonnés peuvent recevoir le prix accidentel entre le moment où le prix a été modifié pour la première fois et où il a été annulé.

Gérer deux changements de prix consécutifs

Si vous avez mis fin à une cohorte d'anciens prix afin d'appliquer une augmentation de prix, puis que vous changez de nouveau le prix, les utilisateurs éligibles n'ont plus besoin de répondre à la première modification de prix, car seule la seconde modification s'applique.

Vous ne devez effectuer qu'un seul changement de prix à la fois. Il n'est pas recommandé de changer de prix juste pour tester l'engouement des utilisateurs, par exemple.

Si vous modifiez le prix d'un abonnement deux fois au cours d'une période de sept jours, les utilisateurs concernés n'ont à accepter que le dernier changement de prix.

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.

Snackbar demandant à l'utilisateur de mettre à jour son mode de paiement
Figure 20. Snackbar demandant à l'utilisateur de mettre à jour son mode de paiement

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