ios iOS沙盒测试用户账号订阅管理

iOS Sandbox Test User account Subscription Management

提问by pseabury

I'm currently trying to add IAP to an existing App. To that end, I've added some products and created some test users. The products are recurring subscriptions. The device I'm testing with is an iPhone 4S with iOS 5.1.

我目前正在尝试将 IAP 添加到现有应用程序。为此，我添加了一些产品并创建了一些测试用户。这些产品是定期订阅。我正在测试的设备是装有 iOS 5.1 的 iPhone 4S。

I can successfully query the store for my products, and successfully purchase them with my new Test users. The problem I have is that if I try to manage my subscriptions from the Store Settings App, it forces me to Review my account by telling me that "This account has not been used to purchase anything in the AppStore, please review your account and continue." If I review the account, it won't let me continue without supplying CreditCard info.

我可以成功查询商店我的产品，并与我的新测试用户成功购买。我遇到的问题是，如果我尝试从商店设置应用程序管理我的订阅，它会告诉我“此帐户尚未用于在 AppStore 中购买任何东西，请检查您的帐户并继续.” 如果我查看帐户，它不会让我在不提供信用卡信息的情况下继续。

The end result is that I can never cancel my test subscriptions. I've deleted Test Users and created new ones, deleted the app and reinstalled it, killed the StoreApp and Settings App, rebooted the device, verified the accounts via email before purchasing, not verified the accounts via email before purchasing...all permutations seem to fail.

最终结果是我永远无法取消我的测试订阅。我删除了测试用户并创建了新用户，删除了应用程序并重新安装了它，杀死了 StoreApp 和设置应用程序，重新启动了设备，购买前通过电子邮件验证了帐户，购买前未通过电子邮件验证了帐户......所有排列似乎失败了。

Sometimes I will purchase the same subscription twice which will prompt StoreKit to ask me to manage my subscription settings. Sometimes this results in the previous "Account Review" process, and sometimes it results in an Alert that says "cannot connect to iTunes Store".

有时我会购买相同的订阅两次，这会提示 StoreKit 要求我管理订阅设置。有时这会导致之前的“帐户审核”过程，有时会导致提示“无法连接到 iTunes Store”。

I've run out of ideas for how to continue.

我已经没有了如何继续的想法。

EDIT - Here is the flow of events with any iTunesConnect Test User I create

编辑 - 这是我创建的任何 iTunesConnect 测试用户的事件流

Initial Subscription

初始订阅

Use Existing ID

使用现有 ID

Test Account Sign-In

测试帐户登录

Manage Subscription

管理订阅

AppStore Sign-in

应用商店登录

Cannot Connect To AppStore

无法连接到 AppStore

Review Your Account

查看您的帐户

Then, the review process forces me to enter CreditCard Info, even though it has my address as "1 Infinite Loop Cupertino, CA" (i.e. it knows this is a test account).

然后，过程迫使我输入信用卡信息，即使它的地址是“1 Infinite Loop Cupertino, CA”（即它知道这是一个测试帐户）。

采纳答案by Surjeet Rajput

There is response by Apple developer.(Rich Kubota) About Subscription testing in sandbox environment.

有苹果开发者的回应。（Rich Kubota）关于沙盒环境下的订阅测试。

This is a bug hole in the in-app purchase simulation process. There is no supported way to simulate the cancellation process or to simulate the manage subscription process from a users iTunes app. This limitation also exists with TestFlight version of the app. When you submit the TestFlight build of the app to a user and they test the app, the user account is actually operating in the sandbox environment. You've verified this because the TestFlight app won't appear as a managed app in the TestFlight users iTunes managed subscription section. That's because the app is in the sandbox environment, which the iTunes app knows nothing about.

It's been a while since I've responded on this forum, however, the best means to verifying that the application will handle the auto-renewing process is to verify that the app also handles the detection of auto-renewing subscription renewals via the transactionObserver properly. For example if you purchase a 1 mo subscription in the sandbox environment. Then kill the app, wait 6 minutes, then relaunch the app, does the transactionObserver detect that there is an incompleteTransaction (the compressed one month renewal) to be processed.

This is very similar to what happens in the case that the user restarts a subscription in the iTunes subscription management page. The transaction is recorded by the iTunes store and an incompleteTransaction for the user account / app bundle ID is enabled. When the app starts up and activates the transactionObserver (via a call to addTransactionObserver) the incompleteTransaction is detected and the updatedTransaction delefgate method called to process the renewal. The app can then validate the applicationReceipt to verify that there is now an in_app array item for the auto-renewing subscription item that has an expire_date greater than the current date and knows that the auto-renewing subscription product_id is active.

