Vendre des abonnements

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

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.

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é. Une SubscriptionNotification est envoyée 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é, 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 averti 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 "Account Hold" (Blocage de compte), comme illustré dans la figure 1 :

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.

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.

Une notification SubscriptionNotification de type SUBSCRIPTION_PAUSED est envoyée 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.

Une notification SubscriptionNotification de type SUBSCRIPTION_RENEWED est envoyée 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.

Une notification SubscriptionNotification de type SUBSCRIPTION_ON_HOLD est envoyée 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 Resubscribe (Se réabonner) (anciennement Restore (Restaurer)) dans la section Subscriptions (Abonnements) de l'application Google Play Store. Vous pouvez également autoriser les utilisateurs à se réabonner à un forfait de base à renouvellement automatique après expiration. Pour cela, vous devez le configurer en conséquence avec l'option de réabonnement.

Restaurations avant expiration

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
      ...
    }
  ],
}

Réabonnements après expiration

Si un produit sur abonnement est configuré pour autoriser le réabonnement après expiration, il est possible que les utilisateurs commencent un achat à partir de l'application Play Store. Dans ce cas, Google Play émet un nouveau jeton d'achat, et votre backend recevra une notification en temps réel pour les développeurs de type SUBSCRIPTION_PURCHASED. L'état de ce type d'achat n'inclura pas de linkedPurchaseToken ni les identifiants de compte obscurcis associés à l'achat d'origine, car il est complètement arrivé à expiration.

Après un réabonnement, les utilisateurs devront ouvrir l'application après la date d'expiration. Ce type d'achat sera traité de la même manière que les autres achats hors application.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Exemples de calcul au prorata

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

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

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

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

IMMEDIATE_WITH_TIME_PRORATION

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

IMMEDIATE_AND_CHARGE_PRORATED_PRICE

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

IMMEDIATE_WITHOUT_PRORATION

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

DEFERRED

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

IMMEDIATE_AND_CHARGE_FULL_PRICE

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

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

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

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

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

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

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

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

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

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

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

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

Remarques :

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

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

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

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

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

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

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

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

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

Recommandations de calcul au prorata

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

Gestion des utilisateurs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Faire la promotion de votre abonnement

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

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

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

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

Résilier, rembourser ou révoquer un abonnement

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

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

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

Reporter la facturation d'un abonné

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

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

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

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

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

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

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

Changer le prix des abonnements

Vous pouvez modifier le prix des forfaits de base et des offres d'abonnement. Par exemple, vous proposez peut-être des produits numériques dont le prix nécessite un ajustement annuel, ou vous pouvez apporter des modifications à l'ensemble des avantages d'un 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 peuvent être effectués par l'un des types d'utilisateurs suivants :

• Utilisateurs qui ne possèdent actuellement aucun abonnement dans votre application
• Utilisateurs ayant déjà souscrit un forfait à renouvellement automatique existant et qui en souscrivent un autre (par exemple, avec une période de facturation plus longue ou un niveau de service supérieur)
• Utilisateurs qui rechargent un forfait prépayé qu'ils ont souscrit

Vous devez traiter les nouveaux achats comme tout autre achat.

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

Vous pouvez modifier le prix d'un forfait de base à renouvellement automatique à tout moment. Par défaut, les abonnés existants ne sont pas concernés. Ils sont placés dans une cohorte d'anciens prix où ils continuent de payer le prix d'origine de leur forfait de base lors du renouvellement. Vous pouvez choisir de mettre fin à la cohorte à tout moment et d'appliquer le prix actuel du forfait de base à ces utilisateurs.

De même, les changements de prix pour les offres spéciales et les phases de tarification individuelle n'affectent pas les abonnés existants. Ceux-ci continuent de payer le prix affiché quand ils ont souscrit l'abonnement.

Pour en savoir plus sur l'utilisation des cohortes d'anciens prix, consultez 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 de 37 jours : 7 jours d'attente initiaux, puis 30 jours pendant lesquels des notifications peuvent être envoyées aux utilisateurs.

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 tarif. Dans le cas contraire, Play résiliera automatiquement leur abonnement. Play avertit les utilisateurs par e-mail et via des notifications push 30 jours, puis 1 jour 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 ou 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 7 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.

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.

Exemples

Exemple 1 (abonnement mensuel) : le 3 mars, SuperStreamz augmente le prix de SuperStreamz Pro, son abonnement premium de streaming vidéo, mettant fin à une cohorte d'anciens prix. Les utilisateurs sont déplacés de l'ancienne cohorte de prix (1 €) vers le tarif de base actuel (2 €). Ce changement de prix entrera en vigueur le 9 avril (soit 37 jours après le 3 mars).

