InAppPurchase验证＆amp;用于游戏逻辑的独立服务器

Question

我正在使用Unity（适用于Android和iOS）开发应用。我正在使用SOOMLA插件允许用户通过In App Purchase购买Gems（虚拟货币）。

用户和Gems以及所有其他游戏逻辑都通过Azure上的服务器。

我希望以下过程以某种方式作为单个事务发生：

1. 用户通过IAP购买Gems
2. App通知服务器
3. 服务器验证购买和更新数据

但如果互联网连接在步骤1和步骤2之间发生故障 - 用户付钱给他没有收到的宝石（不好！）

所以我目前的做法是：

1. 用户发起购买
2. App通知服务器
3. 服务器盲目更新数据
4. 用户通过IAP购买Gems
5. 如果取消购买，请通知服务器将其撤消

这样，用户可以保证购买他购买的宝石，但我不能保证得到报酬（不是很好......）

注意： 我不想在商店本身管理用户Gems。我希望我自己的服务器上的一切。所以SOOMLA的平衡对我来说毫无意义。我不关心它。

我想也许应用程序可以将购买数据存储在持久存储中，直到它设法通知服务器有关它，然后将其删除。但我也认为这可能是一个糟糕的解决方案。因此这个问题。

我认为最好的解决方案可以正确处理这种情况：

1. 用户通过IAP购买Gems
2. IAP成功
3. 互联网崩溃
4. 我的服务器未收到通知
5. 用户从其设备中卸载应用

6. 然后，用户可以在其他设备上安装该应用程序：

   • 要么被指控，要么通过一些魔法获得宝石
   • 或者他被自动退款，因为没有收到宝石

到目前为止，似乎无论如何这都是不可能的，这让我对IAP的技术感到失望。希望找到能证明我错误的答案。

似乎所有我需要的功能是从我的服务器获取用户的购买历史记录，并向Google Play或Apple Store提供安全请求。但这不是框架的一部分。

那么其他人在做什么？什么是最好的方法？

Answer 1

一般来说，您似乎受到Two Generals' Problem

的影响

  

第一个被证明无法解决的计算机通信问题。

由于您的通信协议中的任何地方都可能丢失消息（甚至是确认或确认确认或......）您无法100％确定通信双方（用户设备和服务器）已同意在同一个州。你只能说，在一定的概率下，状态信息已成功互换。

如果有足够数量的话，我会来回发送几个ACK并保存购买。维基百科引用：

  

此外，第一位将军可以在每条消息上发送标记，表示它是n的消息1,2,3 ...这种方法将允许第二将军知道信道的可靠性，并发回适当数量的消息，以确保至少收到一条消息的概率很高

为了让客户满意，我会冒险对他们有利 - 1％没有交付货物会让你遇到很多麻烦但是你可以接受1％的损失。

Answer 2

考虑到您的宝石是虚拟货币，那么自然的应用内商品类型应为耗材，即它们不可恢复购买。

要通过Google Play购买进行购买，您需要拨打consumePurchase。在iOS上，您将在SKPaymentQueue上致电finishTransaction。在这两个市场中，消耗品购买将一直处于活动状态，直到它们被消费为止。如果用户在购买之前将设备从其设备上删除，他们将能够重新安装并恢复之前未使用的购买。

在初始购买和消费之间，您需要进行服务器端验证。购买时，将收据或令牌发送到您的服务器，执行验证并做出相应的响应。在消费购买之前，应用应等待服务器的有效响应。

（请注意，消费的购买信息不会出现在iTunes收据的in_app集合中。只有在购买尚未消费的情况下才会显示。

如果服务器超时或网络连接丢失，购买将保持活动状态，应用程序应继续尝试定期发送详细信息，直到收到预期的响应为止。

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

Answer 3

一些建议：

1. 用户通过IAP购买Gems
2. IAP成功
3. 互联网崩溃
4. 我的服务器未通知
5. 用户从其设备中卸载应用

6. 然后，用户可以在其他设备上安装该应用程序：

   他被指控并且他通过一些魔法获得了宝石，或者他被自动退款，因为没有收到宝石。

1. 在步骤3，收据信息存储在用户的设备上。如果用户卸载并重新安装您的应用，收据信息将会丢失。但你可以恢复它; Apple谈论here。您可以将恢复的收据重新发送到服务器。在您的服务器上，您为用户验证加上Gems，以便他能够收到他应该得到的东西。

2.   

   他被自动退款，因为没有收到宝石

   IAP似乎不可能，因为Apple不允许用户取消购买。 （使用Google IAB，允许退款，更多关于here）

Answer 4

我对Android没有太多了解但是在阅读你的帖子之后我真的很感兴趣搜索如何游戏像在应用程序购买逻辑中的部落冲突工作并防止自由假购买黑客

在做了一些研究之后，我想分享一下我对你的问题的看法，你可以通过以下方法实现它：

完全在线进行应用内购买验证。例如，您可以考虑部落的游戏冲突。

工作原理：

1）游戏加载，与服务器同步。需要网络连接，因为网络连接会破坏服务器的游戏重新加载。

2）用户有10颗宝石，服务器也有10颗宝石。

3）用户购买的宝石，服务器验证购买的消耗品单独购买，宝石记入用户帐户。

4）如果在情况网络失败的情况下，那么服务器也可以验证购买，然后在用户帐户中更新它，无论是否在任何设备上。

5）这也可以帮助您绕过许多虚假的应用购买黑客，例如freedom（prevention）和lucky patcher。

Google为服务器端提供api以验证或获取购买详情，当从应用程序端和服务器端购买时，只有您将宝石或消耗品归功于用户帐户。

有关应用内购买及其黑客防护的更多信息，请访问以下链接：

1）Server side verification of in app purchase part 1和part 2。

2）How would you verify in app purchase billing server side

3）Verify purchase via PHP

4）Secure in app purchase scenario on web server

希望这可能会引导你走向你想去的方向，也希望听到你的想法。

Answer 5

您可以尝试恢复使用特定帐户进行的应用内购买。

此功能仅适用于此情况，即付款和用户未收到承诺的项目或切换设备时。

恢复购买后，您将再次从iTunes服务器接收购买的产品，然后您可以相应地通知您的服务器。