Abonnement avec modules complémentaires

Un abonnement avec modules complémentaires vous permet de regrouper plusieurs produits d'abonnement qui peuvent être achetés, facturés et gérés ensemble. Vous pouvez proposer vos abonnements au catalogue de produits existants en tant que modules complémentaires, sans avoir à les spécifier à l'avance ni à les configurer. Vous pouvez lancer un parcours d'achat avec plusieurs produits sur abonnement existants et les vendre en tant que modules complémentaires.

Points à prendre en compte

Tenez compte des points suivants lorsque vous utilisez la fonctionnalité d'abonnement avec modules complémentaires :

• Les abonnements avec des options ne sont acceptés que pour les forfaits de base à renouvellement automatique.

• Tous les articles de l'achat doivent avoir la même période de facturation récurrente. Par exemple, vous ne pouvez pas avoir un abonnement facturé annuellement avec des modules complémentaires facturés mensuellement.

• Un abonnement avec modules complémentaires peut comporter jusqu'à 50 éléments.

• Cette fonctionnalité n'est pas disponible dans les régions Inde (IN) et Corée du Sud (KR).

Intégrer à la bibliothèque Play Billing

Cette section décrit comment intégrer la fonctionnalité d'abonnement avec modules complémentaires à la bibliothèque Play Billing (PBL). Il suppose que vous connaissez les étapes initiales d'intégration de PBL, comme l'ajout de la dépendance PBL à votre application, l'initialisation de BillingClient et la connexion à Google Play. Cette section se concentre sur les aspects de l'intégration PBL spécifiques aux abonnements avec modules complémentaires.

Lancer un parcours d'achat

Pour lancer un flux d'achat pour un abonnement avec des modules complémentaires, procédez comme suit :

1. Récupérez tous vos éléments d'abonnement à l'aide de la méthode BillingClient.queryProductDetailsAsync.

2. Définissez l'objet ProductDetailsParams pour chaque élément.

   L'élément représenté par l'objet ProductDetailsParams spécifie à la fois ProductDetails, qui indique l'article d'abonnement, et offerToken, qui sélectionne un base plan ou un offer d'abonnement spécifique.

3. Spécifiez les détails de l'article dans la méthode BillingFlowParams.Builder.setProductDetailsParamsList. La classe BillingFlowParams spécifie les détails d'un parcours d'achat.

   L'exemple suivant montre comment lancer le parcours de facturation pour un achat d'abonnement avec plusieurs articles :

   Java

      BillingClient billingClient = …;
   
       // ProductDetails obtained from queryProductDetailsAsync().
       ProductDetailsParams productDetails1 = ...;
       ProductDetailsParams productDetails2 = ...;
       ArrayList productDetailsList = new ArrayList<>();
       productDetailsList.add(productDetails1);
       productDetailsList.add(productDetails2);
   
       BillingFlowParams billingFlowParams =
           BillingFlowParams.newBuilder()
              .setProductDetailsParamsList(productDetailsList)
              .build();
       billingClient.launchBillingFlow(billingFlowParams);

Règles applicables aux articles de l'achat

• Pour que les dates de renouvellement des modules complémentaires correspondent à celles de l'article de base, Google Play peut insérer des frais au prorata après les phases d'essai ou de prix de lancement.
• L'éligibilité aux offres sera évaluée séparément pour chaque article.

Traiter les achats

Le traitement des abonnements avec modules complémentaires est identique à celui des achats d'un seul article, comme décrit dans Intégrer la bibliothèque Google Play Billing à votre application. La seule différence est que l'utilisateur peut recevoir plusieurs droits d'accès avec un seul achat. Un achat d'abonnement avec des modules complémentaires renvoie plusieurs éléments qui peuvent être récupérés à l'aide de Purchase.getProducts() dans la bibliothèque Google Play Billing, puis de la liste lineItems dans purchases.subscriptionsv2.get de l'API Google Play Developer.

Modifier les abonnements avec modules complémentaires

Toute modification apportée à votre abonnement avec des modules complémentaires entraîne une mise à niveau ou un retour à une version antérieure. Pour en savoir plus, consultez Mettre à niveau ou rétrograder des abonnements.

Pour modifier ou restaurer un achat d'abonnement avec des modules complémentaires dans votre application, vous devez appeler l'API launchBillingFlow avec des paramètres supplémentaires et vous assurer des points suivants :