• Alice est déjà abonnée. Le prochain renouvellement de son abonnement est prévu le 5 mars. Le premier renouvellement après l'entrée en vigueur du changement de prix interviendra le 5 mai. L'abonnement sera ainsi renouvelé le 5 mars et le 5 avril à l'ancien tarif (1 €). Le nouveau tarif (2 €) sera appliqué à Alice lors du renouvellement du 5 mai. Google Play commencera à informer Alice du changement de prix le 5 avril, soit 30 jours avant la date du premier renouvellement au nouveau tarif.

• Bob est déjà abonné. Le prochain renouvellement de son abonnement est prévu le 29 mars. L'abonnement sera renouvelé à cette date à l'ancien tarif (1 €), car le changement de prix ne sera pas encore en vigueur. Le nouveau tarif (2 €) sera appliqué à Bob lors du renouvellement du 29 avril. Bob commencera à recevoir des notifications de changement de prix le 30 mars, soit 30 jours avant la date du premier renouvellement au nouveau tarif.

Exemple 2 (abonnement de 3 mois) : le 3 mars, FindMyLove met fin à une ancienne cohorte de prix et augmente le prix de FindMyLove Premium, qui passe de 1 € à 2 € (son forfait de base). Ce changement de prix entrera en vigueur le 9 avril (soit 37 jours après le 3 mars).

• Alice est déjà abonnée. Le prochain renouvellement de son abonnement est prévu le 5 mars. L'abonnement sera renouvelé à l'ancien tarif (1 €), car le changement de prix ne sera pas encore en vigueur. Le nouveau tarif (2 €) sera appliqué à Alice lors du renouvellement du 5 juin. Alice commencera à recevoir des notifications le 6 mai, soit 30 jours avant la date du premier renouvellement au nouveau tarif.

• Bob est déjà abonné. Le prochain renouvellement de son abonnement est prévu le 11 avril. L'abonnement sera ainsi renouvelé au nouveau tarif (2 €), car la date de renouvellement est postérieure à la date d'entrée en vigueur du changement de prix. Bob commencera à recevoir des notifications le 12 mars, soit 30 jours avant la date du premier renouvellement au nouveau prix.

Exemple 3 (abonnement hebdomadaire) : le 3 mars, CutePetsNews met fin à une cohorte d'anciens prix, ce qui déclenche une migration des tarifs. Son service Weekly Dog Alerts passe de 1 € à 2 €. Le changement de prix entrera en vigueur le 9 avril.

• Alice est déjà abonnée. Le prochain renouvellement hebdomadaire de son abonnement est prévu le 6 mars. Son abonnement sera renouvelé les 6, 13, 20 et 27 mars, ainsi que le 3 avril à l'ancien tarif (1 €), car le changement de prix ne sera pas encore en vigueur. Le nouveau tarif (2 €) sera appliqué à Alice lors du renouvellement du 10 avril. Alice commencera à recevoir des notifications le 11 mars, soit 30 jours avant la date du premier renouvellement au nouveau tarif.

Exemple 4 (abonnement mensuel, plusieurs changements de prix) : cet exemple montre comment les changements de prix sont gérés.

Le 3 mars, SuperStreamz déclenche la migration du prix de SuperStreamz Pro, son abonnement premium de streaming vidéo dont le montant passe de 1 € à 2 € par mois. Le 10 mars, le développeur déclenche une deuxième migration de prix, cette fois à 3 € par mois.

Le premier changement de prix entrera en vigueur le 9 avril (soit 37 jours après le 3 mars) et le second le 16 avril (soit 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. Son abonnement sera ainsi renouvelé le 5 mars et le 5 avril à l'ancien tarif (1 €). Le nouveau tarif (2 €) sera appliqué à Alice lors du renouvellement du 5 mai. Elle ne reçoit des notifications qu'au sujet du deuxième changement de prix, car celui-ci est intervenu pendant la période de gel de 7 jours. Alice commencera à recevoir des notifications le 11 mars, soit 30 jours avant la date du premier renouvellement au nouveau tarif.

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

Lorsqu'un utilisateur accepte l'augmentation du prix de votre abonnement, vous recevez une notification SubscriptionNotification de type SUBSCRIPTION_PRICE_CHANGED_CONFIRMED. En cas de baisse du prix ou de renouvellement après l'augmentation du prix de l'abonnement, vous recevez une notification SubscriptionNotification de type SUBSCRIPTION_RENEWED. Vous devez traiter cette notification comme tout autre renouvellement.

Gérer les cas où une augmentation de prix n'est pas acceptée

Si l'utilisateur n'accepte pas la hausse du prix avant le renouvellement au tarif plus élevé, 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 modifiez le prix d'un abonnement deux fois au cours d'une période de 7 jours, les utilisateurs concernés n'ont à accepter que le dernier changement de prix. Par exemple, 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. Vous ne devez pas modifier la tarification utilisateur à des fins de test.

Gérer les refus de paiement

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

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

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

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

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

Messagerie dans l'application

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

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

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

Intégrer la messagerie dans l'application

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

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

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

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

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

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