All articles Analytics Growth Infrastructure Product Updates

Le nouveau modèle d’abonnement et la facturation Google Play Library 5.0: vue d’ensemble

Kamo Spertsyan

Au cours de la conférence annuelle I/O, Google a présenté sa nouvelle version majeure de Google Play Billing Library (bibliothèque de facturation). En dehors des dépréciations et suppressions de méthodes classiques, il y avait aussi de nombreuses informations sur la nouvelle architecture des abonnements, qui a pour but de simplifier la façon dont vous pouvez créer, gérer et vendre des achats dans les applications. Dans cet article, je vais explorer les mises à jour de Google Play Billing Library 5.0 et approfondir les plus intéressantes.

Le nouveau modèle d’abonnement

Le système de facturation de Google Play (« Google Play Billing System ») est le principal outil qui vous aide à monétiser votre application grâce aux abonnements. Si vous ne connaissez pas encore ce service, veuillez lire cet article. Dans la dernière version de sa bibliothèque, Google a modifié la structure de la définition de ses abonnements, ce qui a entraîné des changements dans la façon dont ils sont vendus dans l’application et gérés sur votre backend.

Avec Google Play Billing Library 5.0. Google a introduit une nouvelle architecture d’abonnement, qui ajoute des entités telles que les programmes de paiement de base et les offres. Voyons cela de plus près.

Supposons que vous ayez un abonnement premium dans votre application et que vous proposiez à vos clients des abonnements hebdomadaires, mensuels et annuels. Avant ces mises à jour, vous auriez dû créer trois abonnements différents – un par période. Imaginez ensuite que vous souhaitiez offrir un essai gratuit aux utilisateurs qui ont quitté votre application afin de les persuader de revenir. Vous devrez donc également créer un autre abonnement annuel avec un essai gratuit.

Ce sont seulement deux des cas les plus courants, donnant lieu à la création de nombreux abonnements avec le modèle d’abonnement précédent – il pourrait y avoir de nombreux autres exemples.

Mais à partir de maintenant, vous pouvez gérer tous ces scénarios avec un seul abonnement. Google a divisé un modèle d’abonnement en trois entités : l’abonnement proprement dit, les programmes de paiement de base et les offres.

La nouvelle entité d’abonnement comprend :

un identifiant
titre
description
informations fiscales

Le reste des informations est mis en place via les programmes de paiement de base et les offres.

Un programme de paiement de base contient:

l’identifiant
le type de renouvellement (autorenouvellement ou prépaiement)
la durée
le délai de grâce
prix et disponibilité pour différentes régions
quelques paramètres moins importants

Vous pouvez trouver la liste complète des détails dans la documentation officielle

Une offre contient:

l’identifiant
les critères d’éligibilité – une option déterminant quels utilisateurs peuvent accéder à cette offre (les nouveaux abonnés, ceux qui passent d’un autre abonnement à un abonnement supérieur, ou les développeurs déterminés),
les phases, y compris les essais gratuits et les paiements uniques ou récurrents (l’utilisation des phases est illustrée dans la capture d’écran ci-dessous)
un rabais sur le prix – soit un montant fixe, soit un pourcentage ou une remise absolue en fonction du prix du programme de paiement de base

Chaque abonnement peut contenir un ou plusieurs programmes de paiement de base, qui à leur tour peuvent contenir plusieurs offres (voir le schéma ci-dessus). Ainsi, dans l’exemple ci-dessus, vous pouvez créer un abonnement premium avec trois programmes de paiement de base – un par période, et une offre avec un essai gratuit pour le plan de base annuel.

Achat de nouveaux abonnements

En parlant de code, dans Google Play Billing Library 5.0, la classe SkuDetails est dépréciée ainsi que toute autre entité ou méthode contenant Sku dans son nom. Vous devriez maintenant envisager d’utiliser ProductDetails à cette fin. Les détails du produit contiennent des informations sur un abonnement, y compris ses programmes de paiement de base et ses offres.

