iOS沙盒测试用户账号订阅管理 [英] iOS Sandbox Test User account Subscription Management

查看:42
本文介绍了iOS沙盒测试用户账号订阅管理的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

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.

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

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.

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

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.

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

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".

对于如何继续,我已经没有想法了.

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

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

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

初始订阅

使用现有 ID

Use Existing ID

测试帐户登录

管理订阅

AppStore 登录

AppStore Sign-in

无法连接到 AppStore

Cannot Connect To AppStore

检查您的帐户

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

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).

推荐答案

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

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

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

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.

这是一个然而,自从我在这个论坛上做出回应以来,最好的方法是验证应用程序将处理自动更新过程是为了验证该应用程序还处理自动续订的检测通过 transactionObserver 正确续订订阅.为了例如,如果您在沙盒中购买了 1 个月的订阅环境.然后杀死应用程序,等待 6 分钟,然后重新启动应用程序,transactionObserver 是否检测到有一个不完整交易(压缩的一个月续订)要处理.

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.

这与以下情况非常相似用户在 iTunes 订阅管理中重新启动订阅页.交易记录在 iTunes 商店和用户帐户/应用程序包 ID 的不完整事务已启用.当应用程序启动并激活 transactionObserver(通过调用 addTransactionObserver) 检测到不完整的交易和被调用来处理更新.然后应用程序可以验证 applicationReceipt 以验证现在有一个用于自动更新的 in_app 数组项expire_date 大于当前的订阅项目日期并知道自动续订的订阅 product_id 是积极的.

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.

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

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.

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

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.

这篇关于iOS沙盒测试用户账号订阅管理的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