Remboursement App Store : ce que voit le développeur

Sur l'App Store, c'est Apple qui accorde ou refuse un remboursement, jamais le développeur. Le client fait sa demande sur le site d'Apple ou depuis ton app. Si tu as branché les notifications serveur d'Apple, tu reçois une notification CONSUMPTION_REQUEST au moment de la demande, puis REFUND ou REFUND_DECLINED à la décision. Entre les deux, tu as 12 heures pour envoyer des données de consommation et ta préférence, à condition que le client y ait consenti.

Un remboursement accordé retire l'achat des droits actifs du client et apparaît en négatif dans tes rapports de ventes. Ce guide détaille chaque étape, ce que tu peux envoyer à Apple, et ce que tu as le droit de faire contre les demandes abusives. Les règles viennent des pages d'Apple relues le 3 novembre 2026. Le cas réel vient d'une alerte que j'ai branchée sur mes apps en octobre.

Qui décide d'un remboursement App Store ?

Apple, et Apple seul. La page d'assistance d'Apple décrit le parcours du client : il se connecte à reportaproblem.apple.com, choisit « Request a refund », indique un motif, puis l'achat concerné. Apple lui conseille d'attendre 24 à 48 heures pour avoir une réponse.

Le client peut aussi demander un remboursement depuis ton app. StoreKit propose pour cela une feuille de demande, disponible depuis iOS 15. Apple conseille de l'appeler depuis les réglages du compte ou un menu d'aide. Elle affiche l'achat et une liste de motifs, et Apple prend jusqu'à 48 heures pour trancher.

Dans les deux cas, tu n'as rien à valider. Tu peux seulement donner des informations et une préférence, qui comptent parmi plusieurs critères dans la décision d'Apple.

Ce que voit chacun, étape par étape

Étape	Côté client	Côté développeur
Demande	Formulaire d'Apple ou feuille dans l'app	Notification CONSUMPTION_REQUEST
Dans les 12 heures	Attente	Envoi possible des données de consommation
Sous 48 heures	Réponse d'Apple	Notification REFUND ou REFUND_DECLINED
Après un accord	Argent rendu sur son moyen de paiement	Achat retiré des droits actifs, unités négatives
Après une contestation	Remboursement annulé par Apple	Notification REFUND_REVERSED, accès à rétablir

App Store Connect ne te montre que les remboursements déjà accordés, dans Sales and Trends. La demande elle‑même n'arrive que par les notifications serveur. Sans elles, tu découvres le remboursement après coup.

Les notifications serveur d'un remboursement

Les App Store Server Notifications V2 envoient cinq types utiles ici. Tu les reçois sur l'adresse HTTPS déclarée dans App Store Connect, une pour la production et une pour la sandbox.

Notification	Ce qu'elle annonce	Ce que tu fais
CONSUMPTION_REQUEST	Le client demande un remboursement	Répondre sous 12 heures, si consentement
REFUND	Apple a remboursé la transaction	Retirer le contenu ou l'accès remboursé
REFUND_DECLINED	Apple a refusé la demande	Rien, l'accès continue
REFUND_REVERSED	Apple annule un remboursement après une contestation du client	Rétablir ce que tu avais retiré
REVOKE	Un achat partagé en Partage familial n'est plus disponible	Retirer l'accès au membre de la famille

Ton serveur doit répondre avec un code HTTP entre 200 et 206. D'après la page sur les réponses aux notifications, Apple réessaie sinon cinq fois, 1, 12, 24, 48 puis 72 heures après la tentative précédente. En sandbox, il n'envoie qu'une fois.

La Consumption API : ce que tu peux dire à Apple

Quand la demande arrive, tu peux répondre avec Send Consumption Information. La règle tient en une phrase d'Apple : « Respond within 12 hours of receiving the CONSUMPTION_REQUEST notification. » La version 2 de l'API vaut pour tous les types de produits, abonnements compris.

Les champs de la requête :

