Pendant longtemps, la réponse honnête à la question « comment répondre à une demande de remboursement Apple » était simple : vous ne le faisiez pas. Apple encaissait le paiement, recevait la demande, décidait, et la première chose dont un développeur avait connaissance était un versement plus faible. Ce n'est plus vrai depuis 2021, même si beaucoup continuent de le penser.
Désormais, Apple demande à votre serveur ce qu'il sait de l'achat avant de décider, et attend environ 12 heures la réponse. Nous avons déjà détaillé ce que contient réellement un CONSUMPTION_REQUEST, donc je ne reviendrai pas sur chaque champ de la charge utile. Voici plutôt ce qu'il faut faire une fois qu'une demande arrive.
Points clés
Apple décide de chaque remboursement sur l'App Store. Ce que vous envoyez n'y change rien, mais cela change ce qu'Apple sait au moment de décider.
La demande arrive sous forme de notification CONSUMPTION_REQUEST, uniquement pour les consommables et les abonnements à renouvellement automatique.
Vous disposez de 12 heures pour répondre via le endpoint Send Consumption Information, qui demande désormais cinq champs.
La réponse repose surtout sur trois faits : l'achat a-t-il été livré, quelle part en a été utilisée, le client a-t-il eu un avant-goût gratuit. Plus votre préférence.
D'après notre expérience, les remboursements que les développeurs perdent sont surtout ceux auxquels personne n'a répondu.
Qu'est-ce qu'une demande de remboursement sur l'App Store d'Apple ?
Une demande de remboursement sur l'App Store d'Apple est une demande qu'un client adresse à Apple pour récupérer son argent sur une application ou un achat intégré. Pas à vous. Il se rend sur reportaproblem.apple.com, ou utilise la fiche de remboursement intégrée à l'application, choisit un motif dans un menu restreint, sélectionne l'achat et valide. La page d'assistance d'Apple lui indique qu'il recevra une réponse sous 24 à 48 heures.
Si l'achat était un consommable ou un abonnement à renouvellement automatique, Apple sollicite votre serveur et lui demande ce qu'il sait, puis combine votre réponse avec l'historique d'achats et de remboursements du client, qu'Apple connaît bien mieux que vous, pour prendre sa décision. Vous ne voyez pas le nom du client et vous n'avez pas de droit de veto. Vous disposez d'une courte fenêtre pour exposer les faits.
Comment fonctionne le processus de remboursement Apple pour les développeurs
Le processus de remboursement Apple pour les développeurs se déroule en quatre étapes, et vous n'intervenez que sur une seule d'entre elles.
Le client demande un remboursement à Apple et choisit un motif.
Apple envoie un CONSUMPTION_REQUEST à l'URL de serveur que vous avez enregistrée dans App Store Connect. Cela ne se produit que pour les consommables et les abonnements à renouvellement automatique.
Vous avez 12 heures pour appeler le endpoint Send Consumption Information avec vos données.
Apple décide, puis vous informe via une notification REFUND ou REFUND_DECLINED.
Si vous n'avez jamais configuré d'URL de serveur pour App Store Server Notifications, la deuxième étape ne se produit tout simplement pas. Apple tranche en se fondant uniquement sur le compte du client, et vous l'apprenez via le rapport de ventes, si vous le consultez.
Que se passe-t-il après qu'un client a demandé un remboursement ?
Peu après la soumission par le client, votre endpoint reçoit une charge utile JSON signée avec un notificationType de CONSUMPTION_REQUEST. À l'intérieur : la transaction signée, l'ID du produit, l'ID de transaction d'origine, et un consumptionRequestReason. Apple a ajouté ce motif en 2024 et l'a expliqué lors de la session WWDC24 consacrée aux API serveur de l'App Store. Cinq valeurs possibles : UNINTENDED_PURCHASE, FULFILLMENT_ISSUE, UNSATISFIED_WITH_PURCHASE, LEGAL et OTHER.
Ce qui manque, c'est la personne. Le seul lien vers vos registres est l'ID de transaction, et l'appAccountToken si vous en attachiez un au moment de l'achat. Si ce n'était pas le cas, c'est le moment où vous regretterez de ne pas l'avoir fait.
L'examen se résume donc à une recherche : qui a acheté ceci, l'a-t-il reçu, et qu'en a-t-il fait depuis ?
Comment répondre à une demande de remboursement Apple
Les personnes qui cherchent comment répondre aux notifications de demande de remboursement Apple tombent surtout sur la référence de l'API. Voici les étapes, dans l'ordre.
1. Vérifier la charge utile
Apple signe chaque notification. Vérifiez la signature avant d'en croire un mot. L'App Store Server Library d'Apple s'en charge en Java, Python, Node et Swift.
2. Retrouver l'achat
Utilisez l'ID de transaction ou l'appAccountToken pour retrouver l'achat dans votre propre système. Vous voulez l'utilisateur, l'enregistrement de livraison, et toute utilisation enregistrée depuis.
3. Lire le motif, puis le vérifier
FULFILLMENT_ISSUE signifie que le client affirme n'avoir jamais reçu ce pour quoi il a payé. Vérifiez d'abord vos journaux de livraison, car s'il a raison, vous voulez que ce remboursement soit accordé.
UNINTENDED_PURCHASE correspond généralement à un enfant ou à un faux clic.
C'est avec UNSATISFIED_WITH_PURCHASE que vos données d'utilisation pèsent vraiment, car « je n'ai pas aimé » n'a pas le même poids à 2 % d'utilisation qu'à 100 %.
4. Choisir une préférence
Apple accepte GRANT_FULL, GRANT_PRORATED ou DECLINE. Choisissez celle que vos données étayent. C'est une préférence, et Apple a accordé de nombreux remboursements que des développeurs avaient demandé de refuser.
5. Envoyer la réponse
Appelez le Send Consumption Information endpoint. Le corps de requête actuel comporte cinq champs : customerConsented, deliveryStatus, consumptionPercentage, sampleContentProvided et refundPreference.
La consommation est exprimée en milliunités, ce qui piège souvent les gens : 100000 signifie entièrement utilisé, 45200 signifie 45.2 %.
Et customerConsented doit valoir true, donc l'autorisation de partager les données d'utilisation doit figurer dans vos conditions bien avant l'arrivée de la première demande.
6. Agir en fonction du résultat
REFUND signifie révoquer le contenu ou le droit d'accès, idéalement dans l'heure. REFUND_DECLINED signifie que rien ne change. Dans tous les cas, consignez le résultat dans le dossier.
Imaginons que quelqu'un achète un pack de 500 pièces à 23 h, en dépense 470 pendant la nuit, puis dépose une demande sous UNSATISFIED_WITH_PURCHASE le lendemain matin. Livré, 94 % consommés, aucun essai, préférence DECLINE. Voilà une réponse complète à une demande de remboursement Apple. Ce n'est pas une dissertation.
Quelles informations les développeurs doivent-ils vérifier avant de répondre ?
Cinq éléments, dont la plupart devraient déjà figurer dans votre base de données.
L'enregistrement de l'achat
Date, produit, prix, et si ce compte a déjà acheté chez vous auparavant. Si vos registres sont incomplets, le endpoint Get Transaction History d'Apple renvoie tout ce que ce client a acheté dans votre application, à condition de partir de l'un de ses ID de transaction.
Livraison
Votre serveur a-t-il réellement remis les pièces, débloqué la fonctionnalité, démarré l'abonnement, et à quel moment ? Si cet appel a échoué, votre deliveryStatus correspond à l'une des valeurs UNDELIVERED et le remboursement est justifié. Ne discutez pas vos propres journaux.
Utilisation depuis
Sessions, chapitres ouverts, pièces dépensées, tout ce que « l'utiliser » signifie pour votre produit. Apple ne veut qu'un pourcentage, mais vous ne pouvez pas en produire un que vous sauriez défendre sans les événements qui le sous-tendent.
S'ils ont eu un avant-goût au préalable
C'est-à-dire un essai gratuit, un chapitre d'aperçu ou une offre gratuite. Apple le demande directement, et une réponse positive affaiblit l'argument du « je ne savais pas ce que j'achetais ».
Le compte de votre côté
Son ancienneté, si vous l'avez déjà remboursé auparavant, s'il existe un ticket d'assistance ouvert. Apple voit la moitié de cet historique côté App Store. Vous voyez la vôtre.
Tout cela dépend de la capacité à relier l'ID de transaction d'Apple à un utilisateur dans votre système, ce à quoi sert précisément appAccountToken. C'est la lacune la plus fréquente que nous constatons, et nous avons expliqué pourquoi appAccountToken compte pour la défense des remboursements si vous voulez les détails de mise en place.
Erreurs courantes des développeurs face aux demandes de remboursement Apple
La notification n'arrive jamais
Il n'y a pas d'URL de serveur dans App Store Connect, ou il y en a une, mais elle pointe vers un serveur de préproduction que quelqu'un a mis hors service en mars. Apple continue d'envoyer. Il n'y a personne pour répondre.
Répondre trop tard
Douze heures, ça paraît largement suffisant, jusqu'à ce qu'une demande arrive à 2 h du matin un dimanche et que la personne qui s'en occupe dorme, puis prenne un brunch, puis remarque vaguement un message Slack. Un processus calqué sur les horaires de bureau rate une partie des demandes par construction.
N'avoir rien à dire
La notification arrive et il n'y a ni journal de livraison, ni événements d'utilisation, ni appAccountToken. Apple décide en se fiant uniquement à la parole du client. Cette erreur a été commise des mois plus tôt, au moment du paiement.
Demander à Apple de tout refuser
Nous avons vu des configurations qui envoient DECLINE pour chaque demande, y compris celles où les propres journaux du développeur montrent que la livraison a échoué. Apple peut repérer ce schéma, et cela coûte de la crédibilité sur les demandes où vous avez réellement un dossier solide.
Oublier de révoquer après un remboursement accordé
C'est l'erreur qui coûte deux fois. L'argent est parti et le client a toujours le contenu, et certains s'en aperçoivent.
Tester en production
Apple vous fournit un endpoint de notification de test et des demandes de remboursement en sandbox. Utilisez les deux avant que la première demande réelle n'arrive à une heure inopportune.
Gestion des remboursements Apple : manuelle ou automatisée
La gestion des remboursements Apple couvre tout ce qui entoure cette fenêtre de 12 heures : réception de la demande, recherche des données, choix d'une préférence, envoi de la réponse, consignation du résultat, révocation si nécessaire.
Manuelle
En manuel, c'est une seule personne avec un accès aux journaux et une alerte. Cela fonctionne bien pour une poignée de demandes par mois, à condition que cette personne ne parte jamais une semaine en congé.
Autour de vingt par semaine, ça commence à déraper. À cent, c'est un emploi à temps plein, et personne n'en demande un.
Automatisée
En automatisé, la recherche et la réponse reposent sur des règles que vous avez écrites une fois pour toutes. Un consommable entièrement dépensé reçoit DECLINE, un FULFILLMENT_ISSUE avec une livraison échouée reçoit GRANT_FULL, et tout ce qui sort de l'ordinaire est signalé à une personne.
Les réponses partent en quelques minutes, aussi bien à 2 h du matin qu'à 14 h.
Le hic : l'automatisation ne vaut que ce que valent les données sur lesquelles elle s'appuie. Des registres de livraison et d'utilisation lacunaires ne font qu'envoyer plus vite un « inconnu ».
Quand les développeurs devraient-ils envisager un logiciel de gestion des remboursements Apple ?
Honnêtement, pas au début. Deux ou trois demandes par mois peuvent se gérer avec une checklist et une alerte sonore, et en traiter quelques-unes à la main vous apprend beaucoup.
Cela devient pertinent lorsque les demandes arrivent plus vite qu'une seule personne ne peut les traiter dans le délai imparti, ou à des heures où personne n'est réveillé. C'est aussi utile si vous gérez plusieurs applications, ou Apple et Google Play en parallèle, et que vous voulez une seule liste au lieu de trois.
Un logiciel de gestion des remboursements Apple se justifie dès que le processus manuel commence à laisser passer des demandes. Vous le saurez : ce sera la semaine où vous en ratez trois d'affilée et où vous ne l'apprenez qu'en voyant le versement.
Logiciel de défense des remboursements Apple : que doivent rechercher les développeurs ?
Si vous comparez des logiciels de défense des remboursements Apple, commencez par la mécanique interne : reçoit-il lui-même le CONSUMPTION_REQUEST et répond-il aux cas courants sans intervention humaine ? À quelle vitesse, y compris la nuit et le week-end ? Quelques minutes est la bonne réponse, et demandez à voir des horodatages.
Preuves
Peut-il récupérer ou recevoir vos données de livraison et d'utilisation, ou se contente-t-il de renvoyer la notification avec une préférence attachée ? Le second cas ne vaut pas grand-chose.
Il doit aussi être construit sur l'App Store Server API et Server Notifications V2, et non sur de l'analyse d'e-mails.
Visibilité
Des notifications lorsqu'une demande arrive, lorsqu'une réponse part, et lorsqu'Apple décide.
Un dossier par demande, avec la réponse et le résultat au même endroit.
Des rapports sur les taux de remboursement, les taux de réussite et les motifs, par application et par produit.
Une piste d'audit de qui, ou quoi, a envoyé quelle réponse, et quand.
Des règles que vous contrôlez, de sorte que modifier votre logique ne nécessite pas de déploiement.
Tarification
La tarification varie elle aussi : forfaits mensuels fixes, frais par demande et modèles basés sur un pourcentage des sommes récupérées ont chacun du sens selon le volume.
Une chose qu'aucun d'eux ne peut faire : empêcher les demandes de remboursement de survenir, ou garantir la décision d'Apple. Quiconque prétend le contraire essaie de vous vendre quelque chose.
Bonnes pratiques pour répondre aux demandes de remboursement Apple
Épinglez ceci à côté du planning d'astreinte.
Enregistrez une URL de serveur de production pour App Store Server Notifications V2, et déclenchez une alerte si elle cesse de répondre.
Définissez un appAccountToken sur chaque achat. Chaque achat.
Consignez la livraison avec un horodatage et un résultat, ainsi que la poignée d'événements d'utilisation qui signifient « il l'a utilisé ».
Intégrez dès maintenant le consentement au partage des données d'utilisation dans vos conditions.
Répondez à chaque demande dans les 12 heures, y compris celles où la réponse est « accordez-le ».
Ne demandez DECLINE que lorsque vos données le justifient. Apple repère les schémas récurrents.
Révoquez l'accès à chaque notification REFUND, le jour même.
Une fois par mois, vérifiez quelle part des demandes vous avez réellement traitée. Ce chiffre influence votre taux de remboursement plus que tout le reste.
Un logiciel de gestion des remboursements Apple en vaut-il la peine ?
À faible volume, probablement pas. Dès que les demandes dépassent ce qu'une seule personne peut traiter de façon fiable, ou commencent à arriver en dehors des heures de travail, un logiciel qui répond automatiquement se rentabilise généralement.
S'il y a une seule habitude à retenir de tout cela, c'est de répondre à chaque demande, avec de vraies données, avant la fin du délai. Dipsea, une application audio par abonnement, est passée d'un taux de remboursement de 3 % à 1.9 % en environ deux semaines après avoir commencé à répondre, sans jamais demander à Apple de refuser quoi que ce soit. Les applications qui restent silencieuses ne découvrent jamais ce qu'elles auraient pu conserver.
Questions fréquentes
Un client demande à Apple, généralement via reportaproblem.apple.com, le remboursement d'une application ou d'un achat intégré. Apple indique aux clients qu'ils recevront une réponse sous 24 à 48 heures. Pour les consommables et les abonnements, Apple demande d'abord des informations au développeur.
Vérifiez la notification, retrouvez l'achat dans vos propres registres, contrôlez la livraison et l'utilisation, choisissez une préférence, puis appelez le endpoint Send Consumption Information d'Apple dans un délai de 12 heures. Agissez ensuite en fonction de la décision d'Apple.
Non. Vous pouvez indiquer à Apple que vous préféreriez qu'il soit refusé et envoyer des données à l'appui. Apple garde néanmoins la décision finale, et il accorde parfois des remboursements que les développeurs avaient demandé de refuser.
Cinq éléments : le consentement du client au partage des données, si l'achat a été livré, quelle part en a été consommée, s'il a bénéficié d'un essai ou d'un échantillon gratuit, et votre préférence de remboursement. C'est l'intégralité du corps de requête actuel.
Douze heures à partir du CONSUMPTION_REQUEST. Apple indique qu'il faut répondre dans ce délai si vous voulez que vos données soient prises en compte dans la décision.
