App Store Connect displays the In-App Purchases and Subscriptions section on your app's version page when your app has an In-App Purchase or subscription with a Ready to Submit status. To locate the In-App Purchases and Subscriptions section: In Apps, select the app you want to view. In the sidebar, select the app version. On the version page, scroll down to the In-App Purchases and Subscriptions section. For more information, see Submit an In-App Purchase.

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

Hi everyone, We are currently preparing the release of our Flutter-based iOS application and are experiencing an unusual StoreKit 2 storefront issue that only occurs when the app is installed through TestFlight. The problem When our application is installed through TestFlight, StoreKit 2 consistently returns the United States storefront (USA), and all six auto-renewable subscription products are displayed with USD prices. However, both the regular Apple Account and the Sandbox Apple Account are configured for Germany. We have verified the following: All six subscription products are correctly configured in App Store Connect with EUR prices for Germany. The subscriptions are available in Germany, Austria, and Switzerland. We created a completely new Sandbox tester with Germany selected during account creation, using an email address that had never previously been used for sandbox testing. The issue occurs on two different physical devices (iPhone and iPad). No local StoreKit configuration file is used. Our application does not override the storefront, modify localized prices, or contain any hardcoded USD fallback. Controlled comparison We performed additional tests using the same application code on the same iPhone. The results were: Installation method Storefront Currency Local Debug build via Xcode/Flutter DEU EUR Local development-signed Release build via Flutter DEU EUR TestFlight Release build USA USD The locally installed Release build successfully retrieves all six subscription products with their correct German prices. For example, StoreKit returns the following values for one of our subscriptions: Local Release build: Storefront.current.countryCode = DEU Product currencyCode = EUR Product.displayPrice = 6,99 € TestFlight build: Storefront.current.countryCode = USA Product currencyCode = USD Both builds use the same StoreKit 2 integration and product identifiers. Technical environment Framework: Flutter StoreKit integration: StoreKit 2 Flutter plugin: in_app_purchase_storekit 0.4.11+2 Devices: Physical iPhone and iPad iOS/iPadOS: 26.6.2 Subscription products: Six auto-renewable subscriptions Expected storefront: Germany (DEU) Actual TestFlight storefront: United States (USA) We have traced the storefront country code directly to StoreKit 2’s Storefront.current.countryCode and the localized prices to the product information returned by Product.products(for:). There is no application-level storefront override or price conversion. Questions Why would StoreKit 2 return a different storefront in TestFlight compared with a locally installed development-signed Release build on the same physical device? Could TestFlight use a different sandbox storefront or Apple Account context than a locally installed build? Is there a recommended way to diagnose or reset the storefront association used by TestFlight? Has anyone experienced similar behavior where TestFlight consistently returns USA despite using a German Apple Account and newly created German sandbox testers? We have already contacted Apple Developer Support and followed their recommendation to create a completely new German sandbox tester, but the issue persists. Any guidance from Apple engineers or developers who have encountered similar behavior would be greatly appreciated. Thank you!

