Si vous transférez une app vers un autre compte développeur, les commandes passées avant la vente restent chez le vendeur, et voici ce que cela change pour les remboursements

La page d'aide de Google le dit en une ligne : les commandes créées avant le transfert d'une app restent sur le compte d'origine. Donc, quand vous transférez une app vers un autre compte développeur, les abonnés passent à l'acheteur, mais pas l'historique d'achats. Les remboursements, les litiges et les tickets de support liés à cet historique ne se règlent pas tout seuls. Ils retombent sur la partie que désignent les règles du store, qui n'est pas toujours celle qui a encaissé l'argent. Apple et Google gèrent cela différemment, et Apple en dit moins que Google. Voici ce que documente chaque store, quelles parties de votre dispositif de remboursement cessent de fonctionner sans bruit après un transfert, et ce qu'il faut mettre par écrit avant que l'une ou l'autre partie signe.

Ce qui part et ce qui reste quand vous transférez une app

Les deux stores traitent un transfert comme un changement de propriétaire pour l'avenir. L'app, ses utilisateurs et ses notes suivent. L'historique financier du passé, pour l'essentiel, non.

Sur l'App Store

La règle d'Apple porte sur les données. Le développeur qui transfère garde l'accès aux informations de paiement et de ventes antérieures au transfert et perd l'accès à tout ce qui suit. Le destinataire ne reçoit les informations de paiement et de ventes que pour les transactions postérieures au transfert. Le guide de transfert d'Apple n'aborde pas les remboursements d'achats effectués avant le transfert. Il ne dit rien sur les revenus de qui supportent un remboursement tardif.

Sur Google Play

Google est plus explicite. Les utilisateurs, les statistiques, les données, les commentaires, les notes et les abonnements sont transférés. Les commandes créées avant le transfert restent sur le compte d'origine, et si l'une d'elles doit être remboursée, Google indique qu'il faut revenir au compte d'origine ou utiliser la Google Play Developer API. Le compte du vendeur ne cesse pas de compter le jour de la vente. Il reste le seul endroit d'où certains remboursements peuvent être émis.

Qui émet un remboursement après le transfert d'une app

Sur les deux stores, la plupart des remboursements sont décidés sans le moindre développeur. Apple traite elle-même les demandes de remboursement. Sur Google Play, les acheteurs peuvent se faire rembourser eux-mêmes de nombreux achats sous 48 heures, et le support Google en accorde d'autres. Un transfert ne change rien à tout cela. Ce qui change, c'est qui peut voir le remboursement et qui peut agir dans les rares flux qui sollicitent un développeur.

Un remboursement que vous voulez accorder sur Google Play

Imaginons qu'un abonné de longue date écrive au nouveau propriétaire pour se faire rembourser un prélèvement datant de deux mois avant la vente. Le nouveau propriétaire ne peut pas le rembourser depuis sa propre Play Console, car la commande n'y figure pas. Le vendeur doit se connecter et le faire, ou quelqu'un ayant un accès API au compte du vendeur doit appeler la Google Play Developer API. Si le vendeur a fermé le compte ou ne répond plus, ce remboursement est bloqué. Google propose même de rembourser au vendeur ses frais d'inscription de 25 $ s'il ferme le compte d'origine après un transfert, et c'est justement pour ça que l'acheteur doit s'assurer que les remboursements antérieurs au transfert sont réglés avant que cela arrive.

Un remboursement qu'Apple accorde d'elle-même

Sur l'App Store, ce n'est pas vous qui remboursez, c'est Apple. Quand Apple rembourse un achat antérieur au transfert, l'historique de paiement et de vente correspondant se trouve chez le développeur d'origine. La documentation de transfert d'Apple ne dit pas sur les revenus de quelle partie ce remboursement est imputé, donc aucune des deux ne doit le présumer. Inscrivez-le dans l'accord.

Les deux flux de remboursement qui demandent des éléments

Seuls deux flux de remboursement demandent quelque chose au développeur. Apple envoie un CONSUMPTION_REQUEST et vous laisse 12 heures pour répondre avec des données de consommation via Send Consumption Information. Google Play envoie un examen de rétrofacturation, et vous avez 24 heures pour répondre via orders.reviewrefund. Les deux réponses sont signées avec des identifiants qui appartiennent à un compte, pas à l'app. C'est là que les transferts cassent.

La chaîne de remboursement qui casse lors d'un transfert

Une app transférée peut continuer à vendre pendant des semaines sans que personne ne remarque que le côté remboursement s'est éteint.

L'URL de notifications et la clé In-App Purchase d'Apple

L'URL App Store Server Notifications se configure app par app, sous App information dans App Store Connect. Le guide de transfert d'Apple n'en parle pas, donc le nouveau propriétaire doit ouvrir cet écran dès le premier jour et pointer la production et le sandbox vers son propre serveur. S'il indique encore l'endpoint du vendeur, chaque CONSUMPTION_REQUEST de l'app arrive sur un serveur que l'acheteur ne gère pas, et les 12 heures s'écoulent en silence.

