L'abus répété de remboursements vous coûte deux fois, voici comment les stores vous laissent riposter

Un remboursement isolé est un coût de fonctionnement. Le même compte qui se fait rembourser une quatrième fois, après avoir utilisé ce qu'il a acheté à chaque fois, c'est de l'abus de remboursements, et c'est un schéma que vous ne pouvez voir que si chaque achat porte une identité que vous contrôlez. Apple et Google vous donnent tous deux cette identité, et tous deux vous accordent une fenêtre étroite pour la présenter au store avant qu'un remboursement ou une rétrofacturation ne soit décidé. Ratez la fenêtre, ou n'attachez jamais l'identité, et un rembourseur récidiviste ressemble exactement à un client mécontent pour la première fois. Voici comment les distinguer, et ce que cette différence vaut en argent.

Pourquoi l'abus de remboursements est un problème d'identité, pas un problème de remboursement

Le store décide du remboursement. Vous ne pouvez pas empêcher un client de demander, et sur la plupart des flux vous ne pouvez pas empêcher le store d'accorder. Ce que vous pouvez faire, c'est décider si un compte donné a déjà fait cela auparavant, et si le contenu qu'il a acheté a réellement été livré et utilisé. Ces deux points sont des questions d'identité : lequel de vos utilisateurs est derrière cette transaction, et quel est son historique. Si vos achats ne portent pas d'identifiant stable renvoyant à vos propres enregistrements d'utilisateur, vous ne pouvez répondre à aucune des deux, et chaque remboursement arrive sans contexte.

C'est là le véritable écart. La mécanique du remboursement est fixée par la politique. Les preuves que vous y apportez sont entièrement les vôtres à construire, et elles commencent au moment de l'achat, pas au moment du remboursement.

Les deux fenêtres où les preuves changent l'issue

Il existe exactement deux flux où quelque chose que vous envoyez peut faire bouger une décision. Le CONSUMPTION_REQUEST d'Apple se déclenche quand un client demande un remboursement sur un consommable ou un abonnement à renouvellement automatique, et vous avez 12 heures pour répondre. L'examen des rétrofacturations de Google Play se déclenche quand un utilisateur conteste un débit auprès de sa banque, et vous avez 24 heures pour répondre via la Review Refund API. Tout autre remboursement, le remboursement en libre-service de 48 heures de Play, un remboursement accordé par le support, un remboursement automatique pour achat non reconnu, est décidé sans vous.

Ces deux canaux de preuve sont bien plus solides lorsque la transaction porte déjà votre identifiant. Les informations de consommation d'Apple peuvent inclure l'appAccountToken aux côtés de l'historique et des dépenses du compte, et l'examen de Google peut s'appuyer sur l'ID de compte obfusqué qu'il surveille depuis l'achat. Un compte sans identifiant est un compte sans historique à soumettre.

Les deux champs d'identité, côte à côte

Apple et Google ont résolu le même problème de manière presque identique, avec des noms différents et des règles différentes. Tous deux vous permettent de marquer un achat d'une valeur qui renvoie à votre propre enregistrement d'utilisateur. Aucun n'est activé par défaut. Tous deux sont inutiles si vous ne les définissez pas au moment de l'achat.

Apple: appAccountToken

appAccountToken est un UUID que vous générez et transmettez au démarrage d'un achat. StoreKit l'associe à la transaction qui en résulte, et il apparaît dans les données de transaction que votre serveur vérifie et dans les informations de consommation que vous renvoyez lors d'un CONSUMPTION_REQUEST. Comme c'est votre valeur, il mappe une transaction du store directement sur le compte dans votre base de données, sans e-mail ni nom impliqué. Ce doit être un vrai UUID, et toute autre chose est rejetée. Apple a ensuite ajouté un endpoint Set App Account Token qui peut attacher ou mettre à jour le token sur des transactions passées, y compris des achats effectués en dehors de votre app comme les utilisations de codes promotionnels.

Google Play: l'ID de compte obfusqué

L'équivalent de Google est setObfuscatedAccountId, une chaîne facultative liée au compte acheteur. La documentation de Google elle-même est catégorique sur son objectif : Google Play l'utilise pour détecter une activité irrégulière, comme de nombreux appareils effectuant des achats sur le même compte dans un bref laps de temps, et pour bloquer certaines transactions frauduleuses avant qu'elles n'aboutissent. Elle est limitée à 64 caractères, et ne doit pas contenir de données personnelles en clair. Stockez-y un e-mail brut et Google bloque l'achat purement et simplement, car le champ attend une valeur chiffrée ou un hachage à sens unique. Un champ frère, setObfuscatedProfileId, existe pour les apps où un compte détient plusieurs profils.

Ce que coûte réellement un remboursement d'un abuseur récidiviste

