IOS内购支付服务器验证模式

IOS 内购支付两种模式:

  • 内置模式
  • 服务器模式

内置模式的流程:

  1. app从app store 获取产品信息
  2. 用户选择需要购买的产品
  3. app发送支付请求到app store
  4. app store 处理支付请求,并返回transaction信息
  5. app将购买的内容展示给用户

服务器模式的流程:

  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 返回的结果决定用户是否购买成功

上述两种模式的不同之处主要在于:交易的收据验证,内建模式没有专门去验证交易收据,而服务器模式会使用独立的服务器去验证交易收据。内建模式简单快捷,但容易被破解。服务器模式流程相对复杂,但相对安全。



开发之初,苹果方就很负责的告知:我们的服务器不稳定。真正开发之后,发现苹果方果然是很负责的,不仅是不稳定,而且足够慢。app store server验证一个收据需要3-6s时间。

  1. 用户能否忍受3-6s的等待时间
  2. 如果app store server 宕机,如何确保成功付费的用户能够得到正常服务。

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

对于第二个问题,由于苹果人员很负责人的告知:我们的服务器不稳定,所以不排除收据验证超时的情况。对于验证超时的收据,保存到数据库中并标记为验证超时,定时任务每隔一定的时间去app store验证,确保能够获取收据的验证结果。

在开发过程中,需要测试应用是否能够正常的进行支付,但是又不能进行实际的支付,因此需要使用苹果提供的sandbox Store测试。Store Kit不能在iOS模拟器中使用,测试Store必须在真机上进行。

在sandbox中验证receipt:

https://sandbox.itunes.apple.com/verifyReceipt

在生产环境中验证receipt:

https://buy.itunes.apple.com/verifyReceipt

在实际开发过程中,服务器端通过issandbox字段标识客户端传递的收据是沙盒环境中的收据还是生产环境中的收据。在提交苹果审核前,沙盒测试均无问题。提交苹果审核后,被告知购买失败,审核未通过。通过查询日志发现,客户端发送的交易收据为沙盒收据,但是issandbox字段却标识为生产环境。

结论:

苹果审核app时,仍然在沙盒环境下测试。但是客户端同事在app提交苹果审核时,将issandbox字段写死,设置为生产环境。这样就导致沙盒收据发送到https://buy.itunes.apple.com/verifyReceipt去验证。

那么如何自动的识别收据是否是sandbox receipt呢?

识别沙盒环境下收据的方法有两种:

1.根据收据字段 environment = sandbox。

2.根据收据验证接口返回的状态码,如果status=21007,则表示当前的收据为沙盒环境下收据, t进行验证。

苹果反馈的状态码;

  • 21000App Store无法读取你提供的JSON数据
  • 21002 收据数据不符合格式
  • 21003 收据无法被验证
  • 21004 你提供的共享密钥和账户的共享密钥不一致
  • 21005 收据服务器当前不可用
  • 21006 收据是有效的,但订阅服务已经过期。当收到这个信息时,解码后的收据信息也包含在返回内容中
  • 21007 收据信息是测试用(sandbox),但却被发送到产品环境中验证
  • 21008 收据信息是产品环境中使用,但却被发送到测试环境中验证

先生产验证后测试验证,可以避免来回切换接口的麻烦。测试验证只要用你自己申请的测试appid的时候才会用到,用户不会拥有测试appid,所以不会走到测试验证这一步。即使生产验证出错,应该也不回返回21007状态吗。测试验证通过的用户名,和充值金额最好用数据库记录下来,方便公司资金核对。

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-10-10 06:17:22

IOS内购支付服务器验证模式的相关文章

IOS内购支付server验证模式

IOS 内购支付两种模式: 内置模式 server模式 内置模式的流程: app从app store 获取产品信息 用户选择须要购买的产品 app发送支付请求到app store app store 处理支付请求.并返回transaction信息 app将购买的内容展示给用户 server模式的流程: app从server获取产品标识列表 app从app store 获取产品信息 用户选择须要购买的产品 app 发送 支付请求到app store app store 处理支付请求,返回trans

iOS 内购讲解

