Réponse rapide : Lorsqu'un client demande à Apple un remboursement pour un achat intégré ou un abonnement, l'App Store envoie à votre serveur une notification CONSUMPTION_REQUEST et vous donne environ 12 heures pour répondre avec des données de consommation via l'endpoint Send Consumption Information. Apple prend ces données en compte dans sa décision. Si vous ne répondez pas à temps, Apple décide sans votre contribution et les remboursements injustifiés sont souvent accordés par défaut. Automatiser cette réponse signifie que chaque demande obtient une réponse dans les délais, à chaque fois.
En bref
Apple contrôle les rails de paiement. Lorsqu'un utilisateur achète un abonnement ou un achat intégré dans votre application, Apple collecte l'argent, prélève sa commission et gère les remboursements. Pendant des années, les développeurs n'ont eu absolument aucun mot à dire dans les décisions de remboursement.
Cette situation a changé. Apple vous permet désormais d'envoyer des informations de consommation — des preuves structurées sur la façon dont le client a utilisé ce qu'il a acheté — et les prend en compte dans sa décision de remboursement. Vous ne pouvez pas approuver ou refuser le remboursement vous-même ; c'est toujours Apple qui prend la décision finale. Mais le silence ne donne rien à Apple pour se baser, alors qu'une réponse bien construite lui apporte du contexte.
Le hic, c'est le timing et la régularité. La fenêtre est courte, elle s'ouvre à des heures imprévisibles, et le faire manuellement à un volume réel est impossible. C'est le problème que résout l'automatisation des remboursements Apple.
Comment fonctionne réellement le processus de remboursement Apple
Voici la séquence complète, de bout en bout :
Le client demande un remboursement. Il se rend sur reportaproblem.apple.com, sélectionne l'achat, choisit une raison, puis valide.
Apple notifie votre serveur. Pour les achats éligibles, l'App Store envoie une notification CONSUMPTION_REQUEST via App Store Server Notifications V2. La charge utile contient des données de transaction signées identifiant l'achat. Ce sont ces app store server notifications qui déclenchent le workflow automatisé.
Vous répondez avec des données de consommation. Vous appelez Send Consumption Information avec l'ID de transaction d'origine et un corps ConsumptionRequest structuré décrivant la livraison, l'utilisation, le consentement et votre préférence de remboursement. L'endpoint send consumption information est l'étape API clé de ce processus.
Apple décide. Son système de décision de remboursement évalue vos données ainsi que l'historique du client et d'autres facteurs, puis rend une décision.
Vous êtes informé du résultat. Une notification REFUND signifie que le remboursement a été accordé ; une notification REFUND_DECLINED (pour les demandes initiées via l'API StoreKit) signifie qu'il ne l'a pas été.
Ce que contient une CONSUMPTION_REQUEST et ce que vous renvoyez
La notification elle-même contient des informations de transaction signées et le motif indiqué par le client (consumptionRequestReason). C'est dans votre réponse que se joue l'essentiel. Apple définit un ConsumptionRequest structuré avec, entre autres, les champs suivants :
Champ | Ce que cela indique à Apple |
customerConsented | Indique si le client a accepté de partager ces données. Doit être true, sinon Apple rejette la soumission. |
consumptionStatus | Indique si le contenu acheté n'a pas été consommé, a été partiellement consommé, ou entièrement consommé. |
deliveryStatus | Indique si la valeur ou le service intégré a réellement été livré. |
accountTenure | Depuis combien de temps le client possède un compte chez vous. |
playTime | Le temps que le client a passé dans l'application. |
lifetimeDollarsPurchased | Le total dépensé par le client sur l'ensemble de vos applications. |
lifetimeDollarsRefunded | Le total déjà remboursé au client. |
sampleContentProvided | Indique si le client a pu essayer le contenu avant d'acheter. |
userStatus | Le statut actuel du compte du client (actif, suspendu, etc.). |
refundPreference | Votre recommandation à Apple : non déclarée, préférence pour l'acceptation, ou préférence pour le refus. |
Chaque champ est un signal. Laissé vide, c'est du contexte qu'Apple n'obtient jamais. Nous détaillons chaque champ et ses valeurs acceptées dans Qu'est-ce qu'une notification CONSUMPTION_REQUEST ? Analyse champ par champ. Les développeurs qui évaluent une api de remboursement apple doivent également comprendre comment ces champs s'intègrent dans l'ensemble du processus de remboursement.
La fenêtre de 12 heures
Vous disposez d'environ 12 heures pour répondre à une CONSUMPTION_REQUEST en production. Si vous la manquez, vous perdez la possibilité de donner votre avis ; Apple décide alors avec les éléments dont il dispose déjà.
Le problème n'est pas la durée de la fenêtre, mais le moment où elle s'ouvre. Les demandes de remboursement n'attendent pas les heures de bureau. La fenêtre peut s'ouvrir en pleine nuit, un week-end ou pendant un jour férié, et une file de traitement manuelle ne peut pas couvrir cela sans quelqu'un en astreinte permanente. C'est la raison la plus fréquente pour laquelle les développeurs perdent des remboursements qu'ils auraient pu contester : non pas une mauvaise réponse, mais aucune réponse. Nous approfondissons ce sujet dans La fenêtre de 12 heures : pourquoi la plupart des développeurs perdent des remboursements par défaut.
L'exigence de consentement : ne la négligez pas
C'est le point qui fait trébucher presque tout le monde, et c'est une question juridique, pas seulement technique.
La CONSUMPTION_REQUEST d'Apple ne vous indique pas si le client a consenti à partager ses données. C'est voulu : Apple attend de votre application, et non de votre serveur, qu'elle collecte et confirme le consentement avant l'envoi de toute donnée de consommation. Vous devez définir customerConsented sur true dans votre appel API, et vous, le développeur, êtes seul responsable d'avoir obtenu un consentement valide, puisque c'est vous qui partagez des données collectées auprès de l'utilisateur.
Si vous vous trompez ici, vous ne risquez pas seulement un rejet de votre soumission, mais aussi un problème de conformité RGPD ou DPDP. Gérez correctement le consentement dans les conditions d'utilisation et le parcours d'achat de votre application avant d'automatiser quoi que ce soit. Nous détaillons précisément où et comment dans Consentement du client et Consumption API : ce qu'Apple exige réellement.
Ce qu'implique réellement l'automatisation de ce processus
Sur le papier, automatiser la réponse ressemble à un projet de week-end : capter la notification, remplir les champs, appeler l'endpoint. En production, c'est une infrastructure permanente, et comprendre ce que cela implique réellement fait toute la différence entre « on va le construire » et « on va laisser tomber ».
Un système de réponse fiable développé en interne doit recevoir et vérifier les notifications signées d'Apple, récupérer des données d'utilisation et de facturation précises et à jour pour chaque client dès qu'une demande arrive, faire correspondre ces données aux valeurs exactes de ConsumptionRequest d'Apple, et les soumettre dans la fenêtre d'environ 12 heures, à toute heure, sans supervision humaine. En plus de cela, il lui faut des tentatives de réessai fiables face aux délais, une gestion des échecs, des journaux que vous pouvez auditer, une surveillance pour savoir en cas de panne, et une maintenance continue à chaque fois qu'Apple révise ses charges utiles ou ses champs. Rien de tout cela n'est votre produit. Tout cela est une infrastructure que vous devrez posséder indéfiniment pour un workflow qui n'a rien à voir avec ce que fait votre application. (Nous approfondissons la couche de notifications dans Configurer App Store Server Notifications V2.)
C'est le calcul auquel finissent par arriver la plupart des équipes : les mécanismes sont maîtrisables, mais construire et surveiller un système de réponse conforme et fiable face aux délais représente un coût permanent sans aucun bénéfice pour l'application elle-même. C'est exactement le genre de plomberie indifférenciée pour laquelle un service géré existe.
C'est exactement ce que fait RefundSensor. Il se connecte à votre configuration App Store Connect avec une seule URL de webhook — pas de SDK, pas de modification de code, pas de nouvelle soumission d'application — puis répond automatiquement à chaque CONSUMPTION_REQUEST dans la fenêtre imposée par Apple, associe les champs à vos données, gère les réessais et la surveillance, reste à jour avec les évolutions d'Apple, et enregistre chaque résultat dans un dashboard unique. Vous obtenez le résultat d'un système bien conçu sans avoir à le construire ni à le maintenir. Pour les équipes à la recherche d'un logiciel d'automatisation des remboursements Apple, cela offre une alternative gérée au maintien du workflow en interne.
Répondre réduit-il réellement les remboursements ?
Oui, même si les résultats varient et qu'Apple garde toujours la décision finale. Soumettre des données de consommation précises donne plus de contexte au système d'Apple, et les développeurs qui répondent systématiquement constatent généralement moins de remboursements accordés que ceux qui laissent les demandes sans réponse. Choisir une recommandation « préférence pour le refus », lorsque vos preuves le justifient réellement, est un élément supplémentaire qu'Apple prend en compte. Cela peut s'avérer particulièrement pertinent lors de la gestion d'un workflow de remboursement d'abonnement à grande échelle.
Ce que l'automatisation peut et ne peut pas faire
Soyez honnête avec vous-même quant aux limites :
Elle ne peut pas garantir le refus d'un remboursement spécifique. C'est Apple qui prend la décision finale, à chaque fois.
Elle ne peut pas contester les remboursements qui ne génèrent jamais de CONSUMPTION_REQUEST — ce n'est pas le cas de tous les remboursements.
Elle peut garantir que chaque demande éligible obtient une réponse dans les délais, avec des données cohérentes et précises, afin que vous ne perdiez jamais un remboursement simplement parce que personne n'a vu la notification.
C'est ce dernier point qui fait toute la différence. Vous ne contournez pas Apple, vous vous assurez simplement d'avoir toujours l'occasion de vous exprimer.
Pour les détails précis, référez-vous aux ressources officielles d'Apple, qui font autorité en la matière :
Le secteur a mis 15 ans à obtenir aux développeurs une voix dans les remboursements. Utilisez-la à chaque fois. RefundSensor répond automatiquement aux notifications CONSUMPTION_REQUEST d'Apple dans les délais et suit chaque résultat, pour Apple comme pour Google Play.Essai gratuit
Questions fréquentes
Il s'agit d'une App Store Server Notification qu'Apple envoie à votre serveur lorsqu'un client demande un remboursement pour un achat intégré ou un abonnement éligible. C'est le signal pour répondre avec des données de consommation qu'Apple prendra en compte dans sa décision de remboursement.
Environ 12 heures en production. Si vous ne répondez pas à temps, Apple prend sa décision sans votre contribution, et les demandes sans réponse sont souvent accordées par défaut.
Non. Vous pouvez envoyer un refundPreference recommandant un refus, mais Apple prend toujours la décision finale. L'automatisation améliore vos chances en garantissant que des données précises sont soumises à chaque fois, mais elle ne vous donne pas de droit de veto.
Oui. Vous devez obtenir un consentement valide dans votre application et définir customerConsented sur true. Apple ne le fait pas pour vous, et l'envoi de données sans consentement crée un risque de non-conformité en matière de confidentialité dont vous êtes responsable.
Non. La réponse aux CONSUMPTION_REQUEST se fait côté serveur, via App Store Server Notifications et la Consumption API. Avec RefundSensor, vous collez simplement une URL de webhook dans App Store Connect : pas de SDK, pas de modification de code, pas de nouvelle soumission.
Apple procède sans vos données. Vous perdez votre unique chance de fournir du contexte, et les remboursements, y compris ceux injustifiés, ont plus de chances d'être accordés.
