La plupart des guides sur la gestion des demandes de remboursement commencent au moment de la notification. Apple vous notifie, Google vous notifie, voici ce qu'il faut répondre. Soit, mais au moment où la notification arrive, le travail utile est déjà fait ou déjà manqué, car ce que vous pouvez dire à propos d'un achat dépend de ce que vous avez consigné au moment où il a eu lieu.
Cet article commence donc plus tôt, au moment du paiement. Quelles données d'achat comptent lorsqu'une demande de remboursement arrive, où les conserver, et comment elles se transforment en une réponse que le store prendra réellement en compte. Si vous n'avez jamais associé d'identifiant à un achat, lisez d'abord notre article sur appAccountToken et la défense contre les remboursements d'abord, car tout ce qui suit suppose que vous pouvez relier un identifiant de transaction à une personne.
Points clés
Apple et Google décident eux-mêmes des remboursements, et tous deux vous demandent désormais des données d'achat au préalable. Apple vous donne 12 heures, Google 24.
Les stores veulent des faits globaux, pas des journaux détaillés. Était-ce livré, combien a été utilisé, ont-ils reçu un échantillon, et quelle est votre préférence.
Vous devez enregistrer quatre éléments par achat : qui, quand il a été livré, quand il a été utilisé, et si ce compte a déjà été remboursé auparavant.
Apple indique que la plupart des demandes de remboursement arrivent dans les 30 jours suivant l'achat. Conservez les données au moins aussi longtemps, 90 jours en pratique.
Les applications qui commencent à répondre voient leur taux de remboursement baisser d'environ un tiers, mais seulement s'il y a quelque chose à faire valoir dans le dossier.
Ce que les stores vous demandent réellement
La demande d'Apple est simple. Lorsqu'un client demande un remboursement pour un achat intégré, vous recevez un CONSUMPTION_REQUEST, et vous répondez via le Send Consumption Information endpoint avec cinq champs. À savoir : si le client a consenti à ce que vous partagiez des données, si l'achat a été livré, quel pourcentage a été consommé (en milliunités, donc 100,000 représente la totalité), s'il a d'abord bénéficié d'un échantillon ou d'un essai gratuit, et votre préférence en matière de remboursement. Apple demandait auparavant une douzaine de champs et en a supprimé la plupart, ce que j'interprète comme le signe qu'Apple estime déjà mieux connaître l'historique du client que vous.
La version de Google concerne les rétrofacturations (chargebacks), et elle est un peu plus détaillée. Une notification de révision de remboursement en attente arrive via Real-time Developer Notifications avec un token. Vous envoyez une requête à orders.reviewrefund avec ce token, le même indicateur de contenu d'échantillon, une préférence parmi DECLINE, APPROVE ou NEUTRAL, un pourcentage de consommation facultatif, et jusqu'à 1,000 événements d'utilisation horodatés. Cela compte d'autant plus que Google facture désormais aux développeurs les rétrofacturations sur les commandes passées après le 3 août 2026.
Aucun des deux stores ne veut votre export analytique. Ils veulent la livraison, la consommation, l'échantillonnage et la préférence, et tout ce que vous stockez par ailleurs sert à renseigner ces éléments honnêtement et rapidement.
Historique des achats pour les remboursements : quoi conserver et pendant combien de temps
Le minimum :
Un identifiant au moment du paiement. appAccountToken sur Apple, obfuscatedAccountId sur Google. Sans cela, une demande de remboursement désigne une transaction sans que vous sachiez à qui elle appartient. Les ingénieurs d'Apple recommandent également de conserver au moins un originalTransactionId par utilisateur, car avec n'importe lequel d'entre eux, vous pouvez appeler Get Transaction History et récupérer l'historique d'achat complet de ce client dans votre application, qu'il l'ait encore installée ou non.
Un enregistrement de livraison. Le moment où vous avez accordé les pièces ou débloqué le niveau, avec un horodatage et un résultat. Si la livraison a échoué, dites-le. C'est le seul cas où vous devriez souhaiter que le remboursement soit accordé, et prétendre le contraire vous coûte une crédibilité dont vous aurez besoin plus tard.
Des événements de consommation. Pas chaque interaction, seulement celles qui indiquent que l'achat a été utilisé : pièces dépensées, chapitre ouvert, export lancé. Google en accepte jusqu'à mille. Apple ne veut qu'un pourcentage, mais vous ne pouvez pas en calculer un que vous n'avez jamais enregistré.
Un indicateur d'échantillon par produit. Ce client a-t-il bénéficié d'un essai, d'un aperçu, d'une offre gratuite ? Un oui ou un non sur les deux stores, et c'est un point que l'on oublie constamment.
Les remboursements antérieurs sur le compte. Apple prend de toute façon en compte l'historique des remboursements de son côté, mais vous en aurez besoin pour vos propres règles.
Concernant la conservation, Apple a indiqué que la plupart des demandes de remboursement arrivent dans les 30 jours et qu'il faut stocker les données de consommation en conséquence. Nous en conservons 90, en partie parce que les rétrofacturations Google peuvent arriver bien plus tard, et en partie parce que le stockage est bon marché, contrairement au fait d'argumenter de mémoire.
Comment l'historique des achats facilite les remboursements
Une fois cela en place, la demande cesse d'être une question de jugement et devient une simple recherche.
Livré, entièrement consommé, pas d'échantillon, pas de remboursement antérieur : c'est le cas pour DECLINE. Livré, à peine entamé, demandé dans la journée : GRANT_FULL coûte peu et l'alternative paraît mesquine. Échec de livraison de votre côté : accordez-le et corrigez le bug. Partiellement utilisé sur plusieurs semaines : Apple propose GRANT_PRORATED pour ce cas, et sur Google, le pourcentage de consommation joue le même rôle.
Les chiffres le confirment. Dipsea, une application audio par abonnement, a commencé à répondre aux demandes d'Apple fin 2024, et son taux de remboursement est passé de 3 % à 1.9 % en environ deux semaines. Concernant les rétrofacturations, Appcharge a déclaré à PocketGamer que les litiges non assistés sont gagnés 20 à 30 % du temps, contre plus de 80 % pour ceux étayés par des preuves. Sur les plus de 800 applications présentes sur Refund Sensor, 77 % des demandes éligibles ont été défendues, et celles que nous perdons n'avaient le plus souvent rien d'enregistré.
Ce que l'historique des achats ne permet pas, c'est de gagner des arguments que vous ne devriez pas gagner. Si les données du client montrent qu'il n'a ouvert l'application qu'une seule fois, la réponse honnête est le remboursement.
Comment traiter les demandes de remboursement dans les délais
Le processus de demande de remboursement sur les deux stores est chronométré, il s'agit donc davantage de plomberie technique que de jugement. La notification arrive sur un endpoint que vous avez enregistré. Vous vérifiez la signature, récupérez l'identifiant de transaction, consultez les lignes de livraison et de consommation de l'utilisateur, calculez le pourcentage, choisissez la préférence selon une règle définie à l'avance, puis envoyez. Consignez ce que vous avez envoyé et à quel moment, puis attendez le résultat, qui sur Apple est une notification REFUND ou REFUND_DECLINED. En cas de REFUND, révoquez l'accès dans l'heure, car un client remboursé qui conserve le contenu a tendance à recommencer.
Deux points posent problème. Le consentement : Apple n'accepte pas la soumission tant que customerConsented n'est pas true, donc l'autorisation de partager les données d'utilisation doit figurer dans vos conditions avant même la première demande. Et le timing : les délais ne s'arrêtent pas le week-end, et une part surprenante des demandes arrive la nuit. La gestion des demandes de remboursement consiste surtout à s'assurer que quelque chose reste éveillé. Notre guide sur la gestion des demandes de remboursement Apple approfondit l'aspect opérationnel.
Logiciel de traitement des remboursements pour développeurs, ou votre propre code
Avec une équipe backend, le pipeline décrit ci-dessus représente une semaine de travail, puis une responsabilité continue, et c'est cette responsabilité qui coûte cher.
Si vous utilisez RevenueCat ou Adapty, les deux répondent aux demandes de consommation d'Apple à partir des données d'utilisation déjà collectées par leurs SDK, et Adapty couvre également la révision Google. Un choix raisonnable par défaut si le SDK est de toute façon déjà présent dans l'application.
Refund Sensor fait la même chose sans SDK. Vous connectez une clé API App Store Connect et une URL de notifications, et il reçoit les demandes, envoie la réponse dans les délais impartis, et conserve une chronologie par dossier. La configuration prend quelques minutes et la tarification est fixe. Les détails se trouvent sur le site de Refund Sensor.
Quel que soit votre choix, y compris ne rien choisir, la couche de données vous appartient. Aucun logiciel de traitement des remboursements pour développeurs ne peut inventer un enregistrement de livraison que vous n'avez pas conservé.
Conclusion
On parle souvent de la défense contre les remboursements comme d'un problème de réponse, mais elle découle en réalité d'un problème d'enregistrement. Les stores posent quatre questions précises, et votre capacité à y répondre dépend de décisions prises au moment du paiement et de la livraison, bien avant que quiconque ne demande à être remboursé.
Associez un identifiant, enregistrez la livraison et la consommation avec des horodatages, signalez les échantillons, et conservez le tout pendant 90 jours. Une fois cela en place, le traitement des demandes de remboursement devient une simple règle et une tâche cron, et le taux de remboursement a tendance à se réguler de lui-même.
Questions fréquentes
Apple vous accorde 12 heures à partir du CONSUMPTION_REQUEST. Google vous en accorde 24 à partir de la notification de révision de remboursement en attente pour une rétrofacturation. Dans les deux cas, la décision est prise sans vous si vous dépassez le délai.
Cinq champs : le consentement du client, le statut de livraison, le pourcentage de consommation en milliunités, le fait qu'un échantillon ait été fourni ou non, et votre préférence en matière de remboursement. Les anciens champs comme l'ancienneté du compte et les dépenses cumulées ont disparu.
En grande partie, avec davantage de détails si vous en disposez. Google accepte un pourcentage de consommation et jusqu'à 1,000 événements d'utilisation horodatés, et ses options de préférence sont DECLINE, APPROVE ou NEUTRAL.
Sur Apple, oui. La soumission est rejetée tant que customerConsented n'est pas true, donc l'autorisation doit figurer dans vos conditions avant même l'arrivée de la demande.
Non. Les deux stores considèrent votre préférence comme une donnée parmi d'autres, et ont tous deux accès à l'historique complet du client. Refuser alors que vos propres données montrent un échec de livraison ou une utilisation quasi nulle vous coûte de la crédibilité sur les cas qui comptent vraiment.