Champ	Obligatoire	Ce qu'il dit à Apple
customerConsented	Oui	Le client a consenti au partage de ses données
deliveryStatus	Oui	L'achat a été livré et fonctionne, ou pourquoi il ne l'a pas été
sampleContentProvided	Oui	Un essai, un extrait ou une description était offert avant l'achat
consumptionPercentage	Non	La part consommée, de 0 à 100 000 pour 0 à 100 %
refundPreference	Non	Ta préférence : DECLINE, GRANT_FULL ou GRANT_PRORATED

Deux précisions comptent. Si deliveryStatus n'est pas DELIVERED, la part consommée doit valoir zéro. Et pour un remboursement au prorata d'un abonnement, tu omets la part consommée : Apple la calcule.

Le consentement est la condition de tout. Apple écrit : « You must obtain valid consent from the customer before sharing their personal data with Apple in the Send Consumption Information API. » Sans consentement, tu ne réponds pas. Apple interdit aussi d'utiliser la fenêtre de suivi publicitaire pour recueillir ce consentement : « Don't use the AppTrackingTransparency prompt to obtain consent ».

Si tu passes par RevenueCat

Avec RevenueCat, c'est lui qui reçoit les notifications d'Apple et qui répond à la demande, avec Refund Control. Tu choisis une politique parmi quatre : préférer un remboursement complet, préférer un refus, envoyer seulement les données de consommation, ou ne pas répondre.

Activer le partage des données revient à confirmer que tu as le consentement de tes clients. RevenueCat le dit lui‑même : « Enabling consumption data sharing confirms that you obtained consent from your Customers. » Il conseille aussi de réserver « Prefer no refund » à un groupe ciblé, et prévient quand cette préférence touche la plupart de tes clients.

Pour recevoir aussi les notifications sur ton propre serveur, RevenueCat propose un champ « Apple Server Notification Forwarding URL » dans les réglages de l'app. Il est décrit dans sa page sur les notifications d'Apple. C'est ce que j'utilise. Le montage d'un abonnement avec RevenueCat est dans RevenueCat et l'abonnement in-app iOS.

L'effet sur tes revenus et sur l'abonnement

Sur l'accès. D'après la documentation de currentEntitlements, « Products that the App Store has refunded or revoked don't appear in the current entitlements ». Si ton app vérifie les droits avec currentEntitlements, l'accès remboursé disparaît de lui‑même. La transaction porte la date et le motif du retrait, dans revocationDate et revocationReason.

Sur les rapports. D'après l'aide du rapport de ventes, un remboursement apparaît avec des unités et un prix client négatifs. Pour les abonnements, la page sur les données d'abonnement compte les remboursements complets et partiels parmi les événements, et les retire des unités quotidiennes.

Sur ta réputation. La guideline 5.6.4 cite les demandes de remboursement excessives parmi les signes d'une qualité insuffisante. Un taux de remboursement élevé n'est pas qu'une perte d'argent : Apple peut en tenir compte pour juger ton respect du code de conduite.

Mon cas : l'alerte branchée sur mes apps

Le 12 octobre 2026, j'ai branché une alerte sur mes apps. RevenueCat transmet les notifications d'Apple à une route de devoria.fr. Elle vérifie la signature d'Apple, puis m'envoie une alerte, sans montant. Je voulais voir la demande au moment où elle arrive, pas seulement le résultat.

Le 18 octobre, la première vraie demande est arrivée sur TradaZen, mon simulateur de trading. Un abonnement annuel, payé à la fin d'un essai gratuit de 7 jours. Motif indiqué : un achat involontaire. Trois leçons :

1. La même demande peut arriver plusieurs fois. J'ai reçu trois fois la même alerte le même soir. Depuis, chaque alerte est dédupliquée sur le type de notification et l'identifiant de transaction.
2. La décision est arrivée en moins d'une journée. Apple a refusé environ 22 heures après la demande. Le client a gardé son accès.
3. Un refus n'est pas la fin. Le même client a refait une demande deux jours plus tard, sur la même transaction.

