Le remboursement d'une app payante n'atteint jamais votre serveur, c'est donc l'app elle-même qui doit le détecter

Les apps payantes à l'achat sont remboursées par une porte dérobée que la plupart des outils de remboursement ne surveillent jamais. Quand un acheteur retourne l'app elle-même, et non un élément acheté à l'intérieur, Apple et Google reprennent l'argent sur votre versement sans envoyer la moindre notification à votre serveur. Google, au moins, désinstalle l'app. Sur iOS, des développeurs signalent sur les forums d'Apple que les acheteurs remboursés continuent de l'utiliser. Si vous vendez une app payante, son remboursement est le seul que vous ne verrez jamais autrement que comme une ligne négative dans un rapport, à moins que l'app ne le vérifie sur l'appareil.

Règles de remboursement des apps payantes sur Google Play et l'App Store

Les deux stores traitent l'achat du téléchargement comme un produit à part, avec ses propres règles. Voici ce que dit la documentation de chacun.

Comment fonctionne le retour de deux heures sur Google Play

L'aide de la Play Console de Google est claire : après l'achat d'une app payante, l'utilisateur dispose de deux heures maximum pour la retourner contre un remboursement intégral, et il ne peut retourner une app qu'une seule fois. La politique de remboursement de Google pour les consommateurs ajoute que, dans les 48 heures, un acheteur peut obtenir un remboursement selon l'achat, que l'app est désinstallée dans le cadre du remboursement et qu'une personne qui rachète la même app ne peut pas être remboursée pour celle-ci. Passé 48 heures, Google renvoie les acheteurs vers le développeur.

Comment Apple rembourse une app payante

Sur l'App Store, l'acheteur fait sa demande à Apple via reportaproblem.apple.com, choisit un motif et sélectionne l'app. Apple annonce une réponse sous 24 à 48 heures. Vous ne pouvez pas rembourser vous-même un achat sur l'App Store. C'est votre contrat qui fixe la limite extérieure. La section 6.3 du Schedule 2 de l'Apple Developer Program License Agreement prévoit que, si un acheteur souhaite annuler dans les quatre-vingt-dix jours suivant le téléchargement, ou si l'app n'est pas conforme à vos spécifications ou à la loi applicable, Apple peut rembourser l'intégralité du prix, et vous remboursez Apple ou lui accordez un avoir de ce montant.

Pourquoi votre serveur n'apprend jamais le remboursement d'une app payante

Tous les signaux de remboursement envoyés par les deux stores sont conçus pour les achats intégrés. Apple décrit son notificationType comme l'événement d'In-App Purchase ou d'achat externe à l'origine de la notification. Son type REFUND couvre un consommable, un non-consommable, un abonnement à renouvellement automatique ou un abonnement sans renouvellement. Get Refund History renvoie les achats intégrés remboursés d'un client. Le téléchargement de l'app ne figure sur aucune de ces listes.

Même chose chez Google. Les notifications en temps réel pour les développeurs couvrent les abonnements, les produits ponctuels et les achats annulés, et le productType d'un achat annulé est soit un abonnement, soit un achat ponctuel. La Voided Purchases API précise qu'elle s'applique aux commandes intégrées ponctuelles et aux abonnements, et ne remonte que sur 30 jours.

Le remboursement d'une app payante déclenche-t-il un CONSUMPTION_REQUEST ?

Non. La documentation d'Apple indique qu'elle envoie CONSUMPTION_REQUEST lorsqu'un client demande le remboursement d'un In-App Purchase consommable ou d'un abonnement à renouvellement automatique. C'est l'un des deux seuls flux de remboursement, tous stores confondus, qui demandent des preuves au développeur. L'autre est l'examen des rétrofacturations de Google Play, auquel on répond via orders.reviewrefund dans les 24 heures, et il arrive par le même flux de notifications d'achats intégrés. Aucun des deux n'est documenté pour les téléchargements d'apps. Le remboursement d'une app payante est tranché sans rien que vous puissiez transmettre.

L'acheteur remboursé continue-t-il d'utiliser l'app ?

Sur Google Play, la politique indique que l'app est désinstallée. Sur iOS, les forums d'Apple contiennent des fils de développeurs qui posent exactement cette question. L'un, de mars 2025, dit : « Quand un utilisateur se fait rembourser une app payante à l'achat, il a toujours accès à l'app. » Un autre, de 2022, soupçonne des acheteurs d'acheter, d'installer, de se faire rembourser et de continuer comme si de rien n'était. Un troisième, de juin 2025, demande si App Store Server Notifications V2 signale seulement les remboursements au niveau de l'app. Aucun des trois n'a obtenu de réponse d'Apple.

Ce que vous coûte en argent le remboursement d'une app payante