• Appelez toujours setOldPurchaseToken avec le jeton d'achat de l'abonnement actuel.
• Pour passer à un niveau supérieur ou inférieur, ou pour effectuer un crossgrade d'un article, appelez SubscriptionProductReplacementParams.setReplacementMode afin de spécifier comment le changement de forfait doit être géré entre l'ancien et le nouvel article acheté. Sinon, il n'est pas nécessaire de définir ce paramètre.
• Lorsque l'élément de base n'est pas modifié, vous pouvez toujours appeler SubscriptionProductReplacementParams.setSubscriptionReplacementMode pour appliquer un comportement de remplacement spécifique. Pour connaître les règles applicables dans ce cas, consultez Se réabonner ou changer de forfait dans le même abonnement.
• Les nouveaux modules complémentaires s'appliqueront immédiatement, avec des frais au prorata pour aligner la prochaine date de renouvellement sur l'élément de base de l'abonnement.
• Les modules complémentaires supprimés expireront à la fin de leur période de facturation en cours.
• Lorsque vous lancez le processus de facturation, vous devez spécifier tous les éléments actifs de l'abonnement avec modules complémentaires, à l'exception de ceux à supprimer, ainsi que les nouveaux modules complémentaires.

L'exemple suivant montre comment appeler l'API launchBillingFlow lors de la modification d'un achat d'abonnement existant avec des modules complémentaires :

BillingClient billingClient = …;

int replacementMode =…;

// ProductDetails obtained from queryProductDetailsAsync().
ProductDetailsParams productDetails1 = ...;
ProductDetailsParams productDetails2 = ...;
ProductDetailsParams productDetails3 = ...;

ArrayList newProductDetailsList = new ArrayList<>();
newProductDetailsList.add(productDetails1);
newProductDetailsList.add(productDetails1);
newProductDetailsList.add(productDetails1);

BillingFlowParams billingFlowParams =
    BillingFlowParams.newBuilder()
        .setSubscriptionUpdateParams(
          SubscriptionUpdateParams.newBuilder()
              .setOldPurchaseToken(purchaseTokenOfExistingSubscription)
              // No need to set if change does not affect the base item.
             .setSubscriptionReplacementMode(replacementMode)
             .build())
        .setProductDetailsParamsList(productDetailsList)
        .build();

billingClient.launchBillingFlow(billingFlowParams);

Scénarios de modification d'abonnement

Le tableau suivant liste les différents scénarios de modification d'un abonnement avec des modules complémentaires, ainsi que le comportement correspondant.

Lorsque vous utilisez SubscriptionProductReplacementParams

Lorsque vous utilisez SubscriptionUpdateParams

Notifications en temps réel pour les développeurs

Le champ subscriptionId n'est pas fourni dans RTDN pour les achats d'abonnements avec des modules complémentaires, qui contiennent plusieurs droits d'accès à des articles. Vous pouvez utiliser les API Play Developer pour obtenir l'achat et consulter les droits d'accès associés à l'article.

Changements de prix pour les abonnés existants

La modification du prix d'un abonnement existant avec achat de modules complémentaires est semblable à la modification du prix d'un abonnement à un seul article, comme décrit dans Modifier le prix des abonnements. Toutefois, il existe certaines limites et différences fonctionnelles, comme décrit dans cette section.

Mettre fin à une cohorte d'anciens prix

Mettre fin à une cohorte d'anciens prix a également un impact sur les achats d'abonnements avec modules complémentaires. Les règles suivantes s'appliquent :

• Toutes les augmentations de prix avec option d'acceptation en attente doivent avoir la même heure de renouvellement que le nouveau prix. Si un article d'un achat d'abonnement avec modules complémentaires a une augmentation de prix avec option d'acceptation qui n'a pas encore été confirmée par l'utilisateur, toute nouvelle augmentation de prix avec option d'acceptation pour d'autres articles de l'achat sera ignorée, sauf si elle entraîne la même heure de renouvellement de l'application du nouveau prix que l'augmentation de prix existante à l'état OUTSTANDING. Une fois que l'utilisateur a confirmé l'augmentation de prix, les nouveaux changements de prix sont enregistrés. De plus, les utilisateurs ne peuvent accepter qu'en une seule fois toutes les augmentations de prix nécessitant une confirmation.

  Exemple :

  • Prenons l'exemple d'un abonnement avec des modules complémentaires (éléments A et B) qui se renouvelle le 7 de chaque mois.
  • L'article A fait l'objet d'une migration de prix de 7 $à 10 $, qui devrait être applicable le 7 juillet.
  • Une nouvelle migration de prix de 5 $à 6 $commence pour l'article B le 2 juin. Étant donné que l'augmentation de prix avec option d'acceptation commence 37 jours après la migration, la première augmentation de prix pour l'article B aura lieu le 7 août.

  Dans ce scénario, tant que l'utilisateur n'a pas accepté le changement de prix de l'article A (tant qu'il n'est pas à l'état CONFIRMED), le changement de prix de l'article B n'est pas enregistré pour cet achat d'abonnement, et SubscriptionPurchaseV2 ne renvoie pas les détails du changement de prix pour l'article B. Une fois que l'utilisateur a confirmé le changement de prix de l'article A, le changement de prix de l'article B commence. L'utilisateur ne reçoit l'augmentation de prix avec option d'acceptation pour l'article B qu'après avoir accepté celle de l'article A.

