La politique de remboursement de l'App Store expliquée aux développeurs d'apps mobiles

C'est Apple qui décide si un remboursement est accordé. Ce que la politique vous laisse, c'est tout ce qui se passe autour de cette décision, et c'est là que se concentre l'essentiel des pertes évitables.

On entend souvent une variante de cette histoire. Un utilisateur demande un remboursement à Apple en mars. Apple accepte. Le serveur du développeur n'en est jamais informé. En juin, ce même utilisateur utilise toujours la version payante de l'app. Personne ne s'en aperçoit avant que la finance fasse une vérification en fin de trimestre, et même là, il faut du temps pour comprendre ce qui s'est passé. Le remboursement figure dans un rapport de versement. L'enregistrement d'accès se trouve dans la base de données de l'app. Les deux ne communiquent jamais.

C'est ainsi que la plupart des développeurs découvrent la politique de remboursement de l'App Store. Pas en la lisant, mais en constatant, des mois plus tard, tout ce qu'elle n'a jamais couvert.

Voici ce que la politique ne dit pas explicitement. Apple qui annule un paiement et votre app qui retire l'accès sont deux événements distincts. Apple gère le premier. Vous gérez le second. C'est dans l'écart entre les deux que les développeurs perdent discrètement de l'argent, mois après mois. L'essentiel de cet article porte sur la façon de combler cet écart.

Ce billet examine donc la politique du point de vue du développeur : ce qu'Apple contrôle, ce qui vous incombe, et ce que vos systèmes doivent faire une fois qu'un remboursement est accordé. Si vous préférez l'aspect pratique à la politique elle-même, notre guide sur la gestion des remboursements App Store sans perdre de revenus d'app mobile couvre ce point.

Points clés

● Apple prend chaque décision de remboursement. Il n'existe aucun bouton dans App Store Connect pour approuver ou refuser un remboursement, parce que ce choix n'a jamais appartenu au développeur.

● Le lieu de résidence du client peut changer le résultat. L'éligibilité et la procédure varient selon le pays ou la région, conformément aux Conditions générales des Services multimédias d'Apple.

● Apple peut envoyer des notifications liées aux remboursements à votre serveur, et peut demander des informations sur l'utilisation d'un achat pendant qu'il examine une demande.

● Vous disposez de 12 heures pour répondre, et uniquement si le client a autorisé le partage de ces informations.

● Un remboursement approuvé par Apple et un remboursement enregistré dans votre base de données sont deux événements distincts. C'est dans l'espace entre les deux que l'argent s'échappe.

● L'automatisation peut rendre votre partie du processus plus rapide et plus cohérente. Elle n'a aucun effet sur la décision d'Apple.

Qu'est-ce que la politique de remboursement de l'App Store ?

En résumé, c'est l'ensemble des règles selon lesquelles Apple traite la demande de remboursement d'un client, plus une liste de tâches techniques qui retombent sur le développeur.

Apple décide si un remboursement est approuvé. Vous n'avez pas voix au chapitre. Vous ne pouvez ni approuver une demande, ni la bloquer. App Store Connect n'a aucun écran où un développeur vote sur ce point. Tout ce que vous pouvez faire, c'est envoyer certaines informations à Apple à quelques étapes du parcours, et nous y reviendrons bientôt. Si vous voulez voir comment les clients soumettent concrètement une demande, c'est décrit dans le guide d'Apple pour demander le remboursement d'apps ou de contenu.

Nous découpons généralement la politique en quatre parties pour les équipes, parce que seules deux des quatre vous concernent vraiment.

La première partie, c'est l'éligibilité. Les demandes vont directement à Apple, jamais à vous. L'éligibilité peut varier selon le pays ou la région du client, et les règles figurent dans les Conditions générales des Services multimédias Apple. Donc si un utilisateur demande pourquoi son remboursement a été accepté alors que celui d'un ami ne l'a pas été, il n'y a pas de réponse simple. Tout dépend de l'endroit où chacun d'eux vit.

La deuxième partie, c'est la décision elle-même. Elle appartient entièrement à Apple. Vous ne l'apprenez qu'une fois qu'elle est prise.

La troisième partie, ce sont vos responsabilités, et elles sont techniques, pas juridiques, ce qui surprend presque à chaque fois. Faire tourner un serveur capable de recevoir des notifications. Fournir des informations quand Apple les demande. Tenir des enregistrements propres. C'est là tout le travail.

