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

Lutter contre les fraudes et les abus

À mesure que votre application devient populaire, elle peut attirer l'attention indésirable d'utilisateurs malveillants cherchant à en abuser. Cet article décrit les recommandations à appliquer pour éviter ces attaques contre votre intégration de facturation et pour réduire l'impact des abus dans votre application.

Déplacer la logique sensible vers votre backend

Dans la mesure du possible, transférez les données et la logique sensibles vers un serveur backend que vous contrôlez. Plus vous disposez de données et de logiques dans un appareil d'interface, plus il est vulnérable aux modifications et falsifications.

Par exemple, un jeu d'échecs en ligne doit valider tous les mouvements dans le backend plutôt que de croire aveuglément que l'interface n'envoie que des coups autorisés.

De plus, si vous détectez des failles ou des problèmes de sécurité, selon la conception de votre système, il peut être plus facile de déboguer, de corriger et de déployer des mises à jour sur le backend plutôt que sur l'interface.

Vérifier les achats avant d'accorder des droits

La validation des achats est un cas particulier de données et de logiques sensibles devant être gérées dans le backend. Une fois qu'un utilisateur a effectué un achat, procédez comme suit :

  1. Envoyez le purchaseToken (jeton d'achat) correspondant à votre backend. Cela signifie que vous devez conserver un enregistrement de toutes les valeurs de purchaseToken pour tous les achats.
  2. Vérifiez que la valeur de purchaseToken pour l'achat en question ne correspond à aucune valeur de purchaseToken antérieure. purchaseToken est unique. Vous pouvez donc utiliser cette valeur en toute sécurité comme clé primaire dans votre base de données.
  3. Utilisez Purchases.products:get ou Purchases.subscriptionsv2:get dans l'API Google Play Developer pour vérifier auprès de Google que l'achat est légitime.
  4. Si l'achat est légitime et qu'il n'a pas été utilisé par le passé, vous pouvez alors accorder en toute sécurité le droit d'accès à l'abonnement ou à l'élément intégré.
  5. Pour les abonnements, lorsque linkedPurchaseToken est défini dans Purchases.subscriptionsv2:get, vous devez également supprimer linkedPurchaseToken de votre base de données et révoquer les droits d'accès accordés à linkedPurchaseToken pour empêcher plusieurs utilisateurs de bénéficier du même achat.
  6. Vous ne devez accorder des droits d'accès que lorsque l'état d'achat est PURCHASED (Acheté) et vous assurer de gérer correctement les achats PENDING (Annulés). En cas de pic d'achats CANCELED, vous pouvez accorder des droits d'accès lorsque l'état d'achat est toujours PENDING (En attente). Pour en savoir plus, consultez la page gérer les transactions en attente.

Protéger votre contenu déverrouillé

Pour éviter que des utilisateurs malveillants ne partagent votre contenu déverrouillé, ne le regroupez pas dans votre fichier APK. Effectuez plutôt l'une des opérations suivantes :

  • Utilisez un service en temps réel pour diffuser votre contenu (un flux, par exemple). La diffusion de contenu via un service en temps réel vous permet également de garder vos contenus à jour.
  • Utilisez un serveur distant pour diffuser votre contenu.

Lorsque vous diffusez du contenu depuis un serveur distant ou un service en temps réel, vous pouvez stocker le contenu déverrouillé dans la mémoire ou la carte SD de l'appareil. Si vous stockez du contenu sur une carte SD, veillez à chiffrer le contenu et à utiliser une clé de chiffrement propre à l'appareil.

Détecter et traiter les achats annulés

Les achats annulés regroupent les achats ayant été annulés, révoqués ou rejetés. Si un achat annulé a précédemment fait bénéficier à l'utilisateur d'éléments intégrés ou d'autres contenus, vous pouvez utiliser l'API Voided Purchases pour connaître la raison de l'annulation de l'achat et récupérer tout contenu associé récupérable.

Les achats d'éléments intégrés et d'abonnements peuvent être annulés pour différentes raisons :

  • Un achat est annulé, soit par l'utilisateur, soit par le développeur, soit par Google. Pour les abonnements, notez qu'il s'agit d'annuler l'achat d'un abonnement, plutôt que d'annuler l'abonnement en lui-même.
  • Un achat est remboursé.
  • Le développeur de l'application annule ou rembourse une commande utilisateur et vérifie l'option "revoke" (révoquer) dans la console.

En fonction du motif de l'annulation de l'achat et des données relatives au comportement passé de l'utilisateur, plusieurs actions s'offrent à vous. Nous vous recommandons de mettre en œuvre une ou plusieurs d'entre elles :

  • Effectuer des récupérations : lorsqu'un achat est annulé, vous pouvez récupérer les articles inutilisés comme s'ils n'avaient jamais été achetés. Par exemple, si l'achat d'une monnaie en jeu a été annulé, vous pouvez récupérer le montant déjà accordé à l'utilisateur. Si l'utilisateur a déjà dépensé cette somme, vous pouvez envisager de lui imputer un solde négatif et de limiter son activité dans l'application ainsi que ses futurs achats jusqu'à ce que le solde redevienne positif.
  • Mettre en œuvre plusieurs avertissements : envisagez d'entreprendre des actions moins drastiques pour les nouveaux contrevenants, comme afficher des avertissements dans l'application. En cas d'infractions répétées, envisagez des mesures plus sévères.
  • Désactiver temporairement les achats : comme pour les avertissements, vous pouvez envisager de désactiver les achats pour les utilisateurs dont les achats ont été annulés, jusqu'à ce que vous puissiez examiner plus précisément les raisons de leur annulation.
  • Interdire temporairement ou définitivement l'accès à votre application : pour les cas extrêmes avec des activités malveillantes répétées, envisagez d'interdire temporairement ou définitivement l'accès à votre application.
  • Effectuer des appels fréquents à l'API Voided Purchases : lorsque vous détectez un ou plusieurs achats annulés, envisagez d'effectuer plus d'appels fréquents à l'API Voided Purchases afin de récupérer les achats avant que l'utilisateur ne les utilise. Pour en savoir plus sur les quotas de l'API Voided Purchases, consultez la documentation de l'API Voided Purchases.

Aider Google à anticiper les fraudes

Certains types de fraudes sont liés à des utilisateurs malveillants qui créent plusieurs comptes Google et comptes d'applications pour masquer leur activité.

Utilisez les méthodes setObfuscatedAccountId et setObfuscatedProfileId dans le compilateur de BillingFlowParams pour aider Google à relier les comptes Google aux comptes d'applications.

Google utilise ces données pour détecter les comportements suspects et bloquer certains types de transactions frauduleuses avant leur finalisation.

Lutter contre les atteintes aux marques et aux droits d'auteur

Si vous utilisez un serveur distant pour diffuser ou gérer du contenu, demandez à votre application de vérifier l'état d'achat du contenu déverrouillé chaque fois qu'un utilisateur y accède. Cela vous permet de révoquer l'utilisation si nécessaire et de réduire le piratage. Si vous constatez que votre contenu est redistribué sur Google Play, réagissez rapidement et de manière décisive. Pour en savoir plus, consultez la page questions fréquentes sur les droits d'auteur du centre d'aide relatif aux droits d'auteur.