General: Forums topic: StoreKit Forums tag: In-App Purchase App Store Pathway Simple and safe In-App Purchases Auto-renewable subscriptions In-App Purchase documentation Getting started with In-App Purchase using StoreKit views documentation Supporting business model changes by using the app transaction documentation Testing at all stages of development with Xcode and the sandbox documentation App Store Server Notifications documentation App Store Server API documentation Simplifying your implementation by using the App Store Server Library documentation TN3185: Troubleshooting In-App Purchases availability in Xcode technote TN3186: Troubleshooting In-App Purchases availability in the sandbox technote TN3188: Troubleshooting In-App Purchases availability in the App Store technote Understanding StoreKit workflows sample code Implementing a store in your app using the StoreKit API sample code What’s new in StoreKit and In-App Purchase video

Summary: In Sandbox, Product.products(for:) returns all 3 of my IAPs with correct JPY prices and Japanese localizations, but product.purchase() fails immediately — the payment sheet is never presented — with ASDServerErrorDomain Code=3504 (Product.PurchaseError.productUnavailable). All 3 products fail identically. Reproduction captured in the sysdiagnose attached to FB24067333: 2026-07-30 18:43:58 JST — in-app purchase() on app.negaiboshi.placement; 18:44:40 JST — OS-level test (Settings > Developer > Sandbox Apple Account > Manage > Start Transaction), same product ID. Server correlation keys from the device log: inAppBuy → AMSServerCorrelationKey HNB5UGLE72AXSMY5KY7G4NAXQY (failureType 3504); Start Transaction → FQN4Y4JOEHYBW2GIR7KPTYTB2A (AMSServerErrorCode 3766, "provided product ID or bundle ID is invalid"). Environment App: Negaiboshi — Apple ID 6794682125, Bundle ID app.negaiboshi, Team 778QPP83C4 App status: first submission in preparation (never reviewed); build 1.0 (1) on TestFlight IAPs (all "Ready to Submit" since 2026-07-27 JST, attached to the 1.0 submission): app.negaiboshi.pro.monthly (auto-renewable, ¥480, group 22264517), app.negaiboshi.placement (non-consumable, ¥720), app.negaiboshi.nightsky (non-consumable, ¥1,200) IAP base country: Japan (JPY); availability 145/175 countries Device: iPhone, iOS 26.5.2; development build from Xcode; StoreKit Configuration = None Sandbox Apple Account: (address in FB24067333), region Japan, no purchase history; signed in under Settings > Developer Storefront.current = JPN. No Screen Time restrictions. Actual error (verbatim): Error Domain=ASDServerErrorDomain Code=3504 "このアイテムは見つかりませんでした。" UserInfo={AMSServerErrorCode=3504, client-environment-type=Sandbox, storefront-country-code=JPN} TN3186 checklist fully verified, none apply (Paid Apps Agreement, banking, tax all active; bundle ID + IAP capability; signing; membership). Also tried: Sandbox sign-out/sign-in, device restart — no change. Consistent across all 3 products and relaunches. Reproduced with zero app code involved (decisive): Settings > Developer > Start Transaction with product ID app.negaiboshi.placement and bundle ID app.negaiboshi fails: "The provided product ID or bundle ID is invalid. [Environment: Sandbox]" — Apple's own OS-level tool, no third-party code. Calibration: a deliberately nonexistent ID (app.negaiboshi.zzz) yields the identical error — the backend treats my real product like a nonexistent one. A price change (¥720→¥700, "now", 2026-07-29) propagated to the sandbox metadata catalog within minutes (products(for:) returned "¥700") — purchase() still 3504. Reverted. A full base-country change (2026-07-30): Japan (¥720) → United States ($4.99) at 15:52 JST — this deletes and recreates the price schedule and is the exact operation that resolved the identical symptom in thread 839557. It propagated to the metadata catalog (auto-converted ¥800 shown in ~20 min), yet purchase() and Start Transaction still failed at 16:10 and 16:55 JST. Reverted to ¥720 at 16:59 JST. Every lever that rewrites the price schedule reaches the metadata catalog but never the commerce/purchase catalog. Timeline: the products reached Ready to Submit hours after the 2026-07-26 15:22–17:58 PDT In-App Purchases outage (Message ID 1000005803), and the failure still reproduces after the 2026-07-29 16:20–19:30 PDT emergency maintenance on In-App Purchases + Advanced Commerce API (messageId 1000005805). Peer reports with the same metadata-vs-commerce-catalog split in the same window: threads 839220, 839441, 839437, 839645, 839557. Questions: Why does purchase() fail server-side with 3504 ("item not found") while products(for:) succeeds for the same IDs in the same JPN storefront? Can someone check the sandbox commerce-catalog state of the 3 product IDs above (Apple ID 6794682125)? This looks like a server-side provisioning failure that no developer-side action can repair. Is any additional App Store Connect state required before sandbox purchases can complete for a never-yet-reviewed app?

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.

