自动续订订阅和应用回执

时间:2015-05-27 15:53:44

标签: ios in-app-purchase

我想知道当IAP自动续订订阅自动续订时是否以及何时自动刷新应用收据。文档暗示在购买时更新应用程序收据(续订?)但我在IAP沙箱中没有看到此行为:

  

有关消耗品和非续订订阅的信息   当收据付款并保留在收据中时,它会被添加到收据中   收据,直到您完成交易。完成后   交易,此信息将在下次收据时删除   更新 - 例如,下次用户进行购买。

     

有关所有其他类型购买的信息会添加到收据中   当他们付款并无限期地留在收据中时。

此外,文档声明:

  

成功续订订阅后,Store Kit会添加一个   用于续订事务队列的事务。你的应用检查   启动时的事务队列并以相同的方式处理续订   与任何其他交易一样。请注意,如果您的应用已在运行   订阅更新时,不调用事务观察者;   您的应用在下次启动时会发现续订。

对我而言,这意味着我可以监控SKPaymentQueue已完成的交易,然后检查应用收据以查找它们的记录。但我在IAP沙箱中没有看到这种情况。在IAP沙箱中,我有一个自动续订订阅,即自动续订(每次用户/购买6次,正常的沙箱行为)但要发现续订,我需要手动刷新应用收据。< / p>

假设这一切都按照我期望的方式运行,是否有最佳实践在IAP沙箱中进行测试以触发此行为?

1 个答案:

答案 0 :(得分:5)

作为旁注,文件与采购类型及其在收据中的持久性不一致 - 请参阅my answer to this question.

自动续订时,服务器端的 > 更新 - 您可以通过调用服务器端validateReceipt方法来确认。< / p>

更新:看到你正在使用RMStore,我嘲笑了一些东西,以便我可以看一下这个行为。

我认为客户端收据 正在更新。我的方案:一个月的AR订阅(所以在沙盒中续订5分钟)。我在viewDidLoad中添加了一些诊断代码:

RMAppReceipt *receipt = [RMAppReceipt bundleReceipt];
if (receipt != nil) {
    NSDateFormatter* localDateTime = [[NSDateFormatter alloc] init];
    [localDateTime setTimeZone:[NSTimeZone timeZoneWithName:@"PST"]];
    [localDateTime setDateFormat:@"yyyy.MM.dd HH:mm:ss zzz"];

    for (RMAppReceiptIAP* purchase in receipt.inAppPurchases) {
        NSString* cancellationDate = nil;
        if (purchase.cancellationDate) {
            cancellationDate = [localDateTime stringFromDate:purchase.cancellationDate];
        }
        NSLog(@"Transaction: %@: product %@, original purchase date: %@, expiration date: %@, cancellation date: %@",
              purchase.originalTransactionIdentifier,
              purchase.productIdentifier,
              [localDateTime stringFromDate:purchase.originalPurchaseDate],
              [localDateTime stringFromDate:purchase.subscriptionExpirationDate],
              cancellationDate);
    }

我还在RMStore的paymentQueue:updatedTransactions:中设置了一个断点,以查看队列是否随后续AR购买更新。

然后我购买了一个月的测试产品,验证了交易,然后退出了应用程序。

在后续每隔5分钟重新调用一次应用程序时,我看到SKPaymentTransactionObserver方法中的断点被transactionSate SKPaymentTransactionStatePurchased命中。日志显示连续添加的购买(仅显示最后版本):

2015-05-27 14:27:32.828 StoreKitSandbox[5803:1054853] Transaction: 1000000156919353: product com.foo.StoreKitSandbox.1_month_autorenew_foo, original purchase date: 2015.05.27 14:02:59 GMT-7, expiration date: 2015.05.27 14:07:58 GMT-7, cancellation date: (null)
2015-05-27 14:27:33.350 StoreKitSandbox[5803:1054853] Transaction: 1000000156919353: product com.foo.StoreKitSandbox.1_month_autorenew_foo, original purchase date: 2015.05.27 14:06:02 GMT-7, expiration date: 2015.05.27 14:12:58 GMT-7, cancellation date: (null)
2015-05-27 14:27:33.774 StoreKitSandbox[5803:1054853] Transaction: 1000000156919353: product com.foo.StoreKitSandbox.1_month_autorenew_foo, original purchase date: 2015.05.27 14:11:07 GMT-7, expiration date: 2015.05.27 14:17:58 GMT-7, cancellation date: (null)
2015-05-27 14:27:34.174 StoreKitSandbox[5803:1054853] Transaction: 1000000156919353: product com.foo.StoreKitSandbox.1_month_autorenew_foo, original purchase date: 2015.05.27 14:16:00 GMT-7, expiration date: 2015.05.27 14:22:58 GMT-7, cancellation date: (null)
2015-05-27 14:27:34.637 StoreKitSandbox[5803:1054853] Transaction: 1000000156919353: product com.foo.StoreKitSandbox.1_month_autorenew_foo, original purchase date: 2015.05.27 14:21:04 GMT-7, expiration date: 2015.05.27 14:27:58 GMT-7, cancellation date: (null)
2015-05-27 14:27:35.069 StoreKitSandbox[5803:1054853] Transaction: 1000000156919353: product com.foo.StoreKitSandbox.1_month_autorenew_foo, original purchase date: 2015.05.27 14:26:15 GMT-7, expiration date: 2015.05.27 14:32:58 GMT-7, cancellation date: (null)

你可以使用这种诊断方法重新编写吗?