Réponse rapide : Un CONSUMPTION_REQUEST est la notification qu'Apple envoie à votre serveur lorsqu'un client demande un remboursement sur un achat intégré ou un abonnement éligible. Pour y répondre, vous renvoyez un ConsumptionRequest structuré, un ensemble de champs décrivant comment le client a utilisé ce qu'il a acheté, s'il a consenti, et votre préférence de remboursement. Apple prend ces champs en compte dans sa décision. Ce guide explique ce que signifie chacun d'eux et pourquoi il compte.
Ce qu'est la notification
Lorsqu'un client demande un remboursement à Apple, l'App Store envoie un CONSUMPTION_REQUEST à votre serveur via App Store Server Notifications. C'est Apple qui vous dit : dites-nous ce que vous savez sur la façon dont ce client a utilisé cet achat, et nous en tiendrons compte dans notre décision.
Vous répondez en renvoyant un corps ConsumptionRequest. Chaque valeur est un signal. Envoyez des données de remboursement Apple précises et complètes, et Apple dispose de contexte ; laissez des champs vides, et il décide avec moins d'éléments. Vous n'approuvez ni ne refusez le remboursement vous-même, c'est toujours Apple qui tranche en dernier ressort, mais la qualité de ce que vous envoyez influence les chances. Pour le déroulé complet, consultez Comment automatiser les demandes de remboursement Apple.
Les champs qu'Apple accepte
Voici ce qui compose un ConsumptionRequest et ce que chaque champ indique à Apple. Ces champs consumption request fournissent les données structurées utilisées dans le workflow de la consumption api :
Champ | Ce qu'il représente | Pourquoi c'est important |
customerConsented | Indique si le client a consenti à partager ces données | Obligatoire. Doit être true, sinon Apple ne traitera pas la réponse. |
consumptionStatus | Non consommé / partiellement consommé / entièrement consommé | Un achat entièrement consommé est un cas très différent d'un achat non utilisé. |
deliveryStatus | Indique si la valeur ou le service a été livré avec succès | Permet de distinguer « nous avons livré, ils l'ont utilisé » d'un véritable échec de livraison. |
refundPreference | Votre recommandation : non déclarée / préférence pour l'accord / préférence pour le refus | Un des éléments pris en compte par Apple — lorsque vos preuves le justifient, c'est votre voix dans la décision. |
accountTenure | Depuis combien de temps le client possède un compte chez vous | Un compte ancien n'est pas perçu de la même façon qu'un compte tout neuf. |
playTime | Le temps que le client a passé dans votre application | Preuve directe de l'engagement avec ce qu'il demande à rembourser. |
lifetimeDollarsPurchased | Total dépensé par le client sur l'ensemble de vos applications | Permet de savoir s'il s'agit d'un achat isolé ou d'un client fidèle et précieux. |
lifetimeDollarsRefunded | Total déjà remboursé à ce client | Des remboursements répétés constituent un signal significatif. |
sampleContentProvided | Indique si le client a pu essayer avant d'acheter | Indique si l'achat a été fait en connaissance de cause. |
userStatus | Statut actuel du compte (actif, suspendu, etc.) | Précise la situation du client au moment de la demande. |
Apple associe la plupart de ces champs à des ensembles de valeurs définis (par exemple, consumptionStatus et deliveryStatus utilisent des codes énumérés spécifiques). Les codes exacts figurent dans la documentation d'Apple, référencée ci-dessous, et peuvent changer, ce qui explique en partie pourquoi tenir une réponse à jour est un travail continu, et non une mise en place ponctuelle.
Les trois champs les plus importants
Si vous devez concentrer votre attention sur un point, c'est celui-ci :
customerConsented : Ce champ n'est pas seulement important, c'est une condition bloquante. Apple rejette l'ensemble de la soumission si ce n'est pas true, et vous êtes légalement responsable d'avoir obtenu ce consentement dans votre application avant même d'envoyer la moindre donnée. C'est autant un champ de conformité qu'un champ technique. Nous traitons l'exigence de consentement en détail dans Le consentement client et la Consumption API.
refundPreference : C'est ce qui s'apparente le plus à un vote de votre part. Lorsque vos preuves justifient réellement un refus, exprimer cette préférence est l'un des éléments qu'Apple prend en compte. Lorsque ce n'est pas le cas, imposer une préférence de refus n'est pas un passe-droit magique, Apple décide toujours.
consumptionStatus : Savoir si le client a réellement utilisé ce qu'il a acheté est souvent le cœur du dossier. C'est aussi l'un des champs les plus faciles à mal renseigner si vos données d'utilisation ne sont pas précises et à jour au moment où la demande arrive.
Pourquoi bien remplir ces champs est plus difficile qu'il n'y paraît
À la lecture d'un tableau de champs, cela peut sembler être l'affaire d'un après-midi. En pratique, bien répondre implique :
Récupérer des données d'utilisation et de facturation précises et à jour pour chaque client dès l'arrivée d'une demande, pas un instantané de la veille.
Faire correspondre vos données internes aux ensembles de valeurs exacts d'Apple, et maintenir cette correspondance à jour à mesure qu'Apple les révise.
Le faire dans la fenêtre d'environ 12 heures, à toute heure, sans surveillance humaine.
Gérer l'état du consentement, les nouvelles tentatives, les échecs et la journalisation, afin de pouvoir prouver ce que vous avez envoyé et vérifier si cela fonctionne.
Rien de tout cela n'est conceptuellement difficile. Mais tout cela représente une infrastructure que vous devriez posséder et maintenir pour un workflow qui n'est pas votre produit. C'est le calcul que finissent par faire la plupart des équipes : les champs sont connaissables, mais mettre en place et maintenir un système de réponse fiable, respectant les délais et conforme est un coût permanent sans aucun bénéfice pour votre application elle-même.
C'est le vide que RefundSensor comble. Il associe chaque champ à vos données, reste à jour avec les évolutions d'Apple, et répond automatiquement dans la fenêtre impartie, afin que la précision qui décide des remboursements soit assurée sans que vous ayez à la construire ou à la surveiller. Pour les équipes qui comparent les logiciels d'automatisation des remboursements Apple, cela élimine la charge d'infrastructure du workflow.
Sources officielles
Les ensembles de valeurs et les exigences d'Apple évoluent ; considérez donc sa documentation comme la référence ultime :
Les champs sont connaissables. Maintenir un système de réponse pour eux n'est pas votre travail. RefundSensor associe chaque champ ConsumptionRequest à vos données et répond automatiquement dans la fenêtre impartie par Apple, avec précision, actualité et conformité. Commencer gratuitement
Questions fréquentes
C'est la notification App Store Server qu'Apple envoie lorsqu'un client demande un remboursement sur un achat éligible. Elle vous invite à renvoyer des données de consommation qu'Apple prend en compte dans sa décision de remboursement.
Des champs décrivant le consentement, le statut de consommation, le statut de livraison, l'ancienneté du compte, le temps de jeu, les dépenses et remboursements cumulés, le contenu d'essai fourni, le statut du compte, et votre préférence de remboursement. Chacun est un signal qu'Apple intègre à sa décision.
customerConsented est une condition bloquante : sans lui, la réponse est rejetée. refundPreference et consumptionStatus influencent le plus directement le résultat lorsque vos preuves appuient votre dossier.
Une préférence a plus de poids lorsqu'elle est étayée par des données de consommation et de livraison précises. Des réponses incomplètes donnent moins d'éléments à Apple pour agir : une préférence seule est donc moins convaincante qu'une préférence accompagnée de preuves.
Non. C'est toujours Apple qui prend la décision finale. Des données précises améliorent vos chances, mais ne vous donnent pas de droit de veto.
