La vraie limite de temps du remboursement d'une app n'est pas 48 heures, ce sont les mois pendant lesquels vos revenus restent réversibles

Demandez à un développeur combien de temps un client a pour obtenir un remboursement et la plupart diront 48 heures. C'est le nombre que Google Play met devant les acheteurs, et c'est celui qui reste. C'est aussi la plus petite horloge de la pièce. La vraie limite de temps du remboursement d'une app n'est pas une seule fenêtre, c'est une pile d'entre elles, et la plus haute atteint des mois après la vente. Apple acceptera une demande de remboursement jusqu'à 90 jours. Une banque peut annuler un débit Google Play jusqu'à 120 jours après qu'il a été réglé. Tant que chacune de ces horloges n'est pas écoulée, l'argent de votre versement n'est pas définitif, il est réversible. Voici chaque horloge, qui la contrôle et ce que cette longue traîne vous coûte.

Ce qu'est vraiment la limite de temps du remboursement d'une app

Deux questions se cachent dans la limite de temps du remboursement d'une app, et les confondre est là où les ennuis commencent. La première est combien de temps un client a pour demander son argent. La seconde est combien de temps votre argent reste exposé à être repris. La première est un chiffre court et sympathique que la boutique annonce. La seconde est un chiffre bien plus long que la boutique n'affiche pas sur une affiche.

Le chiffre de 48 heures que tout le monde cite

Le remboursement en libre-service de Google Play court sur 48 heures à partir de l'achat. Dans cette fenêtre un client appuie sur un bouton et Google décide, sans le développeur. Google est direct sur les limites qui l'entourent. Selon ses propres mots, Google ne rembourse pas la plupart des achats Google Play, vous ne pouvez retourner une app ou un jeu qu'une seule fois, et émettre un remboursement retire l'accès du client à l'article. Apple n'a aucun bouton de libre-service équivalent. Donc le chiffre de 48 heures que les gens citent est un nombre exclusif à Google et uniquement en libre-service, et c'est le début de l'histoire, pas l'ensemble.

Les horloges qui continuent à tourner après 48 heures

Une fois la fenêtre de libre-service fermée, trois horloges plus longues tournent encore. Sur Google Play la demande est acheminée vers vous, le développeur, et vous pouvez rembourser une commande jusqu'à trois ans via l'API orders.refund. Sur l'App Store un client peut encore déposer une demande auprès d'Apple jusqu'à 90 jours à partir de l'achat. Et sous les deux boutiques se trouve la banque, qui peut annuler un débit de carte ou PayPal jusqu'à 120 jours après qu'il a été réglé. Le tableau ci-dessous les aligne.

Apple ne propose aucun libre-service, juste une longue fenêtre de demande

Apple garde chaque décision de remboursement en interne. Un client n'obtient pas de bouton de libre-service, et il ne peut pas non plus venir vous voir pour un remboursement, car vous n'avez aucun moyen d'en émettre un. Il va chez Apple, et Apple tranche.

Le client dépose, Apple décide

Le chemin est toujours le même. Un client ouvre reportaproblem.apple.com, choisit l'achat et donne un motif. Apple examine la demande au regard de ses propres signaux et envoie une décision par e-mail, généralement en 24 à 48 heures. Apple accepte ces demandes jusqu'à 90 jours à partir de la date d'achat, et l'éligibilité peut varier selon le pays au titre des Apple Media Services Terms. On ne vous demande d'approuver quoi que ce soit. Votre serveur n'apprend le résultat qu'après coup, sous forme de notification REFUND, REFUND_DECLINED ou REFUND_REVERSED.

La seule horloge qui est la vôtre, 12 heures

Il y a exactement un moment où Apple demande votre version, et il est court. Quand un remboursement est en question pour un achat éligible, Apple envoie à votre serveur un CONSUMPTION_REQUEST et vous donne 12 heures pour répondre via le point de terminaison Send Consumption Information. Vous envoyez des données de consommation et une refundPreference. Apple le traite comme l'un de plusieurs facteurs, pas un verdict, puis décide. Ratez les 12 heures et Apple décide sans rien de votre part. Cette fenêtre se situe à l'intérieur de la fenêtre de 90 jours du client, mais elle s'ouvre selon le calendrier d'Apple, pas le vôtre, elle doit donc être automatisée pour être saisie.

Google Play empile trois fenêtres les unes sur les autres

Google Play est là où l'empilement est le plus facile à voir, car chaque étape passe le relais à un décideur différent.

48 heures pour le client, puis ça vous revient

Pendant les 48 premières heures le client se sert lui-même et Google décide. Après cela, la consigne de Google est de contacter le développeur, et la balle est dans votre camp. Vous pouvez émettre un remboursement vous-même via orders.refund sur toute commande de moins de trois ans, avec ou sans révocation de l'accès. C'est de la discrétion, pas une obligation, mais c'est aussi l'étape où une commande fragile est la moins coûteuse à clore, car un remboursement que vous émettez rend le prix d'achat et rien de plus.

