Réponse rapide : Avant d'envoyer des données de consommation à Apple en réponse à un CONSUMPTION_REQUEST, vous devez disposer d'un consentement valide du client, et vous devez définir customerConsented sur true. La notification d'Apple ne vous indique pas si le consentement existe, par conception, Apple attend que ce soit votre application, et non votre serveur, qui le recueille. Et comme c'est vous qui partagez des données que vous avez collectées auprès de l'utilisateur, la responsabilité juridique de ce consentement vous incombe entièrement, pas à Apple. Une erreur sur ce point est un problème de droit de la confidentialité, pas seulement un appel API rejeté.
L'angle mort que la plupart des développeurs ratent
Les guides sur l'automatisation des remboursements adorent parler de la fenêtre de 12 heures et des champs de consommation. Presque aucun ne s'arrête sur le détail le plus susceptible de mettre un développeur dans l'embarras : la notification CONSUMPTION_REQUEST ne contient aucune indication de consentement.
Cela surprend beaucoup de monde. On pourrait raisonnablement supposer que si Apple vous demande des données, Apple a déjà géré l'autorisation de les partager. Ce n'est pas le cas. La position d'Apple est l'inverse : les données que vous enverriez sont des données que vous avez collectées auprès de votre utilisateur, donc la responsabilité d'avoir l'autorisation de les partager vous incombe. Apple exige simplement que vous l'attestiez en définissant customerConsented sur true, et rejette la soumission si vous ne le faites pas. C'est le cœur des exigences de consentement de l'Apple Consumption API.
Ce champ n'est donc pas une simple case à cocher pour satisfaire l'API. C'est une attestation juridique. Le définir sur true alors que vous n'avez pas réellement obtenu le consentement n'est pas un détail technique, c'est un manquement à la conformité qui n'attend que d'être découvert.
Pourquoi le consentement relève de la responsabilité du développeur
Réfléchissez à qui détient quoi. Apple gère le store et la décision de remboursement. Mais l'ancienneté du compte, le temps de jeu, le statut de livraison et l'historique d'utilisation que vous mettriez dans un ConsumptionRequest sont vos données concernant votre utilisateur, recueillies dans le cadre de votre politique de confidentialité. Lorsque vous les envoyez à Apple, vous divulguez des données personnelles à un tiers.
En vertu des régimes de confidentialité applicables, cette divulgation nécessite une base juridique appropriée. La documentation spécifique de l'API d'Apple exige un consentement valide avant le partage des données personnelles via la Consumption Information API, tandis que les exigences juridiques précises dépendent de la juridiction de l'utilisateur. Apple indique qu'il incombe aux développeurs de déterminer la conformité avec les lois applicables.
C'est pourquoi cette charge revient au développeur, et pourquoi « Apple me l'a demandé » n'est pas une défense valable si un régulateur vous demande comment vous aviez l'autorisation de partager les données d'un utilisateur. Pour un flux de consentement de remboursement Apple, l'essentiel est que le consentement existe avant que les données ne soient partagées.
Où le consentement doit être recueilli
C'est là l'aspect pratique le plus important : le consentement doit être recueilli dans votre application, avant le processus de remboursement, et non déduit au niveau du serveur au moment où la notification arrive.
Au moment où un CONSUMPTION_REQUEST arrive sur votre serveur, il est trop tard pour le demander. Aucun utilisateur n'est présent, et vous disposez d'environ 12 heures. Le consentement doit déjà exister, recueilli en amont dans le cadre de la manière dont votre application intègre les utilisateurs et divulgue ses pratiques de données, afin que vous puissiez, en toute honnêteté, définir customerConsented sur true lorsque la demande arrive.
En pratique, cela signifie que les conditions d'utilisation, la politique de confidentialité et le parcours d'achat ou d'intégration de votre application doivent clairement divulguer que les données de consommation peuvent être partagées avec Apple pour traiter les demandes de remboursement, et obtenir un accord que vous pouvez défendre. Un consentement vague, groupé ou dissimulé est précisément ce que le droit moderne de la confidentialité est conçu pour rejeter. Cela est également central pour la confidentialité des remboursements Apple, car Apple exige spécifiquement un consentement valide avant le partage des données de consommation.
Le lien avec le RGPD et le DPDP
Si certains de vos utilisateurs se trouvent dans l'UE/au Royaume-Uni (RGPD), en Inde (DPDP), en Californie (CCPA), ou dans une liste croissante d'autres juridictions, le partage de données de consommation relève pleinement de ces cadres réglementaires. Voici quelques principes qui s'appliquent systématiquement :
Le consentement doit être éclairé et spécifique. L'utilisateur doit comprendre que des données liées au remboursement peuvent être partagées avec Apple, et pas simplement accepter un mur de texte juridique.
Le consentement doit être dissociable. Regrouper le consentement au partage de données avec des conditions sans rapport dans une seule case à cocher obligatoire est une pratique reconnue comme problématique.
Vous devez pouvoir le démontrer. En cas de contestation, l'affirmation « nous avions le consentement » doit pouvoir être prouvée, ce qui signifie que la collecte de votre consentement doit être enregistrée, et non simplement présumée.
Votre politique de confidentialité doit réellement le mentionner. Si votre politique ne divulgue pas le partage des données de consommation avec Apple à des fins de remboursement, votre consentement à ce sujet repose sur des bases fragiles.
Pour les équipes qui examinent les exigences RGPD relatives aux données de consommation, l'essentiel est qu'Apple exige elle-même un consentement valide pour cette API, tandis que les exigences juridiques exactes et la base légale peuvent varier selon la juridiction. Les directives d'Apple indiquent que le consentement doit être donné librement, être spécifique, éclairé et non ambigu, et qu'il incombe aux développeurs de déterminer la conformité selon le droit applicable.
Pour les applications destinées à l'Inde, le consentement au remboursement DPDP doit également être examiné au regard des exigences applicables, plutôt que de supposer que l'exigence de l'API d'Apple résout à elle seule toutes les obligations de confidentialité.
Ceci ne constitue pas un conseil juridique, et les spécificités de vos obligations dépendent de vos utilisateurs et de vos juridictions, mais la direction est claire : le consentement derrière ce champ customerConsented doit être réel, éclairé et documenté.
À quoi ressemble une configuration conforme
En résumé, une configuration défendable comporte trois éléments mis en place en amont de tout remboursement :
Divulgation : votre politique de confidentialité et vos conditions d'utilisation indiquent clairement que les données de consommation/d'utilisation peuvent être partagées avec Apple pour traiter les demandes de remboursement.
Collecte : votre application obtient le consentement éclairé et dissociable de l'utilisateur, et l'enregistre.
Attestation : lorsqu'un CONSUMPTION_REQUEST arrive, votre réponse reflète honnêtement ce consentement enregistré dans customerConsented.
RefundSensor a été conçu en tenant compte de cette chaîne. La plateforme gère la réponse de remboursement et l'attestation customerConsented dans le cadre du flux automatisé, et nous avons publié une suite complète de documents de conformité, politique de confidentialité, conditions d'utilisation, DPA, politiques de cookies et de remboursement alignées sur le RGPD, le DPDP et le CCPA, afin que le volet divulgation et traitement soit couvert plutôt qu'improvisé. La collecte du consentement dans votre application reste de votre ressort, comme il se doit, mais tout ce qui suit est pris en charge.
Pour les équipes qui évaluent un logiciel de conformité pour les remboursements ou un outil d'automatisation des remboursements Apple, cette séparation est importante : l'automatisation peut gérer la réponse technique, mais elle ne doit ni inventer ni présumer le consentement du client.
Les erreurs les plus courantes
Définir customerConsented sur true par défaut. Le moyen le plus rapide de transformer une fonctionnalité de remboursement en risque de conformité.
Supposer qu'Apple gère le consentement. Ce n'est pas le cas, et Apple le dit clairement.
Essayer de recueillir le consentement au moment du remboursement. Il n'y a ni utilisateur ni fenêtre disponible à ce moment-là, il doit exister au préalable.
Ne rien divulguer dans la politique de confidentialité. Si la politique reste silencieuse sur le partage de données avec Apple, le consentement sous-jacent est difficile à défendre.
Le regrouper dans une seule case à cocher obligatoire. Le consentement dissociable est la norme ; le regroupement la compromet.
Utiliser App Tracking Transparency comme mécanisme de consentement. La documentation d'Apple précise explicitement que le consentement requis pour la Consumption Information API est distinct de l'App Tracking Transparency.
Sources officielles
Les exigences comme les réglementations évoluent, considérez donc ces sources comme la référence finale :
Une automatisation des remboursements qui respecte la chaîne de consentement. RefundSensor gère la réponse de remboursement et l'attestation customerConsented dans le cadre d'un flux automatisé, appuyé par une suite complète de documents de conformité alignés sur le RGPD, le DPDP et le CCPA. Pour les équipes en quête d'automatisation des remboursements d'applications, la chaîne de consentement reste une partie de l'implémentation. Commencer gratuitement
Questions fréquentes
Oui. Vous devez disposer d'un consentement valide et éclairé, et définir customerConsented sur true. Apple exige cette attestation et rejette les réponses qui en sont dépourvues, et vous êtes légalement responsable d'avoir obtenu ce consentement.
Dans votre application, avant le processus de remboursement. Lorsqu'un CONSUMPTION_REQUEST arrive sur votre serveur, aucun utilisateur n'est présent et vous disposez d'environ 12 heures, le consentement doit donc déjà exister et être enregistré.
Non. La notification ne contient aucune indication de consentement. Apple attend de votre application qu'elle l'ait recueilli, et attend de vous que vous l'attestiez dans votre réponse.
Elle peut l'être, si la chaîne de consentement est correctement mise en place : divulgation claire dans votre politique, consentement éclairé et distinct recueilli et enregistré dans l'application, et attestation honnête dans la réponse de l'API. L'automatisation gère la réponse ; la collecte du consentement dans l'application relève de votre responsabilité.
Apple ne traitera pas les données de consommation, ce qui vous fait perdre l'occasion d'éclairer cette décision de remboursement. La bonne approche consiste à obtenir un véritable consentement en amont plutôt que d'envoyer des données sans celui-ci.