Auparavant, vous demandiez des détails d’abonnement comme ceux ci-dessous:

val params = SkuDetailsParams.newBuilder()
    .setType(BillingClient.SkuType.SUBS)
    .setSkusList(listOf("premium"))
    .build()

billingClient.querySkuDetailsAsync(params) { 
        billingResult, skuDetailsList -> // Process the result
}

Vous devez maintenant faire comme ceci:

val productList = listOf(
    QueryProductDetailsParams.Product.newBuilder()
        .setProductType(BillingClient.SkuType.SUBS)
        .setProductId("premium")
        .build()
)

val params = QueryProductDetailsParams.newBuilder()
    .setProductList(productList)
    .build()

billingClient.queryProductDetailsAsync(params) {
    billingResult, productDetailsList -> // Process the result
}

Et, pour lancer le flux d’achat, vous avez utilisé les constructions suivantes:

val billingFlowParams = BillingFlowParams.newBuilder()
    .setSkuDetails(skuDetails)
    .build()

val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)

Alors que maintenant, cela devrait ressembler à ceci :

// Note that `subscriptionOfferDetails` can be null if it is an in-app product, not a subscription.
val offerToken = productDetails.subscriptionOfferDetails?.get(selectedOfferIndex)?.offerToken ?: return

val productDetailsParamsList = listOf(
    BillingFlowParams.ProductDetailsParams.newBuilder()
        .setProductDetails(productDetails)
        .setOfferToken(offerToken)
        .build()
)

val billingFlowParams = BillingFlowParams.newBuilder()
    .setProductDetailsParamsList(productDetailsParamsList)

val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)

Vous pouvez également consulter les exemples de migration dans les étapes de migration officielles de Google. Notez qu’il y a quelques erreurs de frappe dans leurs exemples qui sont corrigées ici.

Passons en revue les changements.

Comme je l’ai mentionné, vous devez maintenant utiliser ProductDetails pour interroger les détails de l’abonnement et le flux d’achat. En plus, vous devez fournir un offerToken aux paramètres du flux de facturation, car chaque ProductDetails peut contenir plusieurs offres. Notez que le tableau des détails de l’offre (productDetails.subscriptionOfferDetails) contient toujours les informations sur le programme de paiement de base (si un programme de base existe). Ainsi, même si votre abonnement ne contient qu’un programme de base sans offre, il disposera toujours d’un OfferToken pour l’achat.

Vous pouvez remarquer que le nouveau flux d’achat accepte plusieurs ProductDetails au lieu d’un SkuDetails comme dans la version précédente. Mais si vous fournissez plus d’un ProductDetails, le flux se terminera par une erreur. Le guide d’intégration officiel donne le mauvais exemple d’utilisation des méthodes setProductDetails et setOfferToken directement sur la classe BillingFlowParams.Builder, mais seule setProductDetailsParamsList est la méthode disponib l e pour faire cela. Il semble que Google ait décidé récemment de passer d’un produit unique à plusieurs produits, dans l’optique d’un avenir où la facturation prendra en charge plusieurs abonnements différents à la fois.

Le reste du flux – à savoir le traitement de l’achat – reste le même que dans la bibliothèque de Google Play Billing Library 4.0.

Compatibilité rétroactive des abonnements

Tout semble bon jusqu’à présent, mais que faire si vous ne voulez pas migrer tout de suite? Google s’en est bien occupé.

Bien que la Google Play Console fonctionne déjà uniquement avec le nouveau modèle d’abonnement, tous les anciens abonnements sont automatiquement convertis au nouveau format, ce qui préserve leur rétrocompatibilité. De ce fait, vos abonnements s’affichent dans le nouveau format sur Google Console, mais vous pouvez toujours les utiliser comme auparavant sur votre application.

Vous remarquerez également que tous les anciens abonnements sont mis en lecture seule après la migration. Google vous avertit que la modification désactivera la prise en charge de l’API InAppProducts pour cet abonnement.

