InApp购买validation和游戏逻辑单独的服务器

我正在开发一个使用Unity的应用程序(Android和iOS)。 我正在使用SOOMLA插件,允许用户通过In App Purchase购买Gems(虚拟货币)。

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

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

  1. 用户通过IAP购买Gems
  2. 应用程序通知服务器
  3. 服务器validation购买和更新数据

但是,如果互联网连接在步骤1和步骤2之间出现故障 – 用户支付他没有收到的gem(不好!)

所以我目前的做法是这样的:

  1. 用户启动购买
  2. 应用程序通知服务器
  3. 服务器相应地盲目地更新数据
  4. 用户通过IAP购买Gems
  5. 如果购买被取消,通知服务器撤消它

这样,用户保证会得到他所购买的gem,但我不能保证得到报酬(不是很好…)

注意: 我不想在商店本身pipe理用户gem。 我想在我自己的服务器上的一切。 所以SOOMLA的平衡对我来说毫无意义。 我不在乎。

我想也许应用程序可以将购买数据存储在永久性存储中,直到它设法通知服务器,然后将其删除。 但我也在想,这可能是一个不好的解决scheme。 因此,这个问题。


我把最好的解决scheme想象成能正确处理这种情况的东西:

  1. 用户通过IAP购买Gems
  2. IAP成功
  3. 互联网崩溃了
  4. 我自己的服务器没有通知
  5. 用户从他的设备上卸载应用程序
  6. 用户可以在其他设备上安装应用程序:

    • 要么他被控告了,他通过魔法获得了gem
    • 或者他自动退还,因为gem没有收到

到目前为止,这似乎是不可能的,这让我对IAP的技术感到失望。 希望得到答案,这将certificate我错了。


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


那么别人在做什么? 什么是最好的方法?

Solutions Collecting From Web of "InApp购买validation和游戏逻辑单独的服务器"

总的来说,你好像受到两国将军的问题的困扰

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

由于您的通讯协议中的任何地方都可能丢失一条消息(即使是确认或确认的确认或…),您不能100%确定通信双方(用户设备和您的服务器)已经达成一致州。 你只能说在一定的概率下,状态信息已经被成功地交换了。

如果有足够数量的话,我会前后发送几个ACK并存储购买。 从维基百科引用:

另外,第一个将军可以在每个消息上发一个标记,说明它是n的消息1,2,3 …。 这种方法将允许第二位将军知道信道有多可靠,并发回适当数量的消息以确保至less接收到一个消息的高概率

为了客户的满意度,我会采取对他们有利的赔率 – 1%没有交付的货物会给你带来很多麻烦,但1%的损失是可以接受的。

考虑到你的gem是虚拟货币,那么自然的应用内产品types应该是可消费的 ,即它们不是可恢复的购买。

要通过Google Play购买进行购买,您需要致电consumePurchase 。 在iOS上,您将调用finishTransaction上的SKPaymentQueue 。 在这两个市场中,消费品购买将保持活跃状态​​,直到消费完成。 如果用户在购买消耗之前从应用程序中删除应用程序,他们将能够重新安装,并恢复以前未消费的购买。

初始购买和消费之间是你想要进行服务器端validation的地方。 进行购买时,将收据或令牌发送到您的服务器,执行validation并作出相应的响应。 消费之前,应用程序应等待来自服务器的有效响应。

(请注意,消费的购买将不会出现在iTunes收据上的in_app集合中,只有在购买尚未消耗的情况下才会出现)。

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

Google Play和iOS的购买都存储在本地,因此只需重新build立networking连接,就可以运行一个查找未消费的购买stream程。

您可以像使用银行处理支票的方式一样处理gem的提供; 新的余额将立即更新,但是支出的金额将不匹配,直到支票(或在您的情况下validation)被清除。

一些伪代码,使过程清晰:

 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 

我对Android没有太多的了解,但是在阅读完毕后,我真的很感兴趣,更加关注如何在应用购买逻辑中像部落冲突一样的游戏,防止自由购买黑客

在做一些研究之后,我想分享一下你的问题,你可以通过以下方法来实现

使您的应用程序购买validation完全在线。 例如,你可以考虑游戏的冲突的部落。

怎么运行的:

1)游戏加载,与服务器同步。 需要networking连接,因为networking连接会中断服务器的游戏重新加载。

2)用户有10个gem,服务器也有10个gem。

3)用户购买的gem,服务器validation购买分别为购买的消费品,gem记入用户帐户。

4)如果在networking出现故障的情况下,服务器也可以validation购买,并且稍后在用户帐户中进行更新,无论是否在任何设备上。

5)这也将帮助你绕过许多假冒应用程序购买黑客,如自由 ( 预防 )和幸运补丁 。

Google为服务器端提供API来validation或获取购买细节,当从应用程序端和服务器端进行匹配时,只有您将gem或消耗品记入用户帐户。

有关应用程序购买及其黑客预防的更多信息,请访问以下链接:

1) 在应用程序购买部分1和部分2中的 服务器端validation 。

2) 你如何validation在应用程序购买计费服务器端 。

3) 通过PHPvalidation购买 。

4) 在Web服务器的应用程序购买场景中安全 。

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

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

这个function只适用于这种情况下,付款时,用户没有收到他承诺的项目或当他切换设备。

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

一些忠告:

  1. 用户通过IAP购买Gems
  2. IAP成功
  3. 互联网崩溃了
  4. 我自己的服务器没有通知
  5. 用户从他的设备上卸载应用程序
  6. 用户可以在其他设备上安装应用程序:

    要么他被控告了,他用魔法获得了gem,或者自动退回了gem,因为gem没有收到。


  1. 在步骤3,收据信息被存储在用户的设备上。 如果用户卸载并重新安装您的应用程序,收据信息将会丢失。 但你可以恢复它; 苹果在这里谈论这个。 您可以将已恢复的收据重新发送到您的服务器。 在你的服务器上,你可以validation给用户加上gem,这样他就可以收到他应该做的。

  2. 他自动退还,因为gem没有收到

    这对于IAP来说似乎是不可能的,因为苹果不允许用户取消购买。 (使用Google IAB,退款是允许的,更多关于这里 )