L'examen de rétrofacturation de Google Play vous laisse 24 heures pour riposter, voici quoi envoyer

Quand la banque d'un client annule un débit Google Play, Google Play ne se contente pas de rembourser l'argent et de passer à autre chose. Il envoie à votre serveur une PendingRefundReviewNotification et lance un compte à rebours de 24 heures. Répondez à cette notification via l'API ReviewRefund avec une préférence de remboursement et des preuves de ce que le client a réellement utilisé, et Google Play intègre votre contribution dans la façon dont il conteste la rétrofacturation. Restez silencieux, et le litige est réglé sans un mot de la seule partie qui sait comment le produit a été consommé.

L'examen de rétrofacturation de Google Play est le seul flux de remboursement Android qui vous demande des preuves, l'équivalent direct du CONSUMPTION_REQUEST d'Apple. Il compte plus qu'avant. À partir du 3 août 2026, Google Play transfère le coût des rétrofacturations aux développeurs, donc un litige que vous ne répondez pas sort de votre compte, pas de celui de Google. Voici exactement ce que porte la notification, ce que vous renvoyez, les champs qui composent vos preuves, et où le silence se transforme en argent.

Ce qu'est vraiment un examen de rétrofacturation Google Play

Une rétrofacturation n'est pas une demande de remboursement. Le client s'adresse à sa banque ou à son réseau de cartes et conteste le débit, et la banque récupère les fonds. Google Play traite la plupart de ces cas tout seul. Pour une partie, il ouvre un examen et vous demande d'abord, parce que vous détenez des informations que Google n'a pas : si la commande a été livrée et quelle part le client en a consommée. Cet examen est le flux derrière l'API ReviewRefund.

C'est le seul endroit du système de remboursement Android où vos preuves changent l'issue. Toutes les autres voies de remboursement de Google Play fonctionnent sans vous. Un client peut effectuer un remboursement en libre-service dans les 48 heures suivant l'achat, le support peut en accorder un, et un achat non confirmé est remboursé automatiquement, tout cela décidé par Google. L'examen de rétrofacturation est l'exception, et il mérite d'être traité comme la seule conversation de remboursement à laquelle vous pouvez réellement participer.

C'est la version Android de la fenêtre de preuves d'Apple

Deux boutiques, deux flux qui demandent des preuves au développeur, et c'est toute la liste. Apple envoie un CONSUMPTION_REQUEST et vous donne 12 heures pour répondre avec Send Consumption Information. Google Play envoie une PendingRefundReviewNotification et vous donne 24 heures pour répondre avec orders.reviewrefund. La mécanique diffère, mais la leçon est identique : quand la boutique demande ce que le client a utilisé, une réponse précise fait la différence entre garder la vente et la rendre.

Une différence compte en pratique. La charge de consommation d'Apple, ce sont cinq champs numériques et rien d'autre. Les preuves de Google Play sont plus riches. Vous pouvez envoyer un pourcentage de consommation plus une liste d'événements d'usage individuels, chacun avec un horodatage, un identifiant de compte et même une adresse IP et une localisation approximative. Google Play vous laisse plus de place pour décrire la livraison, ce qui signifie plus de place pour être convaincant.

Le compte à rebours de 24 heures et comment la notification vous parvient

L'examen arrive sous forme de Real Time Developer Notification sur votre topic Cloud Pub/Sub, le même canal qui livre vos événements d'abonnement et d'achat. Le message est une charge encodée en base64 avec un objet pendingRefundReviewNotification à l'intérieur. Le compte à rebours démarre quand cette notification est publiée, pas quand vous la lisez, donc un consommateur qui interroge une fois par jour est un consommateur qui rate des litiges.

PendingRefundReviewNotification, champ par champ

La notification est petite. Elle vous dit quelle commande est en examen, vous remet le token que vous devez citer en retour et nomme la raison. Voici chaque champ qu'elle porte.

Seule une rétrofacturation ouvre un examen en attente

Le refundReason d'un examen en attente est toujours CHARGEBACK, livré sous forme de l'entier 7. D'autres raisons de remboursement existent dans l'univers de Google Play, mais elles ne vous parviennent pas par ce flux, parce que vous n'avez pas votre mot à dire. Si vous voyez une PendingRefundReviewNotification, une banque a annulé un débit et Google Play décide s'il le conteste. C'est le seul déclencheur.

Ce que vous renvoyez via l'API ReviewRefund

Vous répondez avec un unique POST vers orders.reviewrefund. Le chemin complet est POST https://androidpublisher.googleapis.com/androidpublisher/v3/applications/{packageName}/orders/{orderId}:reviewrefund, autorisé avec le scope https://www.googleapis.com/auth/androidpublisher, le même scope OAuth que votre intégration à la Play Developer API utilise déjà. Un succès renvoie un corps vide avec HTTP 200.

Le corps est là où vit votre dossier. Vous renvoyez le pendingRefundToken de la notification, déclarez une préférence de remboursement et joignez des preuves de consommation.

Votre préférence de remboursement est une recommandation, pas un verdict

Le champ refundPreference prend l'une de trois valeurs, et c'est un conseil pour Google Play, pas une décision finale. Google reste maître de l'issue. Mais c'est un conseil appuyé par des données que Google ne peut pas voir tout seul, donc il a du poids.

Les champs de preuve qui appuient un DECLINE

