Подтвердить что ты не робот

Проверка InAppPurchase и отдельный сервер для игровой логики

Я разрабатываю приложение с помощью Unity (для Android и iOS). Я использую плагин SOOMLA, чтобы позволить пользователям приобретать драгоценные камни (виртуальную валюту) при покупке приложения.

Пользователи и Gems и все другие логические игры проходят через мой сервер на Azure.

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

  • Пользователь покупает драгоценные камни с помощью IAP
  • Приложение уведомляет сервер
  • Сервер проверяет данные о покупке и обновлениях

Но если интернет-соединение разрывается между шагами 1 и 2, пользователь платит за драгоценные камни, которые он не получил (не хорошо!)

Итак, мой нынешний подход таков:

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

Таким образом, пользователю гарантированно получить его приобретенные драгоценные камни, но я не гарантированно заплачу (не очень...)

Примечание. Я не хочу управлять пользователями Gems в самом магазине. Я хочу все на своем сервере. Поэтому баланс SOOMLA для меня не имеет смысла. Меня это не волнует.

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


Я представляю лучшее решение как что-то, что будет правильно обрабатывать этот сценарий:

  • Пользователь покупает драгоценные камни с помощью IAP
  • IAP успешно
  • Интернет распадается
  • Мой собственный сервер не уведомлен
  • Пользователь удаляет приложение из своего устройства.
  • Пользователь может установить приложение на другие устройства:

    • Либо он был обвинен, и он получил драгоценные камни от какой-то магии.
    • Или он был возвращен автоматически, так как драгоценные камни не были получены

До сих пор кажется, что это невозможно каким-либо образом, что меня разочаровывает в технологии IAP. Надеюсь на ответы, которые докажут, что я ошибаюсь.


Кажется, что все, что мне когда-либо понадобилось, - это возможность получить историю покупок пользователей с моего сервера с защищенным запросом в Google Play или Apple Store. Но это просто не часть рамки.


Так что делают другие? Каков наилучший подход?

4b9b3361

Ответ 1

В общем, вы, кажется, страдаете от проблемы двух генералов, которая была

первая проблема с компьютерной связью, которая будет доказана как неразрешимая.

Так как повсюду в вашем протоколе связи может быть потеряно сообщение (даже подтверждение или подтверждение подтверждения или...), вы не можете быть на 100% уверены, что обе стороны связи (пользовательское устройство и ваш сервер) договорились в том же состоянии. Вы можете только сказать, что с определенной вероятностью информация о состоянии была успешно переделана.

Я бы послал пару ACK обратно и вперед и сохранил покупку, если достаточное количество получило корыто. Цитата из Википедии:

Кроме того, первый генератор может отправить отметку на каждое сообщение, говорящее, что это сообщение 1, 2, 3... из n. Этот метод позволит второму генералу узнать, насколько надежным является канал и отправить соответствующее количество сообщений, чтобы обеспечить высокую вероятность получения хотя бы одного сообщения.

Для удовлетворения клиентов я бы взял шансы в их пользу - 1% не доставленных товаров доставит вам массу неприятностей, но 1% -ная потеря на вашей стороне приемлема.

Ответ 2

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

Чтобы купить покупку с покупкой в ​​Google Play, вы вызываете consumePurchase. На iOS вы назовёте finishTransaction на SKPaymentQueue. На обоих рынках потребительская покупка останется в активном состоянии до тех пор, пока они не будут потреблены. Если пользователь удалит приложение с своего устройства до того, как покупка будет потреблена, они смогут переустановить и восстановить свои прежние неиспользованные покупки.

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

(Обратите внимание, что потребляемые покупки не будут отображаться в коллекции in_app в квитанции iTunes. Они присутствуют только в том случае, если покупка еще не была использована).

Если сервер отключен или сетевое соединение потеряно, покупки будут оставаться в активном состоянии, и приложение должно продолжать пытаться периодически отправлять данные, пока не получит ожидаемый ответ.

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

Вы можете обрабатывать предоставление драгоценных камней так же, как банк обрабатывает депозиты чеков; новый баланс будет немедленно обновлен, но потраченная сумма не будет соответствовать, пока проверка (или в вашем случае проверка) не будет очищена.

Некоторые псевдо-коды, чтобы сделать процесс понятным:

Purchase product or Restore purchases
While consumable purchases > 0
  Send purchase receipt to API
  If response is ok
    If purchase is valid
      Consume product
      Allocate gems
      Break
    Else
      Remove retroactive gem allocation
      Discipline the naughty user
      Break
  Else
    Retroactively allocate un-spendable gems
    Pause process until network is re-established
      Re-send receipt to API

Ответ 3

Некоторые советы:

  • Пользователь покупает драгоценные камни с помощью IAP
  • IAP успешно
  • Интернет распадается
  • Мой собственный сервер не уведомлен
  • Пользователь удаляет приложение из своего устройства.
  • Пользователь может установить приложение на другие устройства:

    Либо он был обвинен, и он получил драгоценные камни от какой-то магии, либо он был автоматически возвращен, так как драгоценные камни не были получены.


  • На шаге 3 информация о получении сохраняется на пользовательском устройстве. Если пользователь удаляет и переустанавливает ваше приложение, информация о квитанции будет потеряна. Но вы можете восстановить его; Apple говорит об этом здесь. Вы можете отправить восстановленную квитанцию ​​на свой сервер. На вашем сервере вы подтверждаете, что плюс Gems для пользователя, чтобы он мог получить то, что должен быть.

  • он был возвращен автоматически, так как драгоценные камни не были получены

    Это кажется невозможным с IAP, потому что Apple не позволяет пользователю отменить свою покупку. (С помощью IAB Google возврат возможен, более подробно об этом здесь)

Ответ 4

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

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

Сделайте свою проверку покупки в приложении полностью онлайн. Например, вы можете рассмотреть игровое столкновение кланов.

Как это работает:

1) Игра загружается, синхронизируется с сервером. Требуется сетевое подключение, так как сетевое соединение прерывает перезагрузку игры с сервера.

2) У пользователя 10 камней, у сервера также 10 камней.

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

4) Если в сети может произойти сбой, тогда и сервер может проверить покупку, а затем обновить ее в учетной записи пользователя, независимо от того, находится ли она на любом устройстве.

5) Это также поможет вам обойти многие поддельные покупки в приложениях, например freedom ( и счастливый патчер.

Google предоставляет api для серверной стороны для проверки или получения деталей покупки и при покупке со стороны приложения и на стороне сервера, а затем только кредитные или драгоценные предметы в учетной записи пользователя.

Для получения дополнительных сведений о покупках приложений и их предупреждениях о взломе вы можете посетить следующие ссылки:

1) Проверка на стороне сервера в части 1 покупки приложения и часть 2.

2) Как вы можете проверить на стороне сервера биллинга покупки приложений.

3) Проверить покупку через PHP.

4) Безопасный сценарий покупки приложений на веб-сервере.

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

Ответ 5

Вы можете попробовать восстановить покупки In, сделанные с помощью определенной учетной записи.

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

После восстановления покупки вы снова получите приобретенный продукт с сервера iTunes, а затем вы можете сообщить об этом своему серверу.