Hi everyone, We are currently preparing the release of our Flutter-based iOS application and are experiencing an unusual StoreKit 2 storefront issue that only occurs when the app is installed through TestFlight. The problem When our application is installed through TestFlight, StoreKit 2 consistently returns the United States storefront (USA), and all six auto-renewable subscription products are displayed with USD prices. However, both the regular Apple Account and the Sandbox Apple Account are configured for Germany. We have verified the following: All six subscription products are correctly configured in App Store Connect with EUR prices for Germany. The subscriptions are available in Germany, Austria, and Switzerland. We created a completely new Sandbox tester with Germany selected during account creation, using an email address that had never previously been used for sandbox testing. The issue occurs on two different physical devices (iPhone and iPad). No local StoreKit configuration file is used. Our application does not override the storefront, modify localized prices, or contain any hardcoded USD fallback. Controlled comparison We performed additional tests using the same application code on the same iPhone. The results were: Installation method Storefront Currency Local Debug build via Xcode/Flutter DEU EUR Local development-signed Release build via Flutter DEU EUR TestFlight Release build USA USD The locally installed Release build successfully retrieves all six subscription products with their correct German prices. For example, StoreKit returns the following values for one of our subscriptions: Local Release build: Storefront.current.countryCode = DEU Product currencyCode = EUR Product.displayPrice = 6,99 € TestFlight build: Storefront.current.countryCode = USA Product currencyCode = USD Both builds use the same StoreKit 2 integration and product identifiers. Technical environment Framework: Flutter StoreKit integration: StoreKit 2 Flutter plugin: in_app_purchase_storekit 0.4.11+2 Devices: Physical iPhone and iPad iOS/iPadOS: 26.6.2 Subscription products: Six auto-renewable subscriptions Expected storefront: Germany (DEU) Actual TestFlight storefront: United States (USA) We have traced the storefront country code directly to StoreKit 2’s Storefront.current.countryCode and the localized prices to the product information returned by Product.products(for:). There is no application-level storefront override or price conversion. Questions Why would StoreKit 2 return a different storefront in TestFlight compared with a locally installed development-signed Release build on the same physical device? Could TestFlight use a different sandbox storefront or Apple Account context than a locally installed build? Is there a recommended way to diagnose or reset the storefront association used by TestFlight? Has anyone experienced similar behavior where TestFlight consistently returns USA despite using a German Apple Account and newly created German sandbox testers? We have already contacted Apple Developer Support and followed their recommendation to create a completely new German sandbox tester, but the issue persists. Any guidance from Apple engineers or developers who have encountered similar behavior would be greatly appreciated. Thank you!

Hello, I would like to clarify the best practices and timing for our backend server to transition its main connection to the production App Store Server API. Currently, we are considering the following approach: We plan to switch our backend’s primary API endpoint from Sandbox to Production once our app passes the App Store review and its status changes to "Ready for Sale." Could you please confirm if this timing is standard and correct? Additionally, to handle App Store reviews (which run in the Sandbox environment) and TestFlight tests seamlessly without manual configuration changes, we are planning to implement an automatic fallback mechanism: Our backend always requests the Production App Store Server API first. If it returns a "TransactionNotFound" (e.g., 4040010) error, the backend automatically retries the request using the Sandbox API. Is this automatic fallback from Production to Sandbox considered a safe and recommended practice by Apple, especially for App Store reviews and post-release testing? Any advice or insights on backend transition timing and fallback strategies would be highly appreciated. Thank you!

Hello, I would like to clarify the exact technical behavior of the App Store Server API (V2) and StoreKit under the following two specific scenarios: Case A (Production Account on Sandbox Endpoint): If a user with a production Apple Account attempts to purchase through a build pointing to the Apple Sandbox environment (or Sandbox API), how does the Apple server handle this transaction and its data lifecycle? (Does StoreKit block this at the client-side, or does the API return a specific error code?) Case B (Restoring Cleared Sandbox Data): If a Sandbox tester's purchase history is cleared/deleted on the Apple server, and the app subsequently requests a "Restore Purchase" or queries the App Store Server API using a previously valid transactionID from that account, what specific error code (such as 4040010 TransactionNotFound) or empty response does the Apple server return? I would highly appreciate your confirmation or any technical insights on these behaviors. Thank you!

Hi, During the App Review process, a test purchase was made using what appeared to be a production Apple account. When our app server sent this transactionId to the Production App Store Server API, it returned the error code 4040010 (TransactionIdNotFoundError). To handle this gracefully and prevent review rejections, we are considering implementing a dynamic fallback mechanism on our app server. Specifically, when the Production API returns 4040010, the server will automatically retry the request using the Sandbox App Store Server API URL. Could you please clarify the following points regarding this design? Is it expected behavior for an App Review purchase to return 4040010 on the Production API, and can it be successfully verified by routing it to the Sandbox API? Is this dynamic fallback logic (Production API ➔ if 4040010 ➔ Sandbox API) a recommended and officially supported best practice for handling App Review and TestFlight transactions? Any confirmation or advice from Apple engineers or the community would be greatly appreciated.Thank you.

