Qui paie un remboursement sur votre app, c'est surtout vous, mais pas pour la commission que vous croyez perdre

Il y a une croyance qui ne meurt pas sur les forums de développeurs : vous gardez 70 pour cent d'une vente, mais un remboursement vous fait rendre 100 pour cent, donc chaque remboursement vous coûte en silence la part de la boutique. C'est faux. Quand Apple ou Google rembourse l'un de vos clients, la boutique rend aussi sa commission, et votre comptabilité n'annule que la part que vous aviez réellement gardée. Alors la réponse honnête à qui paie un remboursement sur votre app, c'est vous, mais pour une facture différente de celle que la plupart des gens citent. Vous perdez la vente et tout ce que vous avez déjà dépensé pour la livrer, pas 30 pour cent de plus pour la boutique. Voici où va vraiment l'argent, ligne par ligne, et pourquoi un type d'annulation, le chargeback, casse la règle.

Qui paie un remboursement, réparti par boutique

Commencez par l'annulation elle-même, avant de parler des coûts de livraison. Un remboursement sur l'App Store et un remboursement sur Google Play défont la vente de la même façon au niveau comptable : la boutique cesse de vous facturer sa commission et vous rendez votre produit net. Le client récupère son prix complet dans les deux cas. Voici la répartition, par boutique.

Apple garde-t-elle sa commission quand un client est remboursé ?

C'est la question que les développeurs posent le plus, sur les Apple Developer Forums et sur Hacker News : si Apple rembourse un acheteur, garde-t-elle la part qu'elle a prise sur la vente ? Lisez le rapport financier et la réponse est non. Un remboursement apparaît comme une ligne avec Sale or Return réglé sur R et une Quantity négative, et l'argent annulé est l'Extended Partner Share, Quantity fois Partner Share, où Partner Share est le prix client moins la taxe et la commission d'Apple. Apple reprend ce qu'elle vous a payé, votre produit net, pas le prix brut. Les développeurs qui ont sorti leurs propres rapports détaillés ont trouvé la même chose : Apple a déduit le montant après commission, pas la vente complète.

Il y a un piège dans les petits caractères. Le Paid Applications Agreement d'Apple dit qu'Apple a le droit de retenir sa commission sur une vente malgré un remboursement à l'utilisateur final. Donc le fait de la rendre est la façon dont les rapports sont soldés en pratique, pas une promesse. Apple garde l'option contractuelle de retenir sa part, et la lecture courante est qu'elle le fait quand elle décide qu'un développeur fait quelque chose de mal.

Ce que Google rend, et ce qu'un chargeback garde ensuite

Google est plus explicite par écrit. Son aide sur la gestion des commandes dit que quand vous remboursez une commande, Google vous rend les frais de service et vous les voyez sur votre prochain rapport de revenus. Le moment est lié à votre versement. Remboursez une commande avant que Google ne vous l'ait payée et vous ne recevez tout simplement jamais ce montant dans votre prochain versement. Remboursez-la après avoir été payé et le montant est déduit d'un versement futur. Les remboursements partiels s'ajustent : remboursez la moitié d'une commande et la moitié de votre versement comme des frais de service revient à l'acheteur.

C'est le cas propre. Un chargeback n'est pas propre, et c'est le seul endroit où la boutique cesse de rendre sa part comme le fait un simple remboursement.

Ce qui quitte vraiment votre compte

Alors si la commission revient, pourquoi un remboursement fait-il encore mal ? Parce que le prix de vente n'a jamais été le coût entier de ce client. Suivez l'argent en deux parts.

La première part, c'est la vente elle-même. Sur un remboursement, elle se solde près de zéro. Le client récupère son argent, la boutique rend sa commission et vous annulez votre produit. Vous perdez le bénéfice que vous aviez enregistré, ce qui compte à grande échelle, mais vous ne payez pas de pénalité à la plateforme.

La seconde part est celle que les rapports ne montrent jamais. C'est tout ce que vous avez déjà dépensé pour transformer ce paiement en produit livré, et rien de tout cela ne s'annule quand le paiement s'annule.

