Étiquetez chaque achat Google Play avec un id de compte obfusqué, sinon une rétrofacturation arrive sans moyen de la tracer

Un examen de rétrofacturation Google Play apparaît en nommant une commande et un jeton d'achat. Il ne vous dit pas qui est le client. Si vous n'avez jamais apposé votre propre identifiant sur cet achat, vous rapprochez désormais un simple id de commande de votre table d'utilisateurs sous un compte à rebours de 24 heures, et vous devez répondre avec des preuves d'usage que vous ne pourrez peut-être pas trouver. L'id de compte obfusqué est la solution. C'est une courte chaîne que vous attachez au paiement, que Google Play stocke avec l'achat et vous renvoie plus tard, de sorte que chaque commande peut être retracée jusqu'à l'utilisateur exact qui l'a effectuée. Voici ce qu'est ce champ, pourquoi il détermine si vous pouvez répondre à un litige, et ce que coûte le fait de l'ignorer maintenant qu'une rétrofacturation perdue est une facture.

Ce qu'est réellement l'id de compte obfusqué

L'id de compte obfusqué est une chaîne facultative que vous transmettez au flux de facturation de Google Play lorsqu'un client achète quelque chose. Vous le configurez avec setObfuscatedAccountId sur le constructeur BillingFlowParams, et Google le stocke à côté de l'achat. Ce n'est pas le nom du client, ni son e-mail, ni son compte Google. C'est votre propre identifiant pour votre propre utilisateur, écrit sous une forme que Google peut conserver sans savoir qui est la personne.

C'est une chaîne que vous configurez au paiement, pas un nom

Selon les mots de Google, setObfuscatedAccountId spécifie une chaîne obfusquée facultative qui est associée de manière unique au compte utilisateur de l'acheteur dans votre application. Le mot obfusqué joue un rôle réel. Google ne veut pas votre id utilisateur brut ni quoi que ce soit qui identifie la personne. Il veut un jeton stable qui correspond un à un à un utilisateur de votre côté, et rien de plus. Le champ est limité à 64 caractères, ce qui accueille un hachage confortablement et pas grand-chose d'autre.

Google le lit d'abord pour son propre filtrage antifraude

Avant même de vous être utile, le champ remplit une tâche pour Google. La documentation de facturation indique que Google Play peut utiliser cette valeur pour détecter une activité irrégulière, comme de nombreux appareils effectuant des achats sur le même compte dans un court laps de temps, et que Google utilise ces données pour détecter un comportement suspect et bloquer certains types de transactions frauduleuses avant qu'elles ne soient finalisées. Ainsi, le premier bénéfice de le configurer est en amont, dans des achats plus propres et moins de ceux, frauduleux, qui se transforment plus tard en annulations et litiges. Google liste l'id de compte obfusqué et la Voided Purchases API ensemble comme ses deux outils centraux contre l'abus pour une raison.

Pourquoi cela compte quand un examen de rétrofacturation survient

Un remboursement que vous voyez venir est facile. Le cas difficile est la rétrofacturation bancaire, car elle ne commence pas par votre client qui vous parle. Elle commence par la banque, et Google Play vous la transmet sous forme d'examen avec un compte à rebours attaché.

Le litige nomme une commande, pas une personne

Lorsqu'un client conteste un débit auprès de sa banque et que Google a besoin de votre contribution, Google Play envoie une PendingRefundReviewNotification. Ce message identifie la commande. Il ne porte pas votre id utilisateur, car Google n'a jamais eu votre id utilisateur. Il n'avait que ce que vous avez apposé sur l'achat. Si c'était rien, vous recherchez désormais à l'envers un simple id de commande et jeton d'achat dans vos propres enregistrements, en espérant avoir journalisé le jeton au moment de l'achat et en espérant que la correspondance soit sans ambiguïté. Si vous avez configuré un id de compte obfusqué, l'achat porte votre propre hachage, vous recherchez l'utilisateur en une seule requête, et vous passez à la construction de preuves au lieu de chasser une identité.

Ce que orders.reviewrefund vous demande réellement

Répondre au litige signifie appeler la méthode orders.reviewrefund dans les 24 heures. Google enregistre votre premier appel et ignore le reste, donc la première réponse est la seule réponse. Voici les champs qu'il demande, et chacun des champs de preuve suppose que vous savez déjà à quel utilisateur appartient la commande.

Ce que coûte réellement le fait de l'ignorer

Pendant la majeure partie de l'histoire de Google Play, une rétrofacturation que vous ne pouviez pas défendre était une vente perdue et un haussement d'épaules. Cela a changé. Pour les commandes passées à partir du 3 août 2026, une rétrofacturation perdue facture au développeur le prix d'achat moins les frais de service de Google, plus les frais de rétrofacturation de la banque. Le litige auquel vous ne pouvez pas répondre est désormais une ligne de dépense.

