Chaque renouvellement a son propre ID de commande Google Play, et c'est ce numéro qu'il faut vérifier avant de rembourser qui que ce soit

Regardez la fin du numéro de commande avant de rembourser un client Google Play. GPA.1234-5678-9012-34567 est le premier débit d'un abonnement. GPA.1234-5678-9012-34567..2 est le troisième. Ils partagent la même base, ce sont des paiements différents, et la Play Console ne les traite pas de la même façon au moment du remboursement. L'ID de commande Google Play est le seul identifiant que votre client voit, c'est donc lui qui atterrit dans votre boîte de support. Lisez-le correctement et vous remboursez, une seule fois, le débit qui pose réellement problème.

Ce que vous apprend un ID de commande Google Play

La documentation de la Play Billing Library de Google présente le format par l'exemple. Un ID de commande commence par GPA, suivi de groupes de chiffres. Pour les abonnements, chaque renouvellement reçoit l'ID de commande de base suivi de deux points et d'un compteur qui démarre à zéro. L'achat initial n'a donc pas de suffixe, le premier renouvellement est ..0, le deuxième ..1, et ainsi de suite.

Le suffixe indique donc d'un coup d'œil depuis combien de temps quelqu'un paie. Un client qui écrit au sujet de GPA.3333-4137-0319-36762..11 a été renouvelé douze fois. Un client qui cite l'ID de base seul a soit acheté quelque chose une seule fois, soit parle de son tout premier paiement.

Où apparaît l'ID de commande, et quelle version vous obtenez

C'est là que les équipes trébuchent. Chaque surface vous donne une forme différente du même ID.

• Le reçu Google Play du client affiche l'ID de commande du débit concerné, renouvellements compris.
• Dans votre app, Purchase.getOrderId() de la Play Billing Library renvoie l'ID de la commande initiale pour les renouvellements d'abonnement. L'exemple de Google lui-même : au lieu de GPA.1234-5678-9012-34567..0, vous obtenez GPA.1234-5678-9012-34567.
• Côté serveur, purchases.subscriptionsv2 attribue à chaque ligne un latestSuccessfulOrderId, l'ID de la dernière commande réussie pour cet article. Google a ajouté ce champ le 21 mai 2025.
• Dans la Voided Purchases API, orderId identifie de manière unique un achat ponctuel, un achat d'abonnement ou un renouvellement d'abonnement. La documentation de Google recommande d'utiliser orderId, et non le jeton d'achat, pour distinguer les renouvellements.

À quoi sert le jeton d'achat, alors

Le jeton d'achat identifie l'achat dans son ensemble. Pour un abonnement, un seul jeton couvre le débit initial et tous les renouvellements qui suivent. C'est pour cela qu'il est la bonne clé pour les droits d'accès et la mauvaise pour un remboursement. Les remboursements et les rétrofacturations portent sur un seul débit, et seul l'ID de commande désigne un débit unique.

Comment retrouver une commande Google Play

Dans la Play Console

La gestion des commandes (Order management) accepte dans sa barre de recherche un ID de commande ou l'adresse e-mail complète du client. Chaque commande affiche l'un de ces statuts : Traitée, Annulée, En attente, Remboursement en attente, Remboursée, Remboursement partiel en attente ou Partiellement remboursée. Si le client vous donne un e-mail plutôt qu'un reçu, cherchez par e-mail, choisissez le débit d'après la date, puis vérifiez le suffixe avant d'agir.

Avec l'Orders API

Depuis le 21 mai 2025, la ressource Orders de la Google Play Developer API propose orders.get pour une commande et orders.batchget pour une liste. Quelques limites comptent en pratique :

• batchget accepte entre 1 et 1 000 ID de commande par requête, et ils doivent être distincts.
• Si un seul ID de commande est introuvable ou n'appartient pas au package, toute la requête batchget échoue.
• Les appels à l'Orders API sont décomptés de votre quota de la Play Developer API, fixé par défaut à 200 000 appels par jour.

L'Order renvoyé est la partie utile. Il contient l'état de la commande, son purchaseToken, createTime et lastEventTime, le total et la taxe, un salesChannel comme IN_APP ou PLAY_STORE, et un orderHistory avec les événements de traitement, d'annulation, de remboursement et de remboursement partiel. Il contient aussi developerRevenueInBuyerCurrency, que Google définit comme vos revenus dans la devise de l'acheteur, nets des remboursements partiels, des taxes et des frais. Lorsque Google est le marchand officiel, l'adresse de l'acheteur ne comporte que le pays.

