Les motifs de résiliation d'abonnement vous parviennent souvent avant la demande de remboursement, et Google Play en transmet bien plus qu'Apple

La plupart des abonnés qui finissent remboursés résilient d'abord. Cette résiliation s'accompagne d'un motif, et les deux stores vous en livrent des quantités très différentes. Google Play pose un court questionnaire et transmet la réponse à votre serveur, texte libre compris. Apple envoie un code numérique qui indique comment l'abonnement s'est terminé, pas pourquoi le client voulait partir. Lisez bien les deux et vous verrez venir les demandes de remboursement tant qu'il est encore possible d'agir.

Ce que Google Play vous dit sur les motifs de résiliation

Quand un utilisateur résilie depuis le centre d'abonnements de Play, Google lui demande pourquoi. La réponse se trouve dans la ressource d'abonnement renvoyée par purchases.subscriptionsv2.get, sous canceledStateContext. Cet objet n'existe que lorsque l'abonnement est résilié ou expiré, et il indique qui y a mis fin : l'utilisateur, le système de Google, vous, ou un remplacement comme un changement de forfait.

Quand c'est l'utilisateur, l'objet userInitiatedCancellation contient deux champs. cancelTime indique quand il a résilié. cancelSurveyResult contient la réponse au questionnaire.

La colonne de droite est notre lecture, pas celle de Google. Les deux premières colonnes viennent directement de la référence de l'API.

La notification ne contient pas le motif

Un abonnement résilié déclenche une notification en temps réel pour les développeurs SUBSCRIPTION_CANCELED, de type 3. Google précise clairement que ces notifications indiquent seulement que l'état de l'achat a changé. Le payload vous donne un jeton d'achat et rien d'autre d'utile, donc votre handler doit appeler purchases.subscriptionsv2.get pour lire la réponse au questionnaire.

La vue dans Play Console

Pas besoin de code pour voir les totaux. Les rapports d'abonnements de Play Console comprennent une fiche Résiliations qui répartit l'attrition entre volontaire, involontaire et autre, ainsi qu'une fiche de réponses au questionnaire de résiliation pour les utilisateurs qui ont choisi de répondre. Les réponses en texte libre des utilisateurs ayant choisi autre se téléchargent au format CSV depuis la fiche des autres réponses. Ce téléchargement nécessite l'autorisation View financial data, celle que vous accorderiez à un outil qui lit vos commandes.

Ce qu'Apple vous dit, et ce qu'elle tait

Apple n'a aucun questionnaire de résiliation qui remonte aux développeurs. Le champ le plus proche est expirationIntent, dans les informations de renouvellement signées, et il décrit comment un abonnement s'est terminé, pas ce que pensait le client.

Le code 1 est le seul qui décrit un choix du client, et il ne dit rien de sa motivation. Un client parti parce que l'app plantait sans arrêt et un autre qui a simplement terminé un projet se ressemblent en tout point.

Le signal caché dans AUTO_RENEW_DISABLED

Une notification d'Apple mérite qu'on s'y attarde. DID_CHANGE_RENEWAL_STATUS avec le sous-type AUTO_RENEW_DISABLED signifie en général que le client a désactivé le renouvellement automatique. La documentation d'Apple ajoute un second cas : l'App Store désactive aussi le renouvellement automatique après une demande de remboursement du client.

Sur iOS, un événement de renouvellement désactivé peut donc être la première trace d'une demande de remboursement. Si l'achat est un consommable ou un abonnement à renouvellement automatique, un CONSUMPTION_REQUEST peut suivre, et à partir de là vous avez 12 heures pour envoyer les données de consommation. Un événement de renouvellement désactivé qui arrive sans aucune action visible dans votre app vaut la peine d'être traité comme une alerte pour préparer les données d'utilisation de ce compte.

Apple et Google côte à côte

Quand une résiliation devient un remboursement

Une résiliation arrête le prochain prélèvement. Elle ne rembourse pas le dernier. Que l'argent revienne ou non dépend du parcours de remboursement que le client emprunte ensuite, et la plupart de ces parcours se déroulent sans vous.

• Sur Google Play, un acheteur peut obtenir seul un remboursement dans les 48 heures suivant l'achat, et c'est Google qui décide.
• Les remboursements passant par le support de Google ou d'Apple sont décidés par le store.
• Le CONSUMPTION_REQUEST d'Apple demande vos données de consommation, avec un délai de 12 heures.
• L'examen des chargebacks de Google Play demande des preuves via orders.reviewrefund, avec un délai de 24 heures. La décision de la banque sur un chargeback est définitive.

Un motif de résiliation ne change aucune de ces règles. Ce qu'il change, c'est le moment où vous savez quel client est mécontent, et si vos preuves sont prêtes quand arrive l'un des deux parcours qui en demandent.

Ce que chaque motif vous coûte

La réponse au questionnaire donne aussi une idée approximative de ce que le service d'un compte vous a déjà coûté, c'est-à-dire l'argent qu'un remboursement vous laisse sur les bras.

Problèmes techniques

C'est le plus coûteux. Le client a assez utilisé le produit pour rencontrer des problèmes, donc vous avez payé le calcul derrière ses sessions, les appels à l'API du modèle déclenchés par ses requêtes, le stockage de ce qu'il a créé et toute rémunération due à un créateur dont il a utilisé le contenu. S'il obtient ensuite un remboursement, le prix repart et ces coûts restent pour vous. S'il se tourne vers sa banque sur Google Play, une commande passée après le August 3, 2026 vous coûte le prix d'achat moins les frais de service de Play, plus les frais bancaires.

Question de prix

Une plainte sur le prix vous coûte moins qu'il n'y paraît, sauf si elle cache un renouvellement inattendu. C'est le scénario classique du chargeback : vérifiez si la résiliation a suivi de près un prélèvement de renouvellement et si vos rappels de renouvellement sont bien partis.

Pas assez d'utilisation

Peu d'usage signifie peu de coûts de service, donc un remboursement rend surtout de l'argent qui ne vous a pas coûté grand-chose à gagner. C'est aussi le motif pour lequel des données de consommation honnêtes, si Apple les demande, montrent exactement ce que le client a utilisé ou non.

Meilleure app trouvée

Ces clients contestent rarement quoi que ce soit. Ils sont partis chez un concurrent. Le motif est utile pour les décisions produit et presque jamais pour se défendre contre un remboursement.

Une routine pour lire les motifs de résiliation

• À chaque SUBSCRIPTION_CANCELED de Google Play, appelez purchases.subscriptionsv2.get et enregistrez canceledStateContext avec le jeton d'achat et cancelTime.
• Enregistrez reasonUserInput tel quel quand le motif est autre. C'est le seul texte libre que l'un ou l'autre store vous fournit.
• À chaque DID_CHANGE_RENEWAL_STATUS d'Apple avec AUTO_RENEW_DISABLED, journalisez l'événement et récupérez l'utilisation de ce compte, au cas où un CONSUMPTION_REQUEST suivrait.
• À chaque notification EXPIRED d'Apple, enregistrez le sous-type et expirationIntent pour ne pas confondre attrition volontaire et échecs de facturation.
• Pour les résiliations Google Play pour problèmes techniques, consultez vos journaux d'erreurs pour ce compte et contactez le client avant qu'il ne contacte sa banque.
• Tenez des journaux d'utilisation par compte, pour qu'un CONSUMPTION_REQUEST obtienne une réponse en moins de 12 heures et un examen de chargeback en moins de 24.