Запросы к API Магазина Microsoft всегда возвращают пустые списки продуктов / подписок

Question

У нас есть бесплатное приложение UWP, опубликованное в Магазине Майкрософт с необслуживаемыми надстройками для обновления. Поскольку новая модель выставления счетов за подписку была недавно представлена широкой публике, мы планируем использовать ее, добавив планы подписки в следующем выпуске.

Мы также хотели бы просматривать надстройки, принадлежащие пользователям, и управлять ими на нашем сервере, и для этого есть соответствующая документация. Мы внимательно следили за этим, но в итоге - например, пытаясь получить подписку для пользователя - мы всегда получаем пустой ответ: { "items": [] },

Вот что мы сделали кратко, шаг за шагом:

1. Создана новая регистрация приложения в Azure Active Directory.
2. Идентификатор регистрации приложения, связанный с нашим приложением, через панель инструментов партнера.

3. Созданы три токена Azure Active Directory (AAD) для следующих URI аудитории:

   • https://onestore.microsoft.com/ (используется на шаге 5 для авторизации)
   • https://onestore.microsoft.com/b2b/keys/create/collections (используется на шаге 4)
   • https://onestore.microsoft.com/b2b/keys/create/purchase (используется на шаге 4)

4. Создал ключи идентификатора Microsoft Store для API-интерфейсов сбора и покупки от имени нашей тестовой учетной записи Microsoft, позвонив StoreContext.GetCustomerCollectionsIdAsync а также StoreContext.GetCustomerPurchaseIdAsync соответственно из кода клиента в нашем приложении. Для генерации каждого ключа мы использовали соответствующий токен AAD из шага 3.

5. Запрашиваемые продукты / подписки для пользователя (с использованием токена авторизации AAD с шага 3 и ключей идентификатора хранилища с шага 4).

Итак, мы получаем 200 "OK" ответ, но список всегда пуст, и это очень разочаровывает и на самом деле является серьезной проблемой для нас сейчас.

Через "Историю заказов" мы также можем подтвердить, что нашей вышеупомянутой тестовой учетной записи Microsoft принадлежит как минимум одно долговременное дополнение и одна подписка. Тот же результат можно проверить, позвонив StoreContext.GetUserCollectionAsync или же StoreContext.GetAppLicenseAsync API в клиентском приложении - действительно есть один непотребляемый продукт и одна подписка.

Я разместил тот же вопрос на официальном форуме, но не уверен, что мы получим ответ в ближайшее время, поэтому решил опубликовать его и здесь. Обратите внимание, что аналогичный вопрос также размещен на форумах, но из ветки не совсем ясно, решен он или нет.

Кому-нибудь удалось получить пользовательские покупки из их бэкэнд-сервиса? Мы будем благодарны за любые рекомендации, которые могут помочь нам в этом.

ОБНОВЛЕНИЕ (2018.08.29):

Так что у нас есть небольшой прогресс в этом вопросе. Мы создали новое платное дополнение ($0,99), приобрели его и запросили подписки для пользователя. Как ни странно, в ответе появился новый предмет!

Стоит отметить, что один и тот же пользователь уже владел несколькими бесплатными подписками, но ни одна из них не указана в ответе. И я никогда не видел упоминания в документации о каких-либо ограничениях для бесплатных подписок, где говорится, что они не будут включены в возвращаемые товары.

В любом случае, проблема с подписками была частично решена, теперь мы не можем получить информацию о любом нерасходуемом надстройке длительного пользования с API "Запрос для продуктов", независимо от его ценового уровня - это также серьезная проблема, поэтому дальнейшее исследование необходимо.

Answer 1

Наконец-то кажется, что мы решили проблему!

Существуют немного другие сценарии для нерасходуемых товаров длительного пользования и подписок, но все они связаны с новым обязательным вопросом о сборе личных данных в свойствах надстройки, который выглядит следующим образом:

Вот что вам нужно сделать:

1. Если у вас было многоразовое дополнение длительного пользования, отправленное довольно давно, вам нужно создать новое представление, выбрать любой ответ на вышеупомянутый вопрос и отправить его на сертификацию. Как только ваша обновленная версия продукта появится в магазине, попробуйте запросить пользовательскую коллекцию продуктов - она ​​должна быть включена в ответ.
2. Если вы создаете надстройку подписки, похоже, что вы должны выбрать "Да" на вопрос и указать URL-адрес политики конфиденциальности, иначе он никогда не появится в ответе на "Подписки для пользователя". Также обратите внимание, что, исходя из нашего опыта, вступление в силу займет больше времени по сравнению с непродовольственными товарами длительного пользования - примерно через 24 часа после завершения сертификации.

Хорошо, теперь все хорошо, но я просто не могу понять, почему Microsoft не упомянула эти требования сразу в документации, что привело к потере многих дней в отчаянии...