Достаточно ли использовать deviceID, orderID, PurchaseToken для проверки покупок на сервере?

Question

Последние пару дней я настраивал выставление счетов за приложения и пытался сделать правильный путь. Руководства рекомендуют использовать безопасный внутренний сервер для хранения токена покупки, а не для локального хранения данных. Документация по проверке покупок на сервере очень тонкая, и я не уверен, правильно ли я поступаю.

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

Стоит ли читать идентификатор продукта с сервера, а не прописывать его в apk?

Как часто мне / мне нужно читать идентификатор устройства в этом случае и искать в БД, чтобы убедиться, что у пользователя есть действительная покупка? Только один раз при совершении покупки или с перебоями?

Если я сделаю это, что произойдет, когда покупатель поменяет свой телефон? Идентификатор устройства будет другим, и у меня не будет записи об их новом устройстве, сделавшем успешную покупку. Или здесь я запрашиваю skupurchase, и он возвращает элемент уже принадлежит, записать эти новые данные в БД?

и, наконец, следует ли хранить флаг успешной покупки в общих настройках или что-то подобное, чтобы я не постоянно читал БД и пользователь мог использовать устройство в автономном режиме?

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

Кстати, у меня есть только один продукт, который открывает все функции и не расходуется.

Как правильно это сделать?

Answer 1

Это был мой подход к тем же проблемам.Это может не соответствовать вашему сценарию.Надеюсь, это поможет.

Стоит ли читать идентификатор продукта с сервера, а не жестко прописывать его в apk?

Вы должны хранить идентификаторы продукта в кодетак как они будут использоваться для предоставления функций, закодированных в приложении.

Как часто мне / мне нужно читать идентификатор устройства?

Вы не должны полагаться наидентификатор устройства, поскольку вы выразили обеспокоенность по поводу смены телефона пользователем.Вы хотели бы внедрить систему входа в систему и сделать вход пользователя в приложение перед покупкой продукта.Это сделает ваше устройство подписки независимым.

Процесс должен быть следующим:

1. Пользователь пытается использовать заблокированную функцию.
2. Приложение запрашивает вход в систему.Зарегистрируйте пользователя и войдите в систему.
3. Пользователь снова нажимает кнопку покупки и завершает покупку.
4. Ваш сервер сохраняет информацию для входа в систему пользователя вместе с информацией о покупке.
5. Пользовательизменяет устройство.
6. Пользователь пытается использовать заблокированную функцию.
7. Приложение запрашивает вход в систему.Пользователь входит в систему.
8. Сервер возвращает данные о покупке с информацией о пользователе.
9. Приложение разблокирует функцию.

Как часто я должен проверять информацию о покупкес сервера?

Вы должны периодически проверять детали покупки.

Почему? Пользователь может запросить возврат через некоторое время или платежный шлюз будетпо какой-то причине аннулируйте покупку.

IMO, должно быть два типа методов синхронизации: тихий и принудительный.В моем подходе тихая синхронизация будет проверять интернет каждые 9 дней.Если интернет недоступен, он ничего не сделает.В то время как принудительная синхронизация будет проверять интернет каждые 25 дней с момента последней синхронизации.Если Интернет недоступен, он попросит пользователя включить его, в противном случае пользователь не сможет использовать приложение.

Я использовал период подписки один месяц, но у вас нет-потребляемый продукт вы можете себе позволить 2-4 месяца периода принудительной синхронизации.

Должен ли я хранить флаг успешной покупки в общих настройках или что-то, чтобы я не постоянно читал БД и пользователь мог использовать устройство в автономном режиме?

Процесс синхронизациии вход в систему решит эту проблему.

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

Реализация этого подхода требует много логики на стороне сервера.