I am preparing the first release of my iOS game, Ippon Battle, and testing it on my own physical devices through TestFlight. I am looking for a supported workaround or further diagnostics for inconsistent product prices, and guidance on whether the same behavior can occur in production. Feedback report: FB25378742 (filed October 31, 2026; currently Open). Apple Developer Support directed me to Feedback Assistant for bug reporting and these forums for technical help. The feedback report includes screenshots and the app-specific identifiers. Environment and observations iPhone 15, iOS 27.0.1 (24A446). App version 1.7.11; raw catalog diagnostics were captured in TestFlight build 41. Two non-consumable products: ipponbattle.fighters5 (Japan: JPY 300) and ipponbattle.story (Japan: JPY 400). The Sandbox account is configured for Japan. The iPhone diagnostic reported Storefront country JPN and currency JPY. Japan prices were independently read-verified through the App Store Connect API on October 21, 2026. I have not changed prices as a troubleshooting step. For each exact product ID, native StoreKit calls returned: Product.products(for:): price = 1.99, priceFormatStyle.currencyCode = USD SKProductsRequest: price = 1.99, priceLocale currency = USD This occurred for BOTH products, despite their different configured Japanese prices. The original in-game shop displayed $1.99 for each. The fighter pack's Apple purchase confirmation sheet showed JPY 300. On a second physical device, an iPad running TestFlight build 44, a screenshot shows the story product at $1.99 in the shop behind Apple's purchase sheet showing JPY 400. The sheet explicitly identifies it as a test purchase with no charge. I did not capture raw storefront/API diagnostics on that iPad, so I am not assuming its internal storefront state was identical to the iPhone trace. Both products were successfully test-purchased in earlier tests. Restoration and ownership after relaunch also worked. The issue is the product metadata price/currency, rather than an inability to complete a purchase. Reproduction procedure Install the app through TestFlight and use the Japan-configured Sandbox account. Request the two product IDs with Product.products(for:) and inspect the returned product IDs, price, priceFormatStyle.currencyCode, and displayPrice alongside the current Storefront. Independently request the same IDs through SKProductsRequest and inspect price and priceLocale. Compare those values with the configured Japan prices and Apple's purchase confirmation sheet. Checks and mitigation Signing out of the Apple account did not resolve the problem. Product data is matched by product ID, not response order. There is no fixed USD fallback or persistent price cache in the app. The TestFlight build does not use a local StoreKit configuration file. These are native API results, not simulated UI test responses. The app refreshes product information when the shop opens and clears old quotes on refresh, failure, or storefront changes. StoreKit 1 is used only to cross-check catalog data. Purchases, transaction verification, and restoration remain on StoreKit 2. As a temporary mitigation for this Japan-only app, prices that cannot be verified as JPN/JPY are hidden. I do not relabel USD amounts as yen, convert them, or substitute hard-coded JPY prices. This prevents the misleading display but does not solve retrieval of the correct catalog prices. Questions Is a mismatch between StoreKit product metadata and the purchase sheet a known TestFlight/Sandbox behavior? Is there any supported way to determine whether production is affected before a first public release? What supported recovery or refresh procedure should I try to retrieve prices consistent with the purchase sheet, beyond re-requesting products and signing out/in? What additional diagnostics, logs, or reproduction details would help the StoreKit team investigate FB25378742? I found a similar report, but I do not know whether it has the same cause. I have not isolated the cause to the catalog service, OS, or account. Thank you.