I have 2 iOS app products. One can fetch subscription product information normally, while the other fails with the error errorCode 4040004 'App not found' in Sandbox. The App Store Connect backend configuration should be fine, and the subscription code on the app side is the same codebase for both. I really can't find the root cause anymore — if anyone knows what's going on, please point me in the right direction. Also, I'm able to sync/download the StoreKit product configuration file from App Store Connect directly in Xcode, which should also confirm that my App Store Connect backend configuration is correct.

Hello Applet, I’m experiencing an issue with StoreKit on a TestFlight build. My app uses auto-renewable subscriptions through StoreKit and RevenueCat. Configuration already verified: App installed through TestFlight (not debug). Bundle Identifier: com.ciborgu.vytalai Paid Applications agreement is active. In-App Purchase capability is enabled. Three auto-renewable subscriptions exist in App Store Connect. Product IDs match exactly between App Store Connect, RevenueCat and the application. RevenueCat initializes successfully. A Sandbox test account has been created. Tested on a physical iPhone. Device restarted and app reinstalled from TestFlight. VPN and iCloud Private Relay disabled. When attempting to purchase a subscription, the Apple payment sheet never appears. Our diagnostics indicate that StoreKit does not return any available products for the configured Product IDs, preventing the purchase sheet from opening. Expected Product IDs: vytalai_premium_monthly vytalai_premium_yearly vytalai_premium_yearly_intro Could you please verify if there is any issue with the App Store Connect configuration, StoreKit availability, or the processing state of these subscriptions on Apple’s side? If additional logs or diagnostics are required, I can provide them. Thank you. I have already contacted Apple Developer Support regarding this same issue. Previously, I was advised to schedule a technical support meeting. However, when I requested the meeting, my request was declined because of the subject of my issue, so I was unable to speak with an Apple engineer. Since I have now completed all the recommended troubleshooting and the issue still persists, I would greatly appreciate it if this case could be reviewed by the appropriate technical team or a StoreKit engineer. Thank you for your assistance.

