Chaque remboursement de mise à niveau d'abonnement est une décision de la boutique, pas la vôtre, et il est prélevé directement sur vos revenus
Quand un client passe à un palier supérieur, la boutique émet un remboursement de mise à niveau d'abonnement pour les jours non utilisés de l'ancien plan, et elle réduit vos revenus de façon automatique. Voici comment fonctionnent les remboursements de mise à niveau sur l'App Store et Google Play, et pourquoi Apple garde le montant hors de votre serveur.
Points clés
- Un remboursement de mise à niveau d'abonnement est automatique. Quand un client passe à un palier supérieur en milieu de cycle, la boutique crédite ou rembourse les jours non utilisés de l'ancien plan sans vous demander, et l'argent sort des revenus que vous aviez déjà comptabilisés.
- Sur l'App Store, une mise à niveau prend effet immédiatement et Apple rembourse le montant au prorata de l'abonnement d'origine. Un passage à un palier inférieur attend la prochaine date de renouvellement et ne rembourse rien.
- Apple n'envoie pas à votre serveur le montant du remboursement de mise à niveau. La transaction de mise à niveau est marquée isUpgraded, mais le champ de prix affiche toujours le prix plein du nouveau palier, donc les revenus que vous calculez à partir des App Store Server Notifications sont gonflés.
- Les rapports financiers d'App Store Connect sont le seul endroit où un remboursement de mise à niveau au prorata est comptabilisé. Le personnel d'Apple affirme que le montant n'est pas disponible via l'App Store Server API, les Notifications ni StoreKit.
- Google Play ne rend pas d'argent sur la carte lors d'une mise à niveau. Il crédite le temps non utilisé ou facture la différence de prix, et laquelle des deux se produit dépend du mode de remplacement que vous définissez. La valeur par défaut est WITH_TIME_PRORATION.
- Un remboursement de mise à niveau n'est pas une demande de remboursement d'un client. Il n'y a pas de CONSUMPTION_REQUEST ni d'examen de rétrofacturation, donc pas de fenêtre de 12 heures ou de 24 heures et rien à contester. Vous le rapprochez, vous ne le combattez pas.
- Le mode de remplacement est une décision de revenus. WITH_TIME_PRORATION remet au client du temps payé supplémentaire que vous fournissez au coût du palier supérieur, tandis que CHARGE_PRORATED_PRICE facture la différence maintenant, donc une mauvaise valeur par défaut perd de la marge une mise à niveau à la fois.
Un client touche mettre à niveau, passe de votre palier à cinq dollars à votre palier à dix dollars, et vous enregistrez une vente plus élevée. La boutique fait autre chose au même instant, et vous ne le voyez jamais. Elle remet à ce client un remboursement de mise à niveau d'abonnement pour les jours qu'il avait déjà payés sur l'ancien plan, et cet argent sort de vos revenus. Personne ne vous a demandé. Sur l'App Store, vous ne trouverez même pas le montant dans les événements que reçoit votre serveur.
Ce n'est pas le remboursement que vous pouvez combattre. Ce n'est pas un CONSUMPTION_REQUEST d'Apple et ce n'est pas un examen de rétrofacturation de Google Play. C'est du calcul au prorata, intégré à la façon dont les deux boutiques laissent les gens changer de plan, et il s'exécute tout seul chaque fois qu'un abonné monte d'un palier. Voici ce qu'est vraiment un remboursement de mise à niveau sur chaque boutique, pourquoi Apple garde le montant hors de votre serveur, et ce que le mauvais réglage de Google Play vous coûte.
Ce qu'est vraiment un remboursement de mise à niveau d'abonnement
Un remboursement de mise à niveau, c'est la boutique qui règle le temps que le client a payé mais n'utilisera pas. Cela n'a rien à voir avec une plainte, un litige ou votre politique de remboursement. Il se déclenche uniquement sur la mécanique du changement de plan.
C'est du calcul au prorata, pas une plainte de client
Quand un abonné passe à un palier supérieur au milieu d'une période de facturation, il a déjà payé jusqu'à la fin de cette période à l'ancien prix. La boutique le dédommage pour la partie non utilisée. Apple émet un remboursement au prorata de l'abonnement d'origine. Google Play crédite la valeur non utilisée sur le nouveau plan. Ni l'un ni l'autre ne passe par un flux auquel vous pouvez répondre, et ni l'un ni l'autre n'attend votre approbation.
Seule une mise à niveau le déclenche
Le sens du changement décide de l'argent. Sur l'App Store, une mise à niveau est un passage vers un produit classé plus haut dans le même groupe d'abonnement, et seul ce passage est immédiat et remboursé. Un passage à un palier inférieur est un passage vers un rang plus bas, et il prend effet au prochain renouvellement sans remboursement. Un passage latéral est un passage entre produits de même rang, et son moment dépend des durées en jeu. Classez mal les produits dans App Store Connect et un changement que vous croyez être une mise à niveau se comportera comme autre chose.
| Changement sur l'App Store | Quand il prend effet | Ce qui arrive à l'argent |
|---|---|---|
| Mise à niveau vers un palier supérieur | Immédiatement | Apple rembourse le montant au prorata de l'abonnement d'origine |
| Passage à un palier inférieur | À la prochaine date de renouvellement | Aucun remboursement, renouvelle au prix inférieur |
| Passage latéral, même durée payée d'avance | Immédiatement | Un nouvel abonnement commence, le service payé continue |
| Passage latéral, durées différentes | À la prochaine date de renouvellement | Aucun remboursement en milieu de cycle |
Pourquoi l'App Store cache le remboursement de mise à niveau à votre serveur
Voici la partie qui casse le suivi des revenus. Apple émet le remboursement de mise à niveau, mais ne dit jamais à votre serveur combien il a remboursé.
isUpgraded est le seul signal, et le prix est faux
La nouvelle transaction arrive avec isUpgraded défini sur true, ce qui vous indique qu'un changement de plan a eu lieu. Le champ de prix de cette transaction affiche toujours le prix d'affichage plein du nouveau palier, pas le montant qu'Apple a récupéré de l'ancien. Aucune App Store Server Notification ne porte le chiffre du remboursement. Selon les propres mots d'Apple sur les forums de développeurs, le montant du remboursement au prorata n'est pas disponible via l'App Store Server API, les Notifications ni StoreKit, et le reporting d'App Store Connect est votre source pour toutes les fins de comptabilité financière.
Le rapport financier est le seul relevé honnête
Les rapports financiers et de ventes d'App Store Connect comptabilisent le remboursement de mise à niveau au prorata, parce que ces rapports déterminent ce qu'Apple vous verse réellement. Cela en fait la source de vérité pour tout abonné qui a un jour monté de palier. Bâtissez votre comptabilité à partir des rapports, et traitez les événements du serveur comme des signaux de droit d'accès, pas comme des revenus.
Ce que cela vous coûte, en argent
Le remboursement de mise à niveau n'est pas une erreur d'arrondi. Ce sont de vrais revenus, et sur Google Play vous choisissez en plus quelle part du temps non utilisé vous cédez.
Le remboursement, ce sont des revenus que vous aviez déjà comptabilisés
Prenez un abonné à votre palier de 9.99 par mois qui passe à 19.99 le jour 20 d'un cycle de 30 jours. Environ un tiers du mois est non utilisé, donc Apple rembourse environ 3.33 des 9.99 d'origine. Vous ne perdez pas toute la vente. Vous rendez la partie que le client a payée d'avance et n'utilisera pas. Ce qui compte, c'est que la restitution est automatique et qu'elle retombe sur l'ancienne vente, donc les revenus que vous aviez déjà comptés diminuent après coup. Multipliez cela par chaque abonné qui monte de palier en milieu de cycle et c'est une ligne que vous devriez pouvoir voir, pas un écart que vous découvrez dans le versement.
Sur Google Play, le mode de remplacement est le vrai levier de coût
Google Play ne rembourse pas d'argent sur la carte lors d'une mise à niveau. Il règle le temps non utilisé de plusieurs façons, et vous choisissez laquelle en passant un mode de remplacement au lancement du flux d'achat. Ce choix décide si vous remettez au client du temps payé ou si vous lui facturez la différence. Google recommande CHARGE_PRORATED_PRICE pour les mises à niveau et DEFERRED pour les passages à un palier inférieur, mais la valeur par défaut de la bibliothèque est WITH_TIME_PRORATION, donc un flux que vous n'avez jamais configuré crédite du temps en silence.
| Mode de remplacement Google Play | Quand il prend effet | Ce qui arrive au temps non utilisé |
|---|---|---|
| WITH_TIME_PRORATION (par défaut) | Immédiatement | Crédité comme temps supplémentaire sur le nouveau plan, la prochaine date de facturation est repoussée |
| CHARGE_PRORATED_PRICE (mise à niveau uniquement) | Immédiatement | La différence de prix pour la période restante est facturée maintenant, la date de facturation ne change pas |
| WITHOUT_PRORATION | Immédiatement | Rien n'est réglé maintenant, le nouveau prix démarre au prochain renouvellement |
| CHARGE_FULL_PRICE | Immédiatement | Le prix plein du nouveau plan est facturé maintenant, la valeur restante est reportée ou calculée au prorata |
| DEFERRED | Au prochain renouvellement | Le plan actuel court jusqu'à son expiration, puis le nouveau plan démarre |
Comment éviter que les remboursements de mise à niveau surprennent votre comptabilité
Vous ne pouvez pas désactiver le calcul au prorata, et vous ne le voudriez pas, car c'est ce qui rend un changement de plan équitable pour le client. Ce que vous pouvez faire, c'est le voir, le chiffrer et le tenir à l'écart des remboursements que vous pouvez réellement contester.
Rapprochez les mises à niveau Apple du rapport financier
Comme le montant du remboursement n'atteint jamais votre serveur, les rapports financiers et de ventes d'App Store Connect sont le seul endroit où un remboursement de mise à niveau au prorata apparaît. Rapprochez les revenus par abonné de ces rapports à chaque période, et ne calculez pas les revenus à partir d'un cumul de Server Notifications. Le marqueur isUpgraded vous dit qu'un changement a eu lieu. Le rapport vous dit combien il a coûté.
Choisissez le mode de remplacement Google Play à dessein
Passez un mode de remplacement pour chaque changement de plan de façon délibérée. Utilisez CHARGE_PRORATED_PRICE quand vous voulez encaisser la différence de prix maintenant sur une mise à niveau. Laissez WITH_TIME_PRORATION en place seulement quand vous voulez vraiment donner au client le temps restant. Utilisez DEFERRED pour les passages à un palier inférieur afin de conserver les revenus actuels jusqu'à la fin du terme. La valeur par défaut est une décision, et la mauvaise valeur par défaut cède de la marge une mise à niveau à la fois.
Gardez les remboursements de mise à niveau distincts des remboursements que vous pouvez contester
Un remboursement de mise à niveau est automatique et définitif par conception. Ce n'est pas un client qui réclame son argent. Les remboursements sur lesquels vous pouvez réellement peser sont ceux lancés par le client, où Apple envoie un CONSUMPTION_REQUEST et vous donne 12 heures pour répondre, et où Google Play ouvre un examen de rétrofacturation via orders.reviewrefund avec une fenêtre de 24 heures. Étiquetez vos données pour que les deux ne se confondent jamais. Une ligne que vous rapprochez. L'autre ligne à laquelle vous répondez, contre la montre.
La version courte
Quand un client met à niveau un abonnement, la boutique règle le temps non utilisé à sa place, de façon automatique. Apple rembourse le montant au prorata de l'ancien plan immédiatement et n'envoie jamais le chiffre à votre serveur, donc les rapports financiers d'App Store Connect sont le seul relevé exact. Google Play crédite le temps ou facture la différence selon le mode de remplacement que vous définissez, et la valeur par défaut remet au client du temps payé que vous fournissez à prix coûtant. Rien de tout cela ne passe par un CONSUMPTION_REQUEST ni par un examen de rétrofacturation, donc il n'y a rien à contester. Rapprochez le remboursement de mise à niveau, réglez votre mode Google Play à dessein, et tenez-le à l'écart des remboursements que vous pouvez encore combattre.
Questions fréquentes
- Un remboursement de mise à niveau d'abonnement demande-t-il mon approbation ?
- Non. Un remboursement de mise à niveau d'abonnement est automatique. Quand un client passe à un palier supérieur en milieu de cycle, la boutique règle le temps non utilisé de l'ancien plan d'elle-même, sans aucune demande vers vous et sans fenêtre pour répondre. Apple rembourse le montant au prorata de l'abonnement d'origine, et Google Play crédite le temps non utilisé ou facture la différence de prix selon le mode de remplacement que vous définissez.
- Pourquoi mes revenus App Store ne correspondent-ils pas à mon versement après des mises à niveau ?
- Parce qu'Apple n'envoie pas à votre serveur le montant du remboursement de mise à niveau. La transaction de mise à niveau porte isUpgraded défini sur true, mais le champ de prix affiche toujours le prix plein du nouveau palier, et aucune App Store Server Notification n'inclut le remboursement. Les revenus calculés à partir des événements du serveur comptent la nouvelle vente et manquent le remboursement de l'ancien plan, donc ils sont gonflés jusqu'à ce que vous les rapprochiez des rapports financiers d'App Store Connect.
- Google Play rend-il de l'argent sur la carte quand un client fait une mise à niveau ?
- Non. Google Play traite le temps non utilisé comme un crédit, pas comme un remboursement en argent. Selon le mode de remplacement, soit il crédite le temps restant sur le nouveau plan et repousse la prochaine date de facturation, soit il facture la différence de prix pour la période restante. Le mode par défaut est WITH_TIME_PRORATION, qui crédite le temps.
- Puis-je contester un remboursement de mise à niveau d'abonnement ?
- Non. Un remboursement de mise à niveau n'est pas une demande de remboursement d'un client. Il n'y a pas de CONSUMPTION_REQUEST d'Apple ni d'examen de rétrofacturation de Google Play, donc pas de fenêtre de 12 heures ou de 24 heures et rien à envoyer. Un remboursement de mise à niveau, vous le rapprochez. Vous ne contestez que les remboursements et les rétrofacturations lancés par le client.
- Un passage à un palier inférieur donne-t-il un remboursement au client ?
- Non. Sur l'App Store, un passage à un palier inférieur prend effet à la prochaine date de renouvellement et ne rembourse rien, puisque le client conserve le niveau supérieur jusqu'à la fin de la période payée. Sur Google Play, la façon recommandée de gérer un passage à un palier inférieur est le mode de remplacement DEFERRED, qui maintient le plan actuel jusqu'à son expiration puis démarre le plan inférieur.
- Quel mode de remplacement Google Play dois-je utiliser pour une mise à niveau ?
- Google recommande CHARGE_PRORATED_PRICE pour les mises à niveau, qui facture la différence de prix pour la période restante immédiatement et laisse la date de facturation inchangée. La valeur par défaut WITH_TIME_PRORATION crédite plutôt le temps non utilisé comme service supplémentaire au palier supérieur, donc utilisez-la seulement quand vous comptez donner ce temps.
Sources et lectures complémentaires
- Apple Developer: Auto-renewable subscriptions (upgrade, downgrade, and crossgrade behavior and prorated refunds)
- Apple Developer Forums: Retrieving the prorated refund amount after an upgrade (Apple staff on isUpgraded, the price field, and financial reports as the source)
- Android Developers: BillingFlowParams.SubscriptionUpdateParams.ReplacementMode (all replacement mode constants)
- Android Developers: About subscriptions (proration, default replacement mode, upgrade and downgrade recommendations)
- Google Play Developer API: Method orders.reviewrefund (chargeback review, 24 hours)
- Apple Developer: Send Consumption Information (CONSUMPTION_REQUEST response window)
RefundHalt
Le pilote automatique des remboursements pour l'App Store et Google Play
Poursuivre la lecture
Les achats intégrés non autorisés par des enfants sont remboursés au parent presque à chaque fois, et c'est vous qui en supportez le coût
Quand un enfant achète un pack de pièces sur le téléphone d'un parent, Apple comme Google le remboursent, et ni l'un ni l'autre ne vous demande votre avis. Les régulateurs l'ont voulu ainsi. Voici comment fonctionnent ces remboursements d'achats intégrés non autorisés sur chaque store, la fenêtre de 15 minutes où l'argent part, et ce qu'un seul de ces achats vous coûte réellement.
Vous n'avez jamais possédé le app refund tax, alors un remboursement vous coûte votre part, pas le total du reçu
Remboursez un achat intégré et le reçu affiche le prix majoré de la taxe qui revient. Cette taxe n'a jamais été votre argent. Apple et Google la perçoivent et la reversent en tant que merchant of record, puis l'annulent lors d'un remboursement sans toucher à votre part. Voici ce qu'un remboursement coûte réellement, et la seule configuration où la taxe devient la vôtre.