• L'e-mail de Google Play contient la liste de tous les articles dont le prix augmente ou diminue le même jour.

Résilier un abonnement avec des modules complémentaires

Les utilisateurs peuvent résilier l'intégralité d'un achat d'abonnement avec des modules complémentaires dans le centre des abonnements Play. Vous ne pouvez résilier l'intégralité d'un achat d'abonnement avec des modules complémentaires qu'à l'aide de l'API Google Play Developer.

Lorsqu'un achat d'abonnement est annulé sans être révoqué, aucun des éléments de l'achat ne sera renouvelé automatiquement, mais l'utilisateur continuera d'avoir accès aux éléments auxquels il a droit jusqu'à la fin des périodes de facturation correspondantes.

Révoquer et rembourser des abonnements avec modules complémentaires

Voici quelques consignes à suivre pour révoquer et rembourser des abonnements :

• Utilisez la Play Console pour émettre un remboursement basé sur un montant pour une commande spécifique sans révoquer l'accès à l'abonnement.

• Appelez orders.refund pour rembourser intégralement des paiements d'abonnement spécifiques effectués par l'utilisateur sans révoquer l'accès à l'abonnement.

• Appelez purchases.subscriptionsv2.revoke pour révoquer immédiatement l'accès à tous les éléments de l'abonnement. Avec cette API, vous pouvez :

  • Révoquez l'accès à tous les éléments et accordez un remboursement au prorata.

  • Lorsque vous révoquez un abonnement avec des modules complémentaires en utilisant des remboursements au prorata, un remboursement est émis pour la dernière commande de chaque élément avec un montant au prorata basé sur le temps restant jusqu'au prochain renouvellement.

  • Révoquez l'accès à tous les éléments et effectuez un remboursement total.

  • Révoquez l'accès à un élément individuel et obtenez un remboursement intégral de cet élément.

Révoquer un élément individuel dans un abonnement avec des modules complémentaires

Pour révoquer des éléments d'abonnement individuels dans un abonnement avec des modules complémentaires sans révoquer l'intégralité de l'achat, appelez purchases.subscriptionsv2.revoke avec le champ ItemBasedRefund défini dans RevocationContext. Le productId de l'article qui doit être révoqué et remboursé peut être défini dans le champ ItemBasedRefund.

Le champ ItemBasedRefund peut être défini pour les achats comportant un ou plusieurs éléments d'abonnement à renouvellement automatique.

• S'il reste des éléments actifs dans l'achat d'abonnement après la révocation de l'élément spécifié dans ItemBasedRefund, seul l'élément sera révoqué et remboursé intégralement, sans interrompre l'état de l'abonnement.
• S'il ne reste aucun élément actif dans l'achat d'abonnement après la révocation de l'élément spécifié dans ItemBasedRefund, l'élément est révoqué, entièrement remboursé et l'abonnement est résilié.

Points à prendre en compte

• Lorsque vous utilisez ItemBasedRefund, vous ne pouvez révoquer qu'un seul élément à la fois. La requête peut être appelée plusieurs fois si différents éléments doivent être révoqués.
• Lorsque l'achat d'abonnement est dans l'un des états de paiement refusé, ou que l'article spécifié dans ItemBasedRefund n'est pas possédé ou a expiré, le refus de l'article est bloqué.
• La désactivation d'articles n'est pas disponible pour les abonnements prépayés.

Expiration des articles en cas de paiement refusé

Pour un achat d'abonnement avec des modules complémentaires, il se peut que certains renouvellements n'aient besoin que d'étendre un sous-ensemble de droits d'accès aux éléments, sans affecter les éléments dont la date d'expiration est ultérieure.

Quels que soient les éléments concernés par un renouvellement, si le paiement du renouvellement est refusé, l'achat de l'abonnement dans son ensemble entrera dans la période de grâce et le compte sera suspendu, comme décrit dans la documentation suivante.

Sélection de la période de récupération

