La première rétrofacturation que j'ai manquée est arrivée à 11h40, un samedi soir. Je ne le sais que parce que je suis allé fouiller dans les logs Pub/Sub le lundi suivant, et que je l'ai trouvée en train d'attendre dans un topic que personne ne consommait.
C'était avant le 3 août 2026. À cette époque, en perdre une ne vous coûtait que la vente, rien de plus.
Google Play répercute désormais le coût des rétrofacturations sur les développeurs, pour les commandes passées après cette date. Vous assumez le montant de la commande moins leurs frais de service, plus des frais de réseau de carte de $15 à $25 par dossier. En contrepartie, ils ont aussi donné quelque chose : l'API Review Refund, et environ 24 heures pour déposer des preuves.
La question n'est donc pas de savoir si vous gérez les rétrofacturations. C'est de savoir ce qui les gère à minuit. La configuration se trouve sur la défense contre les rétrofacturations Google Play. Voici la version longue : quatre options, dont deux que je déconseillerais à la plupart des équipes.
Points clés
La gestion des rétrofacturations Google Play repose sur un seul point d'entrée : l'API ReviewRefund, dans les 24 heures suivant une Pending Refund Review Notification.
Google enregistre votre premier appel et ignore les suivants, tout en continuant à renvoyer OK. Un seul essai, aucune correction possible.
Seules les rétrofacturations sont contestables. Les remboursements via le support, les remboursements Play sous 48 heures et les essais non confirmés sont décidés sans vous.
Quatre véritables alternatives : le développer vous-même, utiliser votre plateforme d'abonnement, acheter un logiciel, ou absorber la perte.
Le calcul a changé le 3 août 2026. Manquez un seul délai sur un plan annuel à $99, et cela vous coûte le montant de la commande plus des frais de réseau.
À quoi ressemble vraiment la gestion manuelle
Pour être honnête, « manuel » couvre un large éventail de situations. À une extrémité, c'est une boîte mail partagée et quelqu'un qui vérifie Play Console quand il y pense. À l'autre, c'est un planning de garde, un canal Slack, une feuille de calcul des commandes contestées.
Cette seconde version est meilleure. Elle échoue quand même, pour des raisons qui n'ont rien à voir avec l'effort fourni.
D'abord, vous ne voyez pas l'horloge. Les 24 heures démarrent dès qu'une PendingRefundReviewNotification atteint votre topic Pub/Sub. Vous n'avez jamais activé les notifications développeur en temps réel ? Rien ne vous indique qu'un examen est en cours, et Play Console n'affichera aucun badge.
Ensuite, et cela surprend toujours : Google enregistre votre premier appel ReviewRefund et ignore tous ceux qui suivent, tout en continuant à renvoyer OK. On a l'impression que ça a fonctionné. Quelqu'un qui saisit une réponse dans un script à 9h, à partir de données extraites à la main, c'est exactement comme ça qu'un champ erroné se glisse sans possibilité de retour en arrière.
Y mettre plus d'efforts ne résout aucun des deux problèmes.
Le processus de rétrofacturation Google Play
Cela vaut la peine d'être détaillé, car le délai est plus court que ce que l'on imagine.
Le client conteste le paiement auprès de sa banque. Pas auprès de vous, pas auprès de Google.
Google signale la commande pour examen et envoie une PendingRefundReviewNotification via RTDN, contenant un pendingRefundToken, l'orderId, un refundReason égal à 7 (c'est-à-dire CHARGEBACK) et votre obfuscatedAccountId si vous en avez défini un lors de l'achat.
Vous disposez d'environ 24 heures pour appeler ReviewRefund avec une préférence et toutes les preuves que vous pouvez réunir.
Google s'en sert pour argumenter le dossier auprès de la banque.
En cas de défaite, et pour les commandes passées après le 3 août 2026, le coût est à votre charge.
Une asymétrie qui mérite qu'on s'y arrête. Apple interroge sur les remboursements ordinaires via CONSUMPTION_REQUEST. Google Play, lui, n'ouvre d'examen que pour les rétrofacturations. Tout le reste se règle sans vous, et vous l'apprenez via un achat annulé. Le mécanisme complet : les rétrofacturations Google Play expliquées.
Option 1 : développer le gestionnaire vous-même
Un topic Pub/Sub. Les RTDN activées sous Monetize, puis Monetization setup. Un endpoint push qui vérifie le message avant de lui faire confiance. Ensuite, décoder le champ data en base64, orienter le traitement selon lequel des cinq objets de notification est arrivé, faire correspondre la commande à un utilisateur, réunir les preuves, et appeler ReviewRefund avec un jeton OAuth à portée limitée.
Le construire n'est pas la partie coûteuse. Deux semaines, si vous avez déjà bricolé des webhooks.
La deuxième année, c'est là que ça coûte cher. Google modifie un champ. Un refresh token OAuth expire discrètement un dimanche. Votre gestionnaire tombe en panne la nuit même où arrive un litige de $200, et c'est toujours comme ça que ça se passe. Vous aurez besoin d'observabilité, d'une gestion des rejeux, et de tests pour des formats de notification que vous n'avez pas encore rencontrés.
Si vous gérez un backend et que les remboursements représentent une vraie ligne de revenu, construisez-le. Je préférerais que vous le fassiez. Si vous êtes une seule personne à faire sortir le produit, c'est un mauvais usage de votre mois.
Option 2 : utiliser la plateforme d'abonnement que vous payez déjà
Vérifiez cela avant d'écrire la moindre ligne de code. RevenueCat a ajouté l'API Review Refund de Google sous Refund Control, et Adapty propose Refund Saver côté Apple.
L'avantage : vos reçus, vos entitlements et votre mapping client y vivent déjà, donc les preuves sont plus accessibles et la correspondance des comptes est déjà résolue.
La limite : pour eux, la réponse aux remboursements est une fonctionnalité, pas le produit. Attendez-vous à une préférence et quelques indicateurs, pas à 1 000 événements d'utilisation avec adresses IP. Pour beaucoup d'applications, c'est suffisant. Pour les litiges fortement liés à la fraude, non.
Option 3 : un logiciel dédié de gestion des rétrofacturations Google Play
Cette catégorie existait à peine avant le 3 août, ce qui montre à quel point l'incitation est récente.
Le principe est toujours le même. Le service s'abonne à vos RTDN, dépose une recommandation de refus accompagnée de preuves de livraison et d'engagement dans le délai imparti, et suit le résultat de chaque dossier.
Refund Sensor fait cela pour Google Play et l'App Store depuis un seul compte. Connectez-vous avec Google, accordez deux permissions Play Console (consulter les données financières, gérer les commandes et abonnements), et il provisionne lui-même le topic Pub/Sub. Pas de SDK, aucune modification de code, rien à soumettre à nouveau.
Le compromis : un fournisseur de plus, une ligne mensuelle de plus. Ce que vous y gagnez, c'est de ne plus être la personne qui doit rester réveillée.
Option 4 : absorber la perte
C'est une option légitime pour certaines applications, et je ne prétendrai pas le contraire. Vendez un produit consommable à $1.99, subissez quatre rétrofacturations par an, et deux semaines de développement ne seront jamais rentabilisées.
Faites d'abord le calcul, cependant. Une rétrofacturation perdue sur un plan annuel à $99 coûte le montant de la commande moins les frais de service de Google, plus des frais de réseau de $15 à $25. Deux cas comme celui-ci en un trimestre changent la réponse.
Comment automatiser la gestion des rétrofacturations Google Play
Si vous optez pour la première option, voici l'ordre de construction. La séquence compte plus qu'on ne le pense.
Activez les RTDN dans Play Console, créez le topic Pub/Sub. Cliquez sur Send Test Message avant de faire confiance au canal.
Décodez le champ data et orientez le traitement selon l'objet de notification reçu. Un seul arrive par message. Sur pendingRefundReviewNotification, stockez le pendingRefundToken et démarrez un minuteur. Pas un e-mail. Un minuteur.
Faites correspondre l'orderId à un utilisateur. obfuscatedAccountId est le chemin le plus rapide, ce qui est une raison suffisante pour commencer à le définir dès l'achat.
Réunissez les preuves : sampleContentProvided, consumptionPercentageMilliunits (45200 signifie 45,2 %), et jusqu'à 1 000 consumptionUsageEvents avec horodatages et adresses IP.
Appelez orders.reviewrefund une seule fois, avec un refundPreference de APPROVE, DECLINE ou NEUTRAL. Journalisez l'appel, le payload et la réponse.
Séparément, gérez voidedPurchaseNotification pour la révocation d'accès, et exécutez l'API Voided Purchases chaque nuit pour réconcilier les données. Elle est plafonnée à 6 000 appels par jour.
Cette dernière étape, c'est celle que tout le monde ignore. Je l'ai moi-même ignorée pendant des mois. Les notifications sont manquées pendant les pannes, et l'API de type pull est ce qui vous permet de retrouver ce qui est arrivé pendant votre indisponibilité. L'API Voided Purchases face aux notifications développeur en temps réel détaille le rôle de chaque flux.
Prévention des rétrofacturations Google Play
Moins coûteux que tout ce qui précède, et cela fonctionne sur des litiges que vous ne voyez jamais venir.
Un client qui parvient à joindre votre support n'ira pas voir sa banque. Un moyen de contact visible dans l'application, associé à une réponse en moins d'une journée, élimine une part surprenante des litiges avant même qu'ils ne démarrent.
Ensuite, rendez le renouvellement évident : prix, période et date de renouvellement sur le même écran que le bouton d'achat. La surprise provoque plus de litiges que tout ce que j'ai pu observer.
Deux autres points qui ne reçoivent pas assez d'attention. Surveillez les achats non confirmés, car les essais qui se convertissent sans être remarqués se transforment en rétrofacturations un mois plus tard. Et utilisez voidedReason comme signal de fraude. Il comporte neuf valeurs, dont fraud, friendly_fraud et chargeback, et ces comptes récidivent. Signalez-les avant de leur accorder un nouvel essai.
Maintenez votre taux sous le seuil fixé par Google. Les problèmes persistants affectent la réputation du compte, ce qui est pire que n'importe quel remboursement isolé.
Sources
Questions fréquentes
Un remboursement passe par Google : la décision revient à Google ou à vous, dans Play Console. Une rétrofacturation, c'est le client qui s'adresse à sa banque, ce qui place le dossier sous les règles des réseaux de cartes bancaires. Seule la rétrofacturation ouvre un examen auquel vous pouvez répondre, et seul son coût vous est répercuté.
Environ 24 heures à partir de la PendingRefundReviewNotification. Le compte à rebours démarre à la livraison de la notification, pas au moment où vous la remarquez.
Google argumente la rétrofacturation sans vos preuves, ce qui est la position la plus faible possible. Pour les commandes passées après le 3 août 2026, une défaite vous coûte le montant de la commande moins les frais de service, plus des frais de réseau.
Non. Google enregistre votre premier appel ReviewRefund et ignore tous les suivants, tout en continuant à renvoyer OK. Testez-le sur un achat de test avant de l'approcher de la production.
Celui qui envoie la réponse sans que vous ayez besoin d'être réveillé. Si vous disposez déjà d'un backend, le développer vous-même est un projet raisonnable. Si ce n'est pas le cas, un logiciel de gestion des remboursements Google Play qui se connecte via les permissions de Play Console vaut mieux qu'écrire un consommateur Pub/Sub pour un cas limite.
Non. Vous formulez une recommandation via l'API Play Developer de Google elle-même, appuyée par des preuves de livraison et de consommation. C'est le canal que Google a conçu pour cela.