La quatrième partie, c'est ce qu'il advient des droits d'accès après la décision, et c'est la pièce qui coûte réellement de l'argent. Apple qui annule un paiement ne change rien, en soi, dans votre propre base de données. Un client remboursé qui conserve indéfiniment son accès payant n'est pas un échec de la politique d'Apple. C'est une faille dans la façon dont votre système a été conçu.

Vous devinez sans doute quelle partie compte le plus à nos yeux.

Comment fonctionne le processus de remboursement de l'App Store pour les développeurs ?

C'est le client qui le lance. Apple le termine. Vous vous situez quelque part au milieu.

Le client demande un remboursement via Apple

↓

Apple examine la demande

↓

Votre serveur peut recevoir une notification liée au remboursement

↓

Vous fournissez des informations complémentaires, le cas échéant

↓

Apple prend sa décision

↓

Vous recevez le résultat sous forme de notification

↓

Les droits d'accès sont mis à jour

Deux points à surveiller ici. Apple indique aux clients qu'ils recevront une réponse sous 24 à 48 heures environ, et ce délai n'a rien à voir avec le vôtre, alors faites attention à ce que votre équipe support promet pendant qu'une demande est en attente. Et chaque étape ci-dessus ne fonctionne que si votre serveur est réellement configuré et joignable. Beaucoup d'équipes découvrent que le leur ne l'était pas. Si votre endpoint est hors service, le remboursement a quand même lieu. Vous n'en entendez simplement jamais parler.

Que signifient les règles de remboursement de l'App Store pour les développeurs ?

Retirez le jargon de la politique, et les règles se transforment en une courte checklist, assez peu glamour, pour votre équipe d'ingénierie.

● Des enregistrements de transactions réellement consultables. Les notifications de remboursement font référence aux identifiants de transaction d'Apple. Si vous ne les avez pas sauvegardés au moment de l'achat, la notification est quasiment inutile. Vous avez aussi besoin d'un lien fiable entre chaque transaction et un compte utilisateur, puisque le payload d'Apple identifie l'achat, pas la personne qui l'a effectué.

● Un endpoint de notifications qui fonctionne et vérifie les signatures. Les événements de remboursement arrivent via les App Store Server Notifications, et les payloads sont signés. Vérifiez ces signatures à chaque fois. Un endpoint qui fait confiance à tout ce qu'on lui envoie est un risque de sécurité doté d'une URL.

● Un flux de consentement, mis en place à l'avance. Si Apple demande des informations de consommation, vous n'êtes autorisé à répondre que si le client a déjà accepté de partager ces données. Cette responsabilité vous revient. La documentation Send Consumption Information d'Apple est claire à ce sujet, et toute réponse envoyée sans consentement est rejetée. Vous ne pouvez pas non plus revenir en arrière pour recueillir le consentement une fois qu'une demande est déjà arrivée. Soit vous l'aviez au moment de l'achat, soit vous passez votre tour.

● Une logique de droits d'accès qui fonctionne dans les deux sens. Les remboursements sont parfois annulés. Apple autorise aussi les remboursements partiels, où seule une partie de l'achat est restituée. Complet, partiel ou annulé, votre code doit gérer les trois cas.

● Un endroit où les résultats atterrissent et que la finance peut réellement exploiter. Un remboursement qui n'existe que dans la base de données de l'app ne correspondra jamais à un rapport de versement. La plupart des équipes le découvrent à la clôture du trimestre, et c'est rarement une bonne journée.

Quel est l'impact de la politique de remboursement d'Apple sur les développeurs ?

Tout le monde se concentre sur le montant remboursé. C'est généralement le chiffre le plus petit de l'histoire.

Une période d'abonnement remboursée reprend des revenus que vous aviez déjà comptabilisés, et dans la plupart des cas, la relation s'arrête là aussi. Les renouvellements que vous attendiez cessent discrètement d'apparaître. Les achats uniques sont plus simples, mais ils arrivent quand même après la vente, donc tout reporting basé sur des chiffres bruts sera surestimé tant que les remboursements ne sont pas déduits.

Voici la distinction à retenir de tout cet article. Un remboursement approuvé par Apple et un remboursement réellement enregistré par votre système sont deux événements distincts. La moitié d'Apple se produit selon son propre calendrier, que quelqu'un regarde ou non. Votre moitié ne se produit que si le handler de notification s'est déclenché, si la transaction a été retrouvée, si le compte a été identifié et si l'accès a été mis à jour. Qu'un seul de ces maillons manque et le travail n'est fait qu'à moitié, et de l'extérieur, personne ne peut dire quelle moitié.

