Un client demande un remboursement à Apple. Douze heures plus tard, une fenêtre se referme sur votre serveur, et la plupart des équipes n'ont jamais su qu'elle s'était ouverte.
Cette fenêtre, c'est Apple CONSUMPTION_REQUEST — une notification que l'App Store envoie lorsqu'il souhaite obtenir des informations de votre part pendant l'évaluation d'une demande de remboursement. Ce n'est pas un remboursement. Ce n'est pas une décision. Dans tous les cas, c'est Apple qui prend la décision finale. Ce que la notification vous offre, c'est une occasion limitée de décrire ce qui s'est réellement passé avec l'achat.
Bien la gérer est un problème de backend, pas un problème de support. La notification doit arriver, la transaction doit être identifiable, le statut du consentement doit être connu, et une réponse doit partir à temps.
Cet article explique ce que signifie la notification, ce qu'Apple demande aujourd'hui (la liste des champs est bien plus courte qu'avant) et comment construire un workflow autour. Pour le processus dans son ensemble, notre guide sur la gestion des remboursements App Store pose le contexte.
Points clés
• CONSUMPTION_REQUEST est une demande d'informations d'Apple pendant l'évaluation d'un remboursement. Ce n'est pas une notification de remboursement.
• Apple prend la décision finale. Votre réponse est un élément parmi d'autres.
• L'endpoint actuel accepte cinq champs, dont trois obligatoires — contre douze dans l'ancienne version.
• Le consentement est obligatoire. Apple rejette les requêtes où customerConsented n'est pas true.
• Apple demande une réponse dans les 12 heures suivant la notification.
• Comme la fenêtre est courte et que les notifications arrivent à toute heure, cette étape se prête mieux à l'automatisation qu'à un traitement humain.
Qu'est-ce qu'Apple CONSUMPTION_REQUEST ?
CONSUMPTION_REQUEST est une App Store Server Notification qui vous indique qu'un client a demandé un remboursement à Apple, et que l'App Store vous invite à envoyer des informations de consommation concernant cet achat.
La demande de consommation d'Apple pour les développeurs existe à cause d'un déficit d'information. Apple voit la transaction, le compte et l'historique d'achats. Apple ne voit pas ce qui s'est passé dans votre app — si le contenu a été livré, s'il fonctionnait, à quel point le client l'a réellement utilisé. Vous, si.
Une chose qu'elle n'est pas : un droit de veto. Une réponse ne bloque pas un remboursement, et Apple indique explicitement prendre en compte un ensemble de facteurs.
Comment fonctionne Apple CONSUMPTION_REQUEST ?
La séquence se déroule ainsi :
Le client demande un remboursement
↓
Apple commence à évaluer la demande
↓
CONSUMPTION_REQUEST arrive sur votre endpoint de notifications
↓
Vous vérifiez la notification et identifiez la transaction
↓
Vous vérifiez le consentement et rassemblez les données d'usage réelles
↓
Vous envoyez les informations de consommation, si les conditions sont remplies
↓
Apple prend la décision de remboursement
↓
REFUND ou REFUND_DECLINED arrive ; vous mettez à jour l'état
À noter : sur l'endpoint actuel d'Apple, une demande de remboursement pour n'importe quel type de produit peut la déclencher — consommable, non consommable, abonnement non renouvelable ou abonnement à renouvellement automatique. L'ancienne documentation et la plupart des articles tiers la décrivent encore comme limitée aux consommables et aux abonnements à renouvellement automatique. Si votre handler filtre par type de produit sur cette base, il laisse passer des requêtes.
Quelles informations Apple demande-t-il aux développeurs ?
Moins qu'avant. C'est le point sur lequel la plupart des guides existants se trompent, il vaut donc la peine d'être précis. L'endpoint actuel Send Consumption Information d'Apple accepte cinq champs — trois obligatoires, deux facultatifs.
Champ | Obligatoire | Ce que cela signifie pour vous |
customerConsented | Oui | Doit être true. Sinon, Apple rejette la requête. |
deliveryStatus | Oui | Indique si votre app a bien livré un achat fonctionnel. |
sampleContentProvided | Oui | Indique si le client a eu accès à un contenu d'essai avant d'acheter. |
consumptionPercentage | Non | Part de l'achat consommée, en milliunités. |
refundPreference | Non | Votre issue préférée : accorder en totalité, refuser ou calculer au prorata. |
Deux contraintes piègent souvent. Si deliveryStatus a une valeur autre que delivered, consumptionPercentage doit être à zéro, sinon la requête échoue. Et les milliunités ne sont pas des pourcentages — à moitié consommé, c'est 50000, pas 50.
La préférence de remboursement facultative est plus récente et mérite d'être comprise. Vous pouvez indiquer si vous préférez que le remboursement soit accordé en totalité, refusé ou calculé au prorata. C'est une préférence, pas une instruction — Apple la pèse avec tout le reste, et l'issue peut différer de ce que vous avez demandé.
Si Apple approuve un remboursement au prorata, la portion révoquée est renvoyée dans le payload de la transaction ; votre logique de droits d'accès peut donc devoir gérer une révocation partielle plutôt que de traiter chaque remboursement comme du tout ou rien.
Pourquoi Apple a-t-il besoin d'informations de consommation ?
Parce qu'Apple doit trancher sur une situation qu'Apple ne voit qu'en partie.
Apple sait ce qui a été acheté, quand, par quel compte, et à quoi ressemble l'historique de ce compte. Apple ne sait pas si votre serveur a livré les pièces, si la fonctionnalité déverrouillée fonctionnait, ni si le client a intensément utilisé le produit avant de demander à être remboursé. Ce contexte vit dans vos systèmes.
Un flux de remboursement Apple CONSUMPTION_REQUEST est le moyen pour Apple de récupérer ce contexte avant de décider. C'est aussi pourquoi l'exactitude compte plus que le plaidoyer. Les données décrivent ce qui s'est passé. Ce n'est pas un dossier que vous défendez, et le traiter ainsi comporte un vrai risque sans bénéfice garanti.
Comment les développeurs répondent à CONSUMPTION_REQUEST
Huit étapes. L'essentiel du travail se fait avant l'arrivée de la moindre requête.
1. Recevoir la notification
Les notifications App Store CONSUMPTION_REQUEST arrivent à l'URL serveur que vous configurez pour les App Store Server Notifications V2. Si cet endpoint est absent, non vérifié ou échoue silencieusement, la requête ne vous parvient jamais. La documentation App Store Server Notifications d'Apple couvre la configuration et le format du payload.
2. Vérifier la notification
Les notifications arrivent sous forme de payloads JWS signés. Vérifiez la signature par rapport à la chaîne de certificats d'Apple avant d'agir sur quoi que ce soit à l'intérieur, et contrôlez que le bundle ID correspond à votre app. Un endpoint non vérifié qui accepte tout ce qu'on lui envoie, c'est un moyen pour quelqu'un d'autre de piloter votre logique de remboursement.
3. Identifier la transaction
Le payload décodé contient les identifiants de transaction. Vous avez besoin d'un enregistrement d'achat stocké pour les faire correspondre. Pas d'enregistrement, pas de recherche — et aucun moyen de dire quoi que ce soit d'utile sur la consommation.
4. Associer la transaction au bon utilisateur
Vous ne pouvez pas décrire l'usage d'un client tant que vous ne savez pas de quel client il s'agit. C'est précisément à cela que sert appAccountToken : un UUID que votre app attache au moment de l'achat et qui revient dans le payload de la notification. Sans lui, les équipes finissent par faire des rapprochements sur l'horodatage et des heuristiques, ce qui est lent et peu fiable au moment précis où la vitesse compte.
5. Vérifier les exigences de consentement applicables
Apple est sans ambiguïté sur ce point : vous devez obtenir un consentement valide avant de partager les données d'un client, et l'obtenir relève de votre responsabilité, pas de celle d'Apple. La notification ne contient aucun indicateur de consentement, vous devez donc le savoir à partir de vos propres enregistrements.
Si le client n'a pas consenti, la consigne d'Apple est de ne pas répondre du tout. Envoyer la requête avec le consentement à false ne fonctionne pas — l'App Store la rejette. Apple précise aussi clairement que l'invite App Tracking Transparency n'est pas le mécanisme prévu pour cela ; il s'agit d'un consentement distinct, recueilli dans votre app.
6. Rassembler les informations d'usage réelles
Tirez le statut de livraison et la consommation de vos enregistrements réels. Si votre serveur suit un solde de consommables, vous savez déjà combien a été dépensé. Si un déverrouillage de fonctionnalité a échoué, vos logs le savent aussi. N'estimez pas — un chiffre de consommation inventé, ce sont des données inexactes envoyées à Apple sous un consentement obtenu pour des données exactes.
7. Envoyer les informations appropriées
Répondez par un PUT sur l'endpoint de consommation en utilisant l'identifiant de transaction d'origine issu de la notification. Gérez les réponses d'erreur au lieu d'envoyer sans vérifier : les échecs de validation renvoient un HTTP 400 avec des types d'erreur précis, et un appel échoué silencieusement ressemble exactement à un appel réussi si personne ne vérifie.
8. Consigner le résultat
Journalisez la requête, la transaction, ce que vous avez envoyé, quand vous l'avez envoyé, et ce qu'Apple a finalement décidé. C'est cet enregistrement qui vous permet de répondre à une question du support des semaines plus tard, de repérer des tendances entre remboursements et de confirmer que l'état de vos droits d'accès est correct. Quand un remboursement tombe, révoquez l'accès après remboursement — et soyez prêt à le rétablir si Apple revient ensuite sur sa décision.
Que se passe-t-il si les développeurs manquent la CONSUMPTION_REQUEST ?
Rien de spectaculaire, et c'est une partie du problème.
Manquer la réponse signifie que vous ne fournissez pas les informations supplémentaires qu'Apple vous permettait de soumettre dans ce workflow. Apple décide quand même. Le remboursement peut toujours être approuvé, ou refusé, sur la base des informations dont Apple dispose déjà. Pas d'erreur, pas d'alerte, et aucun signal évident qu'une étape a été sautée.
Les façons de la manquer sont ordinaires. La notification arrive à 2 h du matin. L'ingénieur responsable du handler est absent. La recherche de la transaction traîne parce que l'identifiant est dans un système et les données d'usage dans un autre. Quelqu'un la voit lundi, bien après la fermeture de la fenêtre.
Pourquoi le traitement manuel des CONSUMPTION_REQUEST est difficile
Chaque contrainte de ce workflow plaide contre un traitement manuel.
Les notifications arrivent 24 h/24. La fenêtre est de 12 heures. Chaque requête exige une recherche de transaction, une association à un utilisateur, une vérification du consentement, un calcul d'usage, un appel API signé et un résultat journalisé — sept étapes, aucune intéressante, toutes limitées dans le temps.
À une requête par semaine, c'est un désagrément. À trente par jour, c'est le travail de quelqu'un — un travail qui ne produit rien quand il est bien fait et des pertes silencieuses quand il est fait en retard.
Comment l'automatisation change le workflow de remboursement
L'automatisation ne vous donne aucune influence sur Apple. Cela mérite d'être répété, parce que beaucoup de discours marketing laissent entendre le contraire. La décision d'Apple reste celle d'Apple.
Ce que fait l'automatisation, c'est rendre votre côté cohérent. Les notifications sont surveillées et vérifiées. Les requêtes pertinentes sont isolées du reste du flux. Les transactions sont associées aux comptes. Les données de réponse sont assemblées à partir d'enregistrements réels, les délais sont suivis, les réponses sont soumises et journalisées, et les résultats alimentent les mises à jour des droits d'accès.
Aucune de ces étapes ne demande de jugement. Toutes demandent de l'attention au bon moment, ce qu'un logiciel gère mieux que des humains.
Que doit prendre en charge un logiciel de gestion des remboursements App Store ?
Si vous évaluez un logiciel de gestion des remboursements App Store, la bonne question est de savoir s'il comble les lacunes précises décrites ci-dessus.
Il doit surveiller et vérifier les App Store Server Notifications, pour que les événements ne disparaissent pas dans un endpoint défaillant. Il doit suivre les événements CONSUMPTION_REQUEST séparément, puisqu'ils exigent un traitement différent de celui des résultats de remboursement. Il doit associer les transactions aux comptes, parce que c'est là que part le temps manuel. Il doit suivre les fenêtres de réponse, parce que c'est l'échéance que les gens manquent.
Au-delà : des workflows de données de consommation qui respectent l'état du consentement, un historique des remboursements consultable, un suivi des résultats, une synchronisation des droits d'accès incluant la révocation partielle, et des rapports assez clairs pour faire ressortir des tendances. Ce qui compte, c'est la couverture du workflow, pas la longueur de la liste de fonctionnalités.
Où ces règles sont documentées
Trois sources Apple couvrent tout ce qui précède. Lisez-les directement — ce domaine a changé récemment, et beaucoup de contenus secondaires décrivent une ancienne version de l'API.
Send Consumption Information — l'endpoint actuel. Couvre l'exigence de consentement, la fenêtre de 12 heures, le corps de requête à cinq champs, et le fait que les informations de consommation s'appliquent à tous les types de produits. C'est celui sur lequel construire pour les achats intégrés standard.
App Store Server Notifications — comment les notifications atteignent votre backend, le format du payload signé et les types de notification, dont CONSUMPTION_REQUEST, REFUND et REFUND_DECLINED.
Send Consumption Information V1 — l'ancien endpoint, avec le corps de requête à douze champs que certaines équipes ont encore en place. La note d'Apple sur cette page renvoie les achats intégrés standard vers l'endpoint actuel et limite la V1 aux achats utilisant l'Advanced Commerce API. Utile pour identifier sur lequel repose votre intégration, pas comme cible de développement.
Pour conclure
CONSUMPTION_REQUEST n'est pas la décision de remboursement d'Apple. C'est une occasion courte et limitée dans le temps de dire à Apple ce que vos systèmes savent et que les siens ignorent.
Un workflow qui la gère de façon fiable a besoin d'un endpoint de notifications vérifié, de transactions identifiables, de clients que vous pouvez associer, d'un consentement réellement recueilli, de données d'usage réelles, d'une réponse dans la fenêtre, et de résultats consignés assez bien pour mettre à jour les droits d'accès ensuite.
Si vous ne faites qu'une chose après cette lecture, vérifiez quel endpoint votre intégration appelle. Si elle envoie encore douze champs vers le chemin V1 pour des achats intégrés standard, c'est la lacune à combler en premier.
Si le volume de remboursements dépasse le traitement manuel
Dès que l'activité de remboursement devient assez fréquente pour que surveiller les notifications à la main ne soit plus réaliste, un système dédié peut surveiller les événements, préparer et soumettre les réponses dans la fenêtre, suivre les résultats et garder les droits d'accès synchronisés. RefundSensor automatise le côté développeur de ce workflow — pas la décision d'Apple, seulement la partie dont vous êtes responsable.
Questions fréquentes
C'est une App Store Server Notification qui indique à votre serveur qu'un client a demandé un remboursement et qu'Apple peut souhaiter recevoir des informations de consommation. Ce n'est pas une décision de remboursement.
Apple l'envoie après qu'un client a demandé un remboursement, pendant l'examen de la demande. Elle peut concerner différents types de produits App Store.
Votre serveur reçoit et vérifie la notification, identifie la transaction et le client, contrôle le consentement, puis envoie à Apple les informations de consommation requises dans la fenêtre de réponse.
Vérifiez la notification, contrôlez le consentement du client, fournissez des données d'usage et de livraison exactes, soumettez-les à Apple et conservez une trace de la réponse et du résultat final.
La documentation actuelle d'Apple prévoit une fenêtre de réponse de 12 heures. Les développeurs doivent vérifier les dernières exigences d'Apple avant toute implémentation.
Ce sont des informations sur la façon dont le client a utilisé son achat. Selon l'endpoint actuel, elles peuvent inclure le consentement, le statut de livraison, le contenu d'essai, les données de consommation et une préférence de remboursement.
Non. Apple prend la décision finale. Les développeurs peuvent fournir des informations de consommation et indiquer une préférence de remboursement, mais c'est Apple qui tranche en dernier ressort.
Oui. Les développeurs peuvent automatiser la vérification des notifications, le rapprochement des transactions, les contrôles de consentement, la préparation des données, le suivi des délais et la journalisation des réponses.
