Quelqu'un ouvre Signaler un problème, sélectionne votre app et demande à Apple de lui rembourser son achat. Apple ne tranche pas tout de suite. Elle interroge d'abord votre serveur pour savoir ce que vous savez de cet achat, et attend une réponse pendant environ 12 heures.
Cette interrogation, c'est l'Apple CONSUMPTION_REQUEST. Beaucoup d'équipes qui génèrent de vrais revenus IAP n'en ont jamais entendu parler. Beaucoup d'autres l'ont vue passer une fois dans leurs logs et l'ont laissée là. Si c'est votre cas, notre
guide sur l'Apple CONSUMPTION_REQUEST explique le quoi et le pourquoi. Cet article traite de la réponse. Quoi envoyer, quoi éviter, et ce qui est arrivé à ceux qui ont essayé.
Points clés
Apple envoie une CONSUMPTION_REQUEST quand un client demande un remboursement. Vous avez environ 12 heures. Passé ce délai, Apple décide sans vous.
La réponse tient en cinq champs. Pas cinquante. Cinq.
Votre préférence de remboursement n'est que cela, une préférence. Apple l'a déjà ignorée et le refera.
Pas de consentement du client, pas de réponse. Ce sont les mots d'Apple, pas les nôtres.
Une app est passée d'un taux de remboursement de 3% à 1.9% en deux semaines environ, simplement en commençant à répondre. Elle n'a jamais demandé à Apple de refuser quoi que ce soit.
Personne ne fait ça à la main bien longtemps. Le délai est trop court et les demandes arrivent à des heures impossibles.
Alors, qu'est-ce qu'une Apple CONSUMPTION_REQUEST, exactement ?
C'est une notification serveur, l'une des nombreuses qu'Apple envoie via les App Store Server Notifications V2. Celle-ci se déclenche quand quelqu'un demande le remboursement d'un achat intégré. Elle ne concernait autrefois que les consommables. Depuis la WWDC24, elle couvre aussi les abonnements à renouvellement automatique, là où se trouve l'essentiel de l'argent.
Dans le payload : la transaction signée, l'ID du produit et le motif choisi par le client. La doc
consumption Request Reason d'Apple en liste cinq : UNINTENDED_PURCHASE, FULFILLMENT_ISSUE, UNSATISFIED_WITH_PURCHASE, LEGAL, OTHER.
Ce que vous n'y trouverez pas : un nom ou un identifiant Apple. Juste un identifiant de transaction. Le transformer en « c'est l'utilisatrice 48213 et elle a ouvert l'app 40 fois depuis l'achat », c'est votre travail, et ça ne fonctionne que si vous avez attaché un App AccountToken au moment du paiement. Nous avons écrit un
article complet sur appAccountToken parce que trop de monde s'en passe.
Apple demande, vous répondez, Apple décide. Voilà à quoi ressemblent les demandes de remboursement Apple côté développeur.
Comment répondre à une Apple CONSUMPTION_REQUEST
Vous envoyez un PUT avec un petit corps JSON vers l'endpoint Send Consumption Information d'Apple, avec l'ID de transaction dans le chemin. Ce corps constitue les informations de consommation Apple que le système de remboursement lit.
Customer Consented vient en premier. True ou false. Si c'est false, arrêtez-vous. N'envoyez rien. La doc d'Apple indique que sans consentement, vous ne devez pas répondre du tout. Curieux, mais c'est la règle.
Ensuite, le statut de livraison. DELIVERED si tout s'est bien passé. Sinon, il existe des variantes UNDELIVERED pour problème de qualité, mauvais article, panne serveur et autre.
Sample Content Provided est un oui ou non : le client a-t-il pu essayer avant d'acheter ? Essai gratuit, oui. Aperçu du contenu, oui. Un paywall avec trois puces, probablement non.
Consumption Percentage piège beaucoup de monde. Il s'exprime en milliunités : 100000 signifie entièrement consommé et 50000 la moitié. Omettez-le pour les abonnements à renouvellement automatique. Apple le calcule à partir de la période de facturation.
Et enfin, refund Preference. DECLINE, GRANT_FULL ou GRANT_PRORATED. Facultatif. C'est aussi le seul endroit où vous pouvez dire ce que vous voulez.
Une réponse pour un pack de pièces déjà dépensé :
Apple répond par un 202 et rien d'autre. Aucun verdict. Un ingénieur Apple l'a dit sur les forums développeurs dès 2021 : un 202 signifie que vos données « seront prises en compte ». C'est toute la promesse.
N'envoyez pas DECLINE sur tout
Je sais, c'est tentant. Résistez.
Lisez d'abord le motif. FULFILLMENT_ISSUE signifie : vérifiez vos logs de livraison. Si l'achat n'est vraiment pas arrivé, envoyez le statut UNDELIVERED correspondant avec GRANT_FULL et passez à autre chose. Vous ne gagnerez pas celui-là, et essayer affaiblit vos DECLINE ultérieurs.
UNINTENDED_PURCHASE est une question d'usage. Acheté à 9h02, remboursement demandé à 9h05, zéro session entre les deux ? Sans doute une erreur de manipulation. Laissez passer. Utilisé tous les jours pendant une semaine ? DECLINE, avec votre vrai chiffre de consommation.
UNSATISFIED_WITH_PURCHASE est le cas où Sample Content Provided prend toute sa valeur. Essai gratuit et 80% utilisés ? Refusez. À peine ouvert ? GRANT_PRORATED est un juste milieu.
Pour LEGAL et OTHER, envoyez des données exactes et omettez la préférence, sauf si vos données rendent la décision évidente.
Un DECLINE appuyé sur 95% de consommation et un essai gratuit est une réponse solide. Un DECLINE sur un produit utilisé quatre-vingt-dix secondes a l'air d'un réflexe.
Ce qui est vraiment arrivé à ceux qui l'ont fait
Dipsea est une app audio que RevenueCat a rachetée en septembre 2024 pour tester son propre gestionnaire de remboursements. Le 23 octobre, ils ont commencé à répondre aux consumption requests avec la préférence réglée sur « laisser Apple décider ». Pas de DECLINE. Juste des données. En 15 jours environ, le taux de remboursement est passé d'un 3% stable à 1.9%.
Ils ont publié le graphique.Pour moi, c'est la donnée la plus utile sur le sujet. Les données seules ont fait bouger le chiffre.
Puis l'envers du décor. En mars 2024, un studio de jeux a écrit sur les Apple Developer Forums qu'il envoyait des informations de consommation et qu'Apple approuvait toujours « presque tous » les remboursements sur des pièces que les joueurs avaient déjà dépensées. Les consommables sont le cas difficile. Une fois les pièces parties, Apple ne peut pas les récupérer. Si vous ne révoquez pas vous-même le solde après la notification REFUND, vous perdez l'argent et les pièces.
Et en mai 2025, un fil sur r/iOSProgramming s'est rempli d'utilisateurs RevenueCat qui avaient choisi « toujours préférer refuser » et ont soudain vu tous leurs remboursements approuvés. RevenueCat a parlé d'un changement de politique côté Apple. Quelle qu'en soit la cause, cela a clos un vieux débat. Refund Preference n'est pas un interrupteur. Le DECLINE systématique est un pattern, et Apple peut l'ignorer.
Les façons de récolter un 400
Apple est stricte sur le corps de la requête. Voici les erreurs que nous voyons sans arrêt.
L'histoire des milliunités. Quelqu'un lit « pourcentage », envoie 100, et vient de dire à Apple que le client a utilisé un dixième de pour cent. La plage va de 0 à 100000.
Un pourcentage non nul sur un article non livré. Si delivery Status n'est pas DELIVERED, Consumption Percentage doit être à 0, sinon la requête est rejetée.
N'importe quel pourcentage sur un abonnement à renouvellement automatique. Apple a une erreur dédiée pour ça. Omettez-le.
La mauvaise clé. Cet appel exige une clé In-App Purchase, générée dans App Store Connect sous Users and Access, puis Integrations. Pas la clé App Store Connect API, même si elles se ressemblent trait pour trait. La mauvaise vous vaut un 401 et une heure à douter de votre JWT.
Oublier le consentement. Pas une erreur HTTP, une erreur de conformité. Intégrez la clause dans vos conditions avant la mise en production.
Testez d'abord en sandbox. Un piège : la doc de test d'Apple vous y donne cinq minutes, pas douze heures. Si votre serveur en prend six, le test ignore vos données. Pour forcer un refus, choisissez Other dans la fiche de remboursement et tapez DECLINE.
Comment les développeurs gèrent les demandes de remboursement App Store quand elles sont nombreuses
Le plus souvent en ne les gérant pas, pour être franc. La demande arrive à 3 h du matin. Ou le samedi. Ou un jour férié, quand la seule personne qui comprend le pipeline est hors ligne. Douze heures passent. Apple tranche sur la parole du client.
Gérer les demandes de remboursement Apple en tant que développeur se résume à une décision. Construire la chaîne vous-même (vérifier le JWS, retrouver l'utilisateur, extraire l'usage, calculer le pourcentage, générer un JWT, appeler l'endpoint, journaliser, réessayer) et la maintenir en fonctionnement pour toujours. Ou brancher un logiciel de gestion des remboursements Apple qui fait déjà tout ça.
Refund Sensor est une option de cette seconde catégorie. Vous collez notre URL de notification dans App Store Connect, connectez la clé, et les réponses partent en quelques secondes. Sur l'ensemble des apps actuellement connectées, 77% des demandes éligibles ont été défendues, pour environ $33 protégés par cas. Rien de sorcier. Une réponse avec de vraies données part à chaque fois, avant l'échéance. Si vous préférez comparer, notre guide des outils de gestion des remboursements Apple
indique les questions à poser.
C'est pourquoi l'automatisation des remboursements Apple pour les développeurs revient sans cesse. Douze heures, chaque demande, chaque semaine, ce n'est pas une tâche humaine. Quoi que vous choisissiez, choisissez quelque chose. Le silence signifie qu'Apple n'entend qu'une seule version.
Questions fréquentes
Douze heures en production, cinq minutes en sandbox. Les deux figurent dans la doc d'Apple.
Non. Apple qualifie vos informations de consommation d'« un facteur parmi d'autres ». Cela améliore vos chances. Cela ne décide de rien.
À toutes celles où le client a donné son consentement, oui. Même celles où vous envoyez GRANT_FULL parce que votre serveur était en panne. Des réponses honnêtes sur les cas faciles, c'est ce qui fait qu'Apple fait confiance à vos DECLINE par la suite.
deliveryStatus et sampleContentProvided, avec exactitude. Omettez le pourcentage. Puis allez corriger votre tracking.
Oui. DECLINE et GRANTFULL fonctionnent pour tous les types de produits. GRANTPRORATED aussi, Apple fait simplement le calcul du prorata elle-même pour les abonnements à renouvellement automatique.