Côté versement, c'est prévisible. L'aide de la Play Console de Google indique qu'elle restitue ses frais de service quand vous remboursez, donc la déduction sur votre versement correspond à votre part, pas au prix affiché. Un remboursement émis après que Google vous a payé est prélevé sur un versement futur, et si votre solde reste négatif pendant au moins 48 heures, Google peut débiter votre compte bancaire. Côté Apple, le contrat prévoit que vous remboursez un montant égal au prix. En pratique, RevenueCat a signalé en 2022 qu'Apple déduisait le montant net de commission affiché comme Extended Partner Share, de sorte qu'Apple ne conservait pas sa part.

Les coûts qui ne reviennent pas sont ceux que vous avez engagés pour servir cet acheteur. Voici un exemple illustratif. Une app photo payante à $6.99 applique ses filtres via un modèle dans le cloud et synchronise les projets vers un stockage cloud. Vous avez payé une publicité qui a amené l'acheteur.

C'est sur cette dernière ligne qu'iOS coûte cher. Un acheteur remboursé qui garde l'app continue d'appeler votre backend, et chaque requête d'inférence, chaque synchronisation et chaque appel d'API après le remboursement est un coût sans aucun revenu en face. Pour une app payante sans coûts serveur, un remboursement est une vente perdue. Pour une app avec backend, il peut devenir une facture qui court.

Comment détecter le remboursement d'une app payante dans l'app

Comme le serveur ne reçoit rien, la vérification doit partir de l'appareil, puis prévenir votre serveur.

Sur iOS, lisez revocationDate sur AppTransaction

AppTransaction est l'enregistrement signé par l'App Store de l'achat de l'app par le client. La documentation StoreKit d'Apple y mentionne désormais une propriété revocationDate, décrite comme la date de révocation de l'achat de l'app. Lisez AppTransaction.shared au lancement, vérifiez le résultat et traitez un revocationDate non nil comme un téléchargement remboursé. Envoyez la valeur signée à votre serveur pour qu'il cesse de servir ce compte.

• Selon Apple, appTransactionID reste identique pour un Apple Account même après un remboursement ou un rachat, donc indexez vos enregistrements dessus et un acheteur qui paie à nouveau sera reconnu.
• AppTransaction.refresh() récupère un enregistrement à jour auprès de l'App Store, mais affiche une demande de connexion. Apple recommande de ne l'appeler qu'après une action explicite de l'utilisateur, comme un appui sur un bouton Restaurer.
• La valeur signée vit sur l'appareil. La documentation d'Apple ne décrit aucune notification serveur pour elle, donc votre serveur ne sait que ce que l'app lui signale.

Sur Android, demandez à Play Integrity le verdict de licence

La désinstallation par Google règle la plupart des cas, mais une copie peut y survivre, par exemple une app installée manuellement depuis une sauvegarde. La Play Integrity API renvoie un appLicensingVerdict pour le compte connecté. LICENSED signifie que l'utilisateur dispose d'un droit sur l'app. UNLICENSED signifie qu'il n'en a pas, et Google suggère d'afficher la boîte de dialogue GET_LICENSED. UNEVALUATED signifie que Google n'a pas pu vérifier, par exemple parce que l'utilisateur n'est pas connecté à Google Play. Google précise aussi que, sur certains appareils anciens, l'utilisateur conserve son droit après la désinstallation, donc LICENSED ne prouve pas un achat valide sur tous les appareils.

Faites du serveur le gardien

Les vérifications côté client peuvent être contournées par un patch. Ce qui mérite d'être protégé, c'est le travail payant effectué par votre backend : faites en sorte qu'il refuse les appels d'un compte dont le dernier rapport était un remboursement, un verdict UNLICENSED, ou aucun verdict au-delà d'une période de grâce que vous choisissez. C'est ce qui empêche un remboursement de se transformer en calcul gratuit.

Quand une app payante devrait passer aux achats intégrés

Les recommandations d'Apple sur le changement de modèle économique décrivent le passage d'une app payante à une app gratuite avec In-App Purchases, en utilisant originalAppVersion sur AppTransaction pour continuer d'offrir les fonctionnalités premium à ceux qui ont acheté la version payante. L'avantage de ce changement en matière de remboursements est concret. Dès que le prix porte sur un non-consommable ou un abonnement, les remboursements arrivent sous forme de notifications REFUND et d'achats annulés sur lesquels votre serveur peut agir, et une demande de remboursement d'abonnement sur l'App Store déclenche un CONSUMPTION_REQUEST. Ce sont les signaux que RefundHalt écoute et auxquels il répond dans les fenêtres de 12 heures et de 24 heures. Un téléchargement payant ne vous en donne aucun.