If your app is in review and it sells something, it is fair to wonder whether Apple will actually try to buy it. The answer is yes: a reviewer attempts your purchase, and your restore, in a sandbox before approving the app. That is reassuring and a little nerve-wracking, because a purchase that works for you can still fail for them. Here is what App Review does with your in-app purchases and what makes the test pass.
Short answer
Yes. App Review tests your in-app purchases by attempting a purchase, and a restore, in the sandbox environment before approving the app. The first time you sell an in-app purchase, it must be submitted together with an app version and be in the Ready to Submit state, the Paid Applications Agreement must be active, and a restore mechanism is required for non-consumables and subscriptions under Guideline 3.1.1. Purchases that work for you can still fail for the reviewer if your products do not load or your server cannot validate a sandbox receipt from a production app.
What you should know
- Reviewers really test it: a reviewer attempts the purchase and the restore in the sandbox, with no real charge.
- The first IAP ships with the app: a new in-app purchase is reviewed alongside the binary, so attach it to the version.
- Products must be Ready to Submit: products not in that state are not returned to the reviewer.
- Restore is required: non-consumables and subscriptions need a working restore under Guideline 3.1.1.
- Sandbox receipts reach a production app: your server must handle a sandbox receipt during review.
How does App Review test an in-app purchase?
By behaving like a buyer in the sandbox. The reviewer opens your purchase flow, taps to buy with a sandbox account, and expects the product to be delivered, then tests restore where it applies. There is no real money involved, but the path is the real one: load the products, complete the transaction, grant access to what was bought, and recover it on restore. If any step fails, the app is usually rejected under Guideline 2.1 for being incomplete, with a note that the purchase did not work. So the reviewer is testing the same flow your users will hit on launch day. They also do this on a real device under real conditions, so a purchase that depends on a flaky network call, a slow product fetch, or a race in your code can fail for them even when it passes in your calmer test runs.
What has to be set up for the test to pass?
A short checklist covers most rejections. Each item is something the reviewer's sandbox attempt depends on. The table lists them.
| Requirement | Why it matters for review |
|---|---|
| First IAP submitted with the app version | A new in-app purchase is reviewed with the binary; an unattached IAP is not reviewed |
| Products in Ready to Submit | Products in other states are not returned to the reviewer |
| Paid Applications Agreement active | Without it, in-app purchases are unavailable and will not load |
| Restore mechanism present | Guideline 3.1.1 requires restore for non-consumables and subscriptions |
| Products load in the sandbox | If they fail to load, the reviewer sees buttons that do nothing |
| Server handles sandbox receipts | A production-signed app receives sandbox receipts during review |
Why do purchases that work for me fail for the reviewer?
Because the failure is usually outside your app code. If you can load and buy products in your own sandbox, the integration is fine, and the common causes shift to App Store Connect: the first in-app purchase was not attached to the version, products are not in Ready to Submit, or the Paid Applications Agreement is not active, so App Store Connect does not return the products to the reviewer at all. The result is buttons that do nothing on their device even though everything works on yours. Check those account-level items before assuming the bug is in your StoreKit code. A fast way to localize it is to ask whether the products even appear: an empty purchase screen or non-responsive buttons points at App Store Connect not returning products, while a failure after tapping buy points at the transaction or your receipt server.
What does the sandbox receipt rule mean for my server?
It means your production app will hand your server a test receipt during review. Apple runs the reviewer's purchase in the sandbox, so a production-signed build receives a sandbox receipt, and a server that only validates against production rejects it. Apple's receipt validation guidance is to validate against the production App Store first and, if you get the status that a sandbox receipt was used in production, validate against the test environment instead. Without that fallback, every reviewer purchase fails verification on your server even though the StoreKit side worked, which is a frequent and confusing rejection.
What to watch out for
The first trap is a missing restore. Guideline 3.1.1 requires a restore option for non-consumables and auto-renewable subscriptions, and a reviewer will look for it, so a purchase flow without one is rejected even if buying works. The second is forgetting that only the first in-app purchase has to ride with an app version; later ones can be submitted on their own. In-app purchase review is a functional test rather than a security review, so it is separate from what a pre-submission scan checks, though if you also wired a third-party payment processor a hardcoded key can leak in the binary, which a scan such as PTKD.com (https://ptkd.com) reads the compiled IPA for against OWASP MASVS. Keep the two checks distinct: one confirms the purchase works, the other confirms the build is clean.
What to take away
- Yes, App Review tests your in-app purchases by buying and restoring them in the sandbox before approval.
- Submit the first in-app purchase with the app version, keep products in Ready to Submit, and activate the Paid Applications Agreement.
- Provide a restore mechanism for non-consumables and subscriptions, since Guideline 3.1.1 requires it and reviewers check for it.
- Make your server validate production receipts first and fall back to the sandbox, so the reviewer's test purchase verifies correctly.
