Lisez le code de motif de remboursement que votre serveur reçoit déjà, et il vous dit s'il faut corriger votre application ou affronter le client

Quand Apple ou Google rembourse l'un de vos clients, l'argent est généralement parti avant que vous ayez voix au chapitre. Ce qui atterrit sur votre serveur ensuite ressemble à un reçu, et la plupart des équipes le traitent comme tel. C'est plus que ça. Chaque remboursement porte un code de motif de remboursement, et c'est la seule partie d'un remboursement que vous pouvez encore lire une fois la décision prise. Google Play vous dit que le remboursement était une rétrofacturation, ou une demande de remords, ou un achat que votre propre application n'a jamais confirmé. Apple vous dit si le remboursement met en cause quelque chose dans votre application. Lisez ce code et un remboursement cesse d'être une ligne dans un rapport pour devenir une instruction : corrigez ceci, contestez ceci, ou laissez passer celui-ci. Voici ce que signifie chaque code, comment les trier, et ce que chacun coûte.

Ce qu'est réellement un code de motif de remboursement

Un code de motif de remboursement est l'étiquette de la boutique elle-même expliquant pourquoi un achat a été annulé. Vous ne le définissez pas et vous ne pouvez pas le contester. Il arrive attaché au remboursement après coup, et les deux boutiques l'exposent sous des formes différentes et avec une résolution très différente.

Google Play appose un motif et une source sur chaque annulation

La Voided Purchases API de Google Play renvoie un enregistrement par achat annulé, et chaque enregistrement porte deux entiers qui comptent. Le voidedReason dit pourquoi l'achat a été annulé. Le voidedSource dit qui l'a déclenché. Ensemble, ils transforment un simple remboursement en une phrase : cette commande a été annulée à cause d'une rétrofacturation, initiée par Google, ou annulée par remords, initiée par l'utilisateur. Vous lisez cela en interrogeant l'API ou en vous abonnant à la notification en temps réel pour développeurs qui se déclenche quand une annulation arrive. Dans les deux cas, les deux nombres sont la charge utile qui vaut la peine d'être conservée.

Apple vous donne un signal plus étroit, mais net

Apple ne vous remet pas un motif à neuf valeurs. Sur une transaction remboursée, Apple définit le revocationReason à l'une de deux valeurs. Un 1 signifie que l'App Store a remboursé la transaction à cause d'un problème réel ou perçu dans votre application. Un 0 signifie qu'il a remboursé pour une autre raison, par exemple un achat accidentel. Le champ n'apparaît que sur les transactions qui ont été remboursées ou révoquées, aux côtés d'une revocationDate, à l'intérieur des informations de transaction signées de l'App Store Server Notification REFUND. Deux valeurs, ce n'est pas beaucoup, mais celle qui compte, un 1, c'est Apple qui vous dit que le remboursement concernait votre produit, pas les regrets du client.

Les neuf motifs que Google Play vous donne

Le voidedReason de Google est le plus riche des deux, et chaque valeur vaut la peine d'être connue au premier coup d'œil car chacune pointe vers un endroit différent. Voici l'ensemble complet, directement issu de la ressource VoidedPurchase, avec ce que chaque code vous dit réellement de faire.

Le voidedSource vous dit qui a appuyé sur la détente

À côté du motif se trouve le voidedSource, et il répond à une question différente : qui a annulé ceci. Un 0 signifie que l'utilisateur l'a fait, par libre-service ou par sa banque. Un 1 signifie que le développeur l'a fait, c'est-à-dire vous ou vos propres outils émettant un remboursement. Un 2 signifie que Google l'a fait, de son propre jugement, y compris le remboursement automatique d'un achat non confirmé. Quand vous voyez un pic d'annulations, la source est la première coupe. Un mur de source 2, c'est Google agissant sur votre compte, et c'est généralement un signal qui renvoie à votre intégration plutôt qu'à vos clients.

Triez chaque remboursement en corriger, contester ou accepter

La raison pour laquelle un code est utile, c'est qu'il vous dit laquelle de trois réponses un remboursement mérite. La plupart des équipes traitent tous les remboursements de la même façon et gaspillent des efforts sur ceux qu'elles ne pourront jamais gagner. Les codes se divisent nettement.

Corriger : les remboursements que votre produit a causés

Certains codes sont des rapports de bogue déguisés en remboursement. Défectueux (3) et non reçu (2) sur Google, et un revocationReason de 1 sur Apple, disent tous la même chose : le client a payé et votre application n'a pas livré. Achat non confirmé (8) est le plus net d'entre eux car la faute est entièrement dans votre code de facturation. Ce sont les remboursements les moins chers à éliminer, car vous les éliminez en corrigeant quelque chose qui vous appartient, pas en persuadant qui que ce soit. Un décompte en hausse dans ce tas est un défaut de produit avec un montant en argent attaché.

Contester : les remboursements que quelqu'un manœuvre

Fraude (5), fraude amicale (6) et rétrofacturation (7) sont les litiges. La fraude pure (5) n'est pas votre client et n'est pas un revenu que vous alliez garder. La fraude amicale (6), où l'acheteur a obtenu exactement ce qu'il a payé puis l'a contesté, est le seul litige que vos preuves peuvent encore faire bouger, et la rétrofacturation (7) est là où ces preuves sont soumises. Quand l'un d'eux arrive, vous révoquez l'accès si ce n'est pas déjà fait, et là où une fenêtre d'examen est ouverte, vous y répondez avec ce que vous savez du compte.

