iOS Sandbox测试用户帐户订阅管理

Question

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

我可以成功查询商店的产品，并成功购买我的新测试用户。我遇到的问题是，如果我尝试从商店设置应用程序管理我的订阅，它会强制我通过告诉我“此帐户尚未用于在AppStore中购买任何内容来审核我的帐户，请检查您的帐户并继续“。如果我查看该帐户，则不会在未提供CreditCard信息的情况下继续使用。

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

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

我已经完成了如何继续的想法。

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

初步认购

使用现有ID

测试帐户登录

管理订阅

AppStore登录

无法连接到AppStore

审核您的帐户

然后，审查过程迫使我输入CreditCard Info，即使它的地址为“1 Infinite Loop Cupertino，CA”（即它知道这是一个测试帐户）。

Answer 1

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

  

1个月订阅每5分钟自动续订一次。到现在为止还挺好。他们   自动续订5次然后停止，所以25分钟后你就会得到   21006错误。但即使重新购买相同的订阅   它不会在同一测试帐户上再次自动续订，因为它有   已经自动续订了5次。所以，如果你想测试更新和你   你需要一段时间一直搞乱这些订阅   创建一个新的itunes connect测试用户。老实说，这非常烦人   如果我们可以重置整个过程会更容易   购买测试用户帐户的历史记录。

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

Answer 2

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

  

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

     

这是一个   然而，自从我在这个论坛上做出回应以来，最好的办法就是   验证应用程序将处理自动续订过程   是验证该应用程序还处理自动续订的检测   正确地通过transactionObserver续订订阅。对于   例如，如果您在沙箱中购买了1个月的订阅   环境。然后杀死应用程序，等待6分钟，然后重新启动应用程序，   transactionObserver是否检测到存在   incompleteTransaction（压缩的一个月续订）   处理。

     

这与发生的情况非常相似   用户在iTunes订阅管理中重新启动订阅   页。该交易由iTunes商店记录和   已启用用户帐户/应用程序包ID的incompleteTransaction。   当应用程序启动并激活transactionObserver时（通过   调用addTransactionObserver）检测到incompleteTransaction   和被调用的updatedTransaction delefgate方法来处理   续约。然后，应用程序可以验证applicationReceipt以进行验证   现在有一个in_app数组项用于自动续订   expire_date大于当前的订阅项   date并知道自动续订订阅product_id是   活性。

     

至于测试自动续订订阅的情况   取消后，这又需要iTunes Store服务器支持来模拟。   但是，收据验证过程每天都有效，可以检测哪个   in_app数组项是自动续订的最新项   订阅，然后检测是否设置了cancel_date告诉应用程序   订阅已取消。作为一个说明，只是检测到了   任何元素的cancel_date字段都可能导致误报。该   用户可能先前已取消自动续订订阅   决定它不再那么糟糕，并重新购买该项目。为了这   原因，逻辑需要确保cancel_date字段   设置在最新的in_app数组元素中以了解当前   订阅实际上已被取消。我正在尝试的一个问题   确定 - 如果取消的项目将expire_date移动到   cancel_date使取消的订阅可以显示相同   作为过期订阅。似乎是正确的举动 - 但这一点   信息由iTunes Store服务器团队控制。

     

如果你   我想追求一个mechansim来模拟这些特征   沙盒中的生产商店环境，我建议你提交   使用Apple Developer Bug Report网页的增强请求。   请选择iTunesConnect产品作为错误报告   建议是iTunes Store模拟的东西，而不是iOS。