Apple et Google remboursent une boutique à la fois, votre abonnement multiplateforme doit donc couper l'accès partout ailleurs

Votre abonné a payé Apple, a ouvert votre app Android le jour même et utilise maintenant votre site au bureau. Puis Apple le rembourse. Google Play n'en sait rien. Votre facturation web non plus. Tant que votre propre serveur ne coupe pas l'accès, un abonnement multiplateforme remboursé continue de fonctionner sur chaque écran qui lit votre base de comptes. Les boutiques remboursent une vitrine à la fois, et votre système de comptes est le seul endroit où l'abonnement existe en entier. C'est donc le seul endroit capable d'y mettre fin.

Pourquoi le remboursement d'une boutique ne met pas fin à un abonnement multiplateforme

Apple autorise ce modèle en toutes lettres. L'App Review Guideline 3.1.3(b), Multiplatform Services, indique que les apps présentes sur plusieurs plateformes peuvent permettre aux utilisateurs d'accéder aux contenus, abonnements ou fonctionnalités acquis dans votre app sur d'autres plateformes ou sur votre site, à condition que ces éléments soient aussi proposés en achat intégré dans l'app.

Le guide d'Apple consacré à la proposition d'un même abonnement dans plusieurs apps décrit le fonctionnement concret. Votre serveur accorde l'accès à partir d'une base de comptes unifiée, et chaque app la consulte. Le même guide prévient que si un achat n'est pas propagé aux autres apps, l'utilisateur risque de payer plusieurs fois le même service.

Ce modèle a une conséquence souvent négligée. Le droit d'accès vit dans votre base de données, mais chaque boutique ne connaît que ses propres reçus. Apple peut rembourser l'achat iPhone et prévenir votre serveur. Elle ne peut rien dire à votre app Android ni à votre site. Si le gestionnaire de remboursements ne met à jour que le client iOS, le client récupère son argent et garde l'abonnement partout ailleurs.

Comment révoquer l'accès sur toutes les plateformes après un remboursement

Rattachez chaque achat à un seul compte

Relier un remboursement à une personne est la partie difficile, car chaque boutique identifie l'acheteur à sa manière. Toutes deux vous offrent un champ pour votre propre identifiant de compte. Utilisez-le sur chaque achat.

• Chez Apple, définissez un appAccountToken, un UUID que vous générez, au lancement de l'achat. L'App Store renvoie le même UUID dans les informations de transaction et de renouvellement. Apple précise que vous pouvez réutiliser une même valeur pour toutes les transactions d'un même client.
• Si le client a acheté hors de votre app, par exemple en utilisant un code d'offre dans l'App Store, la transaction n'a pas de jeton. L'endpoint Set App Account Token en ajoute un. Pour un abonnement à renouvellement automatique, il s'applique au renouvellement en cours et aux suivants, pas aux transactions passées, et il ne fonctionne pas pour les achats partagés via le Partage familial.
• Sur Google Play, transmettez un identifiant de compte masqué avec setObfuscatedAccountId au lancement du flux de facturation. Il est limité à 64 caractères. Google indique que des données personnelles en clair, comme une adresse e-mail, entraînent le blocage des achats, et recommande le chiffrement ou un hachage à sens unique.

Écoutez les deux boutiques, puis écrivez un seul droit d'accès

Apple envoie REFUND lorsqu'elle rembourse n'importe quel type de produit, abonnements à renouvellement automatique compris. Elle envoie REFUND_REVERSED lorsqu'elle annule un remboursement déjà accordé, à la suite d'une contestation ouverte par le client. Sur Google Play, la Voided Purchases API liste les achats remboursés et ayant fait l'objet d'une rétrofacturation, chacun avec un orderId qui identifie l'achat ou le renouvellement exact. Votre prestataire de paiement web envoie son propre événement de remboursement. Les trois doivent aboutir au même gestionnaire et modifier le même enregistrement.

Révoquez le droit d'accès, pas le compte

Un remboursement annule un achat, pas une personne. Retirez l'accès issu de l'achat remboursé, puis recalculez ce que le compte possède encore. Si le client détient aussi un abonnement actif dans une autre boutique, il garde l'accès grâce à celui-ci. Sinon, chaque client perd les fonctionnalités premium la prochaine fois qu'il interroge votre serveur.

Quand la même personne s'abonne dans deux boutiques