Hi everyone, I submitted my first iOS app on Oct 21. On Oct 23 I got an automated message asking me to confirm the price of an in-app purchase (Guideline 3.0.0). I answered the same day, and I followed up on Oct 28. Since then I've heard nothing. App Store Connect still shows "Rejected" and "Unresolved Issues", and the only message in the Resolution Center is that automated price question. Has anyone been through this? How long did it take for you after you answered and did anything help besides waiting? How long do I have to wait still? Thanks!

I've already done my test on development signed app locally, all in-app purchase runs well with sandbox tester Apple ID. Errors happens when make a purchase in distribution app from TestFlight. Detail Info: in Apple Store connect , make app available to China Electron project, packaging by electron builder using distribution sign upload to TestFlight, invite myself to test using my Apple ID(not the sandbox tester) to login and purchase dialog appears and said "Account not in this store" VPN is off Apple Store shows Chinese language and Chinese apps, not llikely to be u.s. store I'm suspecting that: Maybe shouldn't use my developer Apple ID to run TestFlight test? TestFlight locked app to be in u.s. store ?

App: Fonn Tunes (Apple ID 6807685437) Version: iOS 1.1 (6), with in-app purchase 6819304769 Submission ID: 0a03aece-1366-48c7-8435-7f502ffd033a Submitted 15 Oct. The macOS version was approved the same day. I requested an expedited review on 21 and 22 Oct, and sent a status query on 26 Oct, with no reply to any of them. App Review raised a pricing query on 28 Oct. I corrected the price the same day and resubmitted, and the status has not changed since. Agreements, tax and banking are all active. Could someone check whether this submission is blocked or needs anything from me? Thank you.

We're testing In-App Purchases for our app distributed via TestFlight, using Sandbox Apple Accounts. We observe two device-dependent behaviors and have two questions. (App-specific details, including the bundle ID, are in our Feedback report FB24632077.) Observation 1 — Consumable second purchase fails with DuplicateTransaction on some devices The first purchase of a consumable succeeds and the transaction is finished. A second purchase of the same consumable then fails with PurchaseFailureReason.DuplicateTransaction ("This In-App Purchase has already been bought") on some devices. It correlates with sandbox session persistence: on devices where the purchase prompts for password only (e.g., iOS 26.x, iPadOS 18.4.1) the second purchase succeeds; on devices where it prompts for the account (email) + password every time (e.g., iOS 18.3.2, iPadAir2 15.6), the second purchase fails. The same Sandbox Apple Account behaves differently on different devices. An Ad Hoc (development-signed) build with the same account succeeds. Observation 2 — Product price sometimes returns USD instead of the storefront currency With the same Sandbox account (region: Japan), prices are shown in JPY on iOS 26.2 but in USD on iOS 18.3.2. The App Store app shows JPY, but SKProductsRequest / StoreKit 2 Product metadata returns USD. Question 1: Are these known Sandbox/TestFlight limitations? If so, what is the recommended way to reliably test repeat consumable purchases (and to get the correct storefront currency) in TestFlight across many devices and OS versions? Question 2: For TestFlight IAP testing, are there environmental differences between (A) using the device's real Apple ID (signed into Media & Purchases; automatic sandbox) and (B) signing out of Media & Purchases and using a Sandbox Apple Account — with respect to: reliability of repeat consumable purchases, authentication / session persistence (password-only vs account + password each purchase), storefront / currency resolution for product metadata, ability to clear purchase history? Which approach do you recommend for a consistent, reliable TestFlight IAP QA environment? Environment: TestFlight (App Store distribution), Sandbox tester region = Japan. (App-specific identifiers such as bundle ID are in our Feedback report FB24632077.) Repro: buy a consumable once (succeeds, finished) → buy the same product again → DuplicateTransaction on affected devices. Thanks!

