Remboursements et achats annulés sur Google Play : que faire

Sur Google Play, l’argent peut revenir à un abonné de plusieurs façons : l’utilisateur obtient un remboursement, vous le remboursez depuis la Play Console ou l’API, un achat n’est jamais accusé (acknowledged), ou le paiement fait l’objet d’un chargeback. Google regroupe tout cela sous un seul terme : un voided purchase (achat annulé). Si vous accordez des accès ou des crédits depuis votre propre backend, vous devez être au courant de chacun d’eux.

Ce guide explique où apparaissent les achats annulés, ce que Google vous dit sur chacun, la nouvelle revue des remboursements pour les chargebacks, et comment réagir. Il s’en tient à la documentation de Google : la référence des notifications en temps réel pour les développeurs, les bonnes pratiques de sécurité sur les achats annulés, le traitement des achats rejetés, le cycle de vie des abonnements, et la référence de la Google Play Developer API pour les voided purchases, orders.refund et orders.reviewrefund (tous consultés en novembre 2026).

Ce qui compte comme un achat annulé

La page sécurité de Google définit les achats annulés comme « des achats qui ont été annulés, révoqués ou ont fait l’objet d’un chargeback », et en liste les principales causes :

• L’achat est annulé par l’utilisateur, le développeur ou Google, y compris les achats annulés automatiquement parce qu’ils n’ont jamais été accusés. Pour les abonnements, cela signifie annuler l’achat lui-même, pas seulement désactiver le renouvellement.
• L’achat fait l’objet d’un chargeback.
• Le développeur annule ou rembourse une commande et coche l’option « revoke ».

Une résiliation d’abonnement normale (l’utilisateur arrête le renouvellement) n’est pas un achat annulé. C’est un événement SUBSCRIPTION_CANCELED, et l’utilisateur garde l’accès jusqu’à la fin de la période.

Rembourser, révoquer, ou les deux

Vous disposez de trois actions, et elles ne font pas la même chose :

Action	API	Argent	Accès
Remboursement seul	orders.refund sans revoke	Remboursé	Conservé
Remboursement et révocation	orders.refund avec revoke=true, ou purchases.subscriptionsv2.revoke avec un remboursement total	Remboursé	Terminé immédiatement
Résiliation	purchases.subscriptionsv2.cancel	Non remboursé	Conservé jusqu’à la fin de la période

Points de la documentation de Google à connaître :

• orders.refund ne peut pas rembourser des commandes de plus de trois ans. Avec revoke à true, l’accès prend fin immédiatement et, pour un abonnement récurrent, tous les paiements futurs s’arrêtent.
• Le guide d’intégration de Google indique que les révocations par le développeur et les remboursements avec révocation déclenchent des notifications et apparaissent dans la Voided Purchases API avec voidedSource réglé sur développeur. Pour les abonnements, vous recevez à la fois SUBSCRIPTION_REVOKED et une VoidedPurchaseNotification.
• Un remboursement sans révocation « ne déclenche ni notification de révocation ni notification d’achat annulé ». Si vous l’utilisez, enregistrez-le vous-même.
• Si vous n’accusez pas un nouvel abonnement dans les trois jours, l’utilisateur est automatiquement remboursé et l’achat est révoqué. Google demande de ne pas compter là-dessus pour rejeter des achats : révoquez et remboursez explicitement à la place.

Où apparaissent les achats annulés

En temps réel : VoidedPurchaseNotification

Si les notifications en temps réel pour les développeurs sont activées pour votre appli Play, un achat annulé arrive sous la forme d’une voidedPurchaseNotification avec :

• purchaseToken : l’achat qui a été annulé.
• orderId : la commande exacte. Pour les abonnements, chaque renouvellement a son propre ID de commande : cela vous dit donc quel paiement a été annulé.
• productType : 1 abonnement, 2 produit ponctuel.
• refundType : 1 remboursement total, 2 remboursement partiel par quantité (achats en plusieurs exemplaires uniquement).

Google note que cela suffit pour « retrouver le bon achat et la bonne commande afin d’ajuster les droits d’accès ». Pour les abonnements, une révocation envoie aussi une notification d’abonnement SUBSCRIPTION_REVOKED ; le guide du cycle de vie indique de révoquer immédiatement l’accès de l’utilisateur dans ce cas.

En masse : la Voided Purchases API

purchases.voidedpurchases.list est une API à interroger (pull). D’après la référence de l’API :

• Elle couvre les 30 derniers jours : startTime ne peut pas être plus ancien.
• Par défaut, elle ne renvoie que les produits ponctuels. Passez type=1 pour inclure les abonnements.
• Chaque enregistrement a un voidedReason : 0 Other, 1 Remorse, 2 Not_received, 3 Defective, 4 Accidental_purchase, 5 Fraud, 6 Friendly_fraud, 7 Chargeback, 8 Unacknowledged_purchase.
• Et un voidedSource : 0 utilisateur, 1 développeur, 2 Google.

