DeviceCheck d'Apple se souvient du téléphone d'un fraudeur aux remboursements, même après une inscription avec un nouveau compte

Bannir le compte n'arrête pas un fraudeur aux remboursements qui se réinscrit sur le même téléphone. DeviceCheck d'Apple et le rappel d'appareil (device recall) de Google Play existent précisément pour combler ce vide. Chacun permet à votre serveur d'associer quelques bits, dont vous fixez le sens, à un appareil physique. Ils sont stockés sur les serveurs du store, si bien que le signalement est toujours là quand la personne revient avec une nouvelle adresse e-mail. Aucun des deux outils ne vous fournit d'identifiant d'appareil, et aucun ne peut bloquer un remboursement. Ce qu'ils font, c'est vous indiquer, à l'inscription ou sur l'écran de paiement, que cet appareil vous a déjà coûté de l'argent.

Voici ce que chaque store stocke réellement, le piège de calendrier qui détermine si vous pouvez même poser le signalement, et ce que coûte un fraudeur récidiviste avant que vous ne le repériez.

Pourquoi un nouveau compte déjoue toutes les défenses au niveau du compte

La plupart des défenses contre les remboursements reposent sur un compte. L'appAccountToken d'Apple rattache une transaction à un utilisateur de votre base de données. L'identifiant de compte obscurci de Google Play fait de même sur Android. Il faut définir les deux à chaque achat, et tous deux décrivent le compte d'une personne, pas le matériel qu'elle tient en main. Supprimez le compte, inscrivez-vous avec un nouvel e-mail, et votre historique sur cette personne repart de zéro.

Les stores ne comblent pas ce vide à votre place. Une notification de remboursement de l'App Store vous indique quelle transaction a été remboursée. Un achat annulé de Google Play vous indique le jeton d'achat, l'identifiant de commande et un voidedReason. Aucun ne contient d'identifiant d'appareil. Un développeur d'app de rencontre a décrit le résultat dans un fil des Apple Developer Forums : des faux profils achetaient sans cesse un abonnement premium ensuite remboursé, et bannir leurs appareils avec la méthode maison du développeur n'a servi à rien.

Un nouveau compte réinitialise-t-il l'essai du store lui-même ?

Pas avec le même compte Apple. La documentation d'Apple précise que les offres de lancement, essais gratuits compris, sont réservées aux clients qui n'en ont pas encore bénéficié pour ce produit ou pour un autre produit du même groupe d'abonnements. Une nouvelle connexion dans votre app n'ouvre donc pas droit à un second essai Apple. Un nouveau compte Apple, si, tout comme ce que vous offrez vous-même : crédits d'inscription, essai financé par votre serveur, bonus de parrainage. Ce sont ces cadeaux qu'un signalement d'appareil protège.

Ce que DeviceCheck d'Apple stocke réellement

DeviceCheck comporte deux parties. Dans l'app, la classe DCDevice génère un jeton éphémère qui identifie l'appareil. Sur votre serveur, vous envoyez ce jeton à Apple avec un JSON web token signé par une clé de votre compte développeur, et Apple vous permet de consulter ou de mettre à jour deux bits pour cet appareil. La réponse à la requête renvoie bit0, bit1 et last_update_time, exprimé en année et en mois. Les exemples d'usage donnés par Apple sont un appareil qui a déjà profité d'une offre promotionnelle et un appareil que vous avez jugé frauduleux.

Apple conserve les bits, mais leur sens vous appartient. Sa documentation précise que c'est à vous de suivre ce que signifient les bits et de décider quand les réinitialiser, avec l'exemple d'un appareil revendu. Deux bits donnent quatre états. Un schéma simple consiste donc à utiliser un bit pour remboursé après un usage intensif et un autre pour a déjà reçu des crédits gratuits.