Le remboursement lui-même est la plus petite partie de la facture. Quand un store accorde un remboursement, vous rendez le revenu, et c'est ce qui est visible sur le grand livre. Ce qui n'est pas sur la ligne du remboursement, c'est tout ce que vous avez dépensé pour livrer le produit qui est désormais gratuit.

Imaginez un consommable qui déclenche un travail réel : une génération d'images, un lot d'appels à l'API d'un fournisseur de modèles, un export vidéo, un paiement à un créateur. Vous avez payé ce calcul au moment où le client l'a utilisé. Le remboursement récupère le prix, mais il ne récupère pas la facture du fournisseur. Un rembourseur récidiviste est quelqu'un qui a appris que le contenu survit au remboursement, alors il relance la boucle : acheter, consommer, se faire rembourser, recommencer. À chaque cycle, vous encaissez le coût de livraison une deuxième fois.

Puis il y a le propre transfert de coûts du store. À partir du 3 août 2026, Google Play transfère le prix d'achat et les frais de rétrofacturation de la banque au développeur pour les commandes passées après cette date. Une rétrofacturation qui était autrefois surtout le problème de Google devient votre revenu plus des frais, et un contestataire récidiviste augmente ce chiffre à chaque fois. Les champs d'identité sont ce qui vous permet d'alimenter la Review Refund API avec les preuves pour contester un litige illégitime dans la fenêtre de 24 heures.

Google présente l'échelle sans détour : il affirme avoir bloqué plus de 2 milliards de dollars de transactions frauduleuses et abusives en 2022. Ce nombre existe parce que les signaux, l'ID de compte obfusqué parmi eux, étaient renseignés. Une app qui expédie des achats avec des champs d'identité vides renonce à cette protection.

Comment repérer les rembourseurs récidivistes avant que le store ne décide

Marquez chaque achat d'une identité qui vous appartient

Définissez appAccountToken sur chaque achat StoreKit et setObfuscatedAccountId sur chaque achat Play Billing, tous deux générés à partir de votre propre enregistrement d'utilisateur. Sur Apple, utilisez un vrai UUID mappé au compte. Sur Google, hachez la clé du compte pour qu'aucune donnée personnelle ne circule en clair. Faites-le au moment de l'achat, car sur Google c'est la seule étape que vous ne pouvez pas récupérer plus tard.

Tenez un grand livre indexé sur cette identité

Enregistrez chaque achat, livraison, événement de consommation et remboursement en regard de l'identifiant. Quand un CONSUMPTION_REQUEST ou un examen de rétrofacturation arrive, l'historique complet du compte, remboursements précédents compris, est à une seule requête de distance. Les informations de consommation d'Apple ont des champs explicites précisément pour cela : consumptionStatus, deliveryStatus, playTime, accountTenure, lifetimeDollarsPurchased, et votre refundPreference.

Lisez voidedReason et orientez les abuseurs différemment

Quand un achat Google est annulé, le champ voidedReason vous dit pourquoi, et friendly_fraud et fraud sont des valeurs distinctes d'un remboursement ordinaire de type remorse. Orientez celles-là vers une file d'examen et une politique plus stricte, pas le même parcours automatique qu'un remboursement pour la première fois. La propre recommandation de Google est un modèle à plusieurs avertissements : avertissez un premier contrevenant, prenez des mesures plus fermes contre les récidivistes, et désactivez les achats pour un compte qui persiste.

Répondez à la fenêtre à chaque fois

Les preuves ne comptent qu'à l'intérieur des deux fenêtres. Automatisez la réponse au CONSUMPTION_REQUEST pour qu'elle se déclenche bien avant les 12 heures, et l'examen de rétrofacturation pour qu'il se déclenche avant les 24. Un historique parfait que vous soumettez en retard est un historique que le store ne lit jamais.

Ce que les stores feront et ne feront pas pour vous

Il vaut la peine d'être précis sur la répartition du travail, car il est facile de supposer que les stores gèrent l'abus, et la plupart du temps ils ne vous préviennent pas quand ils ne le font pas. Google utilise activement l'ID de compte obfusqué pour bloquer une partie de la fraude avant qu'un achat n'aboutisse, et ses systèmes en attrapent une grande part au niveau de la plateforme. Apple décide de chaque remboursement elle-même et traite vos informations de consommation comme une entrée, jamais un vote. Aucun store ne tient votre liste d'abuseurs à votre place, ne déduit un consommable remboursé de votre solde, ni ne dit non à un rembourseur récidiviste en votre nom. L'identité appartient au store pour agir à la marge et à vous pour agir partout ailleurs.

C'est la même raison pour laquelle RefundHalt indexe tout sur l'identité de l'achat : un remboursement, un examen de rétrofacturation et une demande de consommation pour le même compte se résolvent en un seul historique, de sorte qu'un rembourseur récidiviste apparaît comme un schéma dès la première fois qu'il récidive, pas après la quatrième facture que vous avez déjà payée.