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 permet de répondre à chaque demande dans les délais, à chaque fois.
La version courte
Apple contrôle les rails de paiement. Lorsqu'un client 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.
Cela 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 la décision de remboursement. Vous ne pouvez pas approuver ou refuser vous-même le remboursement ; Apple garde toujours la décision finale. Mais le silence ne donne rien à Apple pour travailler, tandis qu'une réponse bien construite lui apporte du contexte.
Le hic, c'est le timing et la régularité. La fenêtre de remboursement est courte, le délai de réponse remboursement Apple est limité, elle s'ouvre à des heures imprévisibles, et faire cela manuellement à un volume réel est impossible. C'est le problème que résout l'automatisation.
Comment fonctionne réellement le processus de remboursement Apple
Voici la séquence, de bout en bout :
Le client demande un remboursement. Il se rend sur reportaproblem.apple.com, sélectionne l'achat, choisit un motif et soumet sa demande.
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.
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.
Apple décide. Son système de décision de remboursement évalue vos données avec 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 un CONSUMPTION_REQUEST, et ce que vous renvoyez
La notification elle-même transporte des informations de transaction signées et le motif indiqué par le client (consumptionRequestReason). C'est dans votre réponse que se joue le travail réel. Apple définit un ConsumptionRequest structuré avec des champs incluant :
Voici le tableau reconstitué à partir de votre image :
Champ | Ce que cela indique à Apple |
customerConsented | Indique si le client a accepté de partager ces données. Doit être défini sur 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 | Combien de temps le client a passé dans l'application. |
lifetimeDollarsPurchased | Montant total dépensé par le client dans l'ensemble de vos applications. |
lifetimeDollarsRefunded | Montant total déjà remboursé au client. |
sampleContentProvided | Indique si le client a pu essayer le contenu avant de l'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'octroi, ou préférence pour le refus. |
Votre recommandation à Apple : non déclarée, préférence pour l'octroi, ou préférence pour le refus.
Chaque champ est un signal. Laissé vide, c'est un 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 ? Décryptage champ par champ.
La fenêtre de 12 heures
Vous disposez d'environ 12 heures pour répondre à un CONSUMPTION_REQUEST en production. Ce délai consumption_request est crucial, car le manquer signifie renoncer à la possibilité de donner votre avis ; Apple décide alors sur la seule base de ce qu'il a déjà.
Le problème n'est pas la durée de la fenêtre de réponse remboursement Apple, c'est le moment où elle s'ouvre. Les demandes de remboursement n'attendent pas les heures d'ouverture. La fenêtre de remboursement peut s'ouvrir en pleine nuit, un week-end ou pendant un jour férié, et une file d'attente de révision manuelle ne peut pas couvrir cela sans quelqu'un disponible en permanence. C'est la raison la plus courante pour laquelle les développeurs perdent des remboursements qu'ils auraient pu contester : non pas une mauvaise réponse, mais une absence de réponse. Nous approfondissons ce sujet dans La fenêtre de 12 heures : pourquoi la plupart des développeurs perdent leurs remboursements par défaut.
L'exigence de consentement, ne la négligez pas
C'est la partie qui piège presque tout le monde, et c'est un enjeu juridique, pas seulement technique.
Le CONSUMPTION_REQUEST d'Apple ne vous indique pas si le client a consenti à partager ses données. C'est volontaire : Apple attend que votre application, et non votre serveur, 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, car c'est vous qui partagez des données collectées auprès de l'utilisateur.
Si vous vous trompez, vous ne risquez pas seulement un rejet de la soumission, vous risquez 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 expliquons exactement où et comment dans Consentement du client & API Consumption : ce qu'Apple exige réellement.
Ce qu'implique réellement l'automatisation de cette réponse
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 vraiment fait la différence entre « on va le construire » et « on va laisser tomber ».
Un système de réponse interne fiable doit recevoir et vérifier les notifications signées d'Apple, extraire des données d'utilisation et de facturation précises et à jour pour chaque client dès l'arrivée d'une demande, convertir ces données dans les valeurs exactes du ConsumptionRequest d'Apple, et les soumettre dans la fenêtre de réponse remboursement Apple d'environ 12 heures, à toute heure, sans personne pour surveiller. En plus de cela, il lui faut des tentatives de reprise compatibles avec le délai, une gestion des échecs, des journaux que vous pouvez auditer, une surveillance pour savoir si quelque chose casse, et une maintenance continue chaque fois qu'Apple révise ses charges utiles ou ses champs. Rien de tout cela ne fait partie de votre produit. Tout cela est une infrastructure que vous devriez maintenir indéfiniment pour un flux de travail qui n'a rien à voir avec ce que fait votre application. (Nous approfondissons la couche de notification dans Configurer App Store Server Notifications V2.)
C'est le calcul auquel la plupart des équipes finissent par arriver : la mécanique est maîtrisable, mais construire et surveiller en permanence un système de réponse conforme et respectant les 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 tâche indifférenciée pour laquelle un service managé existe.
C'est ce que fait RefundSensor. Il se connecte à votre configuration App Store Connect avec une seule URL de webhook, sans SDK, sans modification de code, sans nouvelle soumission d'application, puis répond automatiquement à chaque CONSUMPTION_REQUEST dans la fenêtre de remboursement d'Apple, mappe les champs à partir de vos données, gère les tentatives de reprise et la surveillance, reste à jour avec les évolutions d'Apple, et enregistre chaque résultat dans un dashboard unique. Pour les équipes à la recherche d'un logiciel d'automatisation des remboursements Apple, cela élimine le besoin de construire et de maintenir vous-même toute l'infrastructure de réponse aux remboursements.
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 davantage de contexte au système d'Apple, et les développeurs qui répondent de manière constante 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.
Répondre dans le délai de réponse remboursement Apple peut donc contribuer à ce qu'Apple reçoive vos informations avant l'échéance du consumption_request. Cela ne garantit pas un résultat, mais cela évite qu'une réponse manquée ne devienne la raison pour laquelle vos informations n'ont pas été prises en compte.
Ce que l'automatisation peut et ne peut pas faire
Soyez honnête avec vous-même sur ses limites :
Elle ne peut pas garantir qu'un remboursement spécifique sera refusé. Apple prend toujours la décision finale, à chaque fois.
Elle ne peut pas contester les remboursements qui ne génèrent jamais de CONSUMPTION_REQUEST, car ce n'est pas le cas de tous les remboursements.
Elle peut garantir que chaque demande éligible reçoit une réponse dans la fenêtre de réponse remboursement Apple, 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.
Elle peut automatiser la façon de répondre aux demandes de remboursement Apple dans les 12 heures, réduisant le risque de manquer l'échéance du consumption_request.
C'est ce dernier point qui compte vraiment. Vous ne contournez pas Apple, vous vous assurez simplement d'avoir toujours votre mot à dire.
Pourquoi un traitement manuel ne peut pas combler l'écart
Les équipes qui essaient de gérer cela manuellement se retrouvent généralement dans l'une de ces trois situations :
L'approche « on vérifiera demain matin » — qui manque toutes les demandes nocturnes et du week-end, c'est-à-dire une grande partie d'entre elles.
La rotation d'astreinte — quelqu'un techniquement responsable d'une tâche à fenêtre de 12 heures en permanence, ce qui est un travail pénible et reste sujet à l'erreur humaine.
L'approche « on a abandonné » — la majorité silencieuse, qui a arrêté de répondre parce que suivre le rythme était impossible.
Le point commun : l'échéance avance à la vitesse d'une machine, la réponse à la vitesse d'un humain. Vous ne pouvez pas discipliner une horloge qui tourne pendant que vous dormez. Toute approche manuelle revient en réalité à choisir quelles demandes manquer.
C'est un problème de timing, pas un problème de produit
Le vrai cadre à retenir : perdre ces remboursements ne dit rien de votre application.
Vous pouvez avoir un excellent produit, des utilisateurs satisfaits et un taux de remboursement réel faible, et perdre quand même du chiffre d'affaires par cette fenêtre, car les pertes ne dépendent pas de la légitimité du remboursement. Elles dépendent de la présence ou non de quelqu'un pour répondre. C'est étonnamment une bonne nouvelle. Un problème de produit est difficile à résoudre. Un problème de timing a une solution simple : s'assurer que quelque chose est toujours là pour répondre, instantanément, quelle que soit l'heure.
Ce qui règle réellement le problème
La seule chose capable de combler une fenêtre à vitesse machine, c'est une réponse à vitesse machine. L'automatisation répond à chaque CONSUMPTION_REQUEST dès son arrivée — avec des données de consommation précises et votre préférence de remboursement — dans la fenêtre d'Apple, à 3h du matin un dimanche aussi fiablement qu'à 15h un mardi.
C'est ce que fait RefundSensor. Il surveille chaque demande de remboursement, répond automatiquement dans la fenêtre, et suit le résultat, afin que vous ne perdiez plus jamais un remboursement simplement parce que personne n'a vu la notification. La configuration prend environ 30 minutes, sans modification de code, et couvre aussi la fenêtre de révision des rétrofacturations de Google Play, qui souffre du même problème « s'ouvre n'importe quand, se ferme vite ». (Pour une vue d'ensemble, voir Comment automatiser les demandes de remboursement Apple et Remboursements et rétrofacturations Google Play.)
[EMPLACEMENT RÉSERVÉ POUR DONNÉE PRODUIT : insérez ici une véritable statistique RefundSensor une fois le Refund Index disponible, par exemple la part des demandes arrivant hors des heures d'ouverture, ou le montant défendu. N'inventez PAS de chiffre.]
Vous ne trichez pas avec Apple. Vous vous assurez simplement d'avoir toujours votre mot à dire — celui que la plupart des développeurs abandonnent sans même s'en rendre compte.
Sources officielles {#official-sources}
Les délais et procédures d'Apple peuvent évoluer, considérez donc sa documentation comme la référence ultime :
La fenêtre s'ouvre quand vos clients le décident. Soyez là quand même. RefundSensor répond automatiquement à chaque demande de remboursement Apple, dans la fenêtre de 12 heures — 3h du matin, week-ends et jours fériés inclus — et suit chaque résultat. Environ 30 minutes de configuration, sans modification de code. Démarrer gratuitement →
Liens internes à ajouter après publication : pilier automatisation des remboursements Apple · CONSUMPTION_REQUEST champ par champ · pilier remboursements Google Play.
Questions fréquentes
Environ 12 heures en production, à partir du moment où le client soumet la demande. Si vous la manquez, Apple décide sans votre contribution.
Apple se base sur les informations dont il dispose, à savoir la demande du client et rien de votre part. Les demandes sans réponse, y compris les injustifiées, sont souvent accordées par défaut.
Non. La fenêtre est fixée par Apple. La seule façon fiable de la respecter systématiquement est de répondre automatiquement, dès que la demande arrive.
Généralement, ce n'est pas une question de fond, mais de timing. Les demandes arrivent en dehors des heures d'ouverture, et un processus manuel ne peut pas toutes y répondre à temps, si bien que des remboursements contestables sont perdus par défaut.
Non. Apple prend toujours la décision finale. L'automatisation garantit que vous répondez à chaque fois ; elle ne remplace pas la décision d'Apple.