• Le jeton est à usage unique. Apple indique qu'il reste valide assez longtemps pour relancer une requête, mais vous devez en générer un nouveau à chaque appel.
• Les builds de développement communiquent avec api.development.devicecheck.apple.com. La production doit utiliser api.devicecheck.apple.com, sinon vos signalements atterrissent au mauvais endroit.
• Apple présente DeviceCheck comme un élément parmi d'autres d'une évaluation globale du risque, pas comme un verdict. Considérez un bit activé comme une raison d'y regarder de plus près.

Ce que le rappel d'appareil de Google apporte sur Android

La version de Google fait partie de la Play Integrity API et reste en bêta, accessible via un formulaire de manifestation d'intérêt. Une fois accepté et la fonction activée dans Play Console, chaque verdict d'intégrité comporte trois bits personnalisés pour l'appareil. Vous les écrivez par un appel serveur vers le point de terminaison deviceRecall:write, avec un jeton d'intégrité déjà vérifié. Google indique que les données survivent à une réinstallation de l'app et à une réinitialisation de l'appareil, car elles sont stockées sur ses serveurs.

La documentation de Google est d'une franchise inhabituelle sur le cas d'usage. Elle cite les appareils présentant des preuves d'abus graves, les appareils ayant déjà obtenu un avantage de grande valeur comme un essai gratuit, et les appareils utilisés à répétition pour créer de nouveaux comptes à des fins abusives. Elle est tout aussi claire sur la limite : device recall ne peut servir qu'à protéger la sécurité de l'app et à lutter contre les abus, la fraude et les accès non autorisés, jamais à identifier par empreinte ou à suivre des utilisateurs individuels, et jamais à stocker des caractéristiques sensibles comme l'âge, le genre ou la localisation.

Le problème du calendrier : les remboursements arrivent après la disparition du jeton

Les deux outils ont besoin de quelque chose provenant de l'appareil lui-même avant que vous puissiez le signaler. Apple exige un jeton DCDevice neuf. Google exige un jeton d'intégrité de cet appareil datant de 14 jours au plus. Le remboursement, lui, arrive sur votre serveur via une notification du store qui ne sait rien de l'appareil. La question n'est donc pas de savoir s'il faut signaler un appareil. C'est de savoir si vous aurez encore un moyen de l'atteindre quand le remboursement tombera.

Les remboursements à 48 heures de Google tiennent dans la fenêtre de 14 jours

Les remboursements en libre-service de Google Play ne sont possibles que dans les 48 heures suivant l'achat, bien en deçà des 14 jours pendant lesquels un jeton d'intégrité reste utilisable pour écrire. Lancez une vérification d'intégrité au moment de l'achat, conservez le jeton vérifié avec l'identifiant de commande et, lorsqu'un achat annulé arrive pour cette commande, vous pouvez écrire le bit immédiatement. Les rétrofacturations sont le cas difficile, car un litige bancaire peut survenir bien après le 14e jour.

Les remboursements Apple exigent que l'appareil revienne

Un remboursement Apple peut arriver des semaines après l'achat, et un jeton DeviceCheck stocké n'est pas fait pour être réutilisé. La réponse pratique consiste à signaler d'abord le compte, puis l'appareil. Quand la notification de remboursement arrive, signalez le compte dans votre base de données. La prochaine fois que ce compte ouvre l'app, demandez un jeton DeviceCheck et activez le bit. Les fraudeurs qui conservent le contenu après un remboursement reviennent généralement, car l'utiliser était justement le but.

• À l'achat, enregistrez la transaction sur votre propre compte via appAccountToken ou l'identifiant de compte obscurci.
• Lors d'un remboursement ou d'une annulation, signalez ce compte sur votre serveur.
• À la session suivante du compte signalé, récupérez un jeton d'appareil et activez votre bit.
• À chaque inscription, consultez les bits avant d'accorder quoi que ce soit qui vous coûte de l'argent.

Ce que vous coûte un fraudeur récidiviste aux remboursements

