Summary
Sandbox purchases of our first auto-renewable subscription fail with "This item cannot be found". Product metadata loads correctly, so this looks specific to commerce. Our App Store Connect configuration is complete and has been verified exhaustively, and four other apps on the same team sell in-app purchases in production without issue. The affected app has never been submitted or released, and the subscription sits in "Ready to Submit".
Symptoms
On device (TestFlight build, purchasing with the tester's real Apple Account -
no sandbox Apple Account is configured, per the documented TestFlight flow), a
purchase attempt returns storeProductNotAvailable and the system alert "Item
Unavailable". Device logs (idevicesyslog) show:
mzstorekit-sb.itunes.apple.com/inApps/v2/history-> HTTP 404,(4040004) App not foundsandbox.itunes.apple.com/.../inAppBuy->AMSErrorDomain 305,AMSServerErrorCode=3504, "This item cannot be found"
Product.products(for:) returns the product and the paywall renders
product.displayPrice, so product metadata resolves. Only the purchase fails.
Server-side observation
Using the App Store Server API in the sandbox environment with our team key, requesting a deliberately non-existent transaction ID:
GET https://api.storekit-sandbox.itunes.apple.com/inApps/v1/history/1234567890
| The affected app | 1 subscription, Ready to Submit | never | HTTP 401, empty body |
| Another app, same team | non-consumable, Approved | yes | 404 4040010 Transaction id not found |
| Another app, same team | 2 non-consumables, Approved | yes | 404 4040010 Transaction id not found |
| Another app, same team | 2 non-consumables, Approved | yes | 404 4040010 Transaction id not found |
| Another app, same team | non-consumable, Approved | yes | 404 4040010 Transaction id not found |
Same key, same issuer, same team, same request shape - only the bid claim
differs. We note openly that this is not a clean experiment: all four
comparison apps differ from the affected app in two ways at once (they are
released, and they have approved products), so the 401 may simply reflect an
app with no approved commerce products rather than a missing app record. We
include it because the difference is stark and reproducible, not because we
think it is conclusive.
What makes this app different
Being unreleased does not by itself appear to be the barrier: we were able to test the in-app purchases of the four apps above in the sandbox before those apps were released. The difference we cannot account for is product type and approval state - those were one-time non-consumables, whereas this is our first auto-renewable subscription, which App Store Connect tells us "must be submitted with a new app version" and which has therefore never been approved.
Timeline
- 2026-07-30 ~00:30 CEST - Pricing and Availability set for the app (it had been unset; that was the cause of an earlier, separate failure).
- 2026-07-30 09:26 CEST - captured the device logs above.
- 2026-07-31 00:50 CEST - toggled a territory's availability off and back on to force a re-propagation of the availability record. No change.
- 2026-07-31 - still failing 24+ hours on. Automated probes every 30 minutes throughout have returned the same result without exception.
This is well beyond the "up to 1 hour" propagation window documented in TN3186.
Already verified
Account level - four other apps on this same team currently sell in-app purchases in production:
- Paid Apps agreement: Active
- Banking and tax information: complete and active
App Store Connect configuration for the affected app:
- App availability: 175 of 175 territories, none excluded
- Subscription availability: 175 of 175 territories
- Subscription priced in all 175 territories
- Four localizations and the review screenshot present; group localized; subscription state Ready to Submit
- App price: Free
- Every territory reads
CANNOT_SELL / AVAILABLE_FOR_SALE_UNRELEASED_APP, consistent with an app that has not yet been released
Client / build:
- Product ID in code matches App Store Connect exactly
- Explicit App ID (no wildcard), In-App Purchase capability enabled
- Build signed with Apple Distribution, delivered via Transporter, tested from TestFlight (not a development build)
- No StoreKit configuration file active in the scheme
- Bundle ID matches the App Store Connect record
Questions
- Is the subscription provisioned for commerce in the sandbox environment? The
(4040004) App not foundresponse suggests the app or its commerce record is not present there. - TN3186 states that sandbox testing does not require submitting in-app purchases for review. Does that hold for an app's first auto-renewable subscription, given that such a subscription must be submitted alongside an app version and so cannot reach an approved state beforehand?
- If submitting the app version together with the subscription is in fact the prerequisite, please confirm - we are currently holding our submission specifically so we can complete one successful sandbox purchase first, since App Review purchases through this same environment. If that ordering is not possible, we would rather submit and have App Review encounter the working production path than keep waiting on a sandbox purchase that cannot succeed.
Happy to provide the app's Apple ID and product identifier privately if that helps.