最近看了内购相关的东西，发现坑还真是不少，这里做个总结。
IAP，即in-App Purchase，是一种智能移动终端应用程序付费的模式，在苹果（Apple）iOS、谷歌安卓（Google Android）、微软WindowsPhone等智能移动终端操作系统中都有相应的实现。
-- 百度百科
我们通过内购的流程，一步步地说坑到底在哪里
苹果内购的主要流程：
获取商品信息 --> 创建交易 --> 把交易添加到队列 --> 交易成功获取凭证 --> 拿着凭证做二次验证 --> 交易成功
-
通过产品ID获取商品信息（SKProduct）。
#import <StoreKit/StoreKit.h> //把商品ID信息放入一个集合中 NSSet *sets = [NSSet setWithObjects:@"phonicsphase1", nil]; //请求内购商品信息，只返回你请求的产品（主要用于验证商品的有效性） SKProductsRequest *productrequest = [[SKProductsRequest alloc] initWithProductIdentifiers:sets]; productrequest.delegate = self; [productrequest start]; #pragma mark - 获取商品ID成功的代理方法 - (void)productsRequest:(SKProductsRequest *)request didReceiveResponse:(SKProductsResponse *)response { //返回的是SKProduct对象数组 //如果你上面请求的是多个，那么这里返回的也是多个 SKProduct *product = [response.products firstObject]; //查询成功，开始支付 [self startPaymentWithProduct:product]; } -
拿到商品信息，创建支付对象（SKMutablePayment）。
- (void)startPaymentWithProduct:(SKProduct *)product { SKMutablePayment *payment = [SKMutablePayment paymentWithProduct:product]; payment.applicationUsername = @"myOrderID"; [[SKPaymentQueue defaultQueue] addPayment:payment]; }
这里的applicationUsername是一个透传字段，我们在这里传什么参数，在支付成功的时候Apple会原封不动的返回给我们。
最常用的就是拿它传递我们自己的订单号，以便跟我们知道是哪个订单支付成功了。
这里有个坑： 据说我们传递过去的applicationUsername有可能返回的时候变成空的，这点我没有遇到，有遇到的可以说一下。
-
把当前交易添加到交易队列中去（上面的addPayment:方法）。
-
监听支付结果（paymentQueue:updatedTransactions:），如果支付成功，Apple会把支付成功的凭证（recipt）存到沙盒中。
//首先我们要在 viewDidLoad 方法中添加监听对象 [[SKPaymentQueue defaultQueue] addTransactionObserver:self]; #pragma mark - 监听的代理方法 - (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray<SKPaymentTransaction *> *)transactions { [transactions enumerateObjectsUsingBlock:^(SKPaymentTransaction * _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) { SKPaymentTransaction *transation = obj; switch (transation.transactionState) { case SKPaymentTransactionStatePurchasing: { NSLog(@"购买中"); } break; case SKPaymentTransactionStatePurchased: { NSLog(@"交易完成"); //获取透传字段 NSString *orderNo = transation.payment.applicationUsername; //transactionIdentifier：相当于Apple的订单号 NSString *transationId = transation.transactionIdentifier; NSLog(@"orderNo = %@, 交易ID = %@", orderNo, transationId); //从沙盒中获取交易凭证 NSData *reciptData = [NSData dataWithContentsOfURL:[[NSBundle mainBundle] appStoreReceiptURL]]; //转化成Base64字符串（用于校验） NSString *reciptString = [reciptData base64EncodedStringWithOptions:NSDataBase64Encoding64CharacterLineLength]; //传给后台做二次验证 [self checkReceipt:reciptString]; } break; case SKPaymentTransactionStateFailed: { //localizedDescription可以作为提示信息（交易失败无法连接到 iTunes Store） NSLog(@"交易失败%@", transation.error.localizedDescription); [[SKPaymentQueue defaultQueue] finishTransaction:transation]; } break; case SKPaymentTransactionStateRestored: { NSLog(@"恢复购买完成"); //恢复完成（对应restoreCompletedTransactions）方法 } break; case SKPaymentTransactionStateDeferred: { NSLog(@"交易推迟, 等待外部操作"); //交易推迟 //官方解释是：交易已经加入队列，但是需要等待外部操作 //主要用于儿童模式，需要询问家长同意。这种情况下不能关闭订单（完成交易），否则这类充值将无法处理。 } break; default: break; } }]; }注意：
- 透传字段
applicationUsername可能返回的是nil，这也是丢单的原因之一，有些人说遇到过，有的则说没有遇到过。这个尚不清楚。 -
[[SKPaymentQueue defaultQueue] finishTransaction:transation]如果不调用这个方法，那么transation就永远不会结束。也就是说每次进来都会重新调用updatedTransactions这个方法，就算你做过二次校验都没用。 - 二次校验只会校验你的凭证是不是有效，不会关心你这个凭证是不是校验过了，所以说，一个凭证可以被校验多次（这是刷单方法之一）
- 上面说过，如果不
finishTransaction，每次进入这个界面都会调用监听方法，但是注意了每次返回的 reciptData都是不一样，即使是同一个订单。也就是说，同一个订单也有可能有多个reciptData，所以它并不能用来确定是哪个订单。 - 我们最好是在App启动的时候就去设置监听。把内购封装成一个工具类，这样每次启动App就会调用苹果的补单流程。
- 透传字段
-
我们从沙盒中取到凭证（recipt），发送给我们自己后台进行二次验证，验证成功表示支付成功。
- (void)checkReceipt:(NSString *)receipt { [AntManager postWithPath:CheckReceipt_URL params:params success:^(id response) { if ([response[@"status"] integerValue] == 0) { //如果支付成功，我们就结束交易 [[SKPaymentQueue defaultQueue] finishTransaction:transation] } else { } } failure:^(id error) { }]; }注意：前面说过，Apple在最初设计IAP的时候就没有想过后台的参与，但是，为了安全起见，我们要把二次验证放到后台做，至于为什么，我们后边会讲到。但是不管怎样，我们至少要了解一下怎么做的二次校验。
- 我们把recipt经过Base64编码之后，传给Apple的验证服务器进行验证（格式如下：）。
{"receipt-data": 你编码过的recipt}-
Apple的验证服务器地址有两个
https://sandbox.itunes.apple.com/verifyReceipt是沙盒环境的验证地址。https://buy.itunes.apple.com/verifyReceipt是正式环境的验证地址 -
如果你用的是测试账号（就是在iTunes Connect里面设置的，具体请看这里）支付的，那么你就需要发送到沙盒环境的验证地址，正式环境应该切换到正式环境的验证地址。
Apple返回的完整数据如下：{ "status": 0, "environment": "Sandbox" "receipt": { "receipt_type": "ProductionSandbox", "adam_id": 0, "app_item_id": 0, "bundle_id": "com.BlueMobi.Phonics", "application_version": "1.5.0", "download_id": 0, "version_external_identifier": 0, "receipt_creation_date": "2018-06-28 14:08:26 Etc/GMT", "receipt_creation_date_ms": "1530194906000", "receipt_creation_date_pst": "2018-06-28 07:08:26 America/Los_Angeles", "request_date": "2018-08-05 04:50:58 Etc/GMT", "request_date_ms": "1533444658147", "request_date_pst": "2018-08-04 21:50:58 America/Los_Angeles", "original_purchase_date": "2013-08-01 07:00:00 Etc/GMT", "original_purchase_date_ms": "1375340400000", "original_purchase_date_pst": "2013-08-01 00:00:00 America/Los_Angeles", "original_application_version": "1.0", "in_app": [ { "quantity": "1", "product_id": "*******", "transaction_id": "1000000404314890", //这个苹果的交易唯一标识符 "original_transaction_id": "1000000404314890", "purchase_date": "2018-06-04 09:58:41 Etc/GMT", "purchase_date_ms": "1528106321000", "purchase_date_pst": "2018-06-04 02:58:41 America/Los_Angeles", "original_purchase_date": "2018-06-04 09:58:41 Etc/GMT", "original_purchase_date_ms": "1528106321000", "original_purchase_date_pst": "2018-06-04 02:58:41 America/Los_Angeles", "is_trial_period": "false" }, { "quantity": "1", "product_id": "*******", "transaction_id": "1000000404523773", "original_transaction_id": "1000000404523773", "purchase_date": "2018-06-05 02:21:26 Etc/GMT", "purchase_date_ms": "1528165286000", "purchase_date_pst": "2018-06-04 19:21:26 America/Los_Angeles", "original_purchase_date": "2018-06-05 02:21:26 Etc/GMT", "original_purchase_date_ms": "1528165286000", "original_purchase_date_pst": "2018-06-04 19:21:26 America/Los_Angeles", "is_trial_period": "false" } ] } } -
Apple返回的数据也是Json格式的，里面有个字段
status，当status == 0的时候，表示校验成功。但是，我们不能以这个status为标准，我们还要判断我们的订单是不是在校验信息里面。 -
当
status不为0的时候，是没有其余的Json数据的。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 环境的验证服务 -
in_app是一个数组，一条数据对应一条交易。后台需要遍历数组，跟我们传递给后台的transaction_id做对比，看看是否存在啊，如果存在就说明本条交易校验成功了。 -
有人说
in_app里面的数据是按照时间先后来排序的，只取第一条就可以了，但是经过我的测试发现并不是这样的，所以最好还是逐条对比。
掉单问题的探讨
苹果的IAP缺陷还是很明显的，但是没办法，谁让苹果一家独大呢，我们也只能吐吐槽，想尽一切办法防止掉单的发生。
掉单的原因是有多方面的，我们一个个来说。
-
首先苹果是有补单措施的，如果不finish交易，每次都会请求
updatedTransactions:方法的。但是前面说了，applicationUsername的缺失会导致掉单。applicationUsername的丢失会让我们丢失订单号，但是实际的支付仍然是成功的。- 可以传递给后台
未知订单，但客户投诉的时候，我们从未知订单里面找到符合条件的给恢复订单信息（这样做显然效率很低） -
常用的做法是：
- 把每个订单的
recipt、orderNumber、userId、transactionIdentifier等你需要的信息保存为一个plist文件，每个plist文件对应一个订单。等我们后台返回支付成功的时候就删除相应的plist。 - 每次启动App的时候去沙盒查找plist文件，如果有，就读取plist文件去请求服务器做二次验证，直到服务器返回成功为止。
- 但是这样做，就需要在
SKPaymentTransactionStatePurchased的时候finishTransaction:结束交易，因为每次返回的reciptData是不同的。除非我们每次都去更新它。并且这样做的话，用户卸载App的时候，保存的订单信息全部都没有了。
- 把每个订单的
- 用户支付过后，没有等到验证，就更换Apple账号登录。这种情况我没有试过会不会调用
updatedTransactions:方法 - 其实这个问题始终没有一个很好的解决方案，只能靠苹果的优化了。
- 可以传递给后台
-
由于苹果的服务器在美帝，所以延迟的情况还是很严重的，这时候如果是请求超时，我们服务器又没有收到回调，那么就会产生掉单。比较坑的是，
updatedTransactions:在App整个生命周期只会走一次。其实这种情况只要重启App就会重新走苹果的补单流程了。大佬们如果觉得用户体验不好，可以把信息存本地，隔一段时间请求一次服务器。
其实现在掉单基本就是上面说的那个原因了，只要把它解决了，掉单基本上也就没有了。
注意：
- 掉单问题都是出现在支付完成之后，没有通过二次校验的时候。因为一旦我们得到了
recipt，就说明苹果已经扣款成功了。但是为什么我们不能以这个作为支付成功的标准呢，请看下面的刷单系列。 - 针对上面第二种
recipt存本地的方法，其实没有必要，苹果自己的补单措施基本上是够用了。 - 如果是你们的App中，用户可以一次性购买多个产品，那么更推荐把
recipt存本地。因为如果在有多个成功交易未 finish 掉的情况下把应用关闭后再次打开的时候，有些交易的回调会被漏掉（苹果真坑啊！！！）。当然两者结合也是一个很好的办法。
刷单的问题
刷单的转自这篇博客，我在这里简述一下，做个小结。
刷单主要有以下几种方式：
- 破解IAP
- 重复使用
recipt-data - 信用卡黑卡
- 外币差价
- 以及苹果对小额消费不做验证规则的“36技术”
我们这里只讨论 1 和 2 ，因为下面三种跟我们开发者没有关系，想要详细了解的可以去开头的博客上了解一下。
1. 破解IAP
这个主要是我们不做二次验证引发的漏洞，非法用户可以利用插件模拟扣款成功，有可能是手动调用updatedTransactions:（我猜的??）。就算是我们在App端做了二次验证，结果也有可能是被篡改过的。所以我们需要在自己的服务端进行二次验证。 任何在App端的数据都是不安全的！！！
2. 重复使用recipt-data
我们直到，recipt-data是支付成功返回给我们的校验凭证，前面说过，苹果校验的时候只负责校验recipt的有效性和真假，并不负责这个凭证是否被用过。如果我们在后台只判断status == 0，而不去做其他判断的话，非法用户会保存recipt-data，然后多次使用，因为每次都是校验通过的。
我们也不能判断recipt-data是否被使用，因为上面已经说过，同一个订单也会有多个recipt-data返回的。
防范的方法是在确定status值为0后，进一步解析出数据中的transaction_id并存入数据库。每次发货前先检查数据库中是否已经有本次的transaction_id存在，如果已存在则拒绝发货。
还有一种情况需要注意，有些App购买前先有一步创建订单的行为，在服务器端记录购买的商品、时间等，且发货时是按照订单记录中的商品，那么需要比较苹果返回信息中的product_id与订单表中的记录值是否一致。
到了这里IAP基本上已经结束了，小弟只是把IAP的流程以及需要注意的点列出来，以上的方法只是作为总结，并不适用于所有状况，我们在开发中还要具体问题具体分析。希望大家开发中都不会掉单??。