参考我之前的笔记 苹果内购笔记，在客户端向苹果购买成功之后，我们需要进行二次验证。
二次验证
IOS在沙箱环境下购买成功之后，向苹果进行二次验证，确认用户是否购买成功。
当应用向Apple服务器请求购买，成功之后，Apple会返回以下四个数据给应用
四个验证数据
productIdentifier:cosmosbox.strikehero.gems60
state: Purchased
receipt:
ewoJInNpZ25hdHVyZSIgPSAiQXF1M3JiR1grbmJMeGVvZS9VZGlMa3dQWVlBdkQr
VTE1L1NRL2Y0cGZlaFlBOWFaVGhSbTNMVXpHc25TUGd3aVBoMmsxSTVFaVpweGp6
aEZsS0JDVXBPeHEyWFk5N1lHUGUzMFo0cThMRllDZWJPeHFzWlJaUU01N2xtZFo0
bDN6eHNnaWpGemFiYkRXLzM4cm1EeXFTT0FSYzRES3dXTGFpc2EzYUY5d2JwbUFB
QURWekNDQTFNd2dnSTdvQU1DQVFJQ0NCdXA0K1BBaG0vTE1BMEdDU3FHU0liM0RR
RUJCUVVBTUg4eEN6QUpCZ05WQkFZVEFsVlRNUk13RVFZRFZRUUtEQXBCY0hCc1pT
//receipt省略几十行
transactionIdentifier: 1000000160385706
1. 产品标识符: product Identifier
在itunes store应用内定义的产品ID，例如com.公司名.产品名.道具名(com.xxxx.video.vip)
2. 交易状态: state
| Purchased | 购买成功 |
| Restored | 恢复购买 |
| Failed | 失败 |
| Deferred | 等待确认，儿童模式需要询问家长同意 |
3. Receipt
很长的一段字符串，大概49行，作为二次验证的重要依据
4. 交易标识符: transaction Identifier
我们需要把Receipt发送給苹果的苹果的服务器验证，用户的购买信息是否真实
验证服务器地址
在测试服务器中，发送receipt苹果的测试服务器（ https://sandbox.itunes.apple.com/verifyReceipt ）验证
在正式服务器中(已上线Appstore)，发送receipt到苹果的正式服务器（ https://buy.itunes.apple.com/verifyReceipt ）验证
当我们把应用提交给苹果审核时，苹果也是在sandbox环境购买，其产生的购买凭证，也只能连接苹果的测试验证服务器，所以我们可以先发到苹果的正式服务器验证，如果苹果返回21007，则再一次连接测试服务器进行验证。
验证购买信息
以下是把客户端的购买信息发送到苹果测试服务器进行确认，苹果返回的数据：
ISN: url: https://sandbox.itunes.apple.com/verifyReceipt
ORIGINAL JSON:
{
"receipt":
{
"original_purchase_date_pst":"2015-06-22 20:56:34 America/Los_Angeles", //购买时间,太平洋标准时间
"purchase_date_ms":"1435031794826", //购买时间毫秒
"unique_identifier":"5bcc5503dbcc886d10d09bef079dc9ab08ac11bb",//唯一标识符
"original_transaction_id":"1000000160390314", //原始交易ID
"bvrs":"1.0",//iPhone程序的版本号
"transaction_id":"1000000160390314", //交易的标识
"quantity":"1", //购买商品的数量
"unique_vendor_identifier":"AEEC55C0-FA41-426A-B9FC-324128342652", //开发商交易ID
"item_id":"1008526677",//App Store用来标识程序的字符串
"product_id":"cosmosbox.strikehero.gems60",//商品的标识
"purchase_date":"2015-06-23 03:56:34 Etc/GMT",//购买时间
"original_purchase_date":"2015-06-23 03:56:34 Etc/GMT", //原始购买时间
"purchase_date_pst":"2015-06-22 20:56:34 America/Los_Angeles",//太平洋标准时间
"bid":"com.cosmosbox.StrikeHero",//iPhone程序的bundle标识
"original_purchase_date_ms":"1435031794826"//毫秒
},
"status":0 //状态码,0为成功
}
苹果返回状态码
| Status | 描述 |
| 21000 | App Store不能读取你提供的JSON对象 |
| 21002 | receipt-data域的数据有问题 |
| 21003 | receipt无法通过验证 |
| 21004 | 提供的shared secret不匹配你账号中的shared secret |
| 21005 | receipt服务器当前不可用 |
| 21006 | receipt合法，但是订阅已过期。服务器接收到这个状态码时，receipt数据仍然会解码并一起发送 |
| 21007 | receipt是Sandbox receipt，但却发送至生产系统的验证服务 |
| 21008 | receipt是生产receipt，但却发送至Sandbox环境的验证服务 |
更详细的请参考：http://www.2cto.com/kf/201504/389224.html
最好在客户端存一个数据库，跟踪订单的状态，防止用户订单在某个环节出现问题时无法寻找到订单进行二次处理。
去AppStore请求数据时有时候会出现错误，你可以iTunes connect里的connect us去给他们写邮件反馈问题。但是大部分时间你等等就能解决了，对就是什么也不做等着。也许那一天他就好了。
单机/服务器模式
IOS 应用内支付(内购 /In App Purchase)有两种模式：
1) 单机模式
2) 服务器模式
单机模式
单机模式的流程可以简单的总结为以下几步：
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验证，确保能够获取收据的验证结果。