Gérer les demandes de remboursement App Store (et la consumption request)

Sur l’App Store, vous ne remboursez jamais vous-même un abonnement et vous ne répondez jamais à un litige sur carte. C’est Apple le marchand : il encaisse le paiement, décide des remboursements et traite avec la banque du client. Ce que vous pouvez faire est plus restreint mais reste utile : dire à Apple comment le client a réellement utilisé ce qu’il a payé, réagir correctement quand un remboursement passe et repérer les abus récurrents.

Ce guide couvre ce processus pour les abonnements auto-renouvelables. Il s’en tient à la documentation d’Apple, principalement Send Consumption Information, le corps ConsumptionRequest, la référence notificationType et Get Refund History (tous consultés en novembre 2026).

Comment les clients demandent un remboursement

Le guide d’Apple sur le traitement des notifications de remboursement liste les façons dont un client peut demander à être remboursé :

• en contactant l’assistance Apple ;
• en utilisant le site en libre-service d’Apple, reportaproblem.apple.com ;
• en demandant un remboursement à l’émetteur de son moyen de paiement.

Il existe une quatrième voie que vous maîtrisez : votre app peut ouvrir la feuille de remboursement d’Apple avec beginRefundRequest(in:) de StoreKit. Apple suggère de l’appeler depuis les réglages du compte ou un menu d’aide. La feuille montre l’achat et une liste de raisons, et la documentation d’Apple indique que l’App Store met jusqu’à 48 heures pour accepter ou refuser la demande.

Quelle que soit la voie, la décision revient à Apple. Vous n’avez aucun bouton pour accepter ou refuser.

Les notifications que vous recevrez

Si vous avez mis en place les App Store Server Notifications V2, les remboursements produisent un petit nombre d’événements :

Notification	Ce qu’elle signifie
CONSUMPTION_REQUEST	Un client a lancé une demande de remboursement et Apple vous demande des données de consommation
REFUND	Apple a remboursé une transaction
REFUND_DECLINED	Apple a refusé une demande de remboursement
REFUND_REVERSED	Apple a annulé un remboursement accordé, à cause d’un litige ouvert par le client
DID_CHANGE_RENEWAL_STATUS avec AUTO_RENEW_DISABLED	Entre autres cas, le système a désactivé le renouvellement automatique parce que le client a demandé un remboursement depuis votre app
REVOKE	L’accès via le Partage familial ou un groupe a pris fin, par exemple parce que l’acheteur a été remboursé

Le contenu de CONSUMPTION_REQUEST comporte un consumptionRequestReason avec la raison donnée par le client. Apple documente cinq valeurs : UNINTENDED_PURCHASE, FULFILLMENT_ISSUE, UNSATISFIED_WITH_PURCHASE, LEGAL et OTHER. Enregistrez-la. Avec le temps, elle vous dit si les remboursements viennent d’achats accidentels, de bugs ou de gens qui n’ont tout simplement pas aimé le produit.

Répondre à la consumption request

Apple dit utiliser « divers facteurs » pour décider d’un remboursement, et que les informations de consommation que vous envoyez en font partie. C’est votre seul moyen de mettre des faits sous les yeux de la personne qui examine la demande.

Les règles

La documentation d’Apple est stricte sur trois points :

1. Le consentement d’abord. Vous ne pouvez envoyer des données que si le client a accepté de les partager avec Apple. Sinon, Apple dit de ne pas répondre du tout à la CONSUMPTION_REQUEST. Le serveur rejette toute requête où customerConsented n’est pas true avec une erreur HTTP 400.
2. 12 heures. Répondez dans les 12 heures suivant la réception de la notification.
3. Le consentement est votre affaire. Apple précise que vous êtes « seul responsable de l’obtention d’un consentement valable », qu’il doit être libre, spécifique, éclairé et univoque, et que vous ne devez pas utiliser la demande App Tracking Transparency pour cela. Si vous adoptez l’API, vous devez aussi déclarer cet usage des données dans les informations de confidentialité de votre app.

La requête

Vous appelez PUT https://api.storekit.apple.com/inApps/v2/transactions/consumption/ suivi de l’ID de transaction de la notification. Le corps ConsumptionRequest a cinq champs :

Champ	Ce qu’il faut y mettre
customerConsented	true, la seule valeur qu’Apple accepte
deliveryStatus	DELIVERED, ou l’une de UNDELIVERED_QUALITY_ISSUE, UNDELIVERED_WRONG_ITEM, UNDELIVERED_SERVER_OUTAGE, UNDELIVERED_OTHER
consumptionPercentage	La part consommée, en millièmes. Doit valoir 0 si l’article n’a pas été livré
refundPreference	Facultatif : GRANT_FULL, GRANT_PRORATED ou DECLINE
sampleContentProvided	Si vous avez proposé un échantillon gratuit, un essai ou une description des fonctionnalités avant l’achat

