Android 不适用于采购验证和验证；游戏逻辑的独立服务器

我正在使用Unity（Android和iOS）开发一个应用程序。我使用SOOMLA插件允许用户通过应用内购买购买Gems（虚拟货币）

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

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

用户通过IAP购买宝石

应用程序通知服务器

服务器验证购买并更新数据

但是，如果互联网连接在第1步和第2步之间出现故障-用户为他没有收到的宝石付费（不好！）

因此，我目前的做法是：

用户发起购买

应用程序通知服务器

服务器盲目地相应地更新数据

用户通过IAP购买宝石

如果取消购买，请通知服务器撤消购买

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

注意：我不想在商店中管理用户宝石。我希望一切都在我自己的服务器上。所以苏姆拉的平衡对我来说毫无意义。我不喜欢它

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

---

我认为最好的解决方案是能够正确处理这种情况的：

用户通过IAP购买宝石

IAP成功

互联网瘫痪

没有通知我自己的服务器

用户从其设备卸载应用程序

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

• 要么他被指控，要么他用魔法得到了宝石
• 或者他被自动退款，因为宝石没有收到

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

---

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

---

---

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

一般来说，您似乎受到了

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

由于通信协议中的任何地方都可能丢失消息（即使是确认或确认的确认或…），因此您无法100%确定通信双方（用户设备和服务器）已同意相同的状态。您只能说，在一定的概率下，状态信息已成功交换

如果有足够的数量，我会来回发送一些ACK并存储购买的物品。引自维基百科：

而且，第一位将军可以在每条信息上打上标记，说这是信息1、2、3。。。n。此方法将允许第二位将军知道信道的可靠性，并发送适当数量的消息，以确保至少有一条消息被接收的高概率

为了让客户满意，我会对他们有利——1%的未交货货物会给你带来很多麻烦，但你方1%的损失是可以接受的。

一些建议：

用户通过IAP购买宝石

IAP成功

互联网瘫痪

没有通知我自己的服务器

用户从其设备卸载应用程序

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

要么他被指控通过某种魔法获得了宝石，要么他被自动退款，因为宝石没有收到

---

在步骤3，接收信息存储在用户的设备上。如果用户卸载并重新安装您的应用程序，则收据信息将丢失。但你可以恢复它；苹果公司对此不屑一顾。您可以将恢复的回执重新发送到服务器。在您的服务器上，您为用户验证plus Gems，这样他就可以收到他应该得到的东西

由于没有收到宝石，他被自动退款

这在IAP看来是不可能的，因为苹果不允许用户取消购买。（谷歌IAB允许退款，更多信息）

---

我对android不太了解，但在阅读了你的帖子后，我真的很感兴趣，想深入搜索类似于应用程序购买逻辑中的部族冲突，以及如何防止自由假冒购买黑客

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

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

工作原理：

1） 游戏加载，与服务器同步。需要网络连接，因为网络连接中断了从服务器重新加载的游戏

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

3） 用户购买的gems，服务器分别验证购买的耗材的购买情况，gems记入用户帐户

4） 若在can网络出现故障的情况下，服务器也可以验证购买情况，然后在用户帐户中更新购买情况，无论它是否在任何设备上

5） 这也将帮助您绕过许多假冒的应用程序内购买黑客，如（）和

谷歌为服务器端提供api以验证或获取购买详细信息，当从应用程序端和服务器端购买匹配时，只有您将宝石或消耗品记入用户帐户

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

1） 和

2）

3）

4）

希望这能让你明白我的意思

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