Полезная нагрузка для разработчиков и взаимодействие с сервером (Google In App Billing) - PullRequest
Новая
       6

Полезная нагрузка для разработчиков и взаимодействие с сервером (Google In App Billing)

0 голосов
/ 25 мая 2018

Необходим ли следующий подход и / или передовой опыт?

  1. В моем клиенте вызовите конечную точку внутреннего сервера getRandomString с маркером входа для уникальной идентификации пользователя.
  2. Сервер генерирует случайную строку и добавляет ее в список доступных случайных строк пользователя.
  3. Клиент использует эту случайную строку в качестве полезной нагрузки разработчика.
  4. Когда я прихожу для проверки покупкитокен на сервере Я проверяю, что полезная нагрузка разработчика равна единице в массиве «случайная строка» пользователя.
  5. Если он есть в списке, удалите его и подтвердите покупку, в противном случае отклоните проверку.

Я не могу найти много советов по этому вопросу ни в Google Docs, ни в SE, ни в сообщениях, которые, кажется, были сделаны 5 лет назад.

Является ли вышеуказанный подход правильным путем?,А также, действительно ли необходимо использовать полезную нагрузку разработчика?

1 Ответ

0 голосов
/ 27 мая 2018

Я думаю, что теперь я определил источник путаницы с полезной нагрузкой разработчика.Несколько лет назад, когда я кодировал с InAppPurchasing полезными нагрузками разработчика, это был дополнительный параметр в функции launchPurchaseFlow, но новая Billing Library с ее launchBillingFlow больше не поддерживает полезную нагрузку разработчика.По-видимому, теперь он классифицируется как наследственное поле. См. Здесь, например. А в этом сообщении Google у нас есть подтверждение:

Hi

Поле developerPayload является устаревшим полемсохранено для обеспечения совместимости со старыми реализациями, но, как уже упоминалось на странице Закупка биллинговых продуктов в приложении (https://developer.android.com/training/in-app-billing/purchase-iab-products.html),, это поле не всегда доступно при выполнении задач, связанных с биллингом в приложении. А поскольку библиотека былапредназначенный для представления самой обновленной модели разработки, мы решили не поддерживать developerPayload в нашей реализации, и у нас нет планов включать это поле в библиотеку.

Если вы полагаетесь на любую важную реализацию вашего приложенияЛогика выставления счетов на developerPayload, мы рекомендуем вам изменить этот подход, потому что это поле будет устаревшим в какой-то момент (или в ближайшее время). Рекомендуемые подходы - использовать ваш собственный бэкэнд для проверки и отслеживания важных деталей о ваших заказах. Для получения дополнительной информации,проверьте страницу безопасности и дизайна (https://developer.android.com/google/play/billing/billing_best_practices.html).

Thanks

...