Need to vent a bit before relaxing for Christmas... WatchOS IAP using Storekit 2 is such a mess...is nobody actually using this or does Apple just not care for the user experience here? Lots of users experience after the purchase confirmation double tap on the side button an instant return to the purchase screen with nothing actually happening. No error message whatsoever. There is just one remedy: users need to unpair and re-pair their watch, including restoring a backup and setting up their wallet again. Nobody really wants to do this, or doesn't believe me and think this is just typical support BS, because their watch is paired and most things just work as they expect. And it turns away a customer, often leaving a bad review. And I can't do anything about it. Other errors in the purchase process are reported, but like "process interrupted" in case the payment is not setup correctly (credit car no longer valid or sth.). How should the user know? There must be better ways of letting him know what exactly the problem is. You need to implement a "Restore Purchase" function, otherwise you're not passing the review. But it really asks every time for the AppStore password, and users with crazy passwords -- that they rightfully should have! -- have almost no chance of typing them successfully on the tiny AW keyboard. Why is it not also just a side button double tap like for purchase? At the very least you would need access to the keychain PWs or allow pasting of sth. copied on the paired iPhone. Promo Codes for IAP on AW-only apps just don't work. AW has no redemption at all, and on the iPhone the AppStore will try to talk to a companion app (which AW-only doesn't have) and the end up in a dead-end installation effort. This all feels like never really tested in the field, and people are of course blaming the 3rd party dev. for all these issues. And opening a ticket is just leading nowhere -- at best it's closed after months with the hint "duplicate" but w/o any chance for me to see that one that they then actually work on and track progress. It's all so frustratingly broken...

Hello, I'm developing a consumer iOS app (Capacitor + RevenueCat SDK) and I've been blocked for several weeks on a StoreKit issue: subscription products are never returned to the device, so the Apple payment sheet cannot open. I previously contacted Apple Support. I was told to request a phone call, but my call request was declined because of the topic (StoreKit / in-app purchases). I'm posting here hoping someone from Apple or the community can help. App details App name: Vytal AI Bundle ID: com.ciborgu.vytalai App Store Connect App ID: 6767160542 Team ID: JZF7CR3W8Z Distribution: TestFlight (physical iPhone, France) iOS deployment target: 15+ Subscription product IDs (auto-renewable) vytalai_premium_monthly vytalai_premium_yearly vytalai_premium_yearly_intro All three are in subscription group "Vytal AI" on the correct ASC app (not a typo bundle). Cleared for Sale is ON. Paid Apps Agreement is active. In-App Purchase capability is enabled on the App ID (checkbox is grayed out / locked, which I understand is normal). Problem On a real device via TestFlight: RevenueCat SDK configures successfully (public iOS API key present in build). Purchases.getProducts({ productIdentifiers: [...] }) returns { products: [] } — zero products. Because StoreKit returns an empty array, the Sandbox payment sheet never appears when the user taps Subscribe. This is NOT a UI issue — the native SDK call to Apple returns no products. What I've already verified Bundle ID in signed IPA matches ASC app: com.ciborgu.vytalai Subscriptions exist only on the correct app (not on an old typo bundle com.ciborgue.vytalai) Removed duplicate ASC app; old App ID cannot be deleted ("in use by App Store") but has no IAPs Regenerated EAS provisioning profile for com.ciborgu.vytalai Sandbox tester account configured on device (Settings → App Store → Sandbox Account) Tested without VPN / iCloud Private Relay Reinstalled app from TestFlight after ASC changes Waited for propagation after metadata / availability updates Associated Domains enabled (for deep links) — separate from IAP SDK / integration @revenuecat/purchases-capacitor 13.x Direct StoreKit fetch via Purchases.getProducts() (not only RevenueCat offerings) Same result: 0 products from Apple Expected vs actual Expected: StoreKit returns 3 subscription products in Sandbox; payment sheet opens on purchase. Actual: products array is always empty; no payment sheet. Questions Why would StoreKit return 0 products for valid auto-renewable subscriptions on TestFlight when metadata is "Waiting for Review" / in review — shouldn't Sandbox still return products per TN3186? Is there an ASC configuration state (availability, subscription group localization, missing review screenshot on yearly products, etc.) that causes StoreKit to return zero products even in Sandbox? Is there an internal flag or propagation delay on Apple's side I should ask to be reset for this app/bundle? I'm happy to provide additional logs, a sysdiagnose, or a short screen recording from TestFlight showing the empty product response. Thank you for any guidance — this is blocking App Review (Guideline 2.1) and I cannot test IAP at all. Nathan

Hi, Feedback: FB23494579 Using StoreView / ProductView on iOS 27.0 simulator / device hub throws the following error: Error: Accessing State<ProductViewEventConfiguration>'s value without being installed on a View. This will create a new ProductViewEventConfiguration instance each time. Environment macOS 26.5.2 (25F84) Xcode 27.0 beta 2 (27A5209h) Simulator / Device Hub - iPhone 17 Pro (iOS 27.0) Screenshot

Hi, I’m testing an iOS app with auto-renewable subscriptions in the Apple sandbox environment. The app has its own account system. A user can create/log in with different accounts inside the app. The issue I’m seeing is this: I subscribe to the Pro plan using one sandbox Apple ID. Then I log out of the app. I create or log in with a different account inside the app, but still on the same iPhone / same sandbox Apple ID. Inside the app, this new app account is not marked as subscribed. When I try to subscribe again, StoreKit returns: “Item already owned” So Apple recognizes that the Apple ID already owns the subscription, but our app account does not have Pro access yet. The only way to resolve this is to provide a “Restore Purchase” option, so the current app account can restore the subscription already owned by the Apple ID. My questions are: Is this expected behavior for auto-renewable subscriptions? Can this happen in production too, or is it mainly a sandbox behavior? If a user has multiple accounts inside the app but uses the same Apple ID, is the subscription considered owned by the Apple ID and restorable across those app accounts? Is it acceptable/recommended to keep a small “Already subscribed? Restore purchase” option visible on the paywall at all times? If the app wants to prevent the same Apple subscription from being used across multiple internal app accounts, what is the recommended approach? For brand new Apple IDs that have never subscribed before, the normal purchase flow works correctly. Thank you.

Could you help clarify the expected behavior in downgrade scenarios during a Free Trial period? Does Apple trigger billing immediately for the downgraded plan, or does the change take effect only after the Free Trial window completes?

Type: Auto-renewable subscription Sandbox Storefront: USA StoreKit successfully loads the subscription product and returns its correct name and price (US$29.99). However, every purchase attempt fails: ASDServerErrorDomain Code=3504 AMSServerErrorCode=3504 "Item not found" client-environment-type=Sandbox storefront-country-code=USA This reproduces both in a TestFlight build and in iPhone Developer Settings > Test In-App Purchases. Please verify the app-product linkage and Sandbox commerce availability for this subscription product. Purchase did not return a transaction: Error Domain=ASDServerErrorDomain Code=3504 "找不到此项目。" UserInfo={storefront-country-code=USA, AMSServerErrorCode=3504, client-environment-type=Sandbox, NSLocalizedFailureReason=找不到此项目。} HKIPO-IAP 11:12:33.712 purchase error: type=StoreKit.Product.PurchaseError, domain=StoreKit.Product.PurchaseError, code=1, description=無法使用項目, failureReason=目前無法使用此項目。, underlying=nil, userInfo={}

Our app sells two auto-renewable subscriptions. Product loading succeeds and returns both products with correct localized prices, but every purchase attempt fails roughly one second later with "Item Unavailable". No purchase sheet is ever presented to the user. The app has not yet passed its first App Review. It was rejected under Guideline 2.1(b) because the reviewer encountered this same error on their device. MY QUESTION Under what conditions does StoreKit reject a purchase with "Item Unavailable" for a product that has just been returned successfully, with a valid localized price, by a product request? Is an auto-renewable subscription transactable in the sandbox environment for an app that has never had a binary approved by App Review? Question 2 is the one I most need answered. App Review's rejection states that In-App Purchase products "do not need prior approval to function in review", but neither we nor the reviewer can transact them. DIAGNOSTIC LOG Captured on-device during a failing session: 01:08:56 fetchProducts [com.aurascanner.app.pro.weekly, com.aurascanner.app.pro.annual] 01:08:56 fetchProducts -> 2 product(s): com.aurascanner.app.pro.annual=$39.99; com.aurascanner.app.pro.weekly=$6.99 01:08:56 requestPurchase sku=com.aurascanner.app.pro.weekly 01:08:57 purchaseError: code=purchase-error msg=Item Unavailable 01:08:57 error code=purchase-error, storefront=USA 01:09:05 fetchProducts -> 2 product(s), same prices returned again 01:09:05 requestPurchase sku=com.aurascanner.app.pro.annual 01:09:06 requestPurchase threw: Item Unavailable 01:09:06 error code=purchase-error, storefront=USA An introductory-offer eligibility check earlier in the session also succeeded, using the subscription group ID read from the loaded product. So product metadata, including the subscription group, resolves correctly. CONDITIONS Fails identically for both products, on every attempt. Reproduces in TestFlight on our own devices and Apple IDs. Also failed during App Review on iPad Air 11-inch (M3), iPadOS 26.5.2. Storefront reports as USA in every case. Real devices only. Not reproduced on Simulator. ALREADY VERIFIED Paid Applications Agreement: Active, banking and tax information complete. In-App Purchase capability: enabled on the App ID at Certificates, Identifiers & Profiles. Bundle identifier com.aurascanner.app matches the App Store Connect record. Both subscriptions: complete metadata, review screenshots uploaded, USD pricing set, United States availability. Both subscriptions and the subscription group are attached to the current submission, status "Ready for Review". Subscription group has a localized display name. Build distributed via TestFlight, which routes purchases to sandbox automatically. IMPLEMENTATION The app is React Native and uses a wrapper library over StoreKit 2, but the error text originates from StoreKit rather than the wrapper, and the call order follows the documented pattern: Initialize the StoreKit connection. Load products. This succeeds and returns both products. Register transaction update and error listeners. Request the purchase. This is where it fails. Purchases are verified server-side using Apple's App Store Server Library, and the transaction is finished only after verification succeeds. I am not asking anyone to debug the wrapper. My question is about StoreKit and App Store behaviour: what causes the store to quote a product and then decline to sell it? Any pointers appreciated. I can supply screenshots or the full log.

I am experiencing an issue with a non-consumable in-app purchase in my iOS app. The product loads correctly from the App Store and is displayed in the app, but when attempting to complete the purchase, StoreKit returns the following error: Payment completed with error: Error Domain=ASDServerErrorDomain Code=3504 "This item cannot be found." UserInfo={ NSLocalizedFailureReason=This item cannot be found., AMSServerErrorCode=3504, client-environment-type=Sandbox, storefront-country-code=USA } The same issue was also encountered by the App Review tester when they attempted to purchase the non-consumable product during review. The product: Is correctly configured in App Store Connect Has active pricing Is available in the United States Was included in the app submission Loads successfully and displays the correct price Fails only when the purchase is initiated Since the product metadata can be retrieved successfully, but the transaction fails with “This item cannot be found,” this appears to be a possible inconsistency between the StoreKit product catalog and the purchase backend. Has anyone encountered ASDServerErrorDomain Code=3504 for a non-consumable product that loads correctly but cannot be purchased? Is there any known App Store sandbox or commerce backend issue that can cause this, or any additional App Store Connect configuration that should be checked?

App Store Server Notification returns successful purchase while customer's payment remains Pending We have encountered an edge case with a Non-Renewing Subscription and would appreciate clarification on the expected developer behavior. Steps to reproduce User initiates an in-app purchase using a credit card. The purchase succeeds in the app. Our backend receives an App Store Server Notification V2 (ONE_TIME_CHARGE). We successfully verify the signed JWS transaction. The same transaction is also returned by the App Store Server API. Based on the verified transaction, we grant the user's entitlement. However, on the customer's Apple account: The purchase is shown as Pending in Purchase History / Report a Problem. The customer reports that their credit card has not yet been charged. Question From a developer's perspective, should entitlement be granted immediately after receiving a valid App Store Server Notification and successfully verifying the transaction, even if the customer's purchase is still shown as Pending? Is there any App Store Server API or transaction field that indicates the payment has not yet been settled, allowing developers to delay granting entitlement until the payment is finalized? Or is the expected implementation to grant entitlement upon successful transaction verification and revoke it only if Apple later sends a refund notification? Any clarification on the expected workflow would be greatly appreciated. Thanks in advance. :)

Hello Apple Developer Support / StoreKit team, I am testing auto-renewable subscriptions on a real iPhone device using Settings > Developer > Sandbox Apple Account > Test Transactions. I found that subscriptions work correctly for one of my apps, but fail for another app under the same Apple Developer account. Working app Bundle ID: com.benbendou.pinyincharacter Product ID: xpyxhz.quarterly Result: The sandbox purchase sheet appears and the subscription flow can be completed successfully. Failing app Bundle ID: com.benbendou.chengyudaquan Product ID: cydq.quarterly Result: The Test Transactions flow fails. In my app, Product.products(for:) can load some subscription products successfully. However, when trying to purchase cydq.quarterly, the purchase fails with: errorCode = 4040004 errorMessage = "App not found. Please try again." Because the same issue also happens in iPhone Settings > Developer > Sandbox Apple Account > Test Transactions, using the exact Bundle ID and Product ID, this does not seem to be caused by my app’s StoreKit code. The strange part is that another app under the same developer account works correctly with Test Transactions, but this app does not. Could Apple please help check whether the Bundle ID / app record / subscription group / in-app purchase products for com.benbendou.chengyudaquan are correctly linked in the StoreKit Sandbox backend? It looks like the sandbox environment can load the product metadata, but cannot complete the purchase or find the app during transaction lookup. Thank you.

We have a new iOS app in App Store Connect with six consumable in-app purchases. Environment: Bundle ID: live.mymi.ios TestFlight version: 1.0.4 (70) Storefront: KOR Environment: Sandbox Example product ID: ios_spark_5000 StoreKit product queries return all six products with localized KRW prices. For example, ios_spark_10000 is returned as ₩12,000. However, requesting a purchase fails with Product.PurchaseError.productUnavailable / “This item is not available.” The issue can also be reproduced independently of the app: Settings > Developer > Sandbox Apple Account > Test Transactions Entering bundle ID live.mymi.ios and product ID ios_spark_5000 is rejected with a message stating that the product ID or bundle ID is invalid. The previous app/product pair live.mymi.app + spark_5000 still works on the same device and with the same Sandbox tester. We verified the following: Paid Apps Agreement, banking, and tax information are active The explicit App ID has the In-App Purchase capability enabled The TestFlight build uses the correct bundle ID Product pricing, localization, and availability in all 175 storefronts are configured All six IAPs are attached to the first app version review submission No local StoreKit configuration is involved This has persisted for multiple days. It appears that the product-query catalog contains the products, while the Sandbox transaction service does not recognize the product-to-bundle association. Has anyone seen this with a newly created App Store app/IAP catalog? Did Apple need to re-index the products?We have a new iOS app in App Store Connect with six consumable in-app purchases. Environment: Bundle ID: live.mymi.ios TestFlight version: 1.0.4 (70) Storefront: KOR Environment: Sandbox Example product ID: ios_spark_5000 StoreKit product queries return all six products with localized KRW prices. For example, ios_spark_10000 is returned as ₩12,000. However, requesting a purchase fails with Product.PurchaseError.productUnavailable / “This item is not available.” The issue can also be reproduced independently of the app: Settings > Developer > Sandbox Apple Account > Test Transactions Entering bundle ID live.mymi.ios and product ID ios_spark_5000 is rejected with a message stating that the product ID or bundle ID is invalid. The previous app/product pair live.mymi.app + spark_5000 still works on the same device and with the same Sandbox tester. We verified the following: Paid Apps Agreement, banking, and tax information are active The explicit App ID has the In-App Purchase capability enabled The TestFlight build uses the correct bundle ID Product pricing, localization, and availability in all 175 storefronts are configured All six IAPs are attached to the first app version review submission No local StoreKit configuration is involved This has persisted for multiple days. It appears that the product-query catalog contains the products, while the Sandbox transaction service does not recognize the product-to-bundle association. Has anyone seen this with a newly created App Store app/IAP catalog? Did Apple need to re-index the products?

Summary After setting a single auto-renewable subscription product (not the app) to "Developer Removed from Sale" in App Store Connect, the next scheduled renewal for an existing active subscriber failed with DID_FAIL_TO_RENEW v2 and expirationIntent = 5 ("expired for some other reason"). I expected expirationIntent = 4 ("product wasn't available for purchase at the time of renewal"), since the product was, in fact, not available for purchase. I would like to confirm whether 5 is the documented/expected value for this scenario, and how to deterministically distinguish "developer removed product from sale" from other renewal failures using the notification payload. Reproduction / observed sequence Day 15: Changed product annual_promo (auto-renewable subscription) status from "Approved" to "Developer Removed from Sale" in App Store Connect. The app itself remained Approved and on sale. Other subscription products in the same group remained Approved. Day 16: An existing active subscriber on that product had a scheduled automatic renewal date. Result: Renewal did not occur. We received a DID_FAIL_TO_RENEW v2 notification. Payload (relevant fields): JWSRenewalInfoDecodedPayload.expirationIntent = 5 JWSRenewalInfoDecodedPayload.autoRenewStatus = 0 Questions Is expirationIntent = 5 the correct/expected value when a renewal fails because the developer removed the product from sale? Or should it have been 4 ("product wasn't available for purchase at the time of renewal")? If 5 is intentional, what is the engineering rationale for not using 4 in this scenario? Given that expirationIntent = 5 is documented as a catch-all ("some other reason"), which other fields in the DID_FAIL_TO_RENEW payload (e.g., subtype, autoRenewStatus, gracePeriodExpiresDate, signedTransactionInfo) should we inspect to deterministically classify the failure cause and isolate "developer removed product from sale" from billing failure / customer cancel / price-increase not accepted / etc.? Context I'm aware of the docs page In-App Purchase statuses and Set availability for an auto-renewable subscription, but they describe the status semantics, not the resulting notification payload. Product has been reverted to "Approved" to avoid further impact on subscribers while this is clarified. Thanks in advance.

Am same facing Storekit issue 0 product returns in Product identifier Array. Even i test on device it returns invalid product identifier due to 0 product array. Issue Description Step 1 Create a new Auto-Renewable Subscription from the App Information page in App Store Connect. Step 2 Complete all the required fields for the Auto-Renewable Subscription and click the "Save" button. Expected Result After saving, the subscription status should change from "Prepare for Submission" to "Ready to Submit". Actual Result The subscription status remains "Prepare for Submission" and does not change to "Ready to Submit", even though all required information has been completed and the subscription has been saved. I am currently facing a critical issue while creating an Auto-Renewable Subscription in "App Store Connect". I have already completed all the required subscription details. However, whenever I click the "Save" button, the subscription status does not change from "Prepare for Submission" to "Ready to Submit", as expected. Because the subscription never reaches the "Ready to Submit" state, every purchase attempt in the Sandbox environment fails with the following error: SKErrorDomain Code = 3 "Invalid Product Identifier" To troubleshoot the issue, I have already: Created multiple new Product Identifiers, but every identifier is reported as "invalid" in the Sandbox environment. Verified that my "Banking, Tax, and Paid Applications Agreement" is complete and active. Confirmed that all required fields for the Auto-Renewable Subscription have been filled in before saving. Since I am unable to submit the subscription for review and all Product Identifiers remain invalid, I believe there may be an issue with my App Store Connect configuration or account. I would appreciate it if you could investigate this issue and help resolve it as soon as possible, as it is currently blocking the implementation and testing of in-app purchases.

Hi, Overview I am trying to write a unit test case to buy a storekit product. SKTestSession.buyProduct(identifier: options:) throws the error StoreKit.StoreKitError.notEntitled Testcase Code @Test func example() async throws { let session = try SKTestSession(configurationFileNamed: "VehicleStore") session.disableDialogs = true session.clearTransactions() do { let transaction = try await session.buyProduct(identifier: "nonconsumable.car", options: []) print(transaction) } catch { // Throws StoreKit.StoreKitError.notEntitled print("Error: \(error)") } } Storekit configuration file Note In-App purchases capability is added StoreKit configuration file is used in testcase Environment: macOS 26.5.2 (25F84) Xcode 26.6 (17F113)

Since January 28, 2026, we’ve noticed an increase in StoreKit-related errors during purchase flows. Specifically, we’re seeing a spike in errors reported as “Unable to Complete Request”, categorized as unknown StoreKit errors. This correlates with a noticeable drop in the overall purchase success rate. A few observations: The issue is not limited to the latest app version, it also affects older versions. It appears to occur only on iOS 17+. The impact seems country-specific: some regions are affected more heavily, while others show no significant change compared to previous days. At the moment, there are no related incidents reported on Apple’s System Status page. Given these symptoms, this looks like a potential StoreKit / Apple API issue, but we haven’t found any official confirmation yet. Has anyone else observed similar StoreKit behavior recently on iOS 17+? Any insights or known issues would be greatly appreciated.

Getting 2.1(b) rejection. Reviewer sees "Purchase Failed" alert. Products configured correctly in ASC. Does App Review sandbox use same sandbox environment as developer testing? Can reviewer sandbox accounts trigger purchase failures that developer sandbox accounts cannot? Any known issues with first-time IAP products failing specifically during App Review sandbox session?