Révoquer l'accès après un remboursement : l'étape qu'Apple et Google ne font pas pour vous

Approuver un remboursement et retirer l'accès sont deux étapes distinctes, et une seule des deux se produit automatiquement. Les développeurs qui supposent qu'un remboursement traité équivaut à un achat révoqué se trompent sur les deux principales boutiques, de façons différentes et pour des raisons différentes. Savoir précisément où s'arrête l'automatisation, c'est ce qu'il faut pour révoquer l'accès après un remboursement, plutôt que de découvrir des mois plus tard que cela n'a jamais eu lieu.

Pourquoi un remboursement ne révoque pas l'accès par défaut

Apple et Google traitent tous deux l'argent et l'accès comme deux opérations distinctes. Le volet financier relève de la politique du magasin : une fois le remboursement approuvé, il est définitif et le registre est mis à jour. Le volet accès est optionnel, ou relève du développeur, ou les deux, selon la plateforme et le type d'achat. Aucune des deux boutiques ne suppose que vous voulez que l'accès disparaisse à l'instant où le remboursement est finalisé, car de nombreux cas légitimes (un remboursement partiel, un crédit de courtoisie, un geste commercial) ne sont pas censés retirer le produit du tout.

Google Play : la case à cocher que personne ne remarque

Dans Play Console, rembourser une commande est un formulaire en deux parties : choisir le montant du remboursement, puis décider séparément de cocher ou non "Remove entitlement". Laisser cette case décochée est le chemin par défaut que suivent la plupart des agents du support, car la plupart des demandes de remboursement sont des gestes commerciaux où le client garde ce qu'il a acheté. Le problème, c'est que rien sur l'écran de confirmation du remboursement ne vous indique que c'est aussi ainsi qu'un client conserve un abonnement ou un article intégré après un remboursement que vous vouliez définitif.

Le chemin de l'API comporte le même piège

Le même choix existe dans le code. Le point de terminaison orders.refund accepte un paramètre de requête optionnel revoke ; quand il vaut true, l'accès à l'article est immédiatement supprimé, et pour un abonnement récurrent, chaque paiement futur est annulé avec lui. Omettre le paramètre le fait passer par défaut à false : le remboursement est enregistré, la fiche d'achat est mise à jour, et l'utilisateur continue d'utiliser le produit exactement comme avant.

Cette dernière ligne est celle qui piège les intégrations. La Voided Purchases API existe pour vous permettre de construire un pipeline de révocation sans consulter Play Console à la main, mais elle ne liste que les commandes réellement annulées avec révocation. Un remboursement traité sans la case cochée, ou sans revoke=true, est invisible pour ce flux par conception, pas par bug.

Lire le champ voidedReason Quand un achat apparaît comme annulé, le champ voidedReason en indique la raison, sur une échelle de neuf valeurs : other, remorse, not_received, defective, accidental_purchase, fraud, friendly_fraud, chargeback et unacknowledged_purchase. Ce n'est pas qu'une question de comptabilité. Remorse et accidental_purchase sont des remboursements ordinaires. Fraud, friendly_fraud et chargeback méritent d'être orientés vers une file de revue anti-fraude plutôt que vers un simple chemin de révocation automatique, car le même compte a statistiquement plus de chances de récidiver.

Un détail opérationnel compte si vous développez directement contre ce flux : purchases.voidedpurchases.list est plafonné à 6 000 requêtes par jour et 30 requêtes sur n'importe quelle fenêtre de 30 secondes. Une conception qui interroge en boucle serrée atteint vite ce plafond ; le modèle prévu est une récupération planifiée avec des jetons de pagination, pas un polling continu.

Apple : l'App Store peut révoquer une licence, mais pas un consommable

Les App Store Server Notifications V2 d'Apple envoient une notification REFUND dès qu'un remboursement est finalisé, aussi bien pour les consommables, les non-consommables, les abonnements à renouvellement automatique que les abonnements sans renouvellement. Ce qui se passe après cette notification dépend entièrement du type d'achat, car le mécanisme de révocation propre à StoreKit ne couvre que deux des quatre types.

Pourquoi les consommables font exception

Un non-consommable ou un abonnement possède un droit permanent que les systèmes d'Apple peuvent désactiver. Un consommable n'en a pas : une fois utilisé, il est considéré comme livré, et il ne reste rien dans StoreKit à révoquer. Si un client a acheté 500 pièces, les a dépensées, puis a obtenu un remboursement, les pièces ont déjà disparu du point de vue d'Apple. Le seul registre qui les conserve encore est le vôtre. La notification REFUND est votre unique signal pour retrouver l'identifiant de transaction original correspondant et déduire ce solde de vos propres registres ; rien du côté d'Apple ne le fera pour vous.

La notification que presque personne ne gère

REFUND_REVERSED est celle que la plupart des intégrations ignorent complètement, car elle décrit Apple annulant sa propre décision, un cas que peu de développeurs anticipent du premier coup. Quand elle arrive, revocationDate repasse à null sur la transaction : pour Apple, l'achat est de nouveau valide. Si votre serveur a supprimé un droit d'accès, annulé l'enregistrement d'un abonnement ou remis à zéro un solde de consommable lors du REFUND initial, REFUND_REVERSED est le signal pour tout restaurer.

Comment combler l'écart, étape par étape

• Sur Google Play, faites de revoke=true le comportement par défaut de chaque chemin de remboursement, que ce soit via Play Console ou l'API, sauf si un cas de support précis exige que le client garde l'accès.
• Interrogez purchases.voidedpurchases.list selon un calendrier avec des jetons de pagination, pas en boucle serrée, et restez sous 6 000 requêtes par jour et 30 par tranche de 30 secondes.
• Orientez les valeurs de voidedReason fraud, friendly_fraud et chargeback vers une file de revue plutôt que vers une révocation automatique suivie d'une clôture.
• Chez Apple, abonnez-vous aux App Store Server Notifications V2 et révoquez l'accès aux non-consommables et abonnements dès qu'une notification REFUND les mentionne.
• Conservez l'identifiant de transaction original pour chaque achat consommable, afin qu'une notification REFUND puisse retrouver le solde exact à déduire sans recherche manuelle.
• Traitez REFUND_REVERSED explicitement et enregistrez chaque révocation en la reliant à son identifiant de transaction ou de commande, pour qu'une annulation puisse restaurer précisément ce qui a été retiré.

Ce que coûte réellement cet écart

Rien de tout cela ne concerne l'équité envers le client ; il s'agit de ce qui continue de tourner une fois l'argent parti. Un abonnement remboursé qui continue d'appeler votre API, de stocker des données et de consommer du calcul n'est pas un problème moral, c'est une ligne de coût : vous payez la facture d'infrastructure d'un achat sur lequel vous avez déjà rendu le revenu. Les boutiques ne suivent pas ce coût à votre place, car de leur côté, le remboursement est terminé dès que l'argent bouge. Le volet accès est entièrement à votre charge.

C'est la même raison pour laquelle RefundHalt traite la révocation comme faisant partie du pipeline de remboursement, et non comme une réflexion après coup : un événement REFUND et un changement d'accès sont enregistrés comme une seule action, et un événement REFUND_REVERSED restaure l'état automatiquement, au lieu d'attendre que quelqu'un remarque que le client est encore bloqué hors de quelque chose qu'Apple lui a pourtant rendu.