Rembourser la bonne commande

Une fois que vous savez de quel débit parle le client, la Play Console vous propose un choix qui dépend de la place de cette commande dans l'abonnement.

Via l'API, orders.refund prend le nom du package et l'ID de commande. Les commandes de plus de 3 ans ne peuvent pas être remboursées. Le paramètre facultatif revoke, réglé sur true, coupe immédiatement l'accès à l'abonnement ou à l'article intégré. L'aide de Google précise aussi qu'un remboursement émis ne peut pas être annulé, donc l'ID de commande que vous transmettez est définitif.

Pourquoi une commande à 0,00 $ apparaît-elle pour un abonné ?

La documentation de Google sur le cycle de vie des abonnements l'explique. Quand un utilisateur se réabonne depuis votre app au même forfait de base avant l'expiration de son abonnement, Google Play crée une commande à 0,00 $. Il n'est pas débité, puisqu'il a déjà payé la période en cours, et la facturation normale reprend à la date de renouvellement d'origine. Ce n'est ni un essai gratuit ni une promotion. Il n'y a rien à rembourser sur cette commande. Si le client veut être remboursé, cherchez la commande payée qui la précède.

Ce que vous coûte le remboursement de la mauvaise commande

Un remboursement restitue le prix. Les remboursements partiels fonctionnent de la même façon, au prorata. L'exemple de Google : un remboursement partiel de 50 % reprend aussi 50 % de votre versement et 50 % des frais de service. Ce qui ne revient pas, c'est tout ce que vous avez dépensé pour servir ce client : le calcul, les appels aux API tierces, le stockage, toute commission d'affiliation. Remboursez la mauvaise commande et vous payez tout cela deux fois.

Voici comment ça arrive. Un client en formule mensuelle écrit au sujet du débit ..4, celui de la semaine dernière. Quelqu'un de votre équipe cherche par e-mail, voit la première commande en haut de la liste et clique sur Rembourser uniquement sur la commande de base d'il y a plusieurs mois. Le client récupère maintenant de l'argent pour une période qu'il a utilisée. Le débit dont il se plaignait n'a pas bougé, et son abonnement continue de se renouveler. Il peut toujours demander à sa banque d'annuler le débit de la semaine dernière.

Cette voie bancaire est désormais la plus coûteuse. Pour les commandes passées après le 3 août 2026, Google indique que lorsqu'une rétrofacturation aboutit, le développeur est responsable du prix d'achat, moins les frais de service de Play, plus les frais de rétrofacturation facturés par la banque. Les rétrofacturations sont définitives côté banque. Un suffixe mal lu peut se solder par l'équivalent de deux remboursements perdus, frais en plus.

Les remboursements qui n'arrivent jamais dans votre boîte

La plupart des remboursements Google Play n'ont besoin ni de vous ni de l'ID de commande. La politique de remboursement de Google indique qu'un client peut obtenir un remboursement via Google Play dans les 48 heures suivant l'achat et qu'au-delà de 48 heures, il doit contacter le développeur. Google rembourse et révoque aussi les abonnements que vous ne confirmez pas dans un délai de trois jours. Vous l'apprenez après coup via la Voided Purchases API, qui indique le voidedSource (0 pour l'utilisateur, 1 pour le développeur, 2 pour Google) et un voidedReason comme Remorse, Chargeback ou Unacknowledged_purchase.

Un seul flux de remboursement Google Play vous demande votre version. Lorsqu'une rétrofacturation nécessite l'avis du développeur, vous avez 24 heures pour répondre via orders.reviewrefund avec une préférence de remboursement APPROVE, DECLINE ou NEUTRAL et des preuves d'utilisation de l'achat. RefundHalt répond à cet examen dans le délai à votre place, avec les données d'usage dont vous disposez déjà, pour qu'une commande contestée reçoive vos preuves plutôt que du silence.

Une courte checklist pour les tickets de support avec un ID de commande

• Demandez l'ID de commande complet figurant sur le reçu Google Play, suffixe compris.
• Recherchez-le dans la Play Console ou avec orders.get, et vérifiez d'abord son état.
• Vérifiez que la date du débit correspond à ce que décrit le client.
• Utilisez Rembourser et révoquer uniquement sur la commande la plus récente, et Rembourser uniquement sur les plus anciennes.
• Notez l'ID de commande que vous avez remboursé, pour repérer facilement une rétrofacturation ultérieure sur une autre commande.