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!

Our iPad application uses authenticated accounts in our own service. Before enabling access for a member receiving an assigned subscription, we need to establish that the actual assigned Apple member authorized enrollment into the intended account in our service. The unresolved case is another authenticated application account presenting forwarded, genuinely Apple-signed member transaction or app transaction evidence. We need to understand the supported verification boundary that prevents possession of that evidence from being sufficient to acquire another member's access. Personal purchase ownership will remain separate from assigned-member access. Proposed flow for review: The app obtains AppTransaction and the assigned Transaction directly from StoreKit and checks both against the current device using the documented device-verification procedure. It then proposes an App Attest assertion over the exact evidence and a server-issued challenge associated with the authenticated application account. The proposed client method accepts no forwarded JWS input. Our server would separately authenticate the service session and verify the attestation, assertion, Apple-signed evidence, current assignment and subscription lifecycle before granting access. Is this composition supported for authenticating assigned-member enrollment? Specifically, may the server rely on the direct StoreKit capture and local device checks within the attested app to establish that the same Apple member authorized the intended application-account association? What connects the StoreKit member/device verification, the App Attest key and the intended account, so that a valid assertion over forwarded authentic evidence would not be sufficient? Please identify the required server validation and trust assumptions, or an additional supported API/protocol if the proposal is insufficient. We also need to understand recovery after reinstall or an application-account switch, and the applicable Sandbox, TestFlight and Production support. Matching identifiers or a first successful claim must not transfer another member's access. What we have checked: The StoreKit deviceVerification documentation describes checking whether a transaction belongs to the device. The App Attest server-validation guide describes attestation, assertions, one-time challenges and per-user/device key association. We have not found an explicit assigned-member enrollment contract covering their composition. The closest existing discussions are "Scoping App Attest keys to an appTransactionID" and "Is keying off Storekit's AppTransactionID a valid pattern for storing keys?" They discuss key organization for anonymous users; they do not resolve this assigned-member enrollment question. This is an API and trust-contract clarification. A focused, newly authored sample was supplied privately to DTS. It contains no customer records, credentials, captured transaction evidence or production source. The sample was prepared using Xcode 27.0 on macOS 27.0.1 and targets iOS/iPadOS with the iOS 27 SDK. Swift syntax and project-file parsing passed, but it has not been compiled, signed, installed or device-tested. The default app displays the question; it invokes no StoreKit, App Attest, purchase, enrollment or network calls. We have not enabled assigned-member grants or claimed a reproduced Apple defect. References: https://developer.apple.com/documentation/storekit/transaction/deviceverification https://developer.apple.com/documentation/devicecheck/validating-apps-that-connect-to-your-server https://developer.apple.com/videos/play/wwdc2026/391/ https://developer.apple.com/documentation/appstoreserverapi/get-customer-groups https://developer.apple.com/forums/thread/833174 https://developer.apple.com/forums/thread/831468

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.

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 ?

