How to implement re-fulfillment for products with large catalog of offers in Windows Store App

This is what is said in an article titled “How to manage a large catalog of in-app offers (Windows Store apps using C#/VB/C++ and XAML)” in “How-to” session of “Dev Center- Window Store Apps”

As mentioned earlier, the Windows Store only uses provided offer info to populate the PurchaseResults, and does not create a persistent association between a large catalog offer and Windows Store product listing. As a result you need to track user entitlement for large catalog offers, and provide offer-specific context (such as the name of the item being purchased or details about it) to the user outside of the RequestProductPurchaseAsync operation.

You can get this article at

http://msdn.microsoft.com/en-us/library/windows/apps/dn532256.aspx

With that, is it correct to conclude that the store’s in-app purchase framework does not keep track which offer was purchased within a product by which user?

"You" as an app developer, need to track what offer was purchase. If "you" want to offer re-fulfillment after user uninstall/re-installed or install the app in other device they own. The "tracking" needs to be done outside of the app. In another word, the information needs to be stored in a service that is accessible to the app.

In order for "you" to keep track who purchase what offer of which product, "You" need to know who is the current user.

But UserInformation class only gives "you"  DisplayName, LastName and FirstName, through GetDisplayNameAsync, GetFirstNameAsync and GetLastNameAsync methods.

This is good from privacy point of view, as these pieces of information cannot be used to identify the user. So privacy is protected. However, the question here is how do "you" as the developer to track what offer was purchased by who?

I think this is a gap in in-store purchase framework.

I am putting this question here and hope someone can prove me wrong...

If what I described above is accurate. I would bold enough to offer the following as suggestion:

A reasonable solution would be Microsoft modify its in-app purchase framework to provide one more method on licenseInformation class, say IsPurchased or IsActive and it has two overloadings. One takes only one string which is ProductId, the other one takes 2 parameters, ProductId and OfferId).

Response from Microsoft Technical Support:

Sad news is that in such cases, you will have to keep a track of offers being purchased by the users. Ideally, a web service is recommended but you can just as easily use the roaming app data to keep track of the same. There is also OneDrive SDK so you can upload the data to the cloud for better redundancy.

This isn’t ideal but I have provided feedback to the concerned product groups and I hope they are considering improvements for upcoming releases.