Les remboursements d'abonnement ne fonctionnent pas comme les remboursements d'achat unique, et la boutique sur laquelle vous vous trouvez décide du poids que vous avez dans la décision

Rembourser un abonnement et rembourser un seul achat intégré donnent l'impression d'être le même bouton. Ils ne le sont pas. Un achat unique est une seule charge que vous restituez. Un abonnement est une charge récurrente à laquelle est attaché un droit actif, donc les remboursements d'abonnement doivent répondre à deux questions qu'un remboursement d'achat unique ne pose jamais : quelle part de la période en cours restituez-vous, et l'abonnement continue-t-il de fonctionner. L'App Store et Google Play répondent à ces deux questions de manières opposées, et l'écart décide de la part de contrôle que vous avez et de la somme d'argent qui quitte votre compte.

Voici la carte rapide. Sur l'App Store, Apple détient la décision et vous l'apprenez après coup. Sur Google Play, vous tenez les commandes et choisissez vous-même intégral ou au prorata. Ceci parcourt les deux boutiques, les champs et notifications exacts que chacune utilise, quelle commande vous touchez lorsqu'un abonnement a été facturé de nombreuses fois, et ce qu'un remboursement d'abonnement coûte réellement une fois que vous comptez le calcul que vous avez déjà dépensé.

En quoi les remboursements d'abonnement diffèrent des remboursements d'achat unique

Les deux boutiques considèrent un remboursement comme l'annulation d'une commande précise. Pour un achat unique il n'y a qu'une seule commande, donc il n'y a rien à choisir. Un abonnement est une chaîne de commandes, une par période de facturation, avec un droit qui est actif ou non. Cette structure explique pourquoi un remboursement d'abonnement comporte des choix qu'un remboursement d'achat unique n'a pas.

L'unité qui est annulée est une période de facturation

Lorsque vous remboursez un abonnement, vous ne restituez pas une vie entière de paiements. Vous agissez sur une commande de la chaîne, généralement la plus récente, qui est une seule période de facturation. Un remboursement intégral restitue toute cette période. Un remboursement au prorata ne restitue que la part de la période que le client n'a pas encore utilisée. Dans tous les cas, la vente que vous annulez est le prix d'une période, pas tout l'historique du client avec l'application.

Qui décide est la vraie différence

La séparation la plus nette est l'autorité. Sur l'App Store, Apple décide si un remboursement d'abonnement a lieu ou non, et vous fournissez du contexte tout au plus. Sur Google Play, vous décidez, et l'API fait exactement ce que vous lui dites. Même résultat pour le client, une place complètement différente pour le développeur, et cela change ce que vous construisez pour gérer chacun.

Comment l'App Store gère un remboursement d'abonnement

Du côté d'Apple, vous êtes un spectateur avec un petit microphone. Le client parle à Apple, Apple tranche, et votre serveur lit le résultat.

Le client s'adresse à Apple, et Apple tranche

Un client de l'App Store demande un remboursement d'abonnement sur reportaproblem.apple.com, pas à vous. Apple examine la demande à l'aide de ses propres signaux et décide. Vous ne l'approuvez pas, et il n'existe aucun bouton dans la console d'Apple qui vous permette d'émettre un remboursement d'abonnement comme le fait Google Play. Apple dispose de jusqu'à 90 jours à compter de l'achat pour accepter une demande d'examen, et une fois qu'elle a tranché, la décision est celle d'Apple.

Ce que votre serveur voit lorsque le remboursement arrive

Vous apprenez le résultat via les App Store Server Notifications V2. Un remboursement accordé arrive sous forme de notification REFUND, et la transaction porte désormais un revocationDate indiquant quand l'accès doit prendre fin. Le autoRenewStatus de l'abonnement passe à false, il cesse donc de se renouveler et le client perd le droit. Si Apple refuse la demande vous recevez REFUND_DECLINED, et si Apple annule plus tard un remboursement qu'elle avait déjà accordé vous recevez REFUND_REVERSED et l'abonnement revient. Votre rôle est de lire cela et de basculer l'accès, pas de voter.

Apple mesure un abonnement selon le temps, pas selon vos indicateurs

Pour un consommable, vous pouvez indiquer à Apple combien a été utilisé via les données de consommation. Pour un abonnement à renouvellement automatique, Apple calcule elle-même la consommation à partir du temps écoulé. L'exemple d'Apple elle-même est un client à six mois d'un abonnement annuel, qui en a consommé environ 50 pour cent. Vos indicateurs d'utilisation ne fixent donc pas le chiffre pour un abonnement. Le seul levier que vous pouvez actionner est refundPreference, et pour un abonnement la valeur pertinente est GRANT_PRORATED, qui indique que vous préféreriez qu'Apple ne restitue que la part non utilisée. C'est une préférence, pas une décision. Apple tranche toujours.

Comment Google Play gère un remboursement d'abonnement

Google Play met la décision entre vos mains. Il existe un écran dans la Play Console et un ensemble de méthodes d'API qui vous permettent de rembourser un abonnement directement, de choisir combien, et de décider si l'accès prend fin. C'est la posture inverse de celle d'Apple, et elle s'accompagne de choix que vous devez réussir.

Intégral ou au prorata, et c'est votre décision