Environment: Sandbox Bundle ID: com.fosssocial.app Key ID: L7DZYHGM62 Issuer ID: cf1f7bc7-452f-4bb8-a925-31ca29175fac Summary Our In-App Purchase key is accepted by the App Store Server API but rejected by the Advanced Commerce API, using the exact same bearer token. This appears to be an authorization grant that was never applied to the key, rather than a signing or request-format problem on our side. Reproduction — one token, two API families GET /inApps/v1/subscriptions/1 -> 404, errorCode 4040010 (token ACCEPTED, resource simply not found) POST /advancedCommerce/v1/subscription/changeMetadata/1 -> 401, errorCode 4010000 (token REJECTED) Same JWT, same key, issued seconds apart. A 401 on one family and a 404 on the other isolates this to key authorization. On-device symptom A signed SubscriptionCreateRequest passed to StoreKit as advancedCommerceData fails with StoreKitError.unknown / "Unable to Complete Request". No payment sheet appears and no InvalidRequestError is returned, so there is no field-level error to act on. What we have already verified JWS header: alg ES256, kid, typ JWT Claims: iss, iat, aud "advanced-commerce-api", bid, nonce, request No exp claim (per Apple's documentation) The request claim uses standard padded base64, not base64url Key ID and .p8 file confirmed to be a matching pair Key regenerated after receiving the Advanced Commerce access-granted email; the 401 is unchanged AdvancedCommerceProduct(id:) resolves successfully on device, which confirms the PRODUCT has Advanced Commerce access Question Does the In-App Purchase key require a separate authorization for the Advanced Commerce API beyond the product-level access we were granted? If so, how is that applied to an existing key?

We are implementing StoreKit External Purchase Link for an iOS app distributed in the European Union and are trying to determine whether we are missing a configuration step or encountering a StoreKit server-side eligibility issue. The failure is reproducible in a focused native Swift Xcode project that directly calls StoreKit: let eligible = await ExternalPurchaseCustomLink.isEligible The sample contains no Flutter code, PayPal SDK, networking, or application business logic. Configuration we have verified: The Account Holder accepted the StoreKit External Purchase Link Entitlement Addendum for EU Apps. StoreKit External Purchase Link is enabled and shown as Assigned for the App ID. The regenerated Development provisioning profile contains com.apple.developer.storekit.external-purchase-link = true. The installed app's signed entitlements contain the same value. The application-identifier and team-identifier match the intended App ID and team. The compiled Info.plist contains SKExternalPurchaseCustomLinkRegions with all 27 lowercase EU region codes, including "de". Germany is available for the app in App Store Connect. No local StoreKit Configuration file is enabled. Test environment: Physical iPhone running iOS 26.5.2 (23F84) Xcode 26.6 (17F113) Real German Media & Purchases Apple Account German Sandbox Apple Account StoreKit 2 storefront ID 143443, country code DEU StoreKit 1 also reports country code DEU AppStore.canMakePayments = true AppTransaction verifies in the Sandbox environment Clean build and reinstall using the regenerated Development profile Observed result: ExternalPurchaseCustomLink.isEligible = false For diagnostic purposes only, after observing false eligibility, we also requested both token types: ACQUISITION: StoreKitError.notAvailableInStorefront SERVICES: StoreKitError.notAvailableInStorefront A delayed recheck still reports storefront DEU and isEligible=false. Our production flow does not request tokens unless eligibility is true. We found the similar thread "Unable to enable eligibility for External Purchase Link APIs" (https://developer.apple.com/forums/thread/808349). In that case, the production Media & Purchases account had an unsupported storefront. In our case, both the real Media & Purchases account and the Sandbox account are German, and StoreKit itself reports DEU. We also found "External Purchase in Japan" (https://developer.apple.com/forums/thread/822618), where an Apple App Store Commerce Engineer requested a Feedback Assistant report with a sysdiagnose and screen recording for isEligible=false. Questions: Should ExternalPurchaseCustomLink.isEligible return true in a developer-signed Sandbox build when the entitlement, compiled Info.plist, German storefront, and account conditions are all satisfied, or is TestFlight/App Store approval required? Is there any additional App Store Connect storefront election, entitlement approval, or server-side activation step required beyond the EU addendum, Assigned capability, signed entitlement, and SKExternalPurchaseCustomLinkRegions? If this configuration is complete, could Apple verify whether eligibility has not propagated correctly for the German Development/StoreKit Sandbox environment, and which diagnostics should be included in a Feedback Assistant report? We have also opened a code-level support request and prepared a minimal native Swift reproduction project. Any guidance from StoreKit engineering would be appreciated.

I have simple non-consumable IAPs set up for an app on macOS. Testing in development with a local .storekit configuration file, everything works as expected. Testing in development with a remote Sandbox, everything also seems to work fine. Product names and prices fetch correctly, I am able to make purchases with a Sandbox account (both US and UK). Once I upload a build into TestFlight, IAPs no longer work. The tester would download the Beta app from TestFlight. They open a license manager and can see all the product names, descriptions and prices are pulled from Apple servers correctly (with the correct local currency as well!). So far so good. When trying to purchase any of the IAP, the following error appears: This is TestFlight so testers are using their real Apple ID. My understanding is that they should continue using their production credentials and a TestFlight Sandbox would be configured behind the scenes automatically. This error always says the users cannot purchase from a US store and must switch to [whatever user’s actual store location is] store. For example, my account is based in the UK, has got a UK billing address and a UK payment method, and the error tells me to switch to the UK store. People in Canada get a similar error - you must switch from the US store to Canadian. The error makes no sense, the account is already in the desired country. Clicking on the “Change Store” button opens the App Store app and displays another error: “Cannot Connect to App Store”. Clicking Retry just results in this errors showing again and again. Clicking OK takes us back to the failed IAP purchase and the final error message appears: “Purchase Error - Unable to Complete Request”. Things I’ve done / checked: IAPs are configured in App Store Connect and available for all regions prices are set for all regions in App Store Connect IAP name and description localisation in English (UK) IAP status is Ready to Submit, I don’t think I can go past that unless I make a production release (which I can’t until we fix the problem) IAP capabilities added in xcode the problem is not account, machine, or location dependent - every beta tester testing my app on TestFlight has the same issue, they each use a different account and have accounts in different countries double checked the App Store account location in the App Store settings - it is definitely matching the store this error is asking to switch to application exits at startup with error 173 if app receipt cannot be found - this one was suggested by the review team, I could not really find any documentation for it review team also suggested I should add com.apple.security.network.client to enable IAP connectivity. I did add that to one of the builds and it did not help. I am not really convinced this is necessary Any suggestions on what to check and what to try? I have run out of ideas.

Hi Apple team, We’re evaluating how we generate appAccountToken for in-app purchases. For privacy and security reasons, rather than using a stable UUID associated with an account across all purchases, we’re considering generating a different opaque value for each purchase/context. Internally, our backend would maintain the mapping needed to associate each value with the correct customer account and, potentially, additional purchase context. In other words, the same customer account may result in different appAccountToken values across separate purchases, while our backend can still deterministically resolve each token to the correct account. We’d like to confirm: Does Apple expect or recommend that appAccountToken remain stable for the same app account across purchases? Are there any concerns with this approach for non-subscription / one-time purchases, assuming we maintain the account association on our backend? Our goal is to avoid exposing a stable account-correlatable identifier while still maintaining reliable server-side attribution. Thanks!

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. :)