Pour les abonnements auto-renouvelables, une contrainte compte : si vous choisissez GRANT_PRORATED, n’envoyez pas consumptionPercentage. Apple calcule lui-même le pourcentage pour les abonnements.

Choisir quoi dire

Soyez honnête, parce que c’est la bonne chose à faire et parce qu’Apple a de toute façon le dernier mot. Un jeu de règles simple :

• L’app a failli (panne, fonctionnalité cassée, contenu jamais débloqué) : mettez le statut UNDELIVERED_* correspondant, une consommation de 0 et GRANT_FULL. Se battre contre un remboursement pour quelque chose qui n’a pas marché ne sert à rien.
• Achat accidentel, sans usage : DELIVERED, une consommation nulle ou presque, et GRANT_FULL ou aucune préférence.
• Usage réel et soutenu sur la période : DELIVERED et DECLINE ou GRANT_PRORATED, selon votre politique.
• Essai gratuit avant la période payante : mettez sampleContentProvided à true.

Les chiffres doivent venir de vos propres données d’usage, mesurées de la même façon pour chaque client. Il vous faut donc un usage relié à la transaction App Store, ce qui en pratique veut dire définir un appAccountToken à l’achat pour rattacher la transaction d’Apple à votre utilisateur.

Quand un remboursement passe

Une notification REFUND veut dire que l’argent est parti. La référence des notifications d’Apple indique que le revocationDate de la transaction contient l’horodatage du remboursement et revocationReason sa raison. Il existe deux valeurs de raison :

• 0 : remboursé pour d’autres raisons, par exemple un achat accidentel ;
• 1 : remboursé à cause d’un problème réel ou perçu dans votre app.

Étapes pratiques :

1. Retirez l’accès pour la transaction remboursée, et dites-le dans l’app avec un court message. Le guide d’Apple recommande « des messages contextuels dans l’app pour toute action que vous prenez à la suite du remboursement ».
2. Enregistrez la raison. Une part croissante de raison 1 est un signal produit, pas un signal de facturation.
3. Surveillez les annulations de remboursement. Si un REFUND_REVERSED arrive, Apple dit que vous devez rétablir le contenu ou le service. Pour les abonnements auto-renouvelables, la date de renouvellement ne change pas.
4. Rattrapez les événements manqués. Get Refund History renvoie les remboursements approuvés par l’App Store pour un client, 20 par page, et Apple le suggère pour récupérer les notifications de remboursement manquées pendant une panne.

Et les chargebacks ?

Les clients peuvent demander un remboursement à leur banque émettrice, mais sur l’App Store le litige oppose la banque et Apple. Vous ne recevrez pas de demande de preuves et il n’y a rien à soumettre. Ce que vous verrez, c’est le résultat : un REFUND si l’argent est reparti, et REFUND_REVERSED si Apple a annulé un remboursement après un litige du client.

Le « travail sur les chargebacks » pour une app iOS relève donc surtout de la prévention et de la détection :

• Rendez le chemin de remboursement dans votre app facile à trouver (la feuille beginRefundRequest), pour que les clients mécontents l’utilisent plutôt que leur banque.
• Répondez à chaque consumption request à laquelle vous avez le droit de répondre, dans les temps.
• Rattachez les remboursements aux comptes. Le guide d’Apple suggère de rattacher les notifications REFUND à vos comptes utilisateurs pour « repérer les achats remboursés à répétition » et les activités suspectes.

Erreurs fréquentes

• Envoyer des données sans consentement. L’API les rejette et cela enfreint les règles d’Apple.
• Rater la fenêtre de 12 heures. Traitez CONSUMPTION_REQUEST dans une file avec une alerte, pas dans un traitement de nuit.
• Toujours envoyer DECLINE. Votre préférence n’est qu’un facteur, et revendiquer un usage que vous ne pouvez pas étayer n’aide pas.
• Ne pas retirer l’accès après un remboursement, ou ne pas le rétablir après une annulation de remboursement.
• Aucun lien entre les transactions Apple et vos utilisateurs. Sans appAccountToken, vous ne pouvez pas mesurer la consommation, et vous ne pouvez pas répondre.

Le faire avec NoChurn

NoChurn lit vos App Store Server Notifications, donc les demandes de remboursement, les remboursements, les refus et les annulations de remboursement apparaissent sur la chronologie de chaque client avec la raison donnée par Apple. Quand Apple envoie une consumption request pour un client qui a donné son accord, NoChurn peut y répondre avec l’usage réel de ce client tiré de vos données, dans la fenêtre d’Apple. Les remboursements alimentent aussi le score de churn. Apple garde le paiement, la décision de remboursement et tout ce qui touche à la banque du client ; NoChurn ne prétend jamais le contraire. La mise en place et les limites sont sur NoChurn + App Store.