Un DECLINE seul est une affirmation sans preuve. Les champs de consommation sont la preuve. consumptionPercentageMilliunits est un entier en milliunités, donc 100000 dit que le client a consommé 100 percent de ce qu'il a acheté et 50000 dit la moitié. consumptionUsageEvents est un tableau optionnel où chaque événement peut porter un obfuscatedAccountId, un obfuscatedProfileId, un consumptionTime, un ipAddress, un consumptionItemDescription et une location approximative. sampleContentProvided est un booléen pour le cas où vous avez donné au client un échantillon gratuit du contenu payant. Ensemble, ils disent, dans le schéma même de Google Play, que le produit a été livré et utilisé.

Votre premier appel est votre seul appel

Google Play enregistre le premier appel à ReviewRefund que vous faites contre une notification et ignore chaque appel après lui, tout en renvoyant un statut OK. Il n'y a ni brouillon ni révision. Si votre première réponse est un NEUTRAL précipité sans preuves parce que votre pipeline n'était pas prêt, c'est la réponse enregistrée, et l'appel ultérieur avec l'historique de consommation complet est écarté en silence. Construisez la réponse complète avant d'envoyer quoi que ce soit.

Ce que l'examen vous coûte en argent

Pendant des années, une rétrofacturation perdue sur Google Play coûtait au développeur la vente et peu de choses de plus, parce que Google Play absorbait les frais en aval. Cela se termine le 3 août 2026. Pour les commandes passées après cette date, Google Play partage le coût de la rétrofacturation avec les développeurs, et la part du développeur est le prix d'achat moins la commission de service de Play, plus les frais de rétrofacturation associés facturés par l'institution financière. Google Play continue de couvrir la part de la commission de service. Les frais de la banque sont un poids nouveau dans votre colonne du grand livre.

Le remboursement n'est jamais le vrai chiffre

Le litige rend le paiement du client, mais le paiement n'a jamais été votre seul coût. Une vidéo générée, un lot d'appels à l'API d'un modèle, un reversement à un créateur, du stockage que vous avez provisionné, tout cet argent a quitté votre compte au moment où la commande a été livrée, et rien de tout cela ne revient avec la rétrofacturation. Ajoutez maintenant les frais de rétrofacturation de la banque par-dessus. Vous payez la facture du fournisseur, vous remboursez la vente et vous couvrez les frais du litige, trois coûts pour une commande que vous aviez les preuves de défendre.

L'échelle contre laquelle Google se bat

Google Play affirme avoir bloqué US$3.4B de fraude et d'abus en 2025 et ajoute de la détection de fraude tout au long de 2026. Le changement de partage des coûts fait partie du même effort : donner aux développeurs une raison d'alimenter le système en preuves, et le système conteste davantage de litiges illégitimes. L'API ReviewRefund est la voie par laquelle vos preuves entrent. Une réponse vide est un vote pour laisser une rétrofacturation de fraude amicale tenir à vos frais.

Comment être prêt avant que la notification n'arrive

La fenêtre de 24 heures n'est pas le problème. Le problème, c'est que les preuves dont vous avez besoin doivent exister avant le litige, capturées au moment de l'achat et de la consommation, pas reconstituées après l'apparition d'un token. Une équipe qui commence à rassembler des données quand la notification arrive a déjà perdu.

Attachez l'identité au moment de l'achat

Définissez un obfuscatedAccountId avec setObfuscatedAccountId sur chaque achat, pour que l'id de compte de la notification pointe directement vers un utilisateur dans votre système. Gardez-le sous forme de hash, de 64 caractères ou moins, jamais d'e-mail en clair ni d'autres données personnelles, parce que les identifiants en clair font bloquer les achats. Sans ce lien, vous ne pouvez pas relier le pendingRefundToken à un véritable historique d'usage, et votre DECLINE n'a rien derrière lui.

Consignez la consommation au fur et à mesure

Consignez ce qu'une commande payante a livré, quand et à qui, sous une forme que vous pouvez transformer en consumptionPercentageMilliunits et consumptionUsageEvents à la demande.

• Horodatez chaque unité de consommation, pour que consumptionTime sur chaque événement soit réel, pas estimé.
• Suivez la livraison par rapport à l'achat, pour pouvoir déclarer un pourcentage de consommation avec assurance au lieu de deviner.
• Gardez les identifiants de compte et de profil à côté de l'usage, pour qu'un événement se compose en une seule requête quand le token arrive.
• Capturez l'IP de la requête et la localisation approximative si vous les avez, puisque Google Play accepte les deux comme champs d'événement.

Répondez dans la fenêtre, automatiquement

Une fenêtre de 24 heures est confortable pour une machine et brutale pour un humain qui doit être éveillé et attentif. La réponse devrait être automatique : notification entrante, compte recherché, consommation assemblée, un appel ReviewRefund sortant, le tout sans personne dans la boucle. C'est la partie que RefundHalt gère pour vous. Nous écoutons la PendingRefundReviewNotification, faisons correspondre la commande à l'usage que nous suivons déjà pour ce compte, et répondons à orders.reviewrefund dans la fenêtre avec une préférence de remboursement et de vraies preuves de consommation. Le token est le fil, et les preuves sont le dossier. Ayez les deux prêts et la seule conversation de remboursement à laquelle vous pouvez participer est une conversation que vous pouvez gagner.