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

Question

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

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

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

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

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

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

初始订阅

使用现有 ID

测试账号登录

管理订阅

AppStore 登录

无法连接到 AppStore

查看您的帐户

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

Answer 1

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

1 个月的订阅每 5 分钟自动续订一次。到目前为止，一切都很好。他们 自动更新 5 次然后它们停止，所以 25 分钟后你会得到 21006 错误。但是，即使重新购买相同的订阅 它不会在同一个测试帐户上再次自动更新，因为它已经 已经自动更新了 5 次。所以如果你想测试更新并且你 一段时间以来你一直在搞乱这些订阅，你需要 创建一个新的 iTunes 连接测试用户。老实说，这很烦人 如果我们可以重置整个 测试用户帐户的购买历史记录。

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

Answer 2

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

这是应用内购买模拟过程中的一个漏洞。有 没有支持的方式来模拟取消过程或模拟 从用户的 iTunes 应用程序管理订阅过程。这 该应用程序的 TestFlight 版本也存在限制。当你 将应用程序的 TestFlight 构建提交给用户，然后他们测试 app，用户账号实际上是在沙箱中操作 环境。您已经验证了这一点，因为 TestFlight 应用程序不会 在 iTunes 管理的 TestFlight 用户中显示为托管应用 订阅部分。那是因为应用程序在沙箱中 iTunes 应用程序对此一无所知的环境。

这是一个 虽然自从我在这个论坛上做出了回应，但是，最好的方法是 验证应用程序将处理自动续订过程 是验证应用程序是否也处理自动续订的检测 通过 transactionObserver 正确订阅续订。为了 例如，如果您在沙盒中购买了 1 个月的订阅 环境。然后杀死应用程序，等待 6 分钟，然后重新启动应用程序， transactionObserver 是否检测到存在 CompleteTransaction（压缩的一个月续订）为 处理。

这与发生的情况非常相似 用户在 iTunes 订阅管理中重新启动订阅 页。该交易由 iTunes 商店记录，并且 已启用用户帐户/应用程序包 ID 的不完整事务。 当应用程序启动并激活 transactionObserver 时（通过 调用 addTransactionObserver) 检测到不完整的事务 并调用 updatedTransaction 的 delfgate 方法来处理 更新。然后应用程序可以验证 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 服务器团队控制。

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