iOS Sandbox Test User account Subscription Management

Question

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

Solution 1

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.

Solution 2

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.

Comments

[jbcaveman]

This similar post found an answer: stackoverflow.com/q/4566329

[lifewithelliott]

Fastest way ive come up with - Test purchse, then delete the email within Users and Roles, then recreate iterating with a new suffix, Ex: [email protected] ... [email protected]... only solution as alternate to waiting 5 minutes up to an hour.

[Jonny Cook]

To expedite the process of creating new accounts: In Chrome, open the developer console and fill out the form. After the page loads and the account is created, navigate to the Networks tab of the developer console, find the first request (should be to itunesconnect.apple.com/WebObjects/iTunesConnect.woa/ra/user‌​s/…), right click on it and select "Copy as cURL". Then, each time you want to add a new account, just modify the email address in the cURL command and run it the terminal. Voila, your new account has been created! No need to fill out the form each time.

[Magnus]

It's 2019 and Apple have tightened security... now you need to use Postman to make a HTTP POST to appstoreconnect.apple.com/iris/v1/sandboxTesters. The necessary request headers can be found in the Chrome developer tools as described by @JonnyCook. Make sure you include the cookie header, otherwise you'll get a 401 NOT AUTHORIZED response. And the actual data for your user is sent as JSON in the request body, just change the email for each user.

[Tushar]

This is Sep, 2019 with iOS 13 going to release soon... and we are still having the same issue. Common Apple !