Store-Fallen #3: Sie dürfen es nicht Spende nennen
2026-05-30
Tags: Windows · Microsoft Store · Store-Fallen
Wieder eine Store-Falle. Diese hat mich wirklich überrascht.
Was passiert ist
Ich habe eine kostenlose Windows-Tool-App. Ich wollte eine Möglichkeit hinzufügen, mit der Nutzer die Entwicklung unterstützen können, also habe ich ein In-App-Add-on erstellt — ein einfacher Kauf namens "Support the Author". Die Store-Listung nannte es eine Sponsor-Option, die In-App-Oberfläche zeigte "Consider buying the dev a coffee", und der Kauf lief über das eigene IAP-System des Microsoft Store.
Die Zertifizierung kam zurück:
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.
Moment — abgelehnt, weil Spenden über die In-App-Kauf-API gesammelt wurden?
Die Richtlinie
Die Microsoft Store-Richtlinie 10.8.2 besagt Folgendes:
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.
Übersetzung: Sie müssen die Microsoft-Zahlungsanfrage-API oder eine sichere Drittanbieter-Kauf-API verwenden, um freiwillige Spenden von Nutzern zu erhalten. Aber wenn der Nutzer im Gegenzug digitale Güter oder Dienstleistungen erhält, einschließlich aber nicht beschränkt auf zusätzliche Funktionen oder die Entfernung von Werbung, müssen Sie stattdessen die Microsoft Store In-App-Kauf-API verwenden.
Hier müssen zwei verschiedene Microsoft-APIs unterschieden werden:
- Microsoft Payment Request API: für allgemeine Zahlungsanfragen, kann Spenden empfangen
- Microsoft Store In-App-Kauf-API: für In-App-Käufe von digitalen Gütern und Dienstleistungen, darf nicht für Spenden verwendet werden
Wann welche API verwenden
Fälle, in denen die Microsoft In-App-Kauf-API zwingend verwendet werden muss
Wenn der Nutzer zahlt und im Gegenzug einen digitalen Vorteil in der App erhält (einschließlich, aber nicht beschränkt auf die folgenden Fälle), muss die In-App-Kauf-API verwendet werden:
- Funktionsfreischaltung: Upgrade von der kostenlosen Version auf Pro, Freischaltung von Premium-Tools, Aktivierung von VIP-Privilegien
- Werbung entfernen: Bezahlung zur dauerhaften oder zeitweisen Entfernung von In-App-Werbung
- Digitale Währung/Artikel: Spielwährung, Diamanten, Skins oder Token/Punkte in einer App
- Abonnementdienste: Monats- oder Jahresabonnements für Mitgliedsdienste
Hinweis: Selbst wenn Sie diese Aktionen als „Sponsoring", „Trinkgeld" oder „Spende" tarnen, wird Microsoft es als „Kauf eines digitalen Produkts" einstufen, solange nach der Zahlung eine der oben genannten digitalen Änderungen ausgelöst wird (z. B. ein exklusives VIP-Abzeichen oder das Entfernen von Pop-ups), und die In-App-Kauf-API muss verwendet werden.
Fälle, in denen die Microsoft In-App-Kauf-API nicht verwendet werden darf
In den folgenden Szenarien wird die Verwendung der In-App-Kauf-API stattdessen zur Ablehnung führen:
- Physische Waren: Verkauf von Kleidung, Büchern, Hardware-Geräten
- Dienstleistungen in der realen Welt: Kinotickets buchen, Essen bestellen, ein Taxi rufen, ein Hotel buchen
- Reine gemeinnützige Spenden/Echtgeld-Glücksspiel: Fundraising für legitimierte Wohltätigkeitsorganisationen oder gesetzlich zulässige Echtgeld-Glücksspiele
- Reines persönliches Trinkgeld (ohne Gegenleistung): Der Nutzer zahlt Ihnen einfach etwas, weil er Ihre Arbeit schätzt, aber in der App gibt es keine Funktions- oder Interface-Änderung. In diesem Fall muss eine Drittanbieter-Zahlung oder die Payment Request API verwendet werden
Ein einfacher Test
Muss sich nach der Zahlung durch den Nutzer die Code-Logik in der App (oder ein Datenbankfeld) ändern?
- Ja (z. B.
isProwird zutrueoderadCountwird zu0) → Microsoft In-App-Kauf-API muss verwendet werden - Nein (keine Code-Änderung, der Nutzer zahlt einfach aus Wertschätzung oder wartet auf die Lieferung einer physischen Ware) → Drittanbieter-Zahlung oder Microsoft Payment Request API muss verwendet werden
Zurück zu meinem Fall
Mein Add-on hieß „Support the Author" mit dem Untertitel „Consider buying the dev a coffee" — vom Wortlaut her ein reines Trinkgeld. Es wurde jedoch über die Store In-App-Kauf-API abgewickelt, und die Richtlinie besagt eindeutig: Reine Trinkgelder dürfen nicht die In-App-Kauf-API nutzen.
Aber tatsächlich würde dieses Add-on dem Nutzer eine Änderung wie ein Unterstützer-Abzeichen geben — mit anderen Worten, es war bereits ein digitales Gut. Nach dem obigen Test: Eine Änderung bedeutet digitales Gut, und digitale Güter sollten über die In-App-Kauf-API abgewickelt werden. Das bedeutet, dass diese Zahlung theoretisch nur über die In-App-Kauf-API laufen darf, nicht über die Payment Request API oder Drittanbieter-Zahlung.
Das Problem lag also gar nicht bei der Zahlungsmethode, sondern bei der Beschreibung. Durch die Änderung von „Support the Author" zu „Upgrade to Pro" und das Ersetzen von „Consider buying the dev a coffee" durch eine Beschreibung der konkreten Gegenleistung wurde es genehmigt.
Fazit
- Die Microsoft In-App-Kauf-API darf nur für Transaktionen mit digitalen Gütern und Dienstleistungen verwendet werden — nach der Zahlung muss eine in-App-Änderung stattfinden
- Reine Trinkgelder (ohne In-App-Änderung) dürfen nicht die In-App-Kauf-API nutzen; stattdessen muss die Payment Request API oder eine Drittanbieter-Zahlung verwendet werden
- Entscheidungsregel: Muss sich nach der Nutzerzahlung der Code/die Datenbank ändern? Änderung → In-App-Kauf-API; keine Änderung → Drittanbieter-Zahlung
- Benennung und Beschreibung müssen zum tatsächlichen Verhalten passen: Wenn es nach der Zahlung eine Änderung gibt, sollte die Gegenleistung klar beschrieben werden — vermeiden Sie Formulierungen wie Spende, Sponsoring oder Trinkgeld
Teil der Store-Fallen-Serie.