Abonnement avec modules complémentaires

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

L'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 existants au catalogue de produits en tant que modules complémentaires, sans spécification préalable ni configuration supplémentaire. 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 modules complémentaires 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 des modules complémentaires peut comporter jusqu'à 50 éléments.

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

Intégrer à la bibliothèque Play Billing

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

Lancer un parcours d'achat

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

1. Récupérez tous vos articles 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 l'élément d'abonnement ProductDetails et un offerToken sélectionnant un abonnement spécifique base plan ou offer.

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 s'assurer que les dates de renouvellement des modules complémentaires finissent par s'aligner sur celles de l'élément de base, Google Play peut insérer un débit au prorata après toute phase d'essai ou de prix promotionnel.
• L'éligibilité des offres sera évaluée séparément pour chaque article.

Traiter les achats

Le traitement des abonnements avec des modules complémentaires est le même que celui des achats d'un seul article, comme décrit dans la section 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. L'achat d'un 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 des modules complémentaires

Toute modification apportée à votre abonnement avec des modules complémentaires entraîne une mise à niveau ou une rétrogradation. Pour en savoir plus, consultez la section Mettre à niveau ou rétrograder des abonnements.

Pour modifier ou restaurer un achat d'abonnement existant 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 en cours.
• Pour mettre à niveau, rétrograder ou effectuer une mise à niveau croisée de l'élément de base, appelez setSubscriptionReplacementMode pour spécifier comment le changement de forfait doit être géré entre les éléments de base de l'ancien et le nouvel achat d'abonnement avec des modules complémentaires. 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 setSubscriptionReplacementMode pour appliquer un comportement de prorata spécifique. Pour connaître les règles applicables dans ce cas, consultez la section Se réabonner ou changer de forfait dans le même abonnement.
• Les nouveaux modules complémentaires s'appliquent immédiatement avec un débit au prorata afin d'aligner la date de renouvellement suivante sur l'élément de base de l'abonnement.
• Les modules complémentaires supprimés expirent à la fin de leur période de facturation en cours.
• Lorsque vous lancez le flux de facturation, vous devez spécifier tous les éléments actifs de l'abonnement avec les modules complémentaires, à l'exception de ceux à supprimer, ainsi que les nouveaux modules complémentaires.

L'exemple suivant montre comment appeler l'API launchBillingFlow lorsque vous modifiez 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 présente les différents scénarios de modification des abonnements avec des modules complémentaires, ainsi que le comportement correspondant.

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 plutôt utiliser les API Play Developer pour obtenir l'achat et afficher les droits d'accès associés à l'élément.

Changements de prix pour les abonnés existants

Modifier le prix des abonnements pour les abonnés existants d'un abonnement avec achat de modules complémentaires est semblable à la modification du prix des abonnements à 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 ancienne cohorte a également un impact sur les abonnements avec des achats de modules complémentaires. Les règles suivantes s'appliquent:

• Toutes les augmentations de prix nécessitant une acceptation doivent avoir la même date de renouvellement avec le nouveau prix. Si un article d'un abonnement avec des modules complémentaires fait l'objet d'une augmentation de prix nécessitant une confirmation de la part de l'utilisateur, toute nouvelle augmentation de prix nécessitant une confirmation pour les autres articles de l'achat sera ignorée, sauf si elle entraîne le même délai de renouvellement de l'application du nouveau prix que l'augmentation de prix existante en ATTENTE. Une fois que l'utilisateur a confirmé l'augmentation de prix, les nouveaux changements de prix sont enregistrés. Les utilisateurs ne peuvent accepter toutes les augmentations de prix nécessitant une confirmation qu'en même temps.

  Exemple :

  • Prenons l'exemple d'un abonnement avec des modules complémentaires (articles A et B) qui se renouvelle le 7 de chaque mois.
  • Le prix de l'article A est en cours de migration de 7 $à 10 $. L'augmentation de prix devrait être appliquée 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 nécessitant une acceptation commence 37 jours après la migration, l'augmentation de prix la plus précoce 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 (jusqu'à ce qu'il soit dans 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 de 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 de l'article B qu'après avoir accepté l'augmentation avec option d'acceptation de l'article A.

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

Résilier un abonnement avec des modules complémentaires

Les utilisateurs peuvent annuler l'achat complet d'un abonnement avec des modules complémentaires dans le Centre des abonnements Play. Vous ne pouvez annuler l'achat complet d'un abonnement avec des modules complémentaires qu'à l'aide de l'API Google Play Developer.

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

Résilier des abonnements avec des modules complémentaires et les rembourser