As for testing that an auto-renewing subscription has been canceled, this again needs iTunes Store server support to simulate. However, receipt validation process works daily and can detect which in_app array item is the most current for the auto-renewing subscription, then detecting if the cancel_date is set tells the app that the subscription was canceled. As a note, just detecting that the cancel_date field for any element can result in a false positive. The user might have canceled an auto-renewing subscription earlier, then decided it wasn't so bad any more and re-purchased the item. For this reason, the logic needs to making sure that the cancel_date field is set in the most current in_app array element to know that the current subscription has actually been canceled. One issue which I'm trying to determine - if a canceled item will have the expire_date moved up to the cancel_date so that an canceled subscription can appear the same as an expired subscription. Seems like the right move - but this information is controlled by the iTunes Store server team.

If you want to pursue a mechansim for simulating these features of the production store environment in the sandbox, I suggest that you submit an enhancement request using the Apple Developer Bug Report web page. Please select the iTunesConnect Product for the bug report, as the suggestion is something for the iTunes Store to simulate, not iOS.

这是应用内购买模拟过程中的一个漏洞。没有支持的方法来模拟取消过程或模拟来自用户 iTunes 应用程序的管理订阅过程。此限制也存在于应用程序的 TestFlight 版本中。当您将应用程序的 TestFlight 版本提交给用户并且他们测试应用程序时，用户帐户实际上是在沙盒环境中运行的。您已经验证了这一点，因为 TestFlight 应用程序不会在 TestFlight 用户的 iTunes 托管订阅部分中显示为托管应用程序。那是因为该应用程序处于沙盒环境中，iTunes 应用程序对此一无所知。

自从我在这个论坛上回复已经有一段时间了，但是，验证应用程序将处理自动续订过程的最佳方法是验证该应用程序是否还通过 transactionObserver 正确处理自动续订订阅续订的检测. 例如，如果您在沙盒环境中购买了 1 个月的订阅。然后kill掉app，等待6分钟，然后重新启动app，transactionObserver有没有检测到有不完整的Transaction（压缩的一个月续费）需要处理。

这与用户在 iTunes 订阅管理页面重新开始订阅的情况非常相似。交易由 iTunes 商店记录，并且启用了用户帐户/应用程序包 ID 的不完整交易。当应用程序启动并激活 transactionObserver（通过调用 addTransactionObserver）时，会检测到不完整交易并调用 updatedTransaction derefgate 方法来处理续订。然后，应用程序可以验证 applicationReceipt 以验证现在有一个用于自动续订订阅项的 in_app 数组项，该数组项的 expire_date 大于当前日期，并且知道自动续订订阅 product_id 处于活动状态。

至于测试自动续订订阅是否被取消，这又需要iTunes Store服务器支持来模拟。但是，收据验证过程每天都在运行，并且可以检测哪个 in_app 数组项对于自动续订订阅是最新的，然后检测是否设置了 cancel_date 会告诉应用程序订阅已取消。请注意，仅检测到任何元素的 cancel_date 字段都可能导致误报。用户可能之前取消了自动续订订阅，然后认为情况不再那么糟糕并重新购买了该项目。为此，逻辑需要确保在最新的 in_app 数组元素中设置了 cancel_date 字段，以了解当前订阅实际上已被取消。一个问题，我 我试图确定 - 取消的项目是否会将 expire_date 向上移动到 cancel_date，以便取消的订阅可以与过期的订阅相同。似乎是正确的举动 - 但此信息由 iTunes Store 服务器团队控制。

如果您想寻求一种机制来模拟沙箱中生产商店环境的这些功能，我建议您使用 Apple Developer Bug Report 网页提交增强请求。请为错误报告选择 iTunesConnect 产品，因为建议是 iTunes Store 模拟的东西，而不是 iOS。

回答by suda

You can't really manage subscriptions in sandbox, but as Jean-Paul de Ville de Goyet found out on Apple Developer Forums:

您无法在沙盒中真正管理订阅，但正如 Jean-Paul de Ville de Goyet 在Apple Developer Forums上发现的那样：

1 month subscriptions auto-renew every 5 minutes. So far so good. They auto-renew 5 times and then they stop, so after 25 minutes you'll get the 21006 error. However even when repurchasing the same subscription it will NOT auto-renew again on the same test account since it has already auto-renewed 5 times. So if you want to test renewal and you have been messing with these subscriptions for a while you need to create a new itunes connect test user. This is very annoying honestly and it would be a lot easier if we could just reset the entire purchase history of a test user account.

1 个月订阅每 5 分钟自动续订一次。到现在为止还挺好。它们会自动更新 5 次然后停止，因此 25 分钟后您将收到 21006 错误。但是，即使重新购买相同的订阅，它也不会在同一个测试帐户上再次自动续订，因为它已经自动续订了 5 次。因此，如果您想测试续订并且您已经在处理这些订阅了一段时间，您需要创建一个新的 iTunes Connect 测试用户。老实说，这很烦人，如果我们可以重置测试用户帐户的整个购买历史记录会容易得多。

I tested my subscriptions the same way.

我以同样的方式测试了我的订阅。