Les doubles abonnements sont l'autre moitié du problème. Quelqu'un s'abonne sur Android, achète un nouvel iPhone, ne se connecte pas et s'abonne à nouveau. Il paie désormais deux fois le même service, et l'un de ces prélèvements finit généralement en demande de remboursement. L'équipe commerce d'Apple, répondant à un développeur sur les Apple Developer Forums, l'a dit simplement : le système de comptes d'une app doit inclure une logique qui empêche l'achat en double sur une autre plateforme.

Vérifiez chaque boutique avant d'afficher le paywall

Faites se connecter l'utilisateur avant le paywall, recherchez tous ses achats actifs sur votre serveur et ne présentez pas l'offre si l'un d'eux couvre cette plateforme. Cette seule vérification évite la plupart des doubles prélèvements avant qu'ils ne se produisent.

Quel achat rembourser quand le doublon a déjà eu lieu ?

Remboursez celui que vous maîtrisez. Sur Google Play, vous pouvez émettre le remboursement vous-même dans Play Console, et purchases.subscriptionsv2.cancel avec DEVELOPER_REQUESTED_STOP_PAYMENTS arrête le prochain paiement. Votre abonnement web vous appartient, vous pouvez le rembourser directement. Les remboursements App Store sont décidés par Apple : si le doublon se trouve sur l'iPhone, le client en fait la demande à Apple, et votre app peut ouvrir cette demande avec l'API de demande de remboursement de StoreKit.

Ce que vous coûte un remboursement qui manque une plateforme

Le prix remboursé n'est que la première perte. Un client dont le remboursement Apple n'a jamais atteint votre app Android ni votre site continue d'utiliser ce que vous payez pour faire tourner. Chaque session consomme toujours de la puissance de calcul. Chaque fonctionnalité d'IA continue d'appeler des API tierces qui vous sont facturées. Ses fichiers occupent toujours de l'espace de stockage, et si votre app rémunère des créateurs à la vue ou à l'usage, ces versements continuent de partir. Sur un forfait annuel, cela peut représenter une année entière de coûts de service pour un compte qui ne paie plus rien.

La voie bancaire aggrave les choses. Pour les commandes Google Play passées après le 3 août 2026, Google indique que lorsqu'une rétrofacturation aboutit, le développeur est redevable du prix d'achat, déduction faite des frais de service de Play, plus les frais de rétrofacturation facturés par l'établissement financier. Une rétrofacturation est définitive côté banque. Un client qui a obtenu une rétrofacturation et garde l'accès vous a coûté le prix, les frais et le coût de service en même temps.

L'usage multiplateforme reste une preuve

Un compte unique sur toutes les plateformes aide aussi quand une boutique demande votre version. Les informations de consommation d'Apple demandent quelle part d'un consommable, d'un non consommable ou d'un abonnement non renouvelable le client a consommée. Pour les abonnements à renouvellement automatique, vous n'envoyez pas de pourcentage, car Apple le calcule à partir du temps écoulé. L'examen des rétrofacturations de Google Play accepte jusqu'à 1 000 événements d'utilisation, chacun pouvant porter l'identifiant de compte masqué. Un usage enregistré sous un même identifiant de compte, quel que soit l'appareil qui l'a produit, est un usage que vous pouvez démontrer.

Les remboursements qui ne vous demandent jamais votre version

La plupart des remboursements sont décidés sans vous. Google Play peut rembourser un achat dans les 48 heures via son propre parcours de remboursement. Les remboursements du support de la boutique, les achats annulés et le remboursement automatique par Google des achats que vous ne confirmez jamais, au bout d'environ 72 heures, interviennent d'abord et sont signalés ensuite. Dans ces cas, la logique de révocation décrite plus haut constitue tout le travail.

Seuls deux parcours demandent des preuves. Le CONSUMPTION_REQUEST d'Apple vous laisse 12 heures pour envoyer les informations de consommation. L'examen des rétrofacturations de Google Play vous laisse 24 heures à compter de la PendingRefundReviewNotification pour répondre via orders.reviewrefund, et Google n'enregistre que votre premier appel. RefundHalt répond aux deux dans le délai, à partir des données d'usage que vous collectez déjà, rattachées au même compte dans toutes vos apps.

Une courte checklist pour les remboursements multiplateformes

• Définissez appAccountToken sur les achats Apple et un identifiant de compte masqué sur les achats Google Play.
• Complétez les jetons Apple manquants avec Set App Account Token pour les codes d'offre utilisés.
• Acheminez REFUND et REFUND_REVERSED d'Apple, les achats annulés Google Play et les remboursements web vers un seul gestionnaire.
• Stockez chaque achat avec sa source et calculez l'accès à partir de tous les achats actifs.
• Vérifiez les achats de chaque boutique avant d'afficher un paywall sur n'importe quelle plateforme.