标签：json对象 table 参数 json格式 消费 第一条 elf 开发者 completed
最近看了内购相关的东西，发现坑还真是不少，这里做个总结。
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，所以它并不能用来确定是哪个订单。我们从沙盒中取到凭证（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的时候就没有想过后台的参与，但是，为了安全起见，我们要把二次验证放到后台做，至于为什么，我们后边会讲到。但是不管怎样，我们至少要了解一下怎么做的二次校验。
{"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。SKPaymentTransactionStatePurchased的时候finishTransaction:结束交易，因为每次返回的reciptData是不同的。除非我们每次都去更新它。并且这样做的话，用户卸载App的时候，保存的订单信息全部都没有了。updatedTransactions:方法由于苹果的服务器在美帝，所以延迟的情况还是很严重的，这时候如果是请求超时，我们服务器又没有收到回调，那么就会产生掉单。比较坑的是，updatedTransactions:在App整个生命周期只会走一次。其实这种情况只要重启App就会重新走苹果的补单流程了。大佬们如果觉得用户体验不好，可以把信息存本地，隔一段时间请求一次服务器。
其实现在掉单基本就是上面说的那个原因了，只要把它解决了，掉单基本上也就没有了。
注意：
recipt，就说明苹果已经扣款成功了。但是为什么我们不能以这个作为支付成功的标准呢，请看下面的刷单系列。recipt存本地的方法，其实没有必要，苹果自己的补单措施基本上是够用了。recipt存本地。因为如果在有多个成功交易未 finish 掉的情况下把应用关闭后再次打开的时候，有些交易的回调会被漏掉（苹果真坑啊！！！）。当然两者结合也是一个很好的办法。刷单的转自这篇博客，我在这里简述一下，做个小结。
刷单主要有以下几种方式：
recipt-data
我们这里只讨论 1 和 2 ，因为下面三种跟我们开发者没有关系，想要详细了解的可以去开头的博客上了解一下。
这个主要是我们不做二次验证引发的漏洞，非法用户可以利用插件模拟扣款成功，有可能是手动调用updatedTransactions:（我猜的??）。就算是我们在App端做了二次验证，结果也有可能是被篡改过的。所以我们需要在自己的服务端进行二次验证。 任何在App端的数据都是不安全的！！！
recipt-data
我们直到，recipt-data是支付成功返回给我们的校验凭证，前面说过，苹果校验的时候只负责校验recipt的有效性和真假，并不负责这个凭证是否被用过。如果我们在后台只判断status == 0，而不去做其他判断的话，非法用户会保存recipt-data，然后多次使用，因为每次都是校验通过的。
我们也不能判断recipt-data是否被使用，因为上面已经说过，同一个订单也会有多个recipt-data返回的。
防范的方法是在确定status值为0后，进一步解析出数据中的transaction_id并存入数据库。每次发货前先检查数据库中是否已经有本次的transaction_id存在，如果已存在则拒绝发货。
还有一种情况需要注意，有些App购买前先有一步创建订单的行为，在服务器端记录购买的商品、时间等，且发货时是按照订单记录中的商品，那么需要比较苹果返回信息中的product_id与订单表中的记录值是否一致。
到了这里IAP基本上已经结束了，小弟只是把IAP的流程以及需要注意的点列出来，以上的方法只是作为总结，并不适用于所有状况，我们在开发中还要具体问题具体分析。希望大家开发中都不会掉单??。
标签：json对象 table 参数 json格式 消费 第一条 elf 开发者 completed
原文地址：https://www.cnblogs.com/xiaoyuer123/p/10075737.html