Le prix remboursé est la partie visible. Le reste, c'est tout ce que l'achat a déjà mis en route. Si votre app dépense de l'argent pour fournir ce qu'elle vend, chaque cycle achat, consommation, remboursement laisse cet argent dépensé : temps GPU pour les images générées, appels payants à une API de modèle ou de données, stockage des exports que le client conserve, et reversements aux créateurs calculés sur la vente. Un nouveau compte relance la boucle, et votre comptabilité l'enregistre comme un tout nouveau client.

Les cadeaux gratuits fuient de la même manière, sans le moindre remboursement. Un appareil qui accumule des crédits d'inscription sur dix comptes consomme dix fois la puissance de calcul prévue pour un seul essai. Sur Google Play, les rétrofacturations sur les commandes postérieures au 3 août 2026 vous coûtent aussi le prix d'achat diminué des frais de service de Google, plus les frais bancaires. Une personne qui conteste depuis un nouveau compte à chaque fois vous coûte donc à nouveau l'intégralité du litige.

Que faire d'un appareil signalé

Un signalement répond à une seule question : cet appareil doit-il de nouveau recevoir quelque chose gratuitement ? Restez proportionné, car un bit activé est un indice, pas une preuve. Les téléphones sont revendus, les familles partagent des iPads, et Google vous invite explicitement à envisager d'ignorer ou de réinitialiser les données anciennes pour cette raison.

• Supprimez les crédits d'inscription, l'essai financé par votre serveur ou le bonus de parrainage sur un appareil signalé, et proposez plutôt l'offre payante.
• Ne signez pas d'offre promotionnelle pour un appareil signalé. Sur l'App Store, c'est votre serveur qui génère la signature débloquant une offre promotionnelle, le choix vous revient donc.
• Exigez que le paiement soit confirmé avant de livrer des consommables coûteux sur un appareil signalé.
• Utilisez l'horodatage. Un signalement posé le mois dernier pèse plus qu'un signalement vieux de deux ans.
• Donnez aux gens un moyen de joindre le support. L'acheteur d'un téléphone d'occasion signalé à tort mérite une réponse, et vous pouvez réinitialiser les bits.

Peut-on simplement bannir l'appareil ?

Vous pouvez refuser vos propres extras gratuits, et c'est là que les signalements d'appareil sont rentables. Un blocage total est plus risqué. La personne qui détient le téléphone aujourd'hui n'est peut-être pas celle qui en a abusé, et les conditions de Google limitent device recall à la prévention des abus, pas au suivi des personnes. Restreignez ce qui vous coûte de l'argent et laissez la voie payante ouverte.

Et le Keychain (trousseau) ou un identifiant d'appareil ?

Les développeurs demandent souvent si un marqueur dans le Keychain ou un identifiant matériel ferait le même travail. Un marqueur que votre app stocke sur le téléphone disparaît après une réinitialisation de l'appareil, et Apple ne fournit pas aux apps d'identifiant matériel stable pour cet usage. DeviceCheck et device recall sont les réponses validées par les stores, précisément parce que les bits résident sur les serveurs d'Apple et de Google plutôt que sur le téléphone.

Là où le store décide toujours

Les signalements d'appareil changent ce que votre app offre ensuite. Ils ne touchent pas au remboursement en cours. Seuls deux circuits de remboursement vous permettent de fournir des éléments avant la décision du store. Apple envoie un CONSUMPTION_REQUEST et demande des données de consommation sous 12 heures. Google Play ouvre un examen de rétrofacturation auquel vous répondez sous 24 heures via orders.reviewrefund. Tout le reste, des remboursements à 48 heures de Google Play aux remboursements par le support et aux remboursements automatiques des achats non confirmés, se décide sans vous. Les rétrofacturations sont définitives une fois que la banque a statué.

RefundHalt répond à chaque CONSUMPTION_REQUEST et à chaque examen de rétrofacturation Google Play dans les délais, avec vos données d'usage réelles, et rattache chaque remboursement au compte qui l'a demandé, pour que votre serveur sache quel appareil signaler la prochaine fois qu'il se connecte.