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

pse*_*ury 41 testing itunesconnect app-store storekit ios

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

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

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

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

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

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

初步认购
初步认购

使用现有ID
使用现有ID

测试帐户登录
测试帐户登录

管理订阅
管理订阅

AppStore登录
AppStore登录

无法连接到AppStore
无法连接

检查您的帐户
评论

然后,审查过程迫使我输入CreditCard Info,即使它的地址为"1 Infinite Loop Cupertino,CA"(即它知道这是一个测试帐户).

sud*_*uda 56

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

1个月订阅每5分钟自动续订一次.到现在为止还挺好.他们自动续订5次然后停止,所以25分钟后你会收到21006错误.但是,即使重新购买相同的订阅,它也不会在同一测试帐户上再次自动续订,因为它已经自动续订了5次.因此,如果您想测试续订并且您一直在搞乱这些订阅,您需要创建一个新的itunes connect测试用户.诚实地说这非常烦人,如果我们可以重置测试用户帐户的整个购买历史,那将会容易得多.

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

  • 要加快创建新帐户的过程:在Chrome中,打开开发人员控制台并填写表单.页面加载并创建帐户后,导航到开发人员控制台的"网络"选项卡,找到第一个请求(应该是https://itunesconnect.apple.com/WebObjects/iTunesConnect.woa/ra/users/iap/添加),右键单击它并选择"复制为cURL".然后,每次要添加新帐户时,只需修改cURL命令中的电子邮件地址并将其运行到终端即可.瞧,您的新帐户已创建!无需每次填写表格. (15认同)

Sur*_*put 12

苹果开发者有回应.(Rich Kubota)关于沙盒环境中的订阅测试.

这是应用内购买模拟过程中的一个漏洞.没有受支持的方法来模拟取消过程或模拟用户iTunes应用程序的管理订阅过程.应用程序的TestFlight版本也存在此限制.当您向用户提交应用程序的TestFlight版本并测试应用程序时,该用户帐户实际上是在沙箱环境中运行.您已经验证了这一点,因为TestFlight应用程序不会在TestFlight用户iTunes托管订阅部分中显示为托管应用程序.那是因为应用程序位于沙盒环境中,iTunes应用程序对此一无所知.自从我在这个论坛上做出回应已经有一段时间了,但是,确认应用程序将处理自动续订过程的最佳方法是验证应用程序是否还通过transactionObserver正确处理自动续订订阅续订的检测.例如,如果您在沙箱环境中购买了1个月的订阅.然后杀死应用程序,等待6分钟,然后重新启动应用程序,transactionObserver是否检测到有一个incompleteTransaction(压缩的一个月续订)要处理.这与用户在iTunes订阅管理页面中重新启动订阅的情况非常相似.该事务由iTunes商店记录,并且启用了针对用户帐户/应用程序包ID的incompleteTransaction.当应用程序启动并激活transactionObserver时(通过调用addTransactionObserver),将检测到incompleteTransaction,并调用updatedTransaction delefgate方法来处理续订.然后,应用程序可以验证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服务器团队控制.如果您想在沙盒中使用mechansim来模拟生产商店环境的这些功能,我建议您使用Apple Developer Bug Report网页提交增强请求.请选择iTunesConnect产品以获取错误报告,因为该建议适用于iTunes Store进行模拟,而不是iOS.

  • 这是2019年9月,iOS 13即将发布...而我们仍然遇到同样的问题。普通苹果! (5认同)