Comprendre ce qu'est une notification CONSUMPTION_REQUEST prend à peu près un paragraphe. Construire un traitement qui la gère de manière fiable prend nettement plus de temps, et les points qui piègent les équipes ne sont pas ceux auxquels on s'attend.
La vérification de signature en est un. Le consentement en est un autre, car il doit exister avant l'arrivée de la notification. Et le calendrier des nouvelles tentatives interagit avec le délai de réponse d'une façon qui surprend la plupart des équipes la première fois qu'elles l'examinent de près.
Cet article suit le traitement de bout en bout, du moment où la requête atteint votre endpoint jusqu'à la mise à jour des droits d'accès qui clôt le dossier.
À retenir
• CONSUMPTION_REQUEST demande des informations pendant l'examen d'un remboursement. C'est toujours Apple qui décide.
• Vérifiez la charge utile signée avant d'agir. Ne faites jamais confiance à une notification non vérifiée.
• Le consentement doit déjà exister dans votre app. Vous ne pouvez pas le recueillir après l'arrivée de la requête.
• Apple demande une réponse dans les 12 heures suivant la notification.
• Apple réessaie les livraisons échouées selon un calendrier fixe, et la deuxième tentative arrive après la fermeture du délai de réponse.
• Suivez le résultat et mettez à jour les droits d'accès ensuite. Répondre n'est pas la dernière étape.
Qu'est-ce qu'une notification CONSUMPTION_REQUEST d'Apple ?
Une notification CONSUMPTION_REQUEST d'Apple est une App Store Server Notification qui indique à votre serveur qu'un client a demandé un remboursement et qu'Apple vous invite à envoyer des informations de consommation sur cet achat. Elle arrive à l'URL de notification que vous avez configurée, contient la transaction concernée et vous laisse un temps limité pour répondre.
Ce n'est ni un remboursement ni une décision. Apple est en cours d'examen et rassemble du contexte. Votre rôle est de fournir des informations exactes sur ce qui s'est passé avec l'achat ; celui d'Apple est de trancher.
Pourquoi Apple envoie-t-il une CONSUMPTION_REQUEST ?
Parce qu'Apple ne voit pas ce qui se passe dans votre app. Apple connaît la transaction, le compte et l'historique d'achats. Apple ne sait pas si le contenu a été livré, s'il fonctionnait, ni dans quelle mesure le client l'a utilisé.
Les informations de consommation comblent ce manque. C'est l'un des facteurs qu'Apple prend en compte, pas le facteur décisif, et un taux de consommation élevé n'est pas un bouton de refus. Considérez-les comme du contexte que vous apportez, pas comme un dossier que vous plaidez.
Que doivent faire les développeurs à la réception d'une CONSUMPTION_REQUEST ?
Valider la notification, identifier la transaction et le client, confirmer le consentement, assembler des données de consommation exactes, les envoyer dans le délai imparti par Apple, puis consigner ce qui s'est passé.
Dix étapes en pratique :
1. Recevez la notification sur l'endpoint serveur configuré et enregistrez-la immédiatement.
2. Vérifiez la charge utile signée avant de considérer un champ comme fiable.
3. Lisez le type de notification et routez-la. Une demande de consommation n'est pas un résultat de remboursement.
4. Identifiez la transaction concernée à partir de la charge utile décodée.
5. Associez la transaction à un compte client dans votre propre système.
6. Vérifiez si le consentement de ce client autorise une réponse.
7. Rassemblez les données de livraison et d'utilisation à partir de vos enregistrements, pas d'estimations.
8. Préparez la réponse et contrôlez-la selon les règles de validation des champs.
9. Soumettez-la à l'endpoint de consommation d'Apple et capturez le résultat.
10. Suivez le résultat du remboursement qui s'ensuit, puis mettez à jour les droits d'accès et les enregistrements.
Comment valider une CONSUMPTION_REQUEST ?
Vérifiez la signature avant de faire confiance au contenu. Les notifications arrivent sous forme de charges utiles JWS signées, documentées dans la documentation Apple App Store Server Notifications, et votre traitement doit les contrôler par rapport à la chaîne de certificats d'Apple et confirmer que le bundle ID correspond à votre app.
La raison est simple. Votre URL de notification est un endpoint public. Une implémentation qui analyse tout ce qui arrive et agit en conséquence peut être pilotée par quiconque trouve l'URL.
Trois détails du traitement comptent autant que la signature :
Renvoyez le bon code de statut. Apple considère les codes HTTP 200 à 206 comme un succès. Un 40x ou un 50x indique à l'App Store de réessayer. Renvoyez un succès une fois la notification stockée, pas une fois son traitement terminé — ce sont deux moments différents, et les coupler signifie qu'un job aval lent peut déclencher des tentatives inutiles.
Gérez les doublons. Les nouvelles tentatives impliquent qu'une même notification peut arriver plusieurs fois, et chacune porte un UUID de notification qui permet de dédupliquer. Acquittez les répétitions plutôt que de renvoyer une erreur ; une réponse d'échec ne fait que relancer le cycle de tentatives.
N'oubliez pas que le sandbox se comporte différemment. Les nouvelles tentatives s'appliquent en production. Dans le sandbox, l'App Store ne tente la livraison qu'une seule fois, si bien qu'un traitement qui semble correct en test peut encore perdre des événements en production, et l'inverse est également vrai.
Que vérifier avant de répondre ?
Quatre choses, dans cet ordre.
Le consentement d'abord, car c'est lui qui peut tout bloquer. Apple exige un consentement client valide avant que vous partagiez ses données, l'obtenir relève de votre responsabilité et non de celle d'Apple, et la notification elle-même ne contient aucun indicateur de consentement. Apple précise aussi clairement que l'invite App Tracking Transparency n'est pas le mécanisme adapté ici. Sans consentement, la consigne est de ne pas répondre.
L'identité de la transaction ensuite. Vous devez savoir de quel achat il s'agit et quel compte se trouve derrière. Cette correspondance est précisément le sujet de appAccountToken et la défense contre les remboursements Apple : sans lien stable entre transaction et compte, vous faites des déductions sous la pression du délai.
Le type de produit en troisième, car il détermine les options qui vous sont ouvertes. Et enfin, si vous disposez réellement de données exploitables. Si vos systèmes ne peuvent pas dire si le contenu a été livré, mieux vaut le savoir avant de commencer à assembler une réponse.
Quelles informations de consommation envoyer à Apple ?
La documentation Send Consumption Information actuelle d'Apple définit cinq champs. Trois sont obligatoires et deux facultatifs.
Champ | Obligatoire | En clair |
customerConsented | Oui | Le client a-t-il donné son accord ? Doit être true, sinon la requête est rejetée. |
deliveryStatus | Oui | Votre app a-t-elle réellement livré un achat fonctionnel, et sinon, pourquoi ? |
sampleContentProvided | Oui | Le client pouvait-il essayer avant d'acheter ? |
consumptionPercentage | Non | Quelle part a-t-il utilisée ? En millièmes — la moitié vaut 50000, pas 50. |
refundPreference | Non | Ce que vous préférez : rembourser intégralement, refuser ou rembourser au prorata. |
Deux règles piègent souvent. Si le statut de livraison est autre que « livré », le pourcentage de consommation doit être à zéro. Et la préférence de remboursement est une préférence, pas une instruction ; Apple peut décider autrement, et le fait.
Vérifiez sur quel endpoint vous êtes. Apple documente aussi la documentation ConsumptionRequestV1 d'Apple, la version précédente avec un corps à douze champs que la plupart des articles tiers décrivent encore. La note d'Apple y renvoie les In-App Purchases standard vers l'endpoint actuel et réserve la V1 aux achats via l'Advanced Commerce API. Si votre intégration est antérieure à ce changement, c'est la première chose à examiner.
De combien de temps disposez-vous pour répondre à une CONSUMPTION_REQUEST ?
La documentation actuelle d'Apple demande une réponse dans les 12 heures suivant la notification.
Voici le point qui mérite attention. Apple réessaie les livraisons échouées cinq fois, à 1, 12, 24, 48 et 72 heures après la tentative précédente. Mettez cela en regard d'un délai de 12 heures et le calcul devient inconfortable : si votre endpoint manque la première livraison, la première nouvelle tentative arrive une heure plus tard et tout va bien. S'il manque aussi celle-là, la tentative suivante arrive vers la treizième heure, après la fermeture du délai.
La fiabilité de l'endpoint n'est donc pas ici une simple question d'hygiène générale. Pour les demandes de consommation en particulier, une heure d'indisponibilité environ est rattrapable ; une demi-journée ne l'est pas.
Apple n'indique pas que manquer le délai entraîne l'approbation automatique du remboursement, et il serait faux de l'affirmer. Cela signifie simplement qu'Apple décide sans les informations que vous auriez pu fournir.
Que se passe-t-il après la réponse du développeur ?
Apple intègre vos informations à son examen, les met en balance avec le reste et décide. Le résultat arrive sous forme d'une notification distincte : accordé, refusé, ou annulé si Apple revient ensuite sur un remboursement déjà approuvé.
Trois choses distinctes se produisent ici, et il est utile de les séparer. Votre réponse est une information. La décision d'Apple est une décision. La mise à jour de votre système est un changement d'état. Seule la deuxième appartient à Apple, et la troisième n'a lieu que si vous la construisez.
Gérer les remboursements Apple après la réponse
Une fois le résultat arrivé, le travail revient de votre côté.
Enregistrez le résultat en regard de la transaction et du client. Mettez à jour le statut de l'abonnement, car une période remboursée met généralement fin à l'abonnement plutôt que de le laisser courir. Révoquez les droits d'accès en cas de remboursement accordé, rétablissez-les en cas d'annulation, et gérez le cas du prorata où seule une partie de la transaction est révoquée.
Rapprochez ensuite le montant dans la bonne période de reporting et conservez le remboursement dans un historique consultable. C'est cet historique qui vous dira plus tard si un produit ou un niveau de prix génère une part disproportionnée, et c'est aussi ce dont le support a besoin quand un client demande ce qu'il est advenu de son accès.
Quelles sont les erreurs courantes dans le traitement des CONSUMPTION_REQUEST ?
Celles qui reviennent régulièrement :
• Traiter la notification comme un remboursement et révoquer l'accès immédiatement. Rien n'a encore été décidé.
• Sauter la vérification de signature parce que la charge utile semble correcte en test.
• Découvrir qu'il n'existe aucun parcours de consentement au moment où une réponse est attendue.
• Envoyer des chiffres de consommation estimés au lieu de chiffres réels.
• Lancer la requête sans jamais vérifier si elle a abouti. Après coup, une soumission échouée ressemble exactement à une soumission réussie.
• Confondre une résiliation et un remboursement. Ce sont des événements différents avec des effets différents sur l'accès.
• Gérer les résultats accordé et refusé mais oublier le cas de l'annulation, ce qui bloque des clients payants.
• Compter sur quelqu'un pour remarquer manuellement une notification, avec un compte à rebours de 12 heures.
Peut-on automatiser le traitement des CONSUMPTION_REQUEST ?
Oui, et il devrait l'être presque entièrement, car quasiment chaque étape est déterministe.
L'automatisation couvre la surveillance et la validation des notifications, la recherche de transaction, les contrôles de consentement, la préparation des données de consommation, la soumission, la journalisation des réponses, le suivi des résultats, les alertes internes et le reporting. Rien de tout cela ne demande de jugement sur le moment.
Ce qui reste humain se situe en amont : concevoir le parcours de consentement dans votre app et définir votre politique de préférence de remboursement. Et l'automatisation n'a aucune influence sur la décision d'Apple, quoi qu'en laissent entendre certains outils.
Comment RefundSensor aide les développeurs à gérer les workflows de remboursement Apple
La gestion des remboursements App Store est la catégorie, et RefundSensor en couvre le versant développeur : surveillance des workflows de remboursement Apple, prise en charge du parcours de réponse officiel aux demandes de consommation, suivi des événements et résultats de remboursement, et retrait des tâches répétitives des mains des équipes.
Concrètement, les réponses partent dans le délai sans que personne ne surveille un dashboard à 3 h du matin, et les enregistrements de remboursement restent exacts à mesure que le volume augmente. L'outil n'empêche pas les remboursements et ne peut pas influencer la décision d'Apple. Il supprime la surveillance manuelle et les étapes oubliées.
Où ces règles sont documentées
Send Consumption Information — l'endpoint actuel. Exigence de consentement, délai de 12 heures et les cinq champs de la requête. Développez sur cette base pour les In-App Purchases standard.
Send Consumption Information V1 — l'endpoint précédent avec le corps à douze champs. Utile pour identifier quelle version votre intégration appelle, et pour les achats via l'Advanced Commerce API.
App Store Server Notifications — livraison des notifications, format de la charge utile signée, codes de réponse attendus et calendrier des nouvelles tentatives.
Si tout cela est encore géré à la main
Un délai de 12 heures, un calendrier de nouvelles tentatives qui peut le dépasser et des notifications qui arrivent en pleine nuit se prêtent mal à une surveillance manuelle. RefundSensor prend en charge le versant développeur de ces workflows : validation des notifications, préparation et soumission des réponses dans le délai, et suivi des résultats jusqu'à vos enregistrements de droits d'accès.
Questions fréquentes
Une App Store Server Notification qui indique à votre serveur qu'un client a demandé un remboursement et qu'Apple vous invite à envoyer des informations de consommation sur l'achat. Ce n'est ni une notification de remboursement ni une décision. Apple tranche séparément, en traitant votre réponse comme un élément parmi plusieurs facteurs.
Parce qu'Apple ne voit pas ce qui se passe dans votre app. Apple connaît la transaction et l'historique du compte, mais pas si le contenu a été livré, s'il fonctionnait, ni dans quelle mesure le client l'a utilisé. Ce contexte se trouve dans vos systèmes, donc Apple vous le demande pendant l'examen.
Vérifiez la notification signée, identifiez la transaction et le client concerné, confirmez l'existence du consentement, rassemblez des données réelles de livraison et d'utilisation à partir de vos enregistrements, puis soumettez-les à l'endpoint de consommation d'Apple dans le délai imparti. Capturez le résultat de la réponse plutôt que de supposer que l'appel a réussi.
Cinq champs sur l'endpoint actuel. Trois obligatoires : le consentement du client, le statut de livraison et la mise à disposition ou non d'un contenu d'essai. Deux facultatifs : le pourcentage de consommation et votre préférence de remboursement. L'endpoint V1 précédent demandait douze champs, ce qui explique pourquoi les guides plus anciens décrivent une liste plus longue.
La documentation actuelle d'Apple décrit la notification en lien avec les demandes de remboursement pour tous les types de produits, un périmètre plus large que ce que suggéraient les anciennes docs. Apple ne publie aucune garantie pour chaque cas, donc construisez un traitement qui répond quand une requête arrive plutôt qu'une logique qui suppose qu'il y en aura toujours une.
Apple demande une réponse dans les 12 heures suivant la notification. À noter que le calendrier de nouvelles tentatives d'Apple pour les livraisons échouées s'échelonne à 1, 12, 24, 48 et 72 heures, donc un endpoint qui reste indisponible au-delà de la première tentative peut ne recevoir la notification qu'après la fermeture du délai.
Apple les met en balance avec d'autres facteurs et décide. Le résultat arrive sous forme d'une notification distincte indiquant que le remboursement a été accordé, refusé ou annulé par la suite. À partir de là, il vous revient de mettre à jour les droits d'accès, le statut de l'abonnement et les enregistrements de revenus pour refléter le nouvel état de la transaction.
Oui. La validation, la recherche de transaction, les contrôles de consentement, la préparation des données, la soumission, la journalisation et le suivi des résultats sont tous déterministes. Ce qui reste humain, c'est la conception du parcours de consentement et la définition de votre politique de préférence de remboursement. L'automatisation n'a aucun effet sur la décision de remboursement d'Apple.