I have questions about pricing flexibility and technical implementation. In WWDC26 Session 391, you introduced up to five volume pricing bands that allow developers to offer lower per-seat subscription prices as organizations purchase more seats. For example: 1–20 seats: $39.99/month per seat 21–40 seats: $29.99/month per seat 41+ seats: $19.99/month per seat Volume purchasing and volume discounting provide different benefits. Volume purchasing makes it easier for organizations to buy, deploy, and manage subscriptions. This is valuable independently of discounts. Consider a productivity application deployed to 10,000 employees. Unlike AI services that charge separately for tokens or usage credits, an application offering unlimited, unmetered usage receives no additional revenue beyond its subscription fees. Supporting 10,000 deployments also introduces ongoing responsibilities. Major updates, new capabilities, and performance improvements may require additional testing, deployment coordination, compatibility checks, and technical support. Enterprise customers often have greater requirements for reliability, timely updates, and deployment management. Reducing the fixed subscription price per seat does not reduce these responsibilities or account for the additional value delivered across an organization. My questions for the StoreKit team: Business pricing: Can developers create a separate business subscription with a higher base price than their consumer offering, such as $39.99/month for individuals and $59.99/month per business seat, with independent volume pricing bands? Business-only distribution: Can this subscription be offered exclusively through Apple Business while maintaining the existing consumer subscription? Business features in the same app: Can StoreKit 2 identify whether a user has an individual subscription or an organization-assigned seat, allowing developers to unlock additional business capabilities within the same app binary? Onboarding and deployment: What is the recommended approach for adapting onboarding, subscription unlocking, and access management for organization-assigned users? Are there specific considerations for MDM deployment and managed app configurations? Implementation resources: Are there technical documentation or sample projects covering multiseat purchases, entitlement verification, seat reassignment, subscription changes, and ongoing management after release? The primary opportunity is simplifying organizational purchasing and deployment, while allowing developers to deliver additional business value and price subscriptions according to the ongoing requirements of supporting organizations at scale—not simply discounting additional seats. I’d appreciate clarification on the recommended pricing configuration and StoreKit 2 implementation. Thank you. REF: October 22 Announcement — Offer your subscriptions to businesses and schools

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?

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={}

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 am a long time developer but have never incorporated an IAP into any of my work so this is very new to me. So to save time I have used some AI for coding, but the code is having an issue and I'm not sure whether it is in the code or in Xcode. Xcode 27 on macOS 27.0.1 for iOS 27.0.1. IAP is to unlock full access after a 14-day trial. DESCRIPTION OF PROBLEM In local Xcode StoreKit testing, Product.purchase() returns .pending (as expected, since "Ask to Buy" is enabled), and Xcode’s transaction manager continues to show “Pending Approval.” After closing and reopening the app’s purchase sheet, the same transaction appears as verified and non-revoked in Transaction.currentEntitlements and is delivered through Transaction.updates, giving full access to the app. This reproduces in a standalone UIKit test app (linked below). The source file in question is AppAccessManager.swift. The relevant functions are: AppAccessManager.purchaseProduct() Calls product.purchase(). Handles .pending by recording a request reminder and displaying feedback. AppAccessWindowViewController.viewDidLoad() Runs when the purchase-options sheet is opened. Calls manager.start() followed by manager.refreshAccessState(). This is the sheet-opening path associated with the unexpected transaction delivery. AppAccessManager.refreshAccessState() Iterates Transaction.currentEntitlements. A transaction still labeled “Pending Approval” in Xcode is returned here as verified and nonrevoked. AppAccessManager.startListeningForTransactionUpdates() and handleTransactionUpdate(_:) The same pending transaction is also delivered through this sequence as verified and nonrevoked. The handler applies access before calling transaction.finish(). AppAccessManager.applyVerifiedPurchase(_:) Applies verified transactions received from successful purchases or the listener. STEPS TO REPRODUCE https://avliscoding.com/storekittest.zip Launch app Select "Open Purchase Sheet" Start trial Quit app, enable "Ask to Buy" in StoreKit file configuration settings Restart app. Select Purchase (will give a pending message in response) Close sheet Reopen sheet The app now believes it has made that purchase even though the purchase is still "Pending" in Xcode.

Family Controls: Can Screen Time performance determine StoreKit promotional-offer eligibility? I'm developing an iOS app that helps individuals reduce recreational screen time. The app would use DeviceActivityMonitor to evaluate whether users meet their own screen-time goals. Users who succeed could redeem a discounted one-month subscription through StoreKit promotional offers. The calculation would occur locally on the user's device. No raw usage data, app names, or browsing history would be transmitted. Two questions: Is it permissible under the Family Controls framework's data-use restrictions to use on-device activity outcomes to determine eligibility for a discount on the same app's subscription? Can the resulting discount tier or promotional-offer identifier be sent to our server solely to authorize the StoreKit offer, without violating those restrictions? I'd appreciate clarification from Apple staff about this specific use case before implementing it.

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.

Hello App Review team and fellow developers, Our Padel Tempo: Padel Score iOS 1.0 submission has been in Waiting for Review for nearly five days after a metadata-only resubmission, and I would like to make sure that nothing else is required from our side. App: Padel Tempo: Padel ScoreVersion: iOS 1.0Submission ID: cbc83032-2f7a-4f80-bc2c-e54a5c9f68b3Resubmitted: October 26, 2026 at 5:04 PMCurrent status: Waiting for Review What happened Our initial submission was reviewed on October 26. We received an automated App Review message regarding the auto-renewable subscriptions Premium Monthly and Premium Yearly. The only issue identified was a missing functional link to the standard Apple Terms of Use (EULA) in the App Store metadata. We corrected the issue immediately: added the standard Apple Terms of Use (EULA) link to the App Description; made sure the required metadata was complete; no binary changes were necessary; resubmitted the same app version approximately 12 minutes after receiving the review message. Since then, the submission has remained in Waiting for Review. Why I am posting I understand that review times can vary, and I am not asking to skip the queue. I would simply like to confirm that: the resubmission is correctly queued for App Review; the previous metadata issue is considered resolved; no additional action or information is currently required from us. Since this was a metadata-only correction following an already completed first review, I wanted to make sure the resubmission did not end up waiting because of something we may have missed. If App Review needs any additional information, screenshots, test instructions, or clarification, I can provide it immediately. Thank you for your time, and I would also appreciate hearing from other developers who have recently experienced longer-than-usual Waiting for Review times. Best regards,MykolaPadel Tempo

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 !

After updating to the public release of Xcode 27.2 (27B52), I'm seeing this warning in Apple's StoreKitTest framework: **File**: `SKTestTransaction.h`, line 34 **Warning**: `'SKPaymentTransactionState' is deprecated: first deprecated in iOS 18.0` The warning recommends using `PurchaseResult` from `Product.purchase(confirmIn:options:)`. Is this a known issue?

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.

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.