Sim*_*Var 21 android in-app-purchase ios in-app-billing soomla
我正在使用Unity(适用于Android和iOS)开发应用程序.我正在使用SOOMLA插件允许用户通过In App Purchase购买Gems(虚拟货币).
用户和Gems以及所有其他游戏逻辑都通过Azure上的服务器.
我希望以下过程以某种方式作为单个事务发生:
但是如果互联网连接在步骤1和步骤2之间发生故障 - 用户付钱给他没有收到的宝石(不好!)
所以我目前的做法是这样的:
这样,用户可以保证购买他购买的宝石,但我不能保证得到报酬(不是很好......)
注意: 我不想在商店本身管理用户Gems.我希望我自己的服务器上的一切.所以SOOMLA的平衡对我来说毫无意义.我不在乎.
我想也许应用程序可以将购买数据存储在持久存储中,直到它设法通知服务器有关它,然后删除它.但我也认为这可能是一个糟糕的解决方案.因此这个问题.
我认为最好的解决方案可以正确处理这种情况:
然后,用户可以在其他设备上安装该应用:
到目前为止,似乎无论如何这都是不可能的,这让我对IAP的技术感到失望.希望找到能证明我错误的答案.
似乎我所需要的只是能够从我的服务器获取用户的购买历史记录,并向Google Play或Apple Store提供安全请求.但这不是框架的一部分.
那么其他人在做什么？什么是最好的方法？
在一般情况下,你似乎从遭受两位将军的问题这是
第一个计算机通信问题被证明是无法解决的.
由于您的通信协议中的任何地方都可能丢失消息(甚至是确认或确认确认或......)您无法100%确定通信双方(用户设备和您的服务器)是否同意州.您只能说,在一定概率下,状态信息已成功互换.
如果有足够数量的话,我会来回发送几个ACK并存储购买.来自维基百科的报价:
此外,第一个将军可以在每条消息上发送一个标记,表示它是n的消息1,2,3 .... 这种方法将允许第二将军知道信道的可靠性,并发回适当数量的消息,以确保至少收到一条消息的概率很高
为了让客户满意,我会冒险对他们有利 - 1%没有交付货物会让你遇到很多麻烦,但是你可以接受1%的损失.
考虑到您的宝石是虚拟货币,那么自然的应用程序内产品类型应该是可消耗的,即它们不是可恢复的购买.
要通过Google Play购买购买,您需要致电consumePurchase.在iOS上你会打电话finishTransaction给SKPaymentQueue.在这两个市场中,消耗品购买将一直处于活动状态,直到它们被消费为止.如果用户在购买之前将设备从其设备上删除,则他们将能够重新安装并恢复之前未使用的购买.
在初始购买和消费之间,您需要进行服务器端验证.购买时,将收据或令牌发送到您的服务器,执行验证并做出相应的响应.在消费购买之前,应用应等待服务器的有效响应.
(请注意,消费的购买不会出现在in_appiTunes收据的集合中.只有在购买尚未消费时才会出现.)
如果服务器超时或网络连接丢失,则购买将保持活动状态,应用程序应继续尝试定期发送详细信息,直到收到预期的响应.
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
| 归档时间： |
|
| 查看次数： |
1822 次 |
| 最近记录： |