自动续订订阅和应用收据 [英] Auto-renewing subscription and app receipt
问题描述
我想知道当IAP自动续订订阅自动续订时是否以及何时自动刷新应用收据。文档暗示应用收据在购买时更新（续订？）但我在IAP沙箱中没有看到此行为：
I want to know if and when the app receipt is automagically refreshed when an IAP auto-renew subscription auto renews. The documentation implies that the app receipt is updated when a purchase is made (renewal?) but I'm not seeing this behavior in the IAP sandbox:
有关消耗品和非续订订阅的信息
将在付款时添加到收据中，并保留在
收据中，直至您完成交易。完成
交易后，下次收据
更新时会删除此信息 - 例如，下次用户进行购买时。
Information about consumable products and non-renewing subscriptions is added to the receipt when they’re paid for and remains in the receipt until you finish the transaction. After you finish the transaction, this information is removed the next time the receipt is updated—for example, the next time the user makes a purchase.
有关所有其他类型购买的信息会在付款时添加到收据
中，并且无限期地保留在收据中。
此外，文档说明：
订阅成功续订后，Store Kit添加用于续订事务队列的
事务。您的应用程序在启动时检查
事务队列，并以与任何其他事务相同的方式处理续订
。请注意，如果您的应用在订阅续订时已经运行
，则不会调用事务观察器;
你的应用程序会在下次启动时发现续订。
After a subscription is successfully renewed, Store Kit adds a transaction for the renewal to the transaction queue. Your app checks the transaction queue on launch and handles the renewal the same way as any other transaction. Note that if your app is already running when the subscription renews, the transaction observer is not called; your app finds out about the renewal the next time it’s launched.
对我而言这意味着我可以监控 SKPaymentQueue 对于已完成的交易，然后检查应用收据以查找它们的记录。但我在IAP沙箱中没有看到这一点。在IAP沙箱中，我有一个自动续订订阅，即自动续订（每次用户/购买6次，正常的沙箱行为）但要发现续订，我需要手动刷新应用收据。
To me this implies that I can monitor the SKPaymentQueue for completed transactions then check the app receipt to find record of them. But I'm not seeing this in practice in the IAP sandbox. In the IAP sandbox I have an auto-renew subscription which is auto-renewing (6 times per user/purchase, normal sandbox behavior) but to discover the renewal I need to manually refresh the app receipt.
假设这一切都按照我期望的方式运行，是否有最佳实践在IAP沙箱中进行测试以触发此行为？
Assuming this all does work the way I'm expecting it to, are there best practices for testing in the IAP sandbox to trigger this behavior?
推荐答案
作为旁注，文件与购买类型及其在收据中的持久性不一致 - 请参阅我回答这个问题。
As a side note, the documentation is inconsistent on the types of purchases and their persistence in the receipt -- see my answer to this question.
当自动续订结束时，服务器端的收据 更新 - 您可以通过调用服务器端 validateReceipt 方法。
The receipt is updated on the server-side when the auto-renew ticks over -- you can confirm this by checking with a call to the server-side validateReceipt method.
更新：看到你正在使用RMStore，我嘲笑了一些东西我可以看一下这个行为。
UPDATE: Having seen that you're using RMStore, I mocked something up so that I could look at the behavior.
在我看来，客户端收据 正在更新。我的方案：一个月的AR订阅（所以在沙盒中续订5分钟）。我在 viewDidLoad 中放了一些诊断代码：
It looks to me like the client-side receipt is being updated. My scenario: one month AR subscription (so 5 minute renew in the sandbox). I put some diagnostic code in 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购买更新。
I also put a breakpoint in RMStore's paymentQueue:updatedTransactions: to see if the queue is updated with subsequent AR purchases.
然后我购买了一个月的测试产品，验证了交易，然后退出应用程序。
I then purchased one month of my test product, verified the transaction and then quit the application.
在后续每隔5分钟重新调用一次应用程序时，我看到了 SKPaymentTransactionObserver SKPaymentTransactionStatePurchased 命中$ c>方法。日志显示连续添加的购买（仅显示最后一个版本）：
On subsequent re-invocations of the application at 5 minute intervals, I then saw the breakpoint in the SKPaymentTransactionObserver method being hit with transactionSate SKPaymentTransactionStatePurchased. The log showed successive additions of the purchases (only last version shown):
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)
你可以使用这种诊断方法重新制作吗？
Can you repro using this diagnostic approach?
这篇关于自动续订订阅和应用收据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