Hi everyone, I'm investigating an issue related to StoreKit 1 receipt validation and would appreciate any insight from Apple engineers or developers who have encountered this before. Environment StoreKit 1 Consumable In-App Purchase iOS 16 / iOS 17 / iOS 18 (observed on multiple versions) Receipt validation performed on our server Receipt is read from the app bundle after the transaction completes Issue Occasionally, after a purchase succeeds and the transaction reaches the SKPaymentTransactionStatePurchased state, the App Receipt exists and can be decoded successfully, but the receipt contains: { "receipt": { ... "in_app": [] } } The in_app array is completely empty. As a result, our server cannot find the purchased product in the receipt and cannot complete receipt validation. Questions I'd like to understand under what circumstances Apple may return an App Receipt where receipt.in_app is empty. Specifically: Is it expected behavior that receipt.in_app can be empty after a successful consumable purchase? Could this happen if the app reads the receipt before the receipt has been updated? Is there any possibility that calling finishTransaction: before reading the receipt could cause the purchase record not to appear in receipt.in_app? If receipt synchronization is delayed, what is Apple's recommended approach? Wait and retry? Issue an SKReceiptRefreshRequest? Or validate using another mechanism? Are there any documented scenarios where Apple intentionally returns an empty in_app array? Additional Information The transaction state is Purchased. The purchase callback is received successfully. We have confirmed that the receipt file exists. The issue occurs only occasionally and cannot be reproduced consistently. Most purchases contain the expected in_app entry. Any clarification about the expected behavior of the App Receipt or recommended best practices would be greatly appreciated. Thank you!

