Sandbox vs Production Purchases: Why Your Paywall Works for You but Not Review

Sandbox and production purchases use the same product model but different accounts, transaction history, timing, and store state. A local sandbox success does not prove that the submitted build uses production-ready configuration.

Test the exact distribution build, identify the environment for each transaction, and compare product identifiers, storefront, account state, and entitlement handling before blaming App Review.

The workflow below was checked against Overview of testing in sandbox and Testing In-App Purchases with sandbox on 4 August 2026. The first source controls the rule or workflow; the second supports the article-specific implementation boundary.

The short version

• Remove local StoreKit configuration from the release test path.
• Install the exact build distributed through TestFlight.
• Use a documented sandbox tester and record its storefront.
• Verify the products returned by the store before purchasing.
• Test purchase, cancel, restore, renewal-related state, and errors.

The iOS subscription and in-app purchase review guide connects configuration, submission, and entitlement. This page isolates the environment question so a local StoreKit success, a sandbox transaction, and a production purchase are never treated as interchangeable evidence.

Draw the four test surfaces

Keep local StoreKit testing, sandbox accounts, TestFlight distribution, and live production conceptually separate. Local StoreKit files are useful for UI development but can hide missing App Store Connect records. TestFlight exercises a distributed build and Apple’s sandbox purchase environment. Production begins only after release.

Keep a small evidence note with:

• app version and build number;
• product identifiers tested;
• account type and storefront;
• time of the test and observed result;
• whether the entitlement changed after relaunch.

Prove what the submitted build contains

Record the bundle identifier, version, build number, product identifiers, and non-secret configuration values straight from the archive, not from the source you meant to ship. Compare each value against App Store Connect and your purchase-service dashboard. A release-only missing key or endpoint is the single most common reason a debug build works on your device while the same feature fails for a reviewer.

Check these four values specifically before you assume the code itself is wrong: the release scheme’s API endpoint, the release-only secret or public key, the product identifiers StoreKit actually returns for that build, and whether the entitlement service’s environment flag matches the transaction’s real environment.

Control account and storefront state

Sandbox testers have their own transaction history and storefront. Use a fresh tester when you need to see the initial paywall, and an entitled tester when you need to verify restore. Do not assume reinstalling the app clears purchase history.

Keep environments separate on the server

Receipt validation or an entitlement service has to recognize a sandbox transaction correctly without granting the entitlement to the wrong production account. If you use RevenueCat, its sandbox testing documentation controls how the dashboard classifies and displays sandbox versus production transactions; treat that classification as RevenueCat’s, not Apple’s. Apple’s App Store Connect record for the product, its subscription group, and the review requirements around it stay governed by Apple regardless of which entitlement service sits behind the paywall. If the RevenueCat dashboard shows the transaction but the paywall still fails for the reviewer, check the App Store Connect item status before assuming the entitlement service is at fault: see subscription stuck in Waiting for Review.

Turn failures into evidence

When a product request fails, capture the error, timestamp, build, account type, and storefront. Retry once under controlled conditions. If TestFlight repeatedly succeeds while one review attempt fails, send the evidence and ask for another test without claiming that Apple’s systems were definitely responsible.

Run the first checks in order

These are environment checks, not App Store Connect item checks. Run them before assuming a product or subscription group is misconfigured:

1. Remove local StoreKit configuration from the release test path.
2. Install the exact build distributed through TestFlight.
3. Use a documented sandbox tester and record its storefront.
4. Verify the products returned by the store before purchasing.
5. Test purchase, cancel, restore, renewal-related state, and errors.
6. Confirm server or RevenueCat environment handling does not mix sandbox and production data.

Choose the next action

Match what you actually observe, not what feels likely, to the smallest correct action:

Do not upload a new build before this table tells you the release configuration is actually the problem. A sandbox account that already owns the entitlement produces the same symptom as a real bug and needs a different fix.

Failure patterns to look for

• The developer tested a debug scheme with local products.
• The TestFlight build lacks a release environment variable.
• A sandbox account already owns the entitlement.
• The backend rejects sandbox receipts or assigns them to the wrong user.
• The paywall has no useful state when the store returns zero products.

Those environment mismatches are a reproducibility checklist, not a claim about what Apple sees most often. Confirm the actual account, storefront, build, and transaction environment against Apple’s current testing documentation before deciding where to make a change.

Write App Review Notes as a test script

Tell the reviewer which build and which environment you actually tested, since that detail is what this failure mode hinges on. Name the app version, build number, product identifiers, the sandbox or TestFlight account you used and its storefront, the taps from launch to the paywall, and the result you expect after purchase or restore.

Keep the note factual. State what you tested and where the control appears. Do not promise that production will behave identically to your TestFlight test, and do not describe an entitlement state you have not re-verified since your last build.

A useful structure is:

1. App version, build number, and product identifiers.
2. Entry path from launch to the paywall.
3. Sandbox or TestFlight account and its storefront.
4. Purchase or restore action to test.
5. Visible result expected after the transaction.

What not to change blindly

Do not rotate a purchase-service API key or resubmit a new build because a single review attempt failed once. If the same build already succeeds repeatedly in TestFlight, the more likely cause is a release-only configuration gap or an account or storefront state you have not reproduced, not a defect that a fresh build fixes by chance.

Also avoid changing RevenueCat and App Store Connect settings at the same time as the app’s release configuration. Keep environments separate on the server, and if you cannot tell whether the block sits in the entitlement service or in Apple’s review queue, check the App Store Connect item statuses before touching either dashboard again.

Verification note: the sandbox and production testing behaviour above was checked against Apple’s current documentation on 4 August 2026, and the RevenueCat-specific claim is attributed to RevenueCat’s own sandbox testing documentation. Recheck both sources before you rely on this article for a later resubmission.

FAQ about sandbox vs production StoreKit App Review

Why does the paywall show products in TestFlight but not for the reviewer?

Usually a release-only configuration gap: an API key, endpoint, or product identifier that only exists in your debug scheme. Compare the archive’s actual values against App Store Connect and your purchase-service dashboard rather than assuming the reviewer’s account is broken.

Do sandbox purchases ever affect production revenue or entitlements?

No, when the environments are kept separate on the server. A receipt validation or entitlement service must recognize a transaction’s environment correctly; RevenueCat’s sandbox documentation controls how its own dashboard classifies that transaction, and a misconfigured server is the usual way sandbox and production data mix.

Is a RevenueCat sandbox failure the same as an Apple rejection?

No. RevenueCat’s dashboard reflects what its own service received and classified. App Store Connect’s item statuses and App Review’s decision are Apple’s, and the two can disagree: a clean RevenueCat log does not mean the App Store Connect item is complete, and a stuck App Store Connect item does not mean RevenueCat has a bug.

Can I reuse a sandbox tester across multiple test rounds?

Yes, but its transaction history carries over between rounds. Use a fresh tester when you need to see the initial paywall state, and keep an already-entitled tester only for restore testing, since reinstalling the app does not clear a tester’s purchase history.

Conclusion

Test the exact distribution build, identify the environment for each transaction, and compare product identifiers, storefront, account state, and entitlement handling before blaming App Review.

Match what you actually observe to the table above before you rotate a key or upload a new build. Keep the evidence with your reply so the next review starts from a confirmed environment, not another guess.

Sources and references

• Overview of testing in sandbox: accessed 4 August 2026.
• Testing In-App Purchases with sandbox: accessed 4 August 2026.
• App Review Guidelines: accessed 4 August 2026.
• RevenueCat: Sandbox Testing: accessed 4 August 2026.