Accepter : les remboursements qu'il ne vous appartenait jamais d'empêcher

Remords (1) et achat accidentel (4) sont le propre changement d'avis du client. Le revocationReason de 0 d'Apple se trouve ici aussi. Aucune fonctionnalité n'a échoué et aucune fraude n'a eu lieu. Vous pouvez adoucir le lot des achats accidentels avec une confirmation d'achat plus claire, mais vous ne pouvez pas argumenter contre un remboursement pour remords, et le temps passé à essayer est du temps pris sur le tas des corrections, là où l'argent se trouve réellement.

Le piège des 30 jours qui rend les codes de motif faciles à perdre

Il y a une limite stricte du côté de Google qui transforme ceci d'une fonctionnalité de rapport en une échéance. Si vous ne capturez pas les codes en continu, vous les perdez.

La Voided Purchases API ne remonte que de 30 jours

Google est explicite : l'API ne peut montrer que les achats annulés des 30 derniers jours. Les annulations plus anciennes ne sont pas renvoyées, quel que soit le startTime que vous passez, et la valeur de startTime elle-même ne peut pas être fixée à plus de 30 jours en arrière. Pire pour une intégration naïve, la fenêtre de 30 jours est mesurée selon le moment où les systèmes de Google voient un achat comme annulé, pas selon le moment où l'achat a été fait ni même selon le voidedTimeMillis dans l'enregistrement. Ainsi, un code de motif de remboursement que vous ne récupérez pas dans cette fenêtre est perdu, et une tâche d'export mensuelle avec la moindre lacune abandonnera silencieusement les annulations qu'elle a été trop lente à capturer.

Ce que valent les codes de motif en argent

Deux codes portent un prix précis, et les lire, c'est la façon de mettre un nombre sur des problèmes qui autrement se cachent dans un taux de remboursement agrégé.

Un code est une facture que vous vous êtes écrite vous-même

Le voidedReason 8, achat non confirmé, est l'exemple le plus net d'un remboursement que vous avez causé. Google Play exige que votre application confirme un achat dans les trois jours suivant l'octroi du droit, et si vous ne le faites pas, Google rembourse automatiquement la commande et révoque l'article. Chaque annulation estampillée 8 est une vraie vente, d'un client qui voulait le produit, rendue parce qu'un appel pour confirmer l'achat ne s'est jamais déclenché. Le montant perdu est le prix de vente complet plus le calcul, les appels d'API et le stockage que vous avez déjà dépensés pour la livrer. Ce n'est pas un remboursement que vous négociez. C'est un bogue que vous fermez, et le code est la façon dont vous le trouvez.

Le code de rétrofacturation porte désormais des frais

Le voidedReason 7, rétrofacturation, a changé de coût le 3 août 2026. Pour les commandes Google Play passées à cette date ou après, une rétrofacturation perdue coûte au développeur le prix d'achat moins les frais de service de Play, plus les frais de rétrofacturation de la banque, tandis que Google ne couvre que ses propres frais de service. Comme les frais de rétrofacturation sont forfaitaires et que les prix des produits ne le sont pas, sur un achat intégré bon marché les frais à eux seuls peuvent dépasser ce que le client a payé. Compter vos annulations de code 7, c'est désormais compter un poste de dépense, pas seulement une vente perdue, ce qui est exactement pourquoi la catégorie rétrofacturation mérite sa propre ligne dans tout rapport de remboursements que vous construisez.

Comment Apple et Google s'alignent

Les deux boutiques répondent à la même question à des résolutions différentes, donc un rapport de remboursements inter-boutiques doit les normaliser plutôt que de s'attendre à ce qu'elles correspondent.

Les boutiques ne vous donneront jamais le même code pour le même remboursement, et c'est très bien. Ce qui compte, c'est que les deux vous remettent un motif lisible par machine, et que les deux récompensent une équipe qui le lit. Le bit unique d'Apple vous dit quand un remboursement est la faute de votre produit. Les neuf motifs de Google et son indicateur de source vous disent quel bogue de produit, quel litige et quelle lacune de facturation auto-infligée vous regardez. Aucun code n'arrête un remboursement. Les deux vous disent quoi faire pour que le suivant n'arrive pas.

RefundHalt capture le code de motif sur chaque remboursement dès l'instant où il arrive, sur les deux boutiques, et le conserve bien à l'intérieur de la fenêtre de 30 jours de Google pour que rien ne s'échappe. Il trie chaque annulation en corriger, contester ou accepter, de sorte qu'un pic de code 3 défectueux vous parvient comme une alerte produit et un pic de code 8 non confirmé vous parvient comme un bogue d'intégration, pas comme une vague baisse de revenu. Il répond au CONSUMPTION_REQUEST d'Apple sous 12 heures et à l'examen de rétrofacturation de Google Play sous 24, et il révoque l'accès dès l'instant où un remboursement ou une rétrofacturation arrive. Vous ne pouvez pas changer le code qu'une boutique appose sur un remboursement. Vous pouvez vous assurer de lire chacun d'eux, et d'agir sur ceux qu'il vous appartient réellement de corriger.