IOS内购支付server验证模式
2017-08-09 11:43 tlnshuju 阅读(1074) 评论(0) 编辑 收藏 举报IOS 内购支付两种模式:
内置模式
server模式
内置模式的流程:
app从app store 获取产品信息
用户选择须要购买的产品
app发送支付请求到app store
app store 处理支付请求。并返回transaction信息
app将购买的内容展示给用户
server模式的流程:
app从server获取产品标识列表
app从app store 获取产品信息
用户选择须要购买的产品
app 发送 支付请求到app store
app store 处理支付请求,返回transaction信息
app 将transaction receipt 发送到server
server收到收据后发送到app stroe验证收据的有效性
app store 返回收据的验证结果
依据app store 返回的结果决定用户是否购买成功
上述两种模式的不同之处主要在于:交易的收据验证。内建模式没有专门去验证交易收据,而server模式会使用独立的server去验证交易收据。
内建模式简单快捷,但easy被破解。server模式流程相对复杂,但相对安全。
开发之初,苹果方就非常负责的告知:我们的server不稳定。真正开发之后。发现苹果方果然是非常负责的,不仅是不稳定,并且足够慢。app store server验证一个收据须要3-6s时间。
用户是否能忍受3-6s的等待时间
假设app store server 宕机,怎样确保成功付费的用户可以得到正常服务。
对于第一个问题,我们有理由相信用户全然无法忍受,所以採用异步验证的方式,server收到client的请求后,就将请求放到MCQ中去处理。
对于第二个问题,因为苹果人员非常负责人的告知:我们的server不稳定。所以不排除收据验证超时的情况。对于验证超时的收据,保存到数据库中并标记为验证超时。定时任务每隔一定的时间去app store验证,确保可以获取收据的验证结果。
在开发过程中,须要測试应用是否可以正常的进行支付。可是又不能进行实际的支付,因此须要使用苹果提供的sandbox Store測试。
Store Kit不能在iOS模拟器中使用。測试Store必须在真机上进行。
在sandbox中验证receipt:
https://sandbox.itunes.apple.com/verifyReceipt
在生产环境中验证receipt:
https://buy.itunes.apple.com/verifyReceipt
在实际开发过程中,server端通过issandbox字段标识client传递的收据是沙盒环境中的收据还是生产环境中的收据。
在提交苹果审核前。沙盒測试均无问题。提交苹果审核后。被告知购买失败,审核未通过。通过查询日志发现,client发送的交易收据为沙盒收据,可是issandbox字段却标识为生产环境。
结论:
苹果审核app时,仍然在沙盒环境下測试。可是client同事在app提交苹果审核时。将issandbox字段写死。设置为生产环境。这样就导致沙盒收据发送到https://buy.itunes.apple.com/verifyReceipt去验证。
那么怎样自己主动的识别收据是否是sandbox receipt呢?
识别沙盒环境下收据的方法有两种:
1.依据收据字段 environment = sandbox。
2.依据收据验证接口返回的状态码,假设status=21007。则表示当前的收据为沙盒环境下收据, t进行验证。
苹果反馈的状态码。
- 21000App Store无法读取你提供的JSON数据
- 21002 收据数据不符合格式
- 21003 收据无法被验证
- 21004 你提供的共享密钥和账户的共享密钥不一致
- 21005 收据server当前不可用
- 21006 收据是有效的,但订阅服务已经过期。
当收到这个信息时,解码后的收据信息也包括在返回内容中
- 21007 收据信息是測试用(sandbox),但却被发送到产品环境中验证
- 21008 收据信息是产品环境中使用,但却被发送到測试环境中验证
先生产验证后測试验证,可以避免来回切换接口的麻烦。
測试验证仅仅要用你自己申请的測试appid的时候才会用到,用户不会拥有測试appid,所以不会走到測试验证这一步。
即使生产验证出错,应该也不回返回21007状态吗。測试验证通过的username,和充值金额最好用数据库记录下来,方便公司资金核对。