Les réponses passent par l'App Store Server API, qui nécessite une clé In-App Purchase. Ces clés sont générées sous Users and Access par un Account Holder ou un Admin, et Apple ne permet de télécharger chacune qu'une seule fois. La clé du vendeur se trouve dans le compte du vendeur. L'acheteur doit générer la sienne, et le vendeur doit révoquer la sienne une fois la passation terminée.

Le secret partagé et les webhooks d'Apple

Pour les apps avec des abonnements à renouvellement automatique, Apple demande au vendeur de générer un secret partagé propre à l'app avant le transfert et de le communiquer au destinataire, qui s'en sert pour vérifier les abonnements. Une fois le transfert terminé, le destinataire doit en générer un nouveau pour que des personnes extérieures à son organisation ne l'aient plus. Les webhooks App Store Connect passent aussi au destinataire, et Apple suggère au vendeur de les supprimer avant s'il ne veut plus recevoir d'événements sur son serveur ensuite.

Les autorisations et le projet Cloud chez Google

Google indique que les autorisations et les paramètres d'association des services intégrés ne sont pas transférés. Il demande au vendeur d'ajouter le compte cible comme Owner de tous les projets Google Developers Console qu'utilise l'app. Sur Play, c'est généralement là que se trouvent votre sujet de notifications en temps réel pour les développeurs et le compte de service derrière vos appels à la Developer API. Si le compte de service n'obtient pas d'accès dans la Play Console de l'acheteur, les vérifications d'achats annulés échouent et une réponse orders.reviewrefund ne peut pas partir dans les 24 heures.

Ce qu'un transfert coûte en remboursements et en rétrofacturations

Les mécanismes ci-dessus se traduisent en argent à trois endroits.

Vous servez des utilisateurs qui ont payé le vendeur

Prenons un abonné qui a acheté une formule annuelle à 59,99 $ un mois avant la vente. Sur Google Play, cette commande est sur le compte du vendeur. Sur l'App Store, son historique de paiement reste chez le vendeur. L'acheteur ne touche rien pour lui et assume pourtant le calcul, les appels aux API tierces et le stockage que cet abonné consomme pour le reste de l'année. Si cet abonné demande plus tard un remboursement à l'acheteur, celui-ci ne peut pas l'émettre sur Google Play sans le vendeur. Recensez ces abonnements prépayés à la signature, car c'est un coût que l'acheteur prend en charge sans aucun revenu en face.

Des rétrofacturations sur des commandes que l'acheteur n'a jamais vendues

Pour les commandes Google Play passées après le 3 août 2026, le développeur est redevable du prix d'achat de la rétrofacturation, moins les frais de service de Play, plus les frais de rétrofacturation de la banque. Une rétrofacturation est définitive côté banque une fois tranchée. La page de transfert de Google ne dit pas comment ce coût est traité pour une commande restée sur le compte du vendeur. Tant que Google ne l'a pas précisé, un contrat de cession doit indiquer qui paie une rétrofacturation sur une commande antérieure au transfert, et qui répond à son examen de rétrofacturation.

La tranche à 15 % compte deux fois les mêmes revenus

Les frais de service à 15 % de Google Play s'appliquent au premier million de dollars de revenus d'un développeur chaque année. Quand une app passe d'un compte développeur à un autre dans des Account Groups distincts, tous les revenus de l'app pour l'année civile sont inclus dans le total des deux groupes. L'exemple de Google lui-même est une app qui a généré 100 000 $ dans l'Account Group A et passe à l'Account Group B. Ces 100 000 $ comptent pour le premier million de dollars des deux groupes. Un acheteur proche du seuil peut atteindre le taux standard plus tôt que ne le laisseraient penser ses propres ventes.

Ce qu'il faut régler avant de transférer une app

Pour le vendeur

• Téléchargez les rapports dont vous aurez besoin. L'export groupé, les ventes estimées et les rapports sur les revenus de Google ne sont pas transférés, et le destinataire chez Apple ne verra pas votre historique.
• Gardez le compte d'origine ouvert et joignable jusqu'à ce que les remboursements et les litiges antérieurs au transfert soient arrivés à leur terme.
• Générez et communiquez le secret partagé propre à l'app avant un transfert sur l'App Store, puis révoquez votre clé In-App Purchase et supprimez les webhooks que vous ne voulez plus voir se déclencher.

Pour l'acheteur

• Configurez votre propre URL App Store Server Notifications et générez votre propre clé In-App Purchase dès le premier jour.
• Donnez accès à votre compte de service dans votre Play Console et vérifiez que les notifications en temps réel pour les développeurs arrivent bien sur votre endpoint.
• Demandez la liste des abonnements prépayés et des achats importants récents, pour savoir qui vous servirez sans revenu.
• Inscrivez dans le contrat de cession les remboursements, les rétrofacturations et les examens de rétrofacturation antérieurs au transfert, avec un contact nommé côté vendeur.

RefundHalt se connecte à chaque app avec les identifiants du compte qui la possède. Après un transfert, connectez l'app depuis le compte du nouveau propriétaire, et les demandes de consommation comme les examens de rétrofacturation lui seront acheminés à partir de ce moment.