iOS苹果内购服务端技术方案

IOS内购服务端技术方案

https://www.jianshu.com/p/632a79900aa3

IOS购买vip流程

1. IOS端,用户点击相应的购买按钮

2. 服务端生成订单,并返回订单信息(包含在苹果后台设置产品对应的ProductID)

3. 客户端发起支付

4. 客户端支付完毕,拿到苹果返回的transaction,把该transaction和订单信息传到服务端

5. 服务端更新订单状态,返回客户端该vip购买订单已完成蛋未验证的状态(此时可认为用户已经是vip),客户端流程已结束

6. 服务端根据transaction,去苹果服务器验证收据的有效性,再去更新订单状态,如果错误,则回滚用户vip资格(异步处理)

IOS内购服务器模式的主要流程如下所示:

1. app从服务器获取产品标识列表

2. app从app store 获取产品信息

3. 用户选择需要购买的产品

4. app 发送 支付请求到app store

5. app store 处理支付请求,返回transaction信息

6. app 将transaction receipt 发送到服务器

7. 服务器收到收据后发送到app stroe验证收据的有效性

8. app store 返回收据的验证结果

9. 根据app store 返回的结果决定用户是否购买成功

服务端验证注意点

苹果AppStore线上的购买凭证验证地址是https://buy.itunes.apple.com/verifyReceipt

测试的验证地址是:https://sandbox.itunes.apple.com/verifyReceipt

1. 考虑到网络异常情况,服务器的验证应该是一个可恢复的队列,如果网络失败了,应该进行重试。

2. 与苹果的验证接口文档在这里。简单来说就是将该购买凭证用Base64编码,然后POST给苹果的验证服务器,苹果将验证结果以JSON形式返回。

国内连接苹果服务器的稳定性问题

问题

1. 用户能否忍受3-6s的等待时间

2. 如果app store server 宕机,如何确保成功付费的用户能够得到正常服务。

解决

对于第一个问题,我们有理由相信用户完全无法忍受,所以采用异步验证的方式,服务器收到客户端的请求后,就将请求放到MCQ中去处理。

对于第二个问题,由于苹果人员很负责人的告知:我们的服务器不稳定,所以不排除收据验证超时的情况。

对于验证超时的收据,保存到数据库中并标记为验证超时,定时任务每隔一定的时间去app store验证,确保能够获取收据的验证结果。

相关参考

iOS支付

iOS应用内付费(IAP)开发步骤列表

IOS In App Purchase(内购)验证

 

苹果内购服务器验证之receipt返回多组in_app思考

https://www.cnblogs.com/widgetbox/p/8241333.html

最近有部分用户反映,苹果内购充值失败,经过测试总结有几个关键点出现问题

1.app购买成功苹果没有返回票据,属于票据遗漏(取决于苹果服务器的响应状况),只能客户端进行监听刷新等处理

2.app连续购买的过程中,前几次苹果没有返回票据,几次之后,苹果返回了一个有效的票据,app提交给服务器进行验证的过程中in_app出现多组数据的情况,这种情况还是能充值成功了,只是不能全部到账

3.app连续购买,有一次正常返回票据,在提交给服务器的过程中出现意外,但实际服务端已经接受到票据,为用户成功充值,但app进行下次充值带回票据,再次提交服务器验证的时候,in_app中出现了上次已经提交的票据信息,这种情况服务器将判断为已经充值,导致最后一次充值失败

本着刨根问底的精神,查阅各方资料总结如下,苹果的官方描述(IAP票据验证)如下:

百度翻译如下:

它说,票据在一个在JSON文件,是一个数组包含所有应用程序购买收据基于应用程序购买交易收据数据输入Base-64,而且有可能返回一个空的数组(空数组居然还是有效的)

在应用程序购买收据消耗型产品添加到发票购买时,它是保存在你的应用程序接收到完成交易。在这一点上,它是下一次收到的更新-例如从收据后,当用户再购买或如果您的应用程序显式刷新收据。

原谅我的英文水平低下,看完之后一脸懵逼,下面总结一下我个人的理解,大概意思如下:

对于消耗型产品的购买,在购买完成(苹果那边购买完成,不是服务器购买完成)之后会被添加到票据信息中,直到你的APP完成交易(APP的主动行为),之后它会在用户下一次购买的时候对票据进行刷新,或者APP进行显示刷新。

看完这个就很好理解上面出现的问题了,也就是说:

验证票据返回的receipt里面的in_app字段,这个字段包含了所有你未完成交易的票据信息。也就是在上面说到的APP完成交易之后,这个票据信息,就会从in_app中消失。

如果APP不完成交易,这个票据信息就会在in_app中一直保留。(这个情况可能仅限于你的商品类型为消耗型)

知道了事件的原委,就很好优化解决了,方案有2个

1.对票据返回的in_app数据全部进行处理,没有充值的全部进行充值

2.仅对最新的充值信息进行处理(我们采取的方案)

因为采用一方案:

如果用户仅进行了一次充值,该充值未到账,他不再进行充值了,那么会无法导致。

如果他通过客服的途径已经进行了补充充值,那么他在下一次充值的时候依旧会把之前的产品票据带回,这时候有可能出现重复充值的情况

原文地址:https://www.cnblogs.com/itlover2013/p/15041477.html