Cet écart a un nom : la fuite de remboursements. Ce sont des clients qui ont récupéré leur argent et gardé tout ce qu'ils avaient payé. Ils ne le signaleront pas, parce que de leur point de vue, rien ne cloche. Cela apparaît des mois plus tard lors du rapprochement, si cela apparaît un jour.

Tout le reste découle de ce même écart. Des agents support qui répondent aux tickets sans aucun enregistrement de remboursement à consulter. Des analyses qui surestiment la valeur vie client parce que les annulations n'ont jamais été intégrées aux chiffres. Aucun historique de remboursements à consulter, donc personne ne remarque qu'un produit génère bien plus de remboursements que les autres.

Que doivent faire les développeurs lorsqu'un remboursement Apple est demandé ?

Sept étapes. L'essentiel du travail se fait bien avant qu'une demande n'arrive.

1. Recevoir et vérifier la notification

Les événements de remboursement arrivent sur votre endpoint sous forme de payloads JWS signés. Vérifiez la signature par rapport à la chaîne de certificats d'Apple. Confirmez le bundle ID. Ce n'est qu'ensuite que vous agissez sur le contenu. C'est de l'hygiène de base, et des équipes sautent encore cette étape. Un endpoint qui accepte tout ce qu'on lui donne est un endpoint dont quelqu'un d'autre peut profiter.

2. Retrouver la transaction et le compte

Prenez les identifiants de transaction du payload et faites-les correspondre à vos enregistrements d'achat. Si vous avez associé un jeton de compte stable au moment de l'achat, c'est une simple recherche. Sinon, vous devinez sous pression.

3. Vérifier ce que vous savez déjà de l'achat

Vous ne pouvez rien dire d'utile à Apple tant que vous ne savez pas ce que vos propres systèmes ont enregistré. Le contenu a-t-il été livré ? A-t-il fonctionné comme prévu ? Quelle part le client a-t-il réellement utilisée ? Si vous ne pouvez pas répondre à ces questions à partir de vos propres enregistrements, c'est là votre premier vrai problème, et ce n'est pas le remboursement.

4. Envoyer les informations de consommation quand Apple les demande et que le consentement existe

Une notification CONSUMPTION_REQUEST d'Apple signifie que vous pouvez répondre avec des informations sur l'utilisation de l'achat, mais seulement si deux conditions sont réunies : le client a donné un consentement valide, et vous êtes encore dans la fenêtre de 12 heures fixée par Apple. La documentation actuelle d'Apple associe cette notification aux demandes de remboursement pour tous les types de produits, alors construisez votre handler sans supposer qu'une notification arrivera toujours. Ce que vous envoyez doit provenir directement de vos enregistrements, pas d'une estimation approximative.

5. Suivre le résultat final

Le résultat arrive sous forme de notification. REFUND signifie que le remboursement a été accordé. REFUND_DECLINED signifie qu'il ne l'a pas été. REFUND_REVERSED signifie qu'Apple a annulé un remboursement qu'il avait déjà accordé. Enregistrez les trois résultats. Le cas de l'annulation est celui que les équipes oublient le plus souvent, et une annulation manquée peut priver un client payant de quelque chose qu'il possède légitimement.

6. Mettre à jour les droits d'accès

Révoquez l'accès quand un remboursement est accordé. Rétablissez-le si le remboursement est annulé. Gérez le cas partiel, où seul un pourcentage est restitué. Et faites tourner tout cela à partir d'événements côté serveur, pour que l'accès du client reste correct, qu'il rouvre l'app un jour ou non.

7. Rapprocher avec le reporting des revenus et des abonnements

Rattachez le remboursement à la bonne période et au bon produit. Sautez cette étape, et la finance et l'ingénierie finissent par regarder deux versions différentes du même mois. Quiconque a assisté à cette réunion sait qu'elle vaut la peine d'être évitée.

Pourquoi la gestion manuelle des remboursements App Store devient difficile

Ce n'est pas une question de négligence. Les contraintes ne conviennent tout simplement pas à un processus qui dépend de quelqu'un d'éveillé et d'attentif 24 heures sur 24.

