You can test in-app purchases without creating financial transactions by using Sandbox, a test environment that uses the infrastructure of the App Store but doesn’t process actual payments. Instead, it returns transactions as if payments were processed successfully.
Important: You can only test in-app purchases with apps distributed with Developer License and not with Enterprise License.
Testing in-app purchases without TestFlight
The total limit of devices you can test on is 500, but it is broken down by device type with up to 100 slots each for iPhone, iPad, iPod, Apple Watch, and Apple TV. You also have to specifically add every device UDID code to your signing profile which makes the process more complicated and limited than it is with TestFlight. Here's how to test in-app purchases without TestFlight:
Set up test user accounts within Users and Roles in iTunes Connect, as detailed in Creating Sandbox Tester Accounts in iTunes Connect Developer Guide.
Important: You’ll need a test user for each territory you want to test the app in.Clear any account information stored on your test device.
- In Settings, go to the Store settings.
- Click the Sign Out button.
This prevents an actual user account from automatically being used when testing.
Important: Don’t enter your test account information in the Store settings panel. Doing so may invalidate your test account.Open your app, and perform your in-app purchase product testing.
Use your test account credentials to test the purchase.
When your app uses the Store Kit API to request a payment, you’re asked to sign in. Select Use Existing Account and enter your test account user name and password. You are then asked to confirm the purchase. The transaction completes.
No financial transaction takes place, but a receipt is generated for a successful transaction.
Testing in-app purchases with TestFlight
TestFlight users don't require a sandbox account, but they will test against an automatically created sandbox account. This means it's no longer necessary to create test accounts in iTunes Connect. Your TestFlight user is a legitimate App Store user, but doing in-app purchases made with beta builds are free within the context of the beta version.
You can enable up to 25 users per app from your iTunes Connect team to be internal testers and up to 2000 users to be external testers per app.
Note: External testers do not need to be in your organization; you can invite any user with an email address to become one of your external testers.
Review process
The first time you submit your build for beta testing, there is a delay: usually of about one day. This appears to be a human process.
This is what it looks like during that one-day delay:
When you submit each new build and indicate during submission that there are no new significant changes from the previous build then it goes out to external testers in about 15 minutes.
When you up the version number (not the build number) you have to resubmit for Beta review which has a delay of 1 day again. The best workaround for this is to upload an initial build as early as possible, even before you’re ready to beta test and then when ready for beta testing, up the build number only.
If you want to skip the re-review process, don't update the version ("Bundle versions string, short" in the Info.plist file), update the build ("Bundle version" in the Info.plist file). So instead of doing 0.1 (1) -> 0.2 (1) do 0.1 (1) -> 0.1 (2)
After you have uploaded the new build to TestFlight, you will click the submit for review link under the External testers column. Once you do that, you will see the same screen as the last time you submitted for approval, but this time you should also see the Build Changes section (see below). If you don’t see this, you did something wrong, don’t continue or you will have to wait for Apple’s approval again. Go back through the steps. When you do see this, click on No. Then click submit. Your beta app will be approved right away.
Notes:
You can upload up to 6 external builds per day.
It is very common - about one in eight builds - that the build fails to go through. If you have waited say 30 minutes, and it has not gone through: increase the build number by one and push it through again.
Testing Auto-Renewable Subscriptions
When testing auto-renewable subscriptions in the test environment, keep in mind that the duration times are compressed. Additionally, test subscriptions only auto-renew a maximum of six times. Below is a list of the compressed duration times.
Actual duration > Test duration
1 week > 3 minutes
1 month > 5 minutes
2 months > 10 minutes
3 months > 15 minutes
6 months > 30 minutes
1 year > 1 hour