Une personne qui se fait rembourser pour la quatrième fois n'est pas un client insatisfait. Elle applique une méthode, et cela vous coûte le revenu remboursé, plus tout ce que vous avez dépensé pour honorer la commande. Apple et Google exposent chacun un champ d'identité, appAccountToken d'un côté et l'ID de compte obfusqué de l'autre, qui transforme ces incidents isolés en un schéma visible.
Points clés
Vos preuves n'atteignent un store que dans exactement deux situations : le CONSUMPTION_REQUEST d'Apple, à répondre dans les 12 heures, et l'examen de rétrofacturation de Google Play via la Review Refund API, à répondre dans les 24 heures. Tout le reste est décidé en votre absence.
Sur Apple, un UUID que vous générez accompagne l'achat en tant qu'appAccountToken. StoreKit l'attache à la transaction, ce qui signifie que tout remboursement ultérieur se rattache à un compte identifiable dans vos propres registres.
L'équivalent chez Google est une chaîne hachée de 64 caractères maximum. Google lui-même la lit, utilisant ce champ pour repérer un comportement irrégulier, comme un même compte achetant depuis un nombre improbable d'appareils sur une courte période.
Des données personnelles en clair dans ce champ Google entraînent le blocage pur et simple des achats. Une valeur chiffrée ou un hachage à sens unique est requis. Une adresse e-mail brute, elle, ne l'est pas.
Le voidedReason de Play distingue friendly_fraud et fraud d'un simple remboursement pour changement d'avis, ce qui vous donne des motifs pour envoyer les récidivistes dans une file d'examen plutôt que de suivre le parcours par défaut consistant à rembourser et passer à autre chose.
Google indique avoir bloqué plus de 2 milliards de dollars de transactions frauduleuses et abusives en 2022. Ces défenses fonctionnent grâce à des signaux d'identité qui n'existent que si vos achats les transportent.
Un accès qui survit à un remboursement continue de consommer du stockage, du calcul et du budget API que vous n'êtes plus payé pour fournir, et quelqu'un qui se fait rembourser délibérément provoque précisément ce résultat, à répétition.
Introduction
Les remboursements font partie du jeu, et l'un d'entre eux n'est qu'un coût d'exploitation ordinaire. Ce qui change la donne, c'est le même compte qui revient une quatrième fois, après avoir consommé le produit à chaque occasion précédente. Ce comportement n'est lisible pour vous que si chaque transaction arrive avec un identifiant que vous avez attribué. Les deux plateformes en fournissent un. Les deux ouvrent aussi une fenêtre de réponse étroite avant que le résultat ne soit tranché. Oubliez l'identifiant, ou manquez la fenêtre, et une personne qui exploite le système devient indiscernable d'une personne qui demande un remboursement légitime pour la première fois. Ce qui sépare les deux, et ce que cette séparation vaut en argent, c'est ce qui suit.
L'abus de remboursement est en réalité un problème d'identité déguisé en remboursement
Les décisions de remboursement appartiennent au store. Les clients en font la demande, et dans la plupart des flux, le store accepte, sans que vous ayez votre mot à dire. Votre influence se situe ailleurs : établir si ce compte en particulier a un historique de ce type de comportement, et si ce qu'il a acheté a réellement été livré et utilisé. Ces deux questions sont des questions d'identité. Quel utilisateur se cache derrière cette transaction, et qu'a-t-il fait auparavant. Les achats qui ne comportent aucun lien stable vers vos registres d'utilisateurs laissent ces deux questions sans réponse, si bien que chaque remboursement arrive dépourvu de contexte.
C'est l'écart qu'il vaut la peine de combler. La politique fixe la mécanique, et vous ne pouvez pas la déplacer. Les preuves, en revanche, sont à vous de les assembler, et cet assemblage commence au moment du paiement, pas au moment du remboursement.
Deux fenêtres où ce que vous envoyez compte réellement
Seuls deux flux traitent vos informations comme une véritable contribution. Un client qui demande un remboursement sur un consommable ou un abonnement à renouvellement automatique déclenche le CONSUMPTION_REQUEST d'Apple, et votre réponse est due dans les 12 heures. Un client qui conteste un paiement auprès de sa banque déclenche l'examen de rétrofacturation de Google Play, auquel on répond via la Review Refund API dans les 24 heures. En dehors de ces deux cas, la décision se prend sans vous : le remboursement en libre-service de 48 heures de Play, un remboursement accordé par le support, ou un remboursement automatique pour un achat que vous n'avez jamais validé.
Les deux canaux deviennent nettement plus efficaces lorsque la transaction porte déjà votre identifiant. Les informations de consommation envoyées à Apple peuvent inclure l'appAccountToken aux côtés des dépenses et de l'historique de ce compte, tandis que l'examen de Google s'appuie sur un ID de compte obfusqué qu'il observe depuis la finalisation de l'achat. Sans identifiant, il n'y a pas d'historique à soumettre.
Les deux champs d'identité, comparés
Les deux entreprises sont arrivées à des solutions presque identiques, sous des noms différents et avec des contraintes différentes. Chacune vous permet de marquer un achat avec une valeur qui se rattache à votre propre fiche utilisateur. Aucune des deux n'est activée pour vous par défaut. Les deux sont inutiles si elles ne sont pas définies pendant que l'achat a lieu.
Apple : appAccountToken
Générez un UUID, transmettez-le au début de l'achat, et StoreKit le relie à la transaction qui en résulte. Il réapparaît ensuite dans les données de transaction que votre serveur vérifie, puis à nouveau dans les informations de consommation que vous renvoyez lors d'un CONSUMPTION_REQUEST. Comme la valeur vient de vous, elle permet de relier une transaction du store à une ligne de votre base de données sans qu'aucun nom ni e-mail n'entre en jeu. Seuls de véritables UUID sont acceptés ; tout le reste est rejeté. Apple a depuis déployé un point de terminaison Set App Account Token capable d'écrire ou de mettre à jour le token sur des transactions déjà passées, y compris les utilisations de codes promotionnels et autres achats effectués hors application.
Google Play : l'ID de compte obfusqué
setObfuscatedAccountId est la version de Google, une chaîne optionnelle liée au compte effectuant l'achat. La documentation de Google énonce son objectif sans détour : Play utilise cette valeur pour détecter une activité irrégulière, l'exemple donné étant de nombreux appareils transigeant sur un même compte dans un court intervalle, et pour bloquer certains achats frauduleux avant leur finalisation. La limite est de 64 caractères, et les données personnelles en clair sont interdites. Y placer un e-mail brut fait bloquer l'achat, car ce que le champ attend est une valeur chiffrée ou un hachage à sens unique. Les applications où un seul compte contient plusieurs profils disposent d'un champ compagnon, setObfuscatedProfileId.
appAccountToken est le champ d'Apple. Il doit obligatoirement s'agir d'un UUID, votre code le définit pendant le paiement, et il est absent si vous ne l'ajoutez pas. Apple l'utilise pour ancrer la transaction à votre utilisateur, et il réapparaît dans les données de transaction et de consommation.
obfuscatedAccountId est le champ de Google Play. Il prend une chaîne hachée d'au plus 64 caractères, votre code le définit pendant le paiement, et il est lui aussi absent par défaut. Google l'intègre à la détection d'activité irrégulière et l'utilise pour bloquer certains achats frauduleux avant leur finalisation.
Une asymétrie compte énormément. Google ne propose absolument aucun remplissage rétroactif. Un achat Play effectué sans l'identifiant reste anonyme à jamais, et marquer les achats futurs est le seul remède disponible. Le point de terminaison Set App Account Token d'Apple peut réparer l'historique, ce qui en fait l'exception plutôt que la règle.
Le coût réel d'un remboursement chez quelqu'un qui recommence
Le revenu remboursé est la partie visible, et aussi la plus petite. Accorder un remboursement restitue le prix de vente, ce que votre registre comptable enregistre. Ce qui manque à cette ligne, c'est tout ce qui a été dépensé pour produire ce que le client détient désormais gratuitement.
Prenez un consommable qui déclenche un véritable travail : des images générées, une série d'appels à un fournisseur de modèle, une vidéo exportée, un paiement versé à un créateur. Ce calcul a été acheté au moment de son utilisation. Le remboursement récupère le prix de vente et laisse la facture du fournisseur exactement là où elle était. Quelqu'un qui a compris que le produit survit au remboursement répète simplement la séquence : acheter, consommer, se faire rembourser, et chaque itération vous fait payer à nouveau le coût de livraison.
Il y a aussi la plateforme qui reporte les coûts sur vous. À partir du 3 août 2026, Google Play attribue aux développeurs à la fois le prix d'achat et les frais de rétrofacturation bancaires, pour les commandes passées à partir de cette date. Des litiges qui étaient en grande partie à la charge de Google deviennent votre revenu perdu plus des frais, et quelqu'un qui conteste des paiements de manière habituelle fait grimper ce chiffre à chaque tentative. Ce sont les champs d'identité qui permettent de fournir à la Review Refund API quelque chose qui vaille la peine d'être lu, dans la fenêtre de 24 heures.
Google chiffre l'ampleur du problème : plus de 2 milliards de dollars de transactions frauduleuses et abusives bloquées en 2022. Ce chiffre existe parce que les signaux sous-jacents, dont l'ID de compte obfusqué, étaient réellement renseignés. Livrer des achats avec ces champs vides, c'est choisir de se placer hors de cette protection.
Repérer les rembourseurs récidivistes avant que le store ne tranche
Marquez chaque achat avec une identité que vous maîtrisez
Aucune des deux plateformes ne devrait voir un achat sans cela. Les achats StoreKit portent l'appAccountToken, les achats Play Billing portent le setObfuscatedAccountId, et les deux valeurs proviennent de votre propre fiche utilisateur. Apple attend un véritable UUID associé à ce compte, Google attend la clé de compte hachée pour que rien de personnel ne circule en clair. Le paiement est le moment pour les deux, et chez Google, ce timing ne peut pas être renégocié après coup.
Tenez un registre indexé sur cette identité
Enregistrez les livraisons, les événements de consommation, les achats et les remboursements, tous classés sous cet identifiant. Un CONSUMPTION_REQUEST ou un examen de rétrofacturation rend alors tout le passé de ce compte, remboursements antérieurs inclus, accessible en une seule requête. Les informations de consommation d'Apple fournissent des champs dédiés précisément à ce type de données : consumptionStatus, deliveryStatus, playTime, accountTenure, lifetimeDollarsPurchased, et votre propre refundPreference.
Traitez voidedReason comme une décision d'aiguillage
Les achats Play annulés portent un voidedReason expliquant la cause, et friendly_fraud et fraud sont enregistrés séparément d'un simple remords ordinaire. Ces cas méritent une file d'examen et une politique plus ferme, plutôt que le traitement automatique réservé à un premier remboursement. Les recommandations de Google décrivent des réponses graduelles : un avertissement au début, quelque chose de plus ferme en cas de répétition, et les achats désactivés pour les comptes qui persistent.
Ne manquez jamais la fenêtre
Des preuves soumises en retard reviennent à ne pas exister du tout. Automatisez la réponse au CONSUMPTION_REQUEST pour qu'elle soit envoyée confortablement dans les 12 heures, et l'examen de rétrofacturation dans les 24 heures. Un historique de compte irréprochable déposé après la date limite est un historique que personne, au store, n'ouvrira.
Pour repérer un compte qui transige depuis un nombre d'appareils improbable en même temps, appuyez-vous sur la détection d'activité irrégulière de Google Play, qui lit l'ID de compte obfusqué.
Pour voir un historique de remboursements antérieurs sur ce compte, appuyez-vous sur vos propres registres, c'est-à-dire le journal que vous avez indexé sur l'identifiant de l'une ou l'autre plateforme.
Pour confirmer que le produit a bien été livré à l'acheteur et utilisé, appuyez-vous sur Apple, où consumptionStatus et deliveryStatus se trouvent dans les informations de consommation.
Pour repérer une contestation qui est en réalité une fraude de l'acheteur à votre encontre, appuyez-vous sur Google Play, où voidedReason revient avec la valeur friendly_fraud.
Où les plateformes aident, et où elles s'arrêtent
Être précis sur la répartition des responsabilités vaut la peine, car il est facile de supposer que les stores gèrent eux-mêmes les abus, et ils annoncent rarement le point où ils s'arrêtent. Google lit réellement l'ID de compte obfusqué pour bloquer certaines fraudes avant l'achat, et les systèmes au niveau de la plateforme interceptent un volume substantiel. Apple se réserve chaque décision de remboursement et traite vos informations de consommation comme une preuve, pas comme un vote. Ce que ni l'un ni l'autre des stores ne fait, c'est tenir une liste d'abuseurs pour vous, recréditer sur votre solde un consommable remboursé, ou refuser un rembourseur récidiviste à votre place. Dans les cas limites, l'identité appartient au store pour agir. Partout ailleurs, elle vous appartient.
Refund Sensor est conçu autour de cette identité, pour la même raison. Un remboursement, un examen de rétrofacturation et une demande de consommation appartenant à un même compte se rassemblent en un seul historique, si bien qu'un schéma répété devient visible dès la deuxième occurrence, plutôt qu'après que la quatrième facture a déjà été payée.
Où ces règles sont documentées
Android : BillingFlowParams.Builder et setObfuscatedAccountId
Android : lutter contre la fraude et les abus dans Play Billing
Google Play Billing : suggestions de remboursement et de rétrofacturation via la Review Refund API
Android Developers Blog : Play Commerce et les 2 milliards de dollars bloqués en 2022
Questions fréquentes
Cela décrit un client qui demande des remboursements de manière répétée après avoir reçu et utilisé ce qu'il a acheté, conservant ainsi le bénéfice tout en récupérant le paiement. Dans le contexte d'un app store, cela se traduit généralement par un même compte qui se fait rembourser des consommables ou des abonnements encore et encore, ou par de la fraude amicale (friendly fraud), où un paiement valide est contesté auprès de la banque à la place.
Sur Apple, vous générez un UUID, que vous transmettez en tant qu'appAccountToken au début de l'achat, et StoreKit l'attache à la transaction résultante, d'où il réapparaît à la fois dans les données de transaction et dans les données de consommation. Sur Google, vous appelez setObfuscatedAccountId avec une valeur hachée dérivée de ce compte. Les deux approches permettent de relier une transaction du store à votre propre fiche utilisateur sans exposer aucune donnée personnelle.
Non, ni l'un ni l'autre, du moins pas directement. Google lit l'ID de compte obfusqué pour repérer une activité irrégulière et bloquer certaines fraudes avant l'achat, et Apple accepte l'historique du compte soumis lors d'une demande de consommation (consumption request), mais aucune des deux entreprises ne vous renvoie de liste des récidivistes. C'est à vous de constituer cette liste, à partir des enregistrements que vous avez classés sous ces identifiants.
La présence de données personnelles en clair dans l'ID de compte obfusqué est généralement la cause. Y placer par exemple une adresse e-mail brute fait que Play bloque purement et simplement l'achat. Fournissez plutôt une valeur chiffrée ou un hachage à sens unique, en respectant la limite de 64 caractères.
Cela les réduit plutôt que de les stopper. CONSUMPTION_REQUEST est l'une des deux seules voies où vos preuves arrivent avant la décision, et l'historique du compte combiné aux données de livraison et de consommation aide Apple à reconnaître les abus de retour et la fraude amicale. Apple garde cependant la décision finale, et les abus qui passent par des flux que vous ne pouvez pas contester restent, eux, intacts.
