前言
IAP支付的坑太多，这里写一些高级点的坑。
一、请求商品
下面是请求商品的代码：
- (void)validateProductIdentifier:(NSArray *)productIdentifier {
SKProductsRequest *productRequest = [[SKProductsRequest alloc] initWithProductIdentifiers:[NSSet setWithArray:productIdentifier]];
self.request = productRequest;
productRequest.delegate = self;
[productRequest start];
}
#pragma mark - SKProductsRequestDelegate Protocol
- (void)productsRequest:(SKProductsRequest *)request didReceiveResponse:(SKProductsResponse *)response {
self.products = response.products;
[response.products enumerateObjectsUsingBlock:^(id _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) {
SKProduct *product = (SKProduct *)obj;
NSLog(@"valid identifier: %@", product.productIdentifier);
}];
for (NSString *invalidIdentifier in response.invalidProductIdentifiers) {
// invalid identifier
NSLog(@"invalid identifier: %@", invalidIdentifier);
}
if (![SKPaymentQueue canMakePayments]) {
// display error UI ...
}
// display store UI ...
}向苹果服务器请求商品信息，是为了展示商店UI。请求到的SKProduct，包含了商品的标题、描述、价格、货币符号等信息。在国内，一般都是服务器接口提供商品信息，客户端直接展示商店UI，用户点击购买的时候，才发起支付。所以，这种情况下，没必要向苹果服务器请求商品信息。因为请求商品信息时，苹果服务器在海外，国内延迟大，慢的约六七秒，甚至有可能跳不到SKProductsRequest的代理方法里面，造成支付失败。
解决办法：
直接省略掉SKProductsRequest这个请求的创建发起。支付时，使用paymentWithProductIdentifier来直接生成SKPayment。
SKPayment *payment = [SKPayment paymentWithProductIdentifier:productIdentifier];
[[SKPaymentQueue defaultQueue] addPayment:payment];二、receipt验证
获取receipt
NSData *receipt;
if (IOS7_OR_LATER) {
// iOS 7 style app receipts
NSURL *receiptURL = [[NSBundle mainBundle] appStoreReceiptURL];
receipt = [NSData dataWithContentsOfURL:receiptURL];
}else {
// iOS 6 style transaction receipt
receipt = transaction.transactionReceipt;
}验证receipt
Receipt Validation Programming Guide 上面地址是receipt的验证方法。出于安全考虑，app receipt需要第三方服务器来和苹果服务器进行验证。验证后返回值是json字典。
关于字段status的说明如下：
For iOS 6 style transaction receipts, the status code reflects the status of the specific transaction’s receipt.
For iOS 7 style app receipts, the status code is reflects the status of the app receipt as a whole. For example, if you send a valid app receipt that contains an expired subscription, the response is 0 because the receipt as a whole is valid.
可以看到，iOS 6风格的receipt，包含的就是该笔transaction的receipt。
而iOS 7风格的receipt，包含的信息是一个列表，里面包含了很多transaction的信息，如果返回status=0，那么只是表示整个App的receipt验证通过。
app端需要发receipt给服务端，服务端向苹果服务器验证receipt，然后返回status。注意！iOS 7风格的receipt包含了整个应用的所有的交易凭据，所以，status=0时，应该分发该receipt中所有transaction的商品。苹果的验证结果只告诉我们receipt有效还是无效，并不知道哪些transaction分发过商品，所以，服务端需要根据从数据库里面查询，排重，记录，还要验证该笔transaction是否为退过款的订单，避免重复分发商品。
误区：
使用[[NSBundle mainBundle] appStoreReceiptURL]获得receipt，服务端却试图寻找最后一笔transaction信息。
正确姿势：
应该分发该receipt中所有transaction的商品（重复使用的、退款的除外）
receipt JSON返回结果
iOS 7风格
{
environment = Sandbox;
receipt = {
"adam_id" = 0;
"app_item_id" = 0;
"application_version" = "1.0";
"bundle_id" = "com.dianzhong.kuaikan";
"download_id" = 0;
"in_app" = (
{
"is_trial_period" = false;
"original_purchase_date" = "2016-09-18 07:55:33 Etc/GMT";
"original_purchase_date_ms" = 1474185333000;
"original_purchase_date_pst" = "2016-09-18 00:55:33 America/Los_Angeles";
"original_transaction_id" = 1000000236789335;
"product_id" = "com.dianzhong.kuaikan6";
"purchase_date" = "2016-09-18 07:55:33 Etc/GMT";
"purchase_date_ms" = 1474185333000;
"purchase_date_pst" = "2016-09-18 00:55:33 America/Los_Angeles";
quantity = 1;
"transaction_id" = 1000000236789335;
},
...
);
"original_application_version" = "1.0";
"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";
"receipt_creation_date" = "2017-04-05 08:53:06 Etc/GMT";
"receipt_creation_date_ms" = 1491382386000;
"receipt_creation_date_pst" = "2017-04-05 01:53:06 America/Los_Angeles";
"receipt_type" = ProductionSandbox;
"request_date" = "2017-04-05 08:54:44 Etc/GMT";
"request_date_ms" = 1491382484980;
"request_date_pst" = "2017-04-05 01:54:44 America/Los_Angeles";
"version_external_identifier" = 0;
};
status = 0;
}iOS 6风格
{
receipt = {
bid = "com.dianzhong.kuaikan";
bvrs = "1.0";
"item_id" = 1140823223;
"original_purchase_date" = "2017-04-01 08:48:59 Etc/GMT";
"original_purchase_date_ms" = 1491036539000;
"original_purchase_date_pst" = "2017-04-01 01:48:59 America/Los_Angeles";
"original_transaction_id" = 1000000286821320;
"product_id" = "com.dianzhong.kuaikan12";
"purchase_date" = "2017-04-01 08:48:59 Etc/GMT";
"purchase_date_ms" = 1491036539000;
"purchase_date_pst" = "2017-04-01 01:48:59 America/Los_Angeles";
quantity = 1;
"transaction_id" = 1000000286821320;
"unique_identifier" = 367c781771909890ea8d59b25db3daf05ef0fbcb;
"unique_vendor_identifier" = "7F144627-A82D-4D71-AACD-C3BAF2ED6684";
};
status = 0;
}可以发现，两者的结构基本一致，都包含一个名为receipt的字典，不同的是，iOS 7风格的receipt，把每一笔交易信息放到了in_app数组里。
服务端要做的事情：
当status=0时，记录receipt中的全部交易信息。
服务端可根据transaction_id来记录每一笔交易的信息，作为一条记录，写入数据库，方便后续查询和排重。
字段 | 类型 | 描述 |
transaction_id | integer | 交易号 |
original_transaction_id | integer | 原始交易号 |
product_id | string | 商品标识符 |
quantity | integer | 数量 |
purchase_date | string | 购买日期 |
original_purchase_date | string | 原始购买日期 |
purchase_date_ms | integer | 购买日期(ms) |
original_purchase_date_ms | integer | 原始购买日期(ms) |
purchase_date_pst | string | 购买日期(pst) |
original_purchase_date_pst | string | 原始购买日期(pst) |
cancellation_date | string | 取消购买的日期 |
流程如下：
服务端处理receipt的流程
退款的订单
用户退款过的订单依然会在receipt中出现，因此App服务器实现验证的时候需要能够识别出已经被退款的订单，不至于给退款的订单发货。
被退款订单的唯一标识是：它带有一个cancellation_date字段。
服务端验证凭据时，如果有这个字段，则不分发商品。
三、receipt的安全
唐巧在他的《iOS应用内付费(IAP)开发步骤列表》中提到:
考虑到网络异常情况，iOS端的发送凭证操作应该进行持久化，如果程序退出，崩溃或网络异常，可以恢复重试。
实际上，我们不需要手动造车轮！
SKPaymentQueue只要被监听，系统会遍历该应用所有的transaction，只要没有用finishTransaction:方法结束掉的transaction，都会重新出现在updatedTransactions:方法里。系统为我们做好了非常安全的存储transaction和receipt的操作，底层原理目前还不清楚。本人试过，删除应用后重新安装，只要Bundle ID不变，依然能跳到updatedTransactions:方法里。
注意！如果在付款给苹果之前，你们的后台自己搞了个orderNum这样一个订单号出来，就要自己存储这个orderNum了。
另外，既然后台搞了个订单号出来，就默认这个订单号关联了某一种商品，所以获取receipt时就要用transaction.transactionReceipt，这样才能保证获取的receipt只包含1条交易信息。