Les codes de raison sont la partie la plus utile, car la notification ne les contient pas. Une réserve de la page sécurité : les achats annulés « sans contenu de récupération associé ne sont pas exposés par la Voided Purchases API ».

Utilisez les deux : la notification pour agir en quelques secondes, et une interrogation quotidienne de l’API pour obtenir les raisons et rattraper ce que vous auriez manqué.

Chargebacks : la revue des remboursements

Google a ajouté un moyen pour les développeurs de donner leur avis sur certains chargebacks. Quand un utilisateur demande un chargeback qui nécessite une revue du développeur, vous recevez une pendingRefundReviewNotification. D’après la référence RTDN, vous devez évaluer la demande et envoyer « une suggestion de remboursement et des preuves d’usage de l’achat sous 24 heures » en appelant orders.reviewrefund. Les revues en attente ne prennent actuellement en charge que CHARGEBACK comme raison.

Le corps de la requête, d’après la référence de l’API :

Champ	Signification
pendingRefundToken	Issu de la notification ; obligatoire
refundPreference	APPROVE, DECLINE ou NEUTRAL ; obligatoire
sampleContentProvided	Si vous avez proposé un échantillon gratuit, un essai ou une description avant l’achat ; obligatoire
consumptionPercentageMilliunits	Facultatif, de 0 à 100 000 (45 200 signifie 45,2 %)
consumptionUsageEvents	Liste facultative d’événements d’usage (heure, description de l’élément, adresse IP, localisation, ID de compte ou de profil obfusqué) ; les listes de plus de 1 000 éléments sont rejetées

La notification contient l’obfuscatedAccountId et l’obfuscatedProfileId si vous les avez définis à l’achat. Sans eux, vous aurez du mal à retrouver l’usage de l’utilisateur en 24 heures.

Soyez honnête. Si l’utilisateur n’a pas pu utiliser ce qu’il a payé, APPROVE est la bonne réponse. S’il a utilisé l’abonnement pendant toute la période, un DECLINE accompagné d’événements d’usage concrets est précisément ce à quoi sert ce champ.

Que faire de chaque achat annulé

Le guide de sécurité de Google recommande, selon la raison et l’historique de l’utilisateur :

1. Récupérer les éléments non utilisés, comme une monnaie in-app accordée.
2. Avertissements progressifs : un avertissement dans l’appli pour un premier cas, des mesures plus fortes en cas de récidive.
3. Désactiver temporairement les achats le temps d’examiner la situation.
4. Restreindre l’accès à votre appli dans les cas extrêmes et répétés.
5. Interroger plus souvent la Voided Purchases API une fois que vous détectez des achats annulés.

Pour une appli à abonnement, une politique pratique ressemble à ceci :

Raison	Réponse suggérée
Achat accidentel, remords	Mettre fin à l’accès pour la période remboursée ; aucun avertissement. Éventuellement demander un retour
Non reçu, défectueux	Traiter comme un bug produit ; examiner le compte de l’utilisateur
Achat non accusé	Corriger votre traitement des achats ; c’est votre bug, pas celui de l’utilisateur
Fraude, fraude amicale, chargeback	Mettre fin à l’accès, signaler le compte, bloquer les nouveaux achats jusqu’à examen

Erreurs courantes

• Ne traiter que SUBSCRIPTION_CANCELED. Cela veut dire « arrêter le renouvellement », pas « remboursé ». Les révocations arrivent sous forme de SUBSCRIPTION_REVOKED et de notifications d’achats annulés.
• Rembourser sans révoquer et l’oublier. Aucune notification ne vous le rappellera.
• Interroger l’API moins d’une fois par mois. Tout ce qui a plus de 30 jours disparaît de l’API.
• Pas d’ID de compte obfusqué. Vous ne pourrez pas répondre à temps à une revue de remboursement si vous ne retrouvez pas l’utilisateur.
• Punir les remboursements pour remords comme de la fraude. Les codes de raison existent pour que vous puissiez les distinguer.

Le faire avec NoChurn

NoChurn lit vos notifications en temps réel pour les développeurs Google Play et la Voided Purchases API : remboursements, révocations et chargebacks apparaissent dans la chronologie de chaque client avec leur raison et alimentent le score de churn. Sur Google Play, les remboursements sont en lecture seule dans NoChurn : les décisions de remboursement et les revues de remboursement restent entre vos mains et celles de Google, et les paiements et les relances restent chez Google. Pour rattacher les achats aux clients, définissez un ID de compte obfusqué à l’achat. Voir NoChurn + Google Play.