Hello, Our first release was rejected under Guideline 2.1(b) because subscriptions were unavailable during App Review. We have been unable to reproduce the issue and would appreciate guidance on further diagnostics. Review environment App version: 1.0.0 (9) Device: iPad Air 11-inch (M3) OS: iPadOS 27.0.1 Internet connection: Active, according to the review message The app integrates StoreKit through RevenueCat and offers three auto-renewable subscriptions. We verified that : The Paid Apps Agreement, banking information, and tax forms are active. All three subscriptions and their subscription group are included in the submission. The subscriptions are available in all countries and regions. The submitted build uses the RevenueCat App Store SDK key, rather than a Test Store key. We tested subscription loading 15 times across two networks, including on iPad. Prices loaded successfully, and we completed a sandbox purchase that unlocked Premium. Additional diagnostics on an iPad Air 11-inch (M3) simulator running iPadOS 26.5 returned all three products both through a direct StoreKit Product.products(for:) request and through RevenueCat. No local StoreKit configuration file was attached. We have not reproduced the exact iPadOS 27.0.1 review environment. The simulator runtime is unavailable through our installed Xcode. The rejection message states that subscriptions were unavailable, but does not identify whether product retrieval failed, the subscription options were missing, or a purchase attempt failed. We are asking App Review for those details and a retry. We were wondering: What additional diagnostics would help investigate product availability failures that occur only during App Review? Are there sandbox account or storefront conditions we should test beyond successful product loading and sandbox purchases? Is there a recommended way to collect useful StoreKit error information from a review session when the failure cannot be reproduced locally? Thanks !

