Store Pitfalls #3: You Can't Call It a Donation
2026-05-30
Tags: Windows · Microsoft Store · Store Pitfalls
Another Store Pitfall. This one caught me by surprise.
What Happened
I have a free Windows tool app. I wanted to add a way for users to support development, so I created an in-app add-on — a simple "Support the Author" purchase. The Store listing called it a sponsor option, the in-app UI said "Consider buying the dev a coffee," and the purchase went through the Microsoft Store's own IAP system.
Certification came back:
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.
Wait — rejected for collecting donations through the in-product purchase API?
The Policy
Microsoft Store policy 10.8.2 states:
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.
Note the two different Microsoft APIs here:
- Microsoft Payment Request API: for general payment requests, can receive donations
- Microsoft Store In-Product Purchase API: for digital goods and services, cannot be used to receive donations
When to Use Which API
When you MUST use the In-Product Purchase API
If the user pays and receives any digital benefit (including but not limited to the following), you must use the In-Product Purchase API:
- Feature unlocks: upgrading from free to Pro, unlocking advanced tools, enabling VIP perks
- Ad removal: paying to permanently or periodically remove ads
- Digital currency/items: in-game coins, diamonds, skins, or app tokens/credits
- Subscriptions: monthly or yearly membership services
Note: even if you label these as "sponsorship," "tip," or "donation," as long as the payment triggers any digital change (e.g., a VIP badge appears, popups disappear), Microsoft considers it a "digital product purchase" that must go through the In-Product Purchase API.
When you MUST NOT use the In-Product Purchase API
Using the In-Product Purchase API for these scenarios will get you rejected:
- Physical goods: selling clothes, books, hardware
- Real-world services: booking movie tickets, ordering food, booking hotels
- Charitable donations / real-world gambling: fundraising for charities, or legally permitted real-money gambling
- Pure personal tips (no return): users just want to support you, but the app has no feature or UI changes. This must go through a third-party payment processor or the Payment Request API
A Simple Test
After the user pays, does the app's code logic (or database field) need to change?
- Yes (e.g.,
isProbecomestrue, oradCountbecomes0) → must use the In-Product Purchase API - No (no code changes — the user is just showing love, or waiting for a physical delivery) → must use a third-party payment or the Microsoft Payment Request API
Back to My Case
My add-on was called "Support the Author" with the tagline "Consider buying the dev a coffee" — purely tip language. But it was using the Store In-Product Purchase API, and the policy clearly states: pure tips cannot use the In-Product Purchase API.
But in reality, the add-on did give users a supporter badge — in other words, it was already a digital product. By the test above, if there's a change, it's a digital product, and digital products should go through the In-Product Purchase API. This means the payment could theoretically only go through the In-Product Purchase API, not the Payment Request API or third-party.
So the problem wasn't the payment method at all — it was the description. Changing "Support the Author" to "Upgrade to Pro" and "buy me a coffee" to text describing the actual benefit was all it took to pass.
The Takeaway
- The In-Product Purchase API is only for digital goods and services — the app must have a substantive change after payment
- Pure tips (no app changes) cannot use the In-Product Purchase API — use the Payment Request API or a third-party processor
- Test: does the code/database need to change after payment? Change → In-Product Purchase API; No change → third-party payment
- Naming and description should match the actual behavior: if there's a change after payment, describe it as a clear benefit, avoid donation, sponsor, or tip language
Part of the Store Pitfalls series.