Il se peut que vous utilisiez cette API dans votre backend pour récupérer des détails sur les produits. Soyez prudent : après avoir rendu l’abonnement modifiable, vous recevrez des erreurs (comme indiqué ci-dessous) de cette API si vous essayez de récupérer des informations sur l’abonnement converti. Il en sera de même pour tous les nouveaux abonnements créés après le 11 mai.

HTTP code - 422
Non-existent in-app product: com.qonversion.sample\/ProductId{productId=article_test_trial}

Par conséquent, si vous utilisez l’API InAppProducts, pensez à la mettre à niveau avant de créer de nouveaux abonnements ou de modifier les anciens.

En naviguant dans la nouvelle interface utilisateur des abonnements dans la Google Play Console, vous trouverez des balises ‘Backwards compatible’ près des plans de base et des offres d’abonnements. Cela signifie que si vous achetez ces abonnements en utilisant les SkuDetails obsolètes (comme vous le faites dans Google Play Billing Library 4.0), vous achèterez exactement ces programmes/offres de base compatibles. S’il n’existe qu’un programme de base compatible, sans offre compatible, c’est ce programme de base qui sera acheté. S’il y a à la fois un programme de base compatible et une offre disponible, si l’offre est éligible pour l’utilisateur actuel, elle sera achetée, sinon – plan de base. Vous pouvez choisir un autre programme de base/une autre offre comme rétrocompatible si vous le souhaitez.

Remarque: cette rétrocompatibilité concerne Google Play Billing Library, mais pas l’API InAppProducts. Comme nous l’avons mentionné, si vous commencez à utiliser de nouvelles fonctionnalités, par exemple, plusieurs programmes de paiement de base ou offres pour un abonnement ou si vous le convertissez simplement de lecture seule à modification, cet abonnement peut toujours être rétrocompatible pour une application, mais pas pour une API.

Les autres mises à jour

La bibliothèque de facturation Google Play Billing Library 5.0 comporte plusieurs mises à jour mineures qui méritent d’être brièvement mentionnées.

La méthode queryPurchases, obsolète dans Google Play Billing Library 4.0, a été supprimée.
Plus de requêtes synchronisées, seulement queryPurchasesAsync.
launchPriceChangeFlow a été déprécié – le nouveau flux de changement de prix recommandé nécessite la confirmation des clients via la page d’abonnement de Google Play, vous devez donc utiliser des liens profonds pour y naviguer au lieu d’appeler la méthode BillingClient.
Ajout de la méthode setIsOfferPersonalized pour indiquer un prix personnalisé aux clients de l’UE, conformément à la directive sur les droits des consommateurs. Cette option ajoute une ligne au bas de l’écran d’achat de Google Billing indiquant qu’un prix est personnalisé.

Le nouveau modèle d’abonnement et Qonversion

Pendant que nous travaillons à la prise en charge de la bibliothèque de facturation Google Play Billing Library 5.0, vous pouvez toujours utiliser Qonversion SDK pour vos achats dans l’application. Nous utilisons désormais la bibliothèque Google Play Billing Library 4.0, ce qui signifie que nous ne pouvons gérer que des abonnements avec des plans de base et des offres rétrocompatibles. Vous pouvez toujours modifier les propriétés qui étaient disponibles dans le modèle d’abonnement précédent, comme le prix, le délai de grâce, la durée d’essai, etc. et créer de nouveaux abonnements. Assurez-vous simplement qu’après, vous disposez toujours d’au moins un programme de base rétrocompatible et, si nécessaire, d’une offre rétrocompatible. De plus, nous exigeons toujours un identifiant d’abonnement complet pour configurer les produits dans notre centre de produits, et non des identifiants de plans de base ou d’offres.

Si vous avez des questions, n’hésitez pas à nous les communiquer. Nous serons heureux de vous aider.