Voici quelques consignes concernant la révocation et le remboursement 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 le numéro orders.refund pour rembourser intégralement les 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 articles et effectuez un remboursement au prorata.

  • Lorsque vous révoquez un abonnement avec des modules complémentaires à l'aide de remboursements au prorata, un remboursement est émis pour la dernière commande de chaque article, avec un montant au prorata en fonction du temps restant avant le prochain renouvellement.

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

  • Révoquer l'accès à un article en effectuant un remboursement total de l'article.

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

Pour résilier des éléments d'abonnement individuels dans un abonnement avec des modules complémentaires sans résilier l'achat complet, 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 avec un ou plusieurs éléments d'abonnement à renouvellement automatique.

• Si des articles restent actifs dans l'achat d'abonnement après la révocation de l'article spécifié dans ItemBasedRefund, seul l'article sera révoqué et remboursé intégralement sans interrompre l'état de l'abonnement.
• Si aucun élément actif ne reste dans l'achat d'abonnement après révocation de l'élément spécifié dans ItemBasedRefund, l'élément est révoqué, remboursé intégralement 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 se trouve dans l'un des états de refus de paiement, ou que l'élément spécifié dans ItemBasedRefund n'est pas détenu ou a expiré, le refus de l'élément est bloqué.
• Le refus d'un article n'est pas possible avec un abonnement prépayé.

Expiration de l'article lors du refus du paiement

Pour un achat d'abonnement avec des modules complémentaires, certains renouvellements peuvent ne nécessiter que l'extension d'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 articles concernés par un renouvellement, si le paiement du renouvellement est refusé, l'achat global de l'abonnement entrera dans le délai de grâce et le compte sera bloqué, comme décrit dans la documentation suivante.

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

Comme le délai de grâce lui-même accorde toujours le droit d'accès à l'utilisateur, lors de l'achat d'un abonnement avec des modules complémentaires, le paiement de renouvellement est refusé, l'élément avec le délai de grâce minimum parmi tous les éléments actifs est sélectionné, et son délai de grâce et la période de blocage du compte en tant que période de récupération sont appliqués 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, et excluent les éléments nouvellement ajoutés (qui ne seront pas éligibles qu'après la récupération) et les éléments qui ne sont plus actifs en raison d'une suppression ou d'un refus.

Le paramètre de retenue de compte de l'article avec le délai de grâce minimal sélectionné est appliqué. Si plusieurs articles sont concernés par le délai de grâce minimal, mais que les périodes d'obligation de conservation du compte sont différentes, la période la plus longue s'applique.

Délai de grâce

Lorsqu'un paiement de renouvellement d'abonnement est refusé, l'achat de l'abonnement passe en é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. À l'issue du délai de grâce, si le mode de paiement n'a pas été corrigé, l'achat de l'abonnement est soumis à un blocage de compte. Si d'autres articles atteignent leur date de renouvellement pendant le délai de grâce, une nouvelle tentative de débit sera lancée pour ces articles une fois que l'abonnement aura récupéré après le refus de paiement.

Blocage de compte

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

Si l'abonnement bloqué est récupéré, l'achat de l'abonnement continue de subsister tel quel. Si l'abonnement n'est pas récupéré, les articles pour lesquels le paiement a été refusé expirent, et l'accès aux autres articles 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 de 10 $par mois avec un essai sans frais de sept jours. Aucun délai de grâce n'est défini pour les deux éléments, et leur blocage de compte est de 30 jours.

• Le 22 août, l'utilisateur est débité de 2,90 $ (10*9/31) pour être proratisé 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 refus de paiement, l'utilisateur n'a pas accès à aucun des éléments de l'abonnement avec des modules complémentaires. Le temps restant pour les éléments qui ne sont pas renouvelés sera restitué aux utilisateurs lorsque l'abonnement sortira du blocage de compte, soit parce que le paiement a été récupéré, soit parce qu'il a été annulé.

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 générale du 1er septembre, l'utilisateur retrouve l'accès à la fois à Mon forfait de base et au forfait complémentaire le même jour. La prochaine date de facturation est fixé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 forfait complémentaire, mais pourra continuer à accéder à Mon forfait de base jusqu'au 30 septembre.

Dans cet exemple, vous devez obtenir la expiryTime mise à jour pour TOUS les éléments de l'abonnement avec des 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 de compte.

Rapports financiers et rapprochement

Utilisez le rapport "Revenus" pour rapprocher vos abonnements actifs des transactions effectuées sur Play. Chaque ligne de transaction est associée à un ID de commande. Si les achats représentent plusieurs articles, les rapports "Revenus et ventes estimées" incluront des lignes distinctes pour chaque transaction, telles que les débits, les frais, les taxes et les remboursements, 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 réparties par éléments.

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