Microsoft Store IAP (durable add-on) not detected / purchase returns NotPurchased in packaged WPF app

Question

Dear all,

I’m implementing in-app purchase using the Windows.Services.Store API (StoreContext) with a durable add-on.

• The add-on is published and visible in Partner Center (“In the Microsoft Store”).
• I generated promotional codes specifically for the add-on and redeemed them successfully on test Microsoft accounts (redeem UI shows “MultiDesk Pro – Add on for MultiDesk”).
• I then install the app from Microsoft Store (private link / private audience) and try:
  • Restore purchases (in-app)
  • Buy Pro (in-app)

After redeeming the add-on promo code, the app should detect Pro entitlement (via GetAppLicenseAsync / AddOnLicenses) and unlock Pro features.

When I try Inside the app:

• Restore purchases reports that Pro is not owned (Trial remains active).
• Buy Pro does not complete the transaction; it returns NotPurchased (no Pro entitlement is activated).

Implementation Approach

• The app uses StoreContext.GetDefault().
• For desktop modal dialogs, I initialize the context owner window using:
  • WinRT.Interop.InitializeWithWindow.Initialize(context, hwnd) (WPF window handle obtained from WindowInteropHelper).
• The app checks entitlement with:
  • var license = await context.GetAppLicenseAsync();
  • license.AddOnLicenses.TryGetValue("multidesk.pro", out var addOn) && addOn.IsActive

Because the entitlement isn’t detected, I’m forced to perform continuous updates and resubmissions to try different diagnostics and verify whether this is a Store/Partner Center configuration issue (audience/markets/availability/propagation) vs. an app-side issue.

Could you please help me to solve the problem?

1. Whether the add-on entitlement should be returned through GetAppLicenseAsync()/AddOnLicenses for a redeemed durable add-on promo code in this scenario (packaged desktop app).
2. If there are any known issues/delays with add-on entitlement propagation for promo codes, private audience distribution, or market availability.
3. Whether I should be using the add-on Store ID instead of the Product ID (offer token) for reliable entitlement detection in desktop packaged apps.

Thank you for your help.

Best regards,

Gabriele

Answer 1

To address your issues with the in-app purchase (IAP) for the durable add-on in your packaged WPF app, here are some insights based on the context provided:

1. Entitlement Detection: The entitlement for a durable add-on should indeed be returned through GetAppLicenseAsync() and should reflect the status of any redeemed promo codes. If the promo code was successfully redeemed, the entitlement should be active. Ensure that the add-on is correctly defined in Partner Center and that the promo code has been redeemed on the same Microsoft account that is being used to test the app.
2. Known Issues/Delays: There can be delays in entitlement propagation after redeeming promo codes, especially in scenarios involving private audience distribution. It’s recommended to allow some time for the changes to propagate. Additionally, check the audience settings and market availability in Partner Center to ensure they are correctly configured for your app and add-on.
3. Store ID vs. Product ID: For reliable entitlement detection in desktop packaged apps, you should be using the add-on Store ID instead of the Product ID (offer token). The Store ID is the unique identifier that the Store uses to track the add-on, and it is crucial for ensuring that your app can accurately check the entitlement status.

If you continue to experience issues, consider reviewing the configuration in Partner Center or testing with different Microsoft accounts to rule out account-specific issues.

---

References:

• Enable in-app product purchases
• In-app purchases and trials using the Windows.Services.Store namespace

Answer 2

In a packaged WPF (.NET 8) MSIX app using Windows.Services.Store.StoreContext, we can see our durable add-on Store ID in GetAssociatedStoreProductsAsync, but GetStoreProductsAsync does not return the same product. Is using GetAssociatedStoreProductsAsync + StoreProduct.IsInUserCollection + StoreProduct.RequestPurchaseAsync() the correct and recommended approach?

the returned dictionary does include the Store ID XXXXXXXXXX (so the Store recognizes the add-on as associated with the app).

We initially tried to validate availability/entitlement using:

var r = await context.GetStoreProductsAsync(new[] { "Durable" }, new[] { "XXXXXXXXXX" });

However, although the call succeeds, r.Products does not contain the Store ID XXXXXXXX (so we get null for the add-on). This caused our entitlement check/purchase flow to fail (no product returned → purchase returns NotPurchased).

At the same time, when we call:

var assoc = await context.GetAssociatedStoreProductsAsync(new[] { "Durable" });

he returned dictionary does include the Store ID XXXXXXXX (so the Store recognizes the add-on as associated with the app).

Because of this, we switched to the following approach:

• Get the StoreProduct from GetAssociatedStoreProductsAsync (using the Store ID key)
• Check entitlement via StoreProduct.IsInUserCollection
• Trigger purchase via StoreProduct.RequestPurchaseAsync()

Question: Is this the correct and recommended method for durable add-ons in packaged desktop apps? If not, why would GetStoreProductsAsync not return the add-on even though it is associated and published, and which API should we rely on for entitlement detection and purchase?

Thank you.