I previously responded to thread 840483, but Apple Support staff have not responded. I've also responded in App Review and created a support email, but the response times have been inadequate, and in the email thread it seems that the responding agent(s) did not read or understand the context of the issue, so I'll make this post in the hope that someone from Apple Support can assist. Guideline 2.1(b) rejection, with no way to submit the in-app purchase and the version together. I’m hitting the same deadlock described in thread link text, and I’ve added my case because it looks systemic, not a one-off setup error. My situation New app, iOS 1.0. One non-consumable in-app purchase (Pro Unlock). All metadata, price, availability, and the App Review screenshot are complete, and its status is Ready for Review. Rejected first under 2.1 (information needed), then, after I resubmitted, under 2.1(b): the in-app purchase “has not been submitted for review.” Apple’s instruction was to submit the purchase and upload a new binary. What I can’t do Adding the purchase for review creates a stand-alone Draft Submission that says: “Unable to Submit for Review. To submit your items for review, add an app version for the selected platform.” The version is never offered, and Submit stays disabled. The app version is held by the rejected submission, where the only option is Resubmit. That sends the version alone, which is what caused the rejection. The version page doesn’t show an “In-App Purchases and Subscriptions” section, so there’s nowhere to attach the purchase, contrary to what Apple’s help pages describe. I uploaded a new build, attached it to the version, deleted the stale draft, and tried every Add for Review path I could find. The result is the same. Why this isn’t acceptable App Review’s own message tells developers to do something that App Store Connect currently doesn’t allow. Everything Apple needs to see this is on Apple’s side: the account shows a configured purchase, a version in a rejected submission, and a draft that cannot be submitted. The state is visible without any information from me, yet the response so far is a rejection that repeats an instruction I can’t carry out. Each rejection costs developers days. What I’m asking Apple to do Attach the in-app purchase to the existing submission for the version, or Release the version from the rejected submission, so a single new submission can contain both. Acknowledge whether this is a known App Store Connect issue, and when it will be fixed. Other, older threads reporting similar issues and no posted solution include: link text link text link text I’ve also contacted Developer Support and replied in the Resolution Center. Could an Apple staff member look at this thread and my submission (ID ef48c4f6-1ad2-46d8-bb95-46c20bffc82a)? To anyone else with the same problem: please say so, and describe whether you found any workaround that didn’t require recreating your product IDs.

I’m testing In-App Purchases in the sandbox on a real iPhone. Auto-renewable subscriptions work correctly with the same app build, bundle ID, and sandbox tester account: com.aifalling.sides.vip.monthly com.aifalling.sides.vip.yearly However, a non-consumable product can’t be purchased: Product ID: com.aifalling.sides.vip.onetime App Store Connect IAP Apple ID: 6794812888 Type: Non-Consumable Status: Ready to Submit Bundle ID: com.aifalling.sides The native StoreKit payment request fails immediately with: The purchase identifier was invalid. The wrapper reports error code 700605. I verified the non-consumable product through the App Store Connect API: Product ID exists and is returned by the API One localization exists: zh-Hans A price schedule is configured, including a base territory and prices Availability includes China (CHN) and many other territories availableInNewTerritories is true I waited more than one hour after the latest metadata changes I completely removed the app, rebuilt/reinstalled the custom development build, and retried The same signed build can successfully purchase the two auto-renewable subscriptions This is the first non-consumable IAP type for this app. The app and IAPs have not been submitted for App Review yet because I’m trying to complete sandbox testing first. Does a non-consumable IAP require any additional App Store Connect setup or association that an auto-renewable subscription doesn’t require for sandbox testing? Is Ready to Submit sufficient for sandbox testing of a non-consumable product in this situation? Any guidance would be appreciated.

Since we configured App Store Server Notifications V2 on 15 October 2026, every notification for our app is recorded as TIMED_OUT, with the attemptDate equal to the signedDate (same second), and no HTTP request ever reaches our server. 35 Sandbox notifications (TEST, SUBSCRIBED, DID_RENEW, EXPIRED): one attempt each, TIMED_OUT. 2 Production TEST notifications: retried 5–6 times over a week, all TIMED_OUT. Our endpoint is public, TLS 1.3, valid certificate, answers in < 400 ms, and processes the signedPayload correctly when we POST it ourselves. Today we pointed the Sandbox URL to a webhook.site URL and requested a test notification: TIMED_OUT within 10 s, nothing received on webhook.site either. The app (com.virginactive.revolution, appAppleId 1620160868) was transferred to our current developer account on 2 October 2026; notifications have never been delivered under the new team, so we suspect a server-side state issue after the transfer. Latest test tokens: Sandbox: be12b40b-19a7-4723-aebf-764db83b4690_1793289992274 (29 Oct 2026 16:06 UTC) Production: 80597167-2939-4cc9-a43c-2c3c29c6a161_1792741270174 (23 Oct 2026 07:41 UTC) Feedback Assistant: FB25363489 Is there anything on our side that could make the App Store server fail before attempting the connection, or does this need to be fixed on Apple's side?