一.总说内购的内容 1.协议.税务和银行业务 信息填写 2.内购商品的添加 3.添加沙盒测试账号 4.内购代码的具体实现 5.内购的注意事项 二.协议.税务和银行业务 信息填写 2.1.协议.税务和银行业务 信息填写 的入口 2.2.选择申请合同类型 进入协议.税务和银行业务页面后,会有3种合同类型,如果你之前没有主动申请过去合同,那么一般你现在激活的合同只有iOS Free Application一种. 页面内容分为两块: Request Contracts(申请合同) Contracts I

(转)iOS内购(iap)总结

刚刚做了内购, 记录一下 这里直接上代码, 至于写代码之前的一些设置工作参考以下文章: http://www.jianshu.com/p/690a7c68664e http://www.jianshu.com/p/86ac7d3b593a 需要注意的是: 只要工程配置了对应的证书, 就能请求商品信息, 不需要任何其他处理 沙盒测试填写的邮箱不能是已经绑定appleID的邮箱, 也不能是AppleID的救援邮箱, 其他的无所谓, 其实, 哪怕你填写的邮箱不存在也没有关系 // // IAPMana

IOS 内购

ios内购实现代码如下(): #import "ViewController.h" #import <StoreKit/StoreKit.h> @interface ViewController ()<SKProductsRequestDelegate,SKPaymentTransactionObserver> //记录产品列表 @property(nonatomic,strong)NSArray*allProducts; @end @implementatio

IOS内购验证

客户端在沙箱环境下购买成功之后,需要进行二次验证 参考自:http://www.himigame.com/iphone-cocos2d/550.html 当应用向Apple服务器请求购买成功之后,Apple会返回数据给应用,如下所示: 产品标识符: product Identifier[在itunes store应用内定义的产品ID,例如com.公司名.产品名.道具名(com.xxxx.video.vip)] 交易状态: state Purchased 购买成功 Restored 恢复购买 Fa

iOS内购 服务端票据验证及漏单引发的思考.

因业务需要实现了APP内购处理,但在过程中出现了部分不可控的因素,导致部分用户反映有充值不成并漏单的情况. 仔细考虑了几个付费安全上的问题,凡是涉及到付费的问题都很敏感,任何一方出现损失都是不能接受的,所以在这里整理一些支付安全的要点分享一下. 支付方式 IAP是指In-App Purchase, 是一种付费方式,而并不是苹果专有的付费方式,在其它平台上也会有不同的实现,这里针对Apple IAP. 说到IAP安全问题,在苹果的IAP流程中有一个比较明显的逻辑漏洞,这个逻辑漏洞是建立在我们处理不

IOS内购(IAP)的那些事

最近看了内购相关的东西,发现坑还真是不少,这里做个总结. IAP,即in-App Purchase,是一种智能移动终端应用程序付费的模式,在苹果(Apple)iOS.谷歌安卓(Google Android).微软WindowsPhone等智能移动终端操作系统中都有相应的实现. -- 百度百科 我们通过内购的流程,一步步地说坑到底在哪里 苹果内购的主要流程: 获取商品信息 --> 创建交易 --> 把交易添加到队列 --> 交易成功获取凭证 --> 拿着凭证做二次验证 -->

iOS 内购集成与遇到的坑

1.集成 集成内购的流程网上还是有很多的,在这我就不班门弄斧了. 附上几个比较好的链接: (1)http://www.jianshu.com/p/f7bff61e0b31 这个写的相当详细,里面也有一些细节,作者很好,给了我很多帮助. (2)http://www.jianshu.com/p/86ac7d3b593a 这个也是比较详细 (3)http://www.jianshu.com/p/479cf9e31104 以上三个链接足够你集成走通整个内购流程了. 2.遇到的坑 (1)集成税务时添加的银

iOS内购(IAP)中的那些坑

公司的公共库原来并没有这部分的代码,以前做内购是用两个比较有名的github上的第三方库.一个叫MKStoreKit,另一个叫IAPManager,我看了一下写的都很辣鸡,使用起来很不方便,而且写的还不对...... 于是我自己写了一个,一开始写的也不是很好,受了上面两个垃圾库的影响(这两个库接口是用postNotification的),使用时还要监听事件,下面的小弟吐槽说不太好用.于是我又重做了一个接口为block的版本,感觉写的还是不错的.这下用的就很舒服了! 虽然github上也有几个写的