• Le calcul que vous avez déjà lancé : les secondes de GPU derrière une image, une vidéo ou une réponse de modèle générée que le client a déjà reçue.
• Les appels d'API que vous avez déjà payés : chaque requête tierce, d'une recherche cartographique à un token de LLM, facturée dès qu'elle est partie.
• Le stockage que vous payez encore : les fichiers, les exports et l'historique que le client a créés et que vous continuez d'héberger.
• Les versements que vous avez déjà envoyés : la part du créateur, du chauffeur ou du vendeur que vous avez versée sur une vente qui vient de s'annuler.

Additionnez tout ça et un client remboursé peut coûter plus après le remboursement qu'un client qui n'a jamais acheté. La vente s'efface. La dépense derrière elle, non.

Comment un remboursement traverse votre versement

Les remboursements ne vous sont pas facturés à part. Ils passent par le même règlement mensuel que vos ventes, c'est pourquoi un mois chargé en remboursements peut réduire un versement sur lequel vous comptiez déjà.

Sur l'App Store

Apple génère un rapport financier pour chaque mois fiscal, et les remboursements sont enregistrés dans le mois où ils sont soldés, sous forme de lignes Return négatives. Le rapport d'un mois fiscal est disponible dès le premier vendredi du suivant. Un remboursement émis ce mois-ci réduit le produit de ce mois-ci. Il n'y a pas de facture séparée, juste un nombre plus petit.

Sur Google Play

Google met chaque mouvement sur votre rapport de revenus comme sa propre ligne, une pour un débit, une pour des frais, une pour un remboursement. Si le remboursement arrive avant votre versement pour cette commande, le revenu de la commande n'arrive jamais. S'il arrive après, le remboursement est soustrait d'un versement ultérieur. Dans les deux cas, il sort des revenus, pas d'une facture que vous payez.

La seule ligne de votre rapport qui est le remboursement

Chez Apple, filtrez sur Sale or Return égal à R. Chacune de ces lignes est de l'argent qui part. Chez Google, cherchez le type de transaction de remboursement sur le rapport de revenus et la ligne correspondante de frais de service rendus. Rapprocher cela de vos propres événements de remboursement, c'est ainsi que vous attrapez un client qui a été remboursé mais n'a jamais perdu l'accès, ce qui est la panne qui transforme un remboursement bon marché en un remboursement cher.

Pourquoi un chargeback coûte plus cher qu'un remboursement

Mettez les deux côte à côte et la différence, c'est la banque. Sur un remboursement normal de Google Play, les frais de service reviennent et vous ne perdez que votre part d'une vente qui s'est annulée. Sur un chargeback sous la politique du 3 août 2026, vous perdez le prix d'achat moins les frais de service, et les frais de chargeback de l'établissement financier en plus. La même vente perdue, plus des frais qui n'existent que parce qu'une banque, et non une boutique, a traité l'annulation.

Le côté d'Apple a son propre tranchant. Un chargeback, ou un remboursement qu'Apple accorde après un CONSUMPTION_REQUEST auquel vous avez répondu en retard, annule quand même votre produit, et Apple garde le droit contractuel de retenir sa commission si elle décide que le schéma ressemble à un abus. Le calcul du remboursement simple, où la boutique rend sa part, ne tient que tant que rien dans la transaction ne semble anormal.

Ce que vous pouvez vraiment contrôler

Vous ne pouvez pas décider si un remboursement a lieu. Les deux boutiques se le réservent. Vous pouvez décider combien chacun coûte après son déclenchement.

• Coupez l'accès dès que l'annulation arrive. Un client remboursé ou en chargeback qui continue de générer des résultats, d'appeler vos API et de remplir votre stockage transforme une annulation à l'équilibre en une facture qui gonfle.
• Répondez à temps aux deux fenêtres de preuve. Le CONSUMPTION_REQUEST d'Apple vous donne 12 heures pour envoyer les données de consommation. L'orders.reviewrefund de Google vous donne 24 heures pour contester un chargeback. Ce sont les seuls moments où votre version des faits compte.
• Rapprochez les remboursements de vos propres registres chaque mois, pour qu'une annulation qui n'a pas révoqué l'accès apparaisse comme une ligne sur laquelle vous pouvez agir, pas comme une fuite lente.

Rien de tout cela ne change qui paie un remboursement. Cela change l'ampleur de la facture au moment où vous finissez de la payer.