Suivons une commande. Un client conteste un achat de $9.99 auprès de sa banque. Google Play envoie l'examen, et vous avez 24 heures. Si vous avez étiqueté l'achat, vous trouvez l'utilisateur, voyez qu'il a consommé la majeure partie de ce qu'il a acheté, et répondez à reviewrefund avec une préférence DECLINE et les preuves de consommation, donnant à Google un vrai dossier pour contester un litige illégitime. Si vous ne l'avez pas étiqueté, soit vous ne pouvez pas identifier la commande à temps, soit vous répondez sans rien, le litige est tranché sans votre version, et sur une commande postérieure au 3 août vous remboursez les $9.99 moins les frais de Google, plus des frais fixes de rétrofacturation bancaire qui avoisinent souvent $20. Sur une petite vente, ces frais fixes à eux seuls peuvent être supérieurs à ce que vous avez gagné net.

• Les recettes perdues : votre part nette de la vente, annulée.
• Les frais de rétrofacturation de la banque : un coût fixe que fixe le réseau de cartes, facturé en plus sur les commandes passées après le 3 août 2026, qu'un simple remboursement ne comporte jamais.
• La dépense gaspillée : le calcul, les appels d'API tierces et le stockage que le compte a déjà utilisés, perdus que vous ayez pu répondre ou non.
• Le schéma que vous ne pouvez pas voir : sans id de compte stable, vous ne pouvez pas non plus savoir que le même utilisateur conteste encore et encore, de sorte que l'abus en série se lit comme des pertes isolées sans lien.

Comment le configurer sans faire bloquer les achats

Deux règles couvrent presque toutes les erreurs que les équipes commettent avec ce champ. Hachez l'id, et configurez-le partout.

Hachez votre id utilisateur, n'envoyez jamais de PII

Ne mettez pas d'e-mail, de numéro de téléphone ni aucun détail personnel brut dans ce champ. Google est explicite : stocker des PII comme des e-mails en clair entraîne le blocage des achats, et il recommande un hachage à sens unique ou un chiffrement pour générer la valeur. Le schéma propre est un hachage à sens unique de votre id utilisateur interne, calculé de la même manière à chaque fois pour que le même utilisateur produise toujours la même chaîne de 64 caractères. N'utilisez pas non plus l'id de compte Google de la personne ni votre id de développeur. La valeur ne doit avoir de sens que pour votre système.

Configurez-le sur chaque achat, et relisez-le sur votre serveur

Attachez l'id à chaque flux de facturation, produits ponctuels comme abonnements, pour qu'aucun achat ne soit jamais sans étiquette. Après l'achat, relisez-le à deux endroits. Sur le client, Purchase.getAccountIdentifiers renvoie un objet dont getObfuscatedAccountId vous donne la chaîne que vous avez configurée. Sur votre backend, l'enregistrement d'achat côté serveur le porte sous le champ obfuscatedExternalAccountId, et la copie du serveur est celle à laquelle se fier, car un litige arrive sur votre serveur, pas sur l'appareil.

Utilisez setObfuscatedProfileId quand un compte a plusieurs profils

Si votre application permet à un compte de contenir plusieurs profils, un foyer de streaming ou un jeu avec plusieurs personnages, configurez également setObfuscatedProfileId. C'est le même type de chaîne hachée, de 64 caractères et sans PII, limitée au profil qui a effectué l'achat. Google note que configurer un id de profil requiert aussi de transmettre l'id de compte, alors envoyez les deux. Le résultat est qu'un litige correspond non seulement au compte mais au profil exact qui a dépensé l'argent.

Le parallèle iOS, en une ligne

L'App Store a la même idée sous un nom différent. Sur iOS, vous attachez un appAccountToken, un UUID, à un achat, et il revient sur la transaction et sur la CONSUMPTION_REQUEST qu'Apple envoie lorsqu'un client demande un remboursement. La forme du problème est identique sur les deux boutiques. Le flux de litige ou de remboursement fait référence à une transaction, et votre propre identifiant est ce qui la relie à un utilisateur dont vous pouvez déclarer l'usage.

Rien de tout cela n'est difficile à construire. C'est facile à ignorer, car le jour où vous écrivez le code de paiement n'est pas le jour où une rétrofacturation arrive, et le coût de l'ignorer est invisible jusque-là. RefundHalt configure et suit l'identifiant de compte sur les deux boutiques, maintient le lien achat-utilisateur pour qu'un litige se résolve toujours vers un vrai client, et répond à orders.reviewrefund de Google Play et à la CONSUMPTION_REQUEST d'Apple dans leurs fenêtres avec les preuves de consommation enregistrées au moment de la vente. Le compte à rebours de 24 heures n'est pas le moment de découvrir que vous ne pouvez pas dire qui a acheté la chose.