La façon actuelle de rembourser et de révoquer un abonnement est purchases.subscriptionsv2.revoke, appelée avec un revocationContext. Passez fullRefund et Google Play met fin à l'abonnement et restitue le montant intégral de la période de facturation en cours. Passez proratedRefund et Google Play met fin à l'abonnement et ne restitue que le temps de droit restant et non utilisé. L'ancienne méthode ne pouvait faire que des remboursements intégraux, ce qui est la raison d'utiliser la plus récente. Une révocation au prorata est un corps de deux lignes, un revocationContext enveloppant proratedRefund, et vous remplacez par fullRefund pour toute la période. L'une ou l'autre révocation déclenche une notification en temps réel pour les développeurs SUBSCRIPTION_REVOKED, qui est votre signal pour couper l'accès.

La commande que vous remboursez change ce qui se passe

Google Play vous permet aussi de rembourser une commande sans révoquer, via orders.refund, et ici une règle subtile mord. Si vous remboursez la commande la plus récente d'un abonnement, la commande est remboursée, l'abonnement est supprimé immédiatement, et les récurrences futures sont annulées. Si vous remboursez une commande plus ancienne de la chaîne, cette commande est remboursée mais l'abonnement reste actif. Sur orders.refund, le paramètre revoke ne révoque que lorsque la commande est la plus récente, donc pour mettre fin à l'accès sur un abonnement actif vous utilisez purchases.subscriptionsv2.revoke à la place.

Les limites qui font trébucher les développeurs

Quelques arêtes dures attrapent les gens, et aucune ne se trouve sur le chemin idéal.

• Les commandes de plus de trois ans ne peuvent pas être remboursées du tout.
• Les remboursements partiels ne fonctionnent que sur les commandes passées après March 2018, et jamais sur les achats d'applications payantes.
• Vous pouvez cumuler plusieurs remboursements partiels sur une commande, mais pas jusqu'au total de la commande ni au-delà.
• Un remboursement ne peut pas être annulé une fois émis.

Google Play renvoie généralement une décision de remboursement en un jour, même si cela peut prendre jusqu'à quatre. Prévoyez ce délai lorsqu'un remboursement doit se répercuter dans vos propres contrôles d'accès.

Ce qu'un remboursement d'abonnement vous coûte réellement

La charge remboursée n'est jamais la facture entière. Au moment où une commande d'abonnement a été livrée, vous aviez déjà dépensé de l'argent réel dessus : calcul, appels d'API de modèle, stockage, et tout versement lié à cette période. Un remboursement restitue la vente. Il ne restitue pas ce que vous avez dépensé pour la servir. Sur un abonnement, la forme de la perte dépend du remboursement que vous émettez.

Intégral par rapport à au prorata est une décision d'argent

Un remboursement intégral sur Google Play restitue toute la période en cours, vous perdez donc les revenus de toute la période tout en conservant chaque coût que vous avez déjà engagé cette période. Un remboursement au prorata ne restitue que la tranche non utilisée, vous conservez donc les revenus de la part que le client a réellement eue. Si un client est à 60 pour cent d'une période mensuelle sur un forfait à 10 dollars, un remboursement intégral vous coûte les 10 dollars entiers, et un remboursement au prorata vous coûte environ 4 dollars, les 40 pour cent non utilisés. Apple applique la même logique de temps écoulé de son côté lorsqu'elle dimensionne un remboursement d'abonnement.

Les coûts qui ne reviennent jamais

Quel que soit le remboursement que vous émettez, les coûts en aval de cette période sont perdus. Un appel d'API de modèle que vous avez payé, une vidéo que vous avez rendue, du stockage que vous avez provisionné, un versement à un créateur que vous avez déjà envoyé, rien de tout cela ne s'annule quand le remboursement d'abonnement est réglé. Dimensionnez le remboursement selon ce que le client a réellement utilisé, jamais selon depuis combien de temps il s'est abonné, car le temps écoulé n'est pas un coût et aucune des deux boutiques ne le traite comme tel. Et après le August 3, 2026, si une charge d'abonnement Google Play se termine par une rétrofacturation bancaire plutôt que par un remboursement que vous émettez, vous absorbez aussi les frais de rétrofacturation de la banque, qu'un remboursement que vous accordez d'abord évite.

Comment gérer les remboursements d'abonnement sans qu'une personne surveille

Rien de tout cela ne devrait attendre que quelqu'un lise un tableau de bord. Les notifications arrivent à toute heure, et l'accès devrait basculer à l'instant où un remboursement arrive, pas le lendemain matin.

Lisez le résultat et révoquez l'accès sur les deux boutiques

Sur l'App Store, guettez REFUND, REFUND_DECLINED et REFUND_REVERSED, et utilisez le revocationDate et le autoRenewStatus pour mettre fin à l'accès ou le restaurer automatiquement. Sur Google Play, guettez SUBSCRIPTION_REVOKED et les signaux d'achat annulé et faites de même. C'est la tuyauterie que RefundHalt exécute pour vous : notification en entrée, compte apparié, accès basculé, aucune personne dans la boucle.

Gardez les preuves prêtes avant le litige

Les fenêtres étroites qui demandent bien votre contribution, le CONSUMPTION_REQUEST de 12 heures d'Apple sur les consommables et l'examen de rétrofacturation de 24 heures de Google Play, n'aident que si les preuves existent déjà. Attachez un identifiant de compte à chaque achat, un appAccountToken UUID sur Apple et un setObfuscatedAccountId haché de 64 caractères ou moins sur Google Play, et enregistrez ce que chaque période payée a livré. Ainsi, quand un jeton arrive, le dossier est déjà constitué, et répondre dans la fenêtre est le travail d'une machine, pas une course effrénée.