Pièges du Store #3 : Vous ne pouvez pas l'appeler un don
2026-05-30
Tags: Windows · Microsoft Store · Pièges du Store
Encore un piège du Store. Celui-ci m'a vraiment surpris.
Ce qui s'est passé
J'ai une application outil Windows gratuite. Je voulais ajouter un moyen pour les utilisateurs de soutenir le développement, alors j'ai créé un module complémentaire in-app — un simple achat "Support the Author". La fiche du Store le décrivait comme une option de sponsor, l'interface in-app affichait "Consider buying the dev a coffee", et l'achat passait par le propre système IAP du Microsoft Store.
Le résultat de la certification est revenu :
Status: Attention needed
10.8.2 Third-Party In-Product Purchases
Any developer donations must only be made through a secure third-party purchase processing API. Please use one of those methods or remove any donation options that use the Microsoft API.
Attendez — rejeté pour avoir collecté des dons via l'API d'achat in-app ?
La politique
La politique du Microsoft Store 10.8.2 indique ce qui suit :
You must use the Microsoft payment request API or a secure third-party purchase API to receive voluntary donations from users. However, if the user receives digital goods or services in return, including but not limited to additional features or removal of advertising, you must use the Microsoft Store in-product purchase API instead.
Traduction : Vous devez utiliser l'API de demande de paiement Microsoft ou une API d'achat tierce sécurisée pour recevoir des dons volontaires des utilisateurs. Cependant, si l'utilisateur reçoit en retour des biens ou services numériques, y compris mais sans s'y limiter des fonctionnalités supplémentaires ou la suppression de la publicité, vous devez utiliser l'API d'achat in-app du Microsoft Store à la place.
Il faut distinguer ici deux API Microsoft différentes :
- API Microsoft Payment Request : pour les demandes de paiement générales, peut recevoir des dons
- API Microsoft Store In-App Purchase : pour les achats in-app de biens et services numériques, ne peut pas être utilisée pour recevoir des dons
Quand utiliser quelle API
Cas où l'API d'achat in-app Microsoft est obligatoire
Si l'utilisateur paie et reçoit en retour un avantage numérique dans l'application (y compris, mais sans s'y limiter, les cas suivants), l'API d'achat in-app doit être utilisée :
- Déblocage de fonctionnalités : passage de la version gratuite à Pro, déblocage d'outils premium, activation de privilèges VIP
- Suppression de la publicité : paiement pour supprimer définitivement ou temporairement les publicités dans l'application
- Monnaie/objets numériques : pièces, diamants, skins dans un jeu, ou jetons/points dans une application
- Services d'abonnement : abonnements mensuels ou annuels pour des services membres
Remarque : même si vous déguisez ces actions en « sponsoring », « pourboire » ou « don », Microsoft les considérera comme un « achat de produit numérique » dès lors qu'un des changements numériques ci-dessus est déclenché après le paiement (par exemple, un badge VIP exclusif ou la suppression de pop-ups), et l'API d'achat in-app devra être utilisée.
Cas où l'API d'achat in-app Microsoft ne doit pas être utilisée
Dans les scénarios suivants, l'utilisation de l'API d'achat in-app entraînera au contraire un rejet :
- Biens physiques : vente de vêtements, de livres, de matériel informatique
- Services dans le monde réel : réservation de billets de cinéma, commande de repas, appel de taxi, réservation d'hôtel
- Dons caritatifs purs/jeux d'argent réels : collecte de fonds pour des organismes de bienfaisance agréés ou jeux d'argent en argent réel légalement autorisés
- Pourboire personnel pur (sans contrepartie) : l'utilisateur vous donne simplement de l'argent parce qu'il apprécie votre travail, mais il n'y a aucun changement de fonctionnalité ou d'interface dans l'application. Dans ce cas, un paiement tiers ou l'API Payment Request doit être utilisé
Un test simple
Est-ce que la logique du code dans l'application (ou un champ de base de données) doit changer après le paiement de l'utilisateur ?
- Oui (par exemple
isProdevienttrue, ouadCountdevient0) → L'API d'achat in-app Microsoft doit être utilisée - Non (aucun changement de code, l'utilisateur paie simplement par appréciation ou attend la livraison d'un bien physique) → Un paiement tiers ou l'API Microsoft Payment Request doit être utilisé
Revenons à mon cas
Mon module s'appelait « Support the Author » avec le slogan « Consider buying the dev a coffee » — du point de vue du libellé, c'était un pur pourboire. Mais il passait par l'API d'achat in-app du Store, et la politique stipule clairement : les pourboires purs ne peuvent pas utiliser l'API d'achat in-app.
Mais en réalité, ce module donnait à l'utilisateur un changement comme un badge de supporteur — en d'autres termes, c'était déjà un bien numérique. Selon le test ci-dessus : un changement signifie un bien numérique, et les biens numériques doivent passer par l'API d'achat in-app. Cela signifie que ce paiement ne pouvait théoriquement passer que par l'API d'achat in-app, et non par l'API Payment Request ou un paiement tiers.
Le problème n'était donc pas la méthode de paiement, mais la description. En remplaçant « Support the Author » par « Upgrade to Pro » et en remplaçant « Consider buying the dev a coffee » par une description de la contrepartie concrète, ça a été approuvé.
En résumé
- L'API d'achat in-app Microsoft ne peut être utilisée que pour les transactions de biens et services numériques — un changement in-app doit avoir lieu après le paiement
- Les pourboires purs (sans changement in-app) ne peuvent pas utiliser l'API d'achat in-app ; l'API Payment Request ou un paiement tiers doit être utilisé à la place
- Règle de décision : le code/la base de données doit-il changer après le paiement de l'utilisateur ? Changement → API d'achat in-app ; pas de changement → paiement tiers
- Le nom et la description doivent correspondre au comportement réel : s'il y a un changement après le paiement, décrivez clairement la contrepartie — évitez les termes don, sponsoring ou pourboire
Partie de la série Pièges du Store.