Les demandes de remboursement arrivent quand les clients les envoient. Dimanche matin. Deux heures du matin. Jours fériés. La fenêtre de réponse ne s'arrête pour le planning de personne. Chaque demande exige une recherche de transaction, une correspondance de compte, une vérification du consentement, un chiffre d'utilisation et une mise à jour des droits d'accès. Un bon jour, c'est environ cinq minutes de travail. Mais c'est urgent, répétitif et totalement invisible quand c'est bien fait. Personne n'est remercié pour un remboursement correctement traité à 4 heures du matin.

Le volume complique les choses. Gérer plusieurs apps aussi, avec les données de transaction dans un système et les données de compte dans un autre. Puis l'ingénieur qui comprenait le handler change d'équipe. La feuille de suivi prend un nom du genre refunds_OLD_final_v2 et cesse discrètement d'être ouverte. La finance découvre l'écart à la clôture du trimestre, environ trois mois après le moment où quelqu'un aurait encore pu agir.

Comment les développeurs peuvent-ils gérer les remboursements App Store de façon plus fiable ?

Le suivi manuel ressemble à ceci : quelqu'un ouvre un dashboard, recherche une transaction, met à jour un enregistrement et passe à autre chose. Ça fonctionne bien à faible volume, et c'est là le piège, parce que ça ne casse pas avec fracas. Ça s'effrite lentement. Il n'y a aucun moment précis où ça cesse de fonctionner, donc personne ne le repère à temps.

L'automatisation retire les étapes mécaniques des mains des équipes : recevoir et vérifier les notifications, faire correspondre les transactions aux comptes, assembler les données de réponse, suivre les fenêtres de réponse, enregistrer les résultats et garder les droits d'accès synchronisés.

Ce qu'elle ne peut pas faire, c'est faire changer Apple d'avis. L'automatisation ne rend pas les remboursements moins probables et ne peut pas influencer une décision, quoi qu'en laissent entendre certains outils. Tout ce qu'elle change, c'est que votre partie du processus se déroule de façon cohérente et dans les délais, et c'est déjà en soi une chose qui vaut la peine d'être corrigée.

La gestion des remboursements App Store est la catégorie dans laquelle s'inscrit ce travail, et il vaut la peine d'être direct sur ce qu'un outil de ce domaine doit couvrir : la gestion des notifications, la correspondance entre transactions et utilisateurs, des workflows de réponse qui respectent le consentement et les délais, un historique de remboursements consultable ultérieurement, et des mises à jour de droits d'accès qui gèrent les remboursements complets, partiels et annulés.

RefundSensor couvre cette partie du travail. Il connecte les événements de remboursement App Store et Google Play à un workflow automatisé, pour que les réponses partent dans la fenêtre du store sans que personne ne surveille les notifications à la main, et que les enregistrements de remboursement restent exacts à mesure que le volume augmente. Il ne changera pas la décision d'Apple, parce que rien ne le peut. Il change la quantité de travail que chaque remboursement laisse ensuite à votre équipe.

Où ces règles sont documentées

Trois sources Apple sous-tendent tout ce qui précède. Lisez-les vous-même avant de construire quoi que ce soit, et revenez-y de temps en temps, car ce domaine a déjà changé plus d'une fois.

Demander le remboursement d'apps ou de contenu — la politique que voient les clients. Couvre la soumission des demandes, le délai de réponse de 24 à 48 heures et la note d'Apple sur l'éligibilité régionale.

Send Consumption Information — le workflow de réponse côté développeur. Couvre l'exigence de consentement, la fenêtre de 12 heures et les champs de la requête. À lire en entier avant de toucher à la gestion de la consommation.

App Store Server Notifications — comment les événements de remboursement atteignent votre backend. Couvre le format de payload signé et les types de notification, dont CONSUMPTION_REQUEST, REFUND, REFUND_DECLINED et REFUND_REVERSED.

Si les événements de remboursement sont encore vérifiés à la main

Le suivi manuel fonctionne bien, jusqu'au jour où il ne fonctionne plus, et l'échec est généralement silencieux. Une notification que personne n'a vue. Une fenêtre fermée à 3 heures du matin. Un client remboursé qui a conservé son accès pendant tout un trimestre.

Si cela vous parle, RefundSensor peut sortir le workflow de remboursement du suivi manuel : les événements des stores, les fenêtres de réponse, et l'assurance que les résultats atteignent à la fois vos enregistrements et votre logique de droits d'accès.