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.
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.
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.
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.
EDIT - Here is the flow of events with any iTunesConnect Test User I create
Initial Subscription
Use Existing ID
Test Account Sign-In
Manage Subscription
AppStore Sign-in
Cannot Connect To 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).
There is response by Apple developer.(Rich Kubota) About Subscription testing in sandbox environment.
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.
You can't really manage subscriptions in sandbox, but as Jean-Paul de Ville de Goyet found out on 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.
I tested my subscriptions the same way.
来源：https://stackoverflow.com/questions/10289011/ios-sandbox-test-user-account-subscription-management