La fenêtre de débit non autorisé va jusqu'à 120 jours

Distinct du flux de remboursement, Google gère un canal de litige pour les débits qu'un client ne reconnaît pas. Google déclare qu'il ne peut agir sur les transactions de crédit, de débit ou PayPal que dans les 120 jours de la transaction, et sur la facturation opérateur que dans les 60 jours. Un client qui repère votre ligne sur un relevé deux mois plus tard a encore une voie active pour l'annuler. C'est l'horloge silencieuse que la plupart des modèles de revenus ignorent.

24 heures pour défendre une rétrofacturation

Quand un client contourne Google entièrement et conteste le débit auprès de sa banque, Google envoie un examen de rétrofacturation et vous donne 24 heures pour répondre via l'API orders.reviewrefund. Comme la réponse de consommation d'Apple, c'est une preuve, pas un veto. C'est aussi le seul flux de remboursement Android qui demande votre contribution, la contrepartie directe du CONSUMPTION_REQUEST d'Apple.

La rétrofacturation est l'horloge la plus longue, et la boutique ne peut pas la fermer

Chaque fenêtre ci-dessus sauf la rétrofacturation appartient à la boutique, et on peut raisonner avec la boutique. La rétrofacturation appartient à la banque. Un client peut contourner la boutique entièrement, appeler son émetteur de carte et lancer un litige des mois après l'achat. Le propre chiffre de Google de 120 jours pour les litiges de carte et PayPal est un bon repère de la durée de cette traîne, et les règles des réseaux de cartes peuvent l'étirer davantage dans des cas précis. Une rétrofacturation est définitive avec la banque une fois qu'elle arrive, ce qui signifie que la seule vraie défense est la fenêtre de preuve de 24 heures avant qu'elle ne se règle, ou émettre un remboursement vous-même avant que le client n'appelle la banque.

Ce que la longue traîne vous coûte

La longueur de la traîne compte parce qu'une annulation n'est jamais seulement le prix de vente qui ressort.

L'argent est déjà dépensé au moment où l'horloge s'écoule

Au moment où un remboursement ou une rétrofacturation arrive, des semaines ou des mois plus tard, vous avez livré l'achat depuis longtemps. Le calcul a tourné, les appels aux API tierces ont été facturés, le stockage a été écrit, et tout versement à un créateur est parti. Cette dépense est perdue et ne revient pas avec l'annulation. Plus la fenêtre est longue, plus vous avez accumulé de ces coûts avant que l'argent ne soit repris.

• Le prix de vente : vos revenus nets après la commission de la boutique, annulés quand le remboursement ou la rétrofacturation passe.
• Le coût de livraison : calcul, appels d'API, stockage et versements que vous avez déjà dépensés pour servir l'achat. Perdus quel que soit le résultat.
• Les frais de rétrofacturation : sur Google Play, pour les commandes passées le 3 août 2026 ou après, les frais de rétrofacturation de la banque sont désormais les vôtres aussi.
• L'angle mort : des revenus que vous avez comptés comme définitifs sur une période, annulés sur la suivante, donc vos chiffres n'ont jamais été aussi solides qu'ils en avaient l'air.

Le changement du 3 août rend la traîne Google plus coûteuse

Jusqu'à récemment une rétrofacturation perdue sur Google Play coûtait au développeur la vente et pas grand-chose d'autre. Pour les commandes passées le 3 août 2026 ou après, cela change. Le développeur absorbe le prix d'achat moins les frais de service de Play, plus les frais de rétrofacturation de la banque, tandis que Google ne couvre que ses propres frais de service. Comme les frais de rétrofacturation sont fixes et que les prix des produits ne le sont pas, sur un achat intégré bon marché les frais seuls peuvent dépasser ce que le client a payé. La fenêtre de rétrofacturation de 120 jours a toujours été un risque. Après le 3 août c'est un risque avec des frais attachés.

RefundHalt surveille chacune de ces horloges pour que vous n'ayez pas à le faire. Il attrape le CONSUMPTION_REQUEST d'Apple dans la fenêtre de 12 heures et l'examen de rétrofacturation de Google Play dans la fenêtre de 24 heures, rassemble les preuves de consommation et de livraison, et répond à temps sans que personne dans votre équipe ne surveille une notification à 3h du matin. Il suit la traîne de réversibilité de vos revenus, pour qu'une vente qui s'annule 90 ou 120 jours plus tard soit un chiffre que vous avez vu venir, pas une surprise dans le versement du trimestre suivant. Vous ne pouvez pas raccourcir la fenêtre de remboursement d'un client. Vous pouvez faire en sorte que rien ne s'annule sans votre version de l'histoire.