Une demande pour « achat involontaire » à la fin d'un essai ne se gagne pas dans la réponse à Apple. Elle se prévient sur le paywall, avant le premier paiement.

Limiter les demandes abusives sans enfreindre les règles

Ce qui est permis :

• Répondre à chaque demande avec des données exactes, quand le client a consenti.
• Exprimer une préférence ciblée, par exemple un refus pour un achat déjà consommé, plutôt qu'un refus pour tout le monde.
• Relier chaque REFUND à un compte client. La page d'Apple sur les notifications de remboursement le recommande pour repérer les remboursements répétés.
• Dire clairement ce qu'on achète avant l'achat. La guideline 3.1.2(c) demande de décrire ce que l'utilisateur obtient pour le prix, avant de lui proposer de s'abonner.

Ce qui est interdit :

• Envoyer des données fausses pour faire refuser une demande, ou répondre sans consentement.
• Recueillir le consentement par la fenêtre de suivi publicitaire, ce qu'Apple exclut en toutes lettres.
• Piéger l'achat. La guideline 5.6 interdit de pousser les clients à des achats non voulus ou de facturer ce qui n'est pas livré.
• Faire pression sur un client qui demande un remboursement. La même règle exige le respect dans le service client, sans intimidation.

Le meilleur levier reste en amont : un paywall qui dit le prix, la date du premier paiement et la façon d'annuler. Les erreurs à éviter sont dans les erreurs de paywall, et les règles de l'essai dans l'essai gratuit sur l'App Store.

Tester avant la production

D'après la page sur le test des demandes, la sandbox et les tests StoreKit d'Xcode acceptent les demandes de remboursement. En sandbox, n'importe quel motif déclenche un accord automatique. Pour simuler un refus, choisis « Other » et tape DECLINE. Pour un remboursement au prorata, tape GRANT_PRORATED. En sandbox, ta réponse de consommation doit partir dans les cinq minutes.

Un abonnement qui se rembourse moins

Le Kit iOS part du code de mes apps, avec l'onboarding, le paywall et les abonnements déjà codés, et suit quatre étapes jusqu'à l'App Store, à ton rythme. Le montage complet est détaillé sur la page abonnement in-app iOS, et les règles d'Apple sur l'abonnement dans la guideline 3.1.2.

Avant de lancer ton paywall, fais ton diagnostic gratuit : il te dit ce qui bloque vraiment ton projet et t'envoie ma checklist anti-refus Apple.

Questions fréquentes

Le développeur peut-il refuser un remboursement App Store ?

Non. Apple décide seul. Tu peux envoyer des données de consommation et une préférence, DECLINE par exemple, qui comptent parmi plusieurs critères. Apple garde le dernier mot.

Le développeur est-il prévenu d'une demande de remboursement ?

Oui, s'il a branché les App Store Server Notifications V2. Apple envoie CONSUMPTION_REQUEST au moment de la demande, puis REFUND ou REFUND_DECLINED à la décision. Sans notifications, tu ne vois que les remboursements accordés, dans tes rapports.

Combien de temps Apple met-il à traiter une demande de remboursement ?

Apple annonce 24 à 48 heures au client. La documentation de StoreKit parle de 48 heures au plus. De ton côté, tu as 12 heures pour envoyer les données de consommation.

Que se passe-t-il pour l'accès après un remboursement ?

L'achat remboursé sort des droits actifs du client : StoreKit 2 ne le renvoie plus dans currentEntitlements. Si Apple annule ensuite le remboursement, tu reçois REFUND_REVERSED et tu dois rétablir l'accès.

Faut-il le consentement du client pour répondre à Apple ?

Oui. Apple exige un consentement valide avant tout partage de données par la Consumption API. Sans lui, tu ne réponds pas à la notification. La fenêtre de suivi publicitaire ne peut pas servir à le recueillir.

Les remboursements comptent-ils contre mon app ?

Ils peuvent. La guideline 5.6.4 cite les demandes de remboursement excessives parmi les signes d'une qualité insuffisante, qu'Apple peut prendre en compte pour juger le respect du code de conduite.