谈谈苹果应用内支付(IAP)的坑

前言

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,只要没有用finish​Transaction:​方法结束掉的transaction,都会重新出现在updatedTransactions:方法里。系统为我们做好了非常安全的存储transaction和receipt的操作,底层原理目前还不清楚。本人试过,删除应用后重新安装,只要Bundle ID不变,依然能跳到updatedTransactions:方法里。

注意!如果在付款给苹果之前,你们的后台自己搞了个orderNum这样一个订单号出来,就要自己存储这个orderNum了。
另外,既然后台搞了个订单号出来,就默认这个订单号关联了某一种商品,所以获取receipt时就要用transaction.transactionReceipt,这样才能保证获取的receipt只包含1条交易信息。


关于receipt验证的更多资料,请点击这里

欢迎补充!本人qq:2224048633

推荐阅读更多精彩内容