前言
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中出現，因此App服務器實現驗證的時候需要能夠識別出已經被退款的訂單，不至于給退款的訂單發貨。
被退款訂單的唯一標識是：它帶有一個cancellation_date字段。
服務端驗證憑據時，如果有這個字段，則不分發商品。
三、receipt的安全
唐巧在他的《iOS應用內付費(IAP)開發步驟列表》中提到:
考慮到網絡異常情況，iOS端的發送憑證操作應該進行持久化，如果程序退出，崩潰或網絡異常，可以恢復重試。
實際上，我們不需要手動造車輪！
SKPaymentQueue只要被監聽，系統會遍歷該應用所有的transaction，只要沒有用finish?Transaction:?方法結束掉的transaction，都會重新出現在updatedTransactions:方法里。系統為我們做好了非常安全的存儲transaction和receipt的操作，底層原理目前還不清楚。本人試過，刪除應用后重新安裝，只要Bundle ID不變，依然能跳到updatedTransactions:方法里。
注意！如果在付款給蘋果之前，你們的后臺自己搞了個orderNum這樣一個訂單號出來，就要自己存儲這個orderNum了。
另外，既然后臺搞了個訂單號出來，就默認這個訂單號關聯了某一種商品，所以獲取receipt時就要用transaction.transactionReceipt，這樣才能保證獲取的receipt只包含1條交易信息。
關于receipt驗證的更多資料，請點擊這里
歡迎補充！本人qq：2224048633