Étant donné que le délai de grâce lui-même accorde toujours des droits d'accès à l'utilisateur, lors de l'achat d'un abonnement avec des modules complémentaires, si le paiement du renouvellement est refusé, l'élément avec le délai de grâce minimal parmi tous les éléments actifs est sélectionné, et son délai de grâce et sa période de blocage de compte sont appliqués comme période de récupération pour ce renouvellement.

Les éléments actifs incluent les éléments qui étaient actifs lors de l'achat d'un abonnement avec des modules complémentaires juste avant la tentative de renouvellement. Ils excluent les éléments nouvellement ajoutés (qui ne seront disponibles qu'après la récupération) et les éléments qui ne sont plus actifs en raison de leur suppression ou de leur arrêt.

Le paramètre de blocage de compte de l'élément avec le délai de grâce minimal sélectionné est appliqué. S'il existe plusieurs éléments avec le délai de grâce minimal, mais des périodes de blocage de compte différentes, la période de blocage de compte la plus longue est appliquée.

Délai de grâce

Lorsqu'un paiement de renouvellement d'abonnement est refusé, l'achat de l'abonnement passe à l'état de délai de grâce. Pendant le délai de grâce, l'utilisateur continuera d'avoir accès à tous les éléments actifs de la période de renouvellement précédente. Si le mode de paiement n'a pas été corrigé après le délai de grâce, l'ensemble de l'achat de l'abonnement est soumis à un blocage de compte. Si d'autres éléments arrivent à leur date de renouvellement pendant le délai de grâce, une nouvelle tentative de débit sera lancée pour ces éléments une fois que l'abonnement aura été rétabli après le refus du paiement.

Blocage de compte

Tant que l'achat de l'abonnement est suspendu, l'accès à tous les éléments de l'abonnement est suspendu jusqu'à ce que le paiement soit récupéré.

Si l'abonnement en blocage de compte est récupéré, l'achat d'abonnement reste tel quel. Si l'abonnement n'est pas récupéré, les éléments dont le paiement a été refusé expirent, et l'accès aux autres éléments est rétabli pour le reste de leur période de facturation.

Exemple :

• Un utilisateur dispose d'un abonnement Mon forfait de base qui se renouvelle le 1er de chaque mois. Le 15 août, il ajoute un forfait complémentaire à 10 $par mois avec un essai sans frais de sept jours. Aucun délai de grâce n'est défini pour ces deux éléments, et la période de blocage du compte est de 30 jours pour chacun d'eux.

• Le 22 août, l'utilisateur est facturé 2, 90 $ (10*9/31) au prorata jusqu'au 31 août, mais son mode de paiement expire avant cette date et l'abonnement est refusé le 22 août.

Lorsque l'abonnement est soumis à un blocage de compte en raison d'un échec de paiement, l'utilisateur n'a accès à aucun des éléments de l'abonnement avec modules complémentaires. Le temps restant pour les éléments qui ne sont pas renouvelés sera restitué aux utilisateurs lorsque l'abonnement ne sera plus bloqué, soit parce que le paiement a été récupéré, soit parce qu'il a été résilié.

Dans l'exemple précédent, un abonnement est bloqué le 22 août.

• Si le compte est récupéré le 25 août, avant la date de renouvellement plus générale du 1er septembre, l'utilisateur retrouve l'accès à Mon forfait de base et à Mon forfait complémentaire le même jour. La prochaine date de facturation est reportée au 4 septembre.

• Si le compte n'est pas récupéré au bout de 30 jours, l'abonnement sera résilié le 21 septembre et l'utilisateur perdra l'accès au module complémentaire. Il retrouvera l'accès à son forfait de base jusqu'au 30 septembre.

Dans cet exemple, vous devez obtenir le expiryTime mis à jour pour TOUS les éléments de l'abonnement avec modules complémentaires, car certains éléments peuvent reprendre leur droit d'accès après le délai de grâce et le blocage du compte.

Rapprochement et rapports financiers

Utilisez le rapport sur les revenus pour rapprocher vos abonnements actifs avec les transactions sur Play. Chaque ligne d'article de transaction comporte un ID de commande. Pour les achats représentant plusieurs articles, les rapports sur les revenus et les ventes estimées incluront une ligne distincte pour chaque transaction (par exemple, frais, taxe et remboursement) pour chaque article concerné.

Pour les tableaux de bord de la Play Console :

• Les statistiques sur les revenus présentées dans la section Rapports financiers de la console sont ventilées par élément.

• La gestion des commandes reflète l'achat d'un abonnement avec des modules complémentaires et affiche des listes détaillées des articles achetés. Dans la gestion des commandes, vous pouvez révoquer, annuler ou rembourser intégralement l'achat d'un utilisateur.