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 found
sandbox.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
App
Products
Released?
Result
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 found response 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.
