对Microsoft Store API的请求始终返回产品/订阅的空列表 [英] Requests to Microsoft Store APIs always return empty lists of products / subscriptions

查看:141
本文介绍了对Microsoft Store API的请求始终返回产品/订阅的空列表的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们已经免费发布了带有非消耗性升级附件的UWP应用程序到Microsoft Store.由于新的订阅计费模型为向公众介绍了,我们正计划通过在下一个版本中添加订阅计划来利用它.

We have free UWP app published to the Microsoft Store with non-consumable upgrade add-ons. As new subscription billing model was introduced to public audience recently, we're planning to utilise it by adding subscription plans in the next release.

我们还希望在后端查看和管理用户拥有的加载项,并且有相关的获取订阅-我们总是得到一个空的响应:{ "items": [] }.

We also would like to view and manage user-owned add-ons on our backend, and there's relevant documentation to do just that. We followed it closely, but in the end — while trying to get subscriptions for a user, for example — we always get an empty response: { "items": [] }.

这是我们逐步进行的简要操作:

Here is what we did briefly, step by step:

  1. 在Azure Active Directory中创建了新的应用注册.
  2. 通过合作伙伴信息中心将应用注册的标识符与我们的应用相关联.
  3. 为以下受众URI创建了三个Azure Active Directory(AAD)令牌:

  1. Created new app registration in Azure Active Directory.
  2. Associated app registration's identifier with our app through Partner Dashboard.
  3. Created three Azure Active Directory (AAD) tokens for following audience URIs:

  • https://onestore.microsoft.com (used in step 5 for authorization)
  • https://onestore.microsoft.com/b2b/keys/create/collections (used in step 4)
  • https://onestore.microsoft.com/b2b/keys/create/purchase (used in step 4)

分别通过从应用程序中的客户端代码调用StoreContext.GetCustomerCollectionsIdAsyncStoreContext.GetCustomerPurchaseIdAsync代表我们的测试Microsoft帐户,为Collection和Purchase API创建了Microsoft Store ID密钥.为了生成每个密钥,我们使用了第3步中对应的AAD令牌.

Created Microsoft Store ID keys for Collection and Purchase APIs on behalf of our test Microsoft account by calling StoreContext.GetCustomerCollectionsIdAsync and StoreContext.GetCustomerPurchaseIdAsync respectively from client code in our app. To generate each key we used corresponding AAD token from step 3.

因此我们得到了200 "OK"的响应,但是该列表始终为,这非常令人失望,实际上对我们而言现在是一个主要的阻止问题.

So we're getting 200 "OK" response, but the list is always empty and that is very disappointing and actually a major blocking issue right now for us.

我们还可以通过订单历史记录"确认我们前面提到的测试Microsoft帐户至少拥有一个耐用的附加组件和一个订阅.可以通过在客户端应用程序中调用StoreContext.GetUserCollectionAsyncStoreContext.GetAppLicenseAsync API来检查相同的结果-实际上有一种非消耗性产品和一种订阅.

We also can confirm via "Order History" that our aforementioned test Microsoft account owns at least one durable add-on and one subscription. The same result can be checked by calling StoreContext.GetUserCollectionAsync or StoreContext.GetAppLicenseAsync API in the client app — there are one non-consumable product and one subscription indeed.

I posted same question on the official forum, but not sure if we'll get a reply soon, so decided to post it here as well. Note, that similar question is also posted on the forums, but it's not quite clear from the thread whether it was resolved or not.

有人能从他们的后端服务中获得用户购买吗?我们将不胜感激任何指导,也可能使它对我们同样有用.

Has anyone managed to get user purchases from the their backend service? We'll appreciate any guidance, that could make it working for us too.

更新(2018.08.29):

因此,我们在此问题上取得了一些进展.我们创建了一个新的非免费(0.99美元)订阅附件,并购买了该组件并为用户请求订阅.令人惊讶的是,响应中出现了一个新项目!

So we have a little bit of progress with the issue. We created new non-free ($0.99) subscription add-on, purchased it and requested subscriptions for a user. Surprisingly enough, a new item appeared in the response!

值得一提的是,同一用户已经拥有几个免费的订阅,但是响应中都没有这些订阅.而且我从未在文档中看到任何关于免费订阅的限制的内容,说这些限制不会包含在退回的商品中.

It's worth to mention that same user already owned several subscriptions that were free of charge, but none of them are on list in the response. And I have never seen a mention in documentation about any restrictions for free subscriptions, saying that they won't be included in returned items.

无论如何,订阅的问题已得到部分解决,无论价格如何,现在我们都无法通过查询产品" API获取有关任何非消耗性持久加载项的信息,这也是一个主要问题,因此需要进一步调查.

Anyway, the problem with subscriptions being partially solved, now we can't get info about any non-consumable durable add-on with "Query for products" API, regardless of its price tier — that's also a major problem, so further investigation is needed.

推荐答案

最后,看来我们已经解决了这个问题!

Finally it seems that we resolved the issue!

非消耗性耐用产品和订阅的情况略有不同,但它们都与附加属性中有关个人数据收集的新的必需问题有关,如下所示:

There're slightly different scenarios for non-consumable durable products and subscriptions, but they're all related to a new required question about personal data collection in add-on properties, which looks like this:

这是您需要做的:

  1. 如果您很久以前提交了非消耗性耐用附件,则需要创建一个新的提交,选择上述问题的任何答案并将其提交给认证.产品的更新版本存储在商店中后,请尝试请求用户收集产品-立即将其包含在响应中.
  2. 如果您创建一个订阅附件,则看起来您必须为问题选择是"并提供隐私权政策网址,否则它将永远不会出现在订阅以下内容"的回复中用户".另外请注意,根据我们的经验,与非消耗性耐用产品相比,生效时间更长-认证完成后最多24小时左右.
  1. If you had a non-consumable durable add-on submitted quite a while ago, you need to create a new submission, choose any answer to the aforementioned question and submit it to certification. Once your updated version of product is in the store, try to request user collection of products — it should be included in response now.
  2. If you create a subscription add-on, it looks like you must select "Yes" to the question and provide a privacy policy URL, otherwise it will never appear in the response to "Subscriptions for a user". Also note that based on our experience, it will take longer to take effect compared to non-consumable durable products — up to 24 hours or so after certification finished.

好的,现在很好,但我只是不明白为什么Microsoft在文档中没有立即提到这些要求,导致许多沮丧的日子流逝了……

Ok, now it's fine, but I just can't understand why these requirements weren't mentioned by Microsoft straight away in the documentation, leading to many days lost in frustration…

这篇关于对Microsoft Store API的请求始终返回产品/订阅的空列表的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