Imaginez la scène. Un client achète votre forfait annuel, l'utilise pendant une semaine, puis demande à Apple d'être remboursé. Vous l'apprenez quand votre versement arrive, plus bas que prévu. Personne ne vous a rien demandé. Ou presque.
En réalité, Apple demande souvent. Il envoie à votre serveur un message appelé CONSUMPTION_REQUEST, et il veut savoir comment le client a réellement utilisé ce qu'il a acheté. Si votre serveur n'écoute pas, Apple décide sans vous. Ce guide détaille le processus de remboursement de l'App Store pour les développeurs, étape par étape, et met en évidence les points où les gens se bloquent. Pour un aperçu plus large de la défense contre les remboursements sur iOS, la page de défense contre les remboursements de l'App Store de RefundSensor couvre aussi ce sujet.
Réponse rapide
Une notification CONSUMPTION_REQUEST est la façon dont Apple demande des détails sur l'utilisation lorsqu'un client demande un remboursement. Si le client a accepté le partage de données, votre serveur doit appeler l'Axz`PI Send Consumption Information dans les 12 heures et signaler la livraison et l'utilisation. Apple pèse ces informations et prend la décision finale. Vous ne pouvez ni approuver un remboursement ni garantir le résultat.
Qu'est-ce que CONSUMPTION_REQUEST d'Apple ?
CONSUMPTION_REQUEST est un type de notification dans App Store Server Notifications V2. Apple l'envoie chaque fois qu'un client initie une demande de remboursement, et cela couvre tous les types de produits : consommables, non-consommables, abonnements non renouvelables et abonnements à renouvellement automatique.
Voyez cela comme une question, pas un ordre. Apple ne vous dit pas de rembourser qui que ce soit. Il vous demande ce que vous savez. Apple prend toujours la décision finale, et votre réponse n'est qu'un élément parmi d'autres qu'il examine.
Comment fonctionne le workflow de remboursement d'Apple
Deux choses se produisent ici, et on les confond souvent. Recevoir la notification est automatique. Renvoyer les informations de consommation ne se produit que si votre serveur le fait.
Le client demande un remboursement à Apple.
Apple publie un CONSUMPTION_REQUEST sur l'URL de notification V2 de votre serveur.
Votre serveur vérifie si ce client a accepté de partager ses données d'utilisation.
Si c'est le cas, votre serveur envoie les détails de consommation dans les 12 heures.
Apple prend sa décision. S'il accorde le remboursement, une notification REFUND suit.
Guide de mise en œuvre étape par étape
Voici la configuration de bout en bout.
Ajoutez votre URL de notification. Dans App Store Connect, saisissez l'URL HTTPS de votre serveur et choisissez la Version 2.
Répondez vite. Renvoyez un statut entre 200 et 206. Un 40x ou 50x pousse Apple à réessayer.
Vérifiez la signature. Les payloads V2 sont signés. Vérifiez-les avant de lire quoi que ce soit à l'intérieur.
Trouvez le client. Associez la transaction à un utilisateur dans votre propre base de données.
Vérifiez le consentement. Pas de consentement, pas de réponse.
Appelez l'API. Envoyez les données via une requête App Store Server API, authentifiée avec une clé In-App Purchase provenant d'App Store Connect.
Journalisez-le. Conservez un enregistrement de ce que vous avez envoyé et quand.
Comment répondre à une demande de remboursement Apple en tant que développeur
Commencez toujours par le consentement. Ensuite, dites à Apple ce qui s'est réellement passé. La valeur ici vient de données précises et honnêtes, alors ne les gonflez pas.
Prenons deux cas.
Un joueur achète un pack de pièces et en consomme la majeure partie en une journée. Signalez cette forte utilisation. Demander à Apple de refuser est une préférence légitime.
Un abonné paie pour un an, mais votre serveur était hors service et le contenu ne s'est jamais chargé. Signalez que le contenu n'a pas été livré. Ici, accorder le remboursement peut être la réponse honnête.
Votre préférence de remboursement est une suggestion. Apple n'est pas obligé de la suivre.
L'API Send Consumption Information d'Apple expliquée
Le point de terminaison Send Consumption Information est une requête PUT liée à un ID de transaction (/inApps/v2/transactions/consumption/{transactionId}). Vous l'appelez après la réception d'un CONSUMPTION_REQUEST, et Apple attend la réponse dans les 12 heures.
Le corps est un objet ConsumptionRequest comportant cinq champs :
customerConsented : le client a-t-il accepté de partager ses données ? Cela doit être true. Sinon, Apple rejette l'appel avec une erreur HTTP 400.
deliveryStatus : votre application a-t-elle livré un achat fonctionnel ?
sampleContentProvided : avez-vous proposé un échantillon ou un essai gratuit au préalable ?
consumptionPercentage : la quantité utilisée, en milliunités.
refundPreference : le résultat que vous souhaitez.
Quelques règles piègent les gens. Si deliveryStatus n'est pas DELIVERED, réglez consumptionPercentage sur 0, sinon la requête échoue. Pour un abonnement à renouvellement automatique avec GRANT_PRORATED, omettez consumptionPercentage, car Apple le calcule lui-même. Et le consentement, c'est à vous de le gérer. Apple précise aussi de ne pas utiliser l'invite App Tracking Transparency pour cela.
Intégration d'App Store Server Notifications V2
App Store Server Notifications V2 est le moyen par lequel Apple contacte votre serveur. Vous aurez besoin d'une URL HTTPS sécurisée prenant en charge TLS 1.2 ou version ultérieure.
CONSUMPTION_REQUEST n'est que l'un des nombreux types. D'autres, comme REFUND et REFUND_REVERSED, vous indiquent comment un dossier s'est terminé. Donnez à chaque type son propre gestionnaire afin que le code de remboursement ne s'emmêle pas avec le code de renouvellement. Vous voulez voir le côté App Store Connect en action ? Le guide de configuration Apple de Refund Sensor couvre les clés et l'URL de notification.
Erreurs courantes à éviter
S'arrêter à la notification. Un CONSUMPTION_REQUEST ne fait rien jusqu'à ce que votre serveur renvoie des données.
Ignorer le consentement. Sans accord du client, pas de réponse.
Rater les 12 heures. Ces notifications arrivent la nuit et le week-end. Utilisez une file d'attente et configurez des alertes.
Envoyer des combinaisons incohérentes. Un pourcentage d'utilisation sur un achat non livré échouera.
Sauter la vérification de la signature. Vérifiez d'abord, faites confiance ensuite.
Répondre trop lentement. Renvoyez rapidement un code de succès et effectuez le travail lourd en arrière-plan, sinon Apple continue de réessayer.
Aucun moyen de retrouver l'utilisateur. Si vous ne pouvez pas associer une transaction à un client, vous n'avez rien de concret à signaler.
Comment automatiser les workflows de remboursement de l'App Store
Personne ne veut surveiller un compte à rebours de 12 heures à la main. Si vous voulez automatiser les workflows de remboursement de l'App Store, découpez la tâche en petites étapes :
Acceptez la notification et renvoyez immédiatement un code de succès.
Déposez l'événement dans une file d'attente.
Un worker le vérifie, retrouve l'utilisateur et vérifie le consentement.
Le worker construit la requête à partir des données d'utilisation stockées et appelle l'API.
Journalisez le résultat et alertez quelqu'un en cas d'échec.
Vous obtenez des réponses cohérentes, une piste d'audit claire, et personne n'est réveillé à 3 h du matin. Vous pouvez construire cela vous-même, ou confier le pipeline à un service comme RefundSensor.
Bonnes pratiques pour les développeurs
Stockez de vraies données d'utilisation : sessions, crédits dépensés, contenu ouvert. Vous ne pouvez pas signaler des chiffres que vous n'avez jamais conservés.
Ajoutez une étape de consentement claire à vos conditions ou à votre onboarding, et enregistrez le moment où il a été donné.
Écrivez vos règles de remboursement une fois pour toutes et intégrez-les dans le code, plutôt que de décider au cas par cas.
Testez avec des notifications sandbox avant la mise en production.
Associez un jeton de compte à chaque achat afin de pouvoir identifier l'acheteur plus tard. Ce guide appAccountToken explique comment faire.
Passez en revue les résultats des remboursements une fois par mois. Des pics inhabituels peuvent indiquer une fonctionnalité défaillante ou un paywall confus.
Conclusion
Le workflow de remboursement d'Apple se résume à deux moitiés. Apple envoie le CONSUMPTION_REQUEST, et vous choisissez d'y répondre ou non. Si le client a consenti, envoyez des données honnêtes via l'API Send Consumption Information dans les 12 heures. Apple décide toujours.
Une bonne première étape : vérifiez que votre URL de notification V2 est active et que votre serveur peut associer une transaction à un utilisateur. Ces deux vérifications évitent bien des maux de tête par la suite.
Questions fréquentes
Un message V2 qu'Apple envoie lorsqu'un client demande un remboursement. Il vous demande des détails sur l'utilisation.
Apple demande une réponse dans les 12 heures suivant la notification.
Oui. Sans cela, ne répondez pas. Une requête dont le champ customerConsented n'est pas défini sur true est rejetée.
Pas nécessairement. Apple utilise vos données pour éclairer sa décision, mais c'est elle qui tranche.
Les consommables, les non-consommables, les abonnements non renouvelables et les abonnements à renouvellement automatique.
