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

Hello, We would appreciate some guidance regarding an unexpected StoreKit currency result in a TestFlight build. Our iPhone language and region are both set to France. The Sandbox tester is also configured for France, and our subscription products have French availability and pricing configured in App Store Connect. In the TestFlight build we diagnosed, StoreKit reports the current storefront as France with EUR: storefront=FRA/143442/EUR However, all 10 subscription products are returned with USD product metadata: products=10/10 formatCurrencies=USD localeCurrencies=USD error=NONE Example: formatCurrency=USD locale=fr_US_currency_USD localeCurrency=USD display=1,99 $US price=1.99 We first observed this through Flutter's in_app_purchase integration. To determine whether the Flutter plugin was involved, we added a native StoreKit 2 diagnostic to the same TestFlight build. The native result was identical: receipt=sandboxReceipt storefront before=FRA/143442/EUR storefront after=FRA/143442/EUR products=10/10 formatCurrencies=USD localeCurrencies=USD error=NONE The issue appears specific to the TestFlight distribution. When the application is installed directly from the development computer, prices are returned in euros on the same device. We also tested with the regular Media & Purchases account signed out and a French Sandbox tester connected. Once the products loaded successfully, StoreKit still returned USD metadata. In another configuration, the application displayed the USD price while Apple's purchase sheet displayed the price in euros. We are using the price and formatting information returned directly by StoreKit. We do not want to infer the currency from the device region or perform a client-side currency conversion, because StoreKit should remain the authoritative source. Could you please help us understand: Is it expected for Storefront.current to report FRA/EUR while Product.priceFormatStyle.currencyCode, its locale currency, and Product.displayPrice use USD? Could a TestFlight or App Store Connect configuration cause product metadata to use a different currency from the current storefront? Is there another account, availability, pricing or distribution setting that we should verify? Is there a recommended way to refresh or invalidate the product metadata used by a TestFlight installation? We have already filed Feedback Assistant report FB24723329, which is currently under investigation. Thank you very much for any clarification or additional diagnostic steps you can suggest.

Our app, Unscroll, has an auto-renewable monthly subscription. Users set a daily time limit inside the app. We plan to give a monthly subscriber a free next month through a promotional offer (type: Free, duration: 1 month) when they stayed within their limit on at least 20 days of the current subscription period. Eligibility is computed on the device from the app's own measurement of time spent inside Unscroll. We do not use Screen Time, Family Controls or DeviceActivity data for it. Every paid feature stays available to every subscriber. The free month is an extra, and nothing depends on it. The offer is shown inside the app; notifications are not required. The full monthly price is shown first on the subscription screen, with the condition written next to it. Questions: Is this use of promotional offers acceptable under App Review Guidelines 3.1.1, 3.1.2 and 3.2.2(x)? Can the same customer redeem the same free promotional offer again in later periods (once per qualifying period)? For an active monthly subscriber, does a free promotional offer for the same product take effect at the next renewal date? Thank you.

DTS recommended that we post this question in the Developer Forums. We would like clarification on the supported production behavior of originalTransactionId in the App Store Server API, particularly after a subscription expires and the customer resubscribes. Our main backend design question is: Can we continue using a stored originalTransactionId to identify and retrieve subsequent subscription activity within the same subscription group, or must we support discovering and associating new identifiers? Integration context Our backend uses: GET /inApps/v1/subscriptions/{transactionId} GET /inApps/v2/history/{transactionId} App and subscription details: Bundle ID: com.lgeha.nuts Subscription group identifier: 22350255 Product A: thinq_g_unlimitedpro Product B: thinq_g_single We use originalTransactionId as a key for subscription records and associate those records with user accounts in our service. We do not use it as an identifier for the Apple Account itself. Please assume the same Apple Account and app, with both products in the same subscription group, using ordinary auto-renewable subscriptions without a special subscription migration. This question concerns the identifiers and lookup behavior exposed to our backend by the App Store Server API. Sandbox observation and scope During sandbox testing, purchase history was cleared, and a new originalTransactionId was subsequently observed. We understand that this observation involved a sandbox history reset and does not establish production behavior. Our questions below concern production behavior without any purchase-history reset. Preservation across subscription lifecycle events For each scenario below, is originalTransactionId guaranteed to remain unchanged for subsequent transactions, or can Apple assign a different value? Automatic renewal of the same product. An upgrade, downgrade, or crossgrade between products A and B while the subscription is active. Turning off automatic renewal, then re-enabling it before expiration. Turning off automatic renewal, allowing the subscription to expire, and later resubscribing to the same product. Turning off automatic renewal for product A, allowing it to expire, and later subscribing to product B within the same subscription group. Scenarios 4 and 5 are our primary concern. We would like to distinguish commonly observed behavior from supported guarantees that a backend can rely on. Conditions for a new identifier after expiration For scenarios 4 and 5, can a new purchase legitimately receive a different originalTransactionId in production despite the Apple Account, app, and subscription group remaining unchanged? If so, what conditions determine this? Does it depend on: Time elapsed since expiration. Billing retry or billing grace-period status or history. Whether the purchase uses StoreKit 1 or StoreKit 2. Whether the customer resubscribes inside the app or through App Store subscription management. Our concern is whether these factors affect the identifiers subsequently returned by the App Store Server API. Stability of an existing transaction Separately from a new purchase receiving a new identifier, if the same transactionId is retrieved at two different times, is its associated originalTransactionId guaranteed to remain unchanged? Can an Apple-supported correction process change that association, or should such a result be treated as an inconsistency and reported through Feedback Assistant? This question concerns the same returned transactionId, rather than a different latest transaction returned by a subsequent status query. We have not confirmed such a change in production. Lookup behavior using a previously stored identifier If resubscription can create a new originalTransactionId, how does that affect each endpoint? For GET /inApps/v1/subscriptions/{transactionId}: Can a request using the previous originalTransactionId return the current status of a later resubscription with a different originalTransactionId, assuming the same Apple Account, app, and subscription group? Or must the backend obtain the new identifier separately? For GET /inApps/v2/history/{transactionId}: Can a request using the previous originalTransactionId return transactions from that later resubscription, assuming all applicable pages are retrieved and no filters exclude those transactions? Please clarify any endpoint-specific guarantees or limitations on using an older identifier to discover subsequent subscription activity. Backend account association If resubscription can create a new identifier, should our backend support multiple originalTransactionId values for one service user within the same subscription group? Is there a documented server-side relationship that links subscriptions with different originalTransactionId values? Alternatively, should that association rely on an application-managed identifier such as appAccountToken, where available? Please clarify any limitations, especially for resubscriptions initiated outside the app. Related discussions We reviewed these discussions as background: Transaction ID Misassociation in IAP Subscription API (https://developer.apple.com/forums/thread/777433) original_transaction_id associated to web_order_line_item_id of auto-renewable subscription changed (https://developer.apple.com/forums/thread/778301) We do not assume that these reports establish supported behavior or share the cause of our sandbox observation. Could Apple clarify the supported preservation or replacement rules, particularly after expiration and resubscription, and point us to documentation describing the behavior a backend can rely on? If investigating a specific inconsistency requires a separate Feedback Assistant report, please indicate which server-side request and response details should be included. 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!

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!

I am trying to test a non-consumable in-app purchase in the Apple sandbox using a development-signed, sandboxed macOS app. The app is launched from Finder rather than from an Xcode scheme. A purchase attempt instead produces a transaction that my diagnostic build identifies as an Xcode test transaction. Environment macOS 27.1; Xcode 27.2 (27B52). StoreKit 2; native Swift code called by an Electron macOS app. The app has an Apple Development signature and a development provisioning profile that includes this Mac. The app uses a fixed app bundle ID and a non-consumable product ID configured in App Store Connect. What I observed After I removed the app’s existing test transaction in Xcode’s transaction manager, the diagnostic app found no current entitlement for the product. I attempted a purchase from the Finder-launched app. There was no Apple account login or purchase confirmation prompt. A new transaction appeared in Xcode’s transaction manager, and the app returned its own verificationFailed error. The diagnostic build later found a verified current entitlement for this product and app bundle whose Transaction.environment was .xcode. The app intentionally rejects Xcode test transactions for production entitlement access. I quit Xcode and launched the app again from Finder. After removing the app’s test transaction, the same result occurred on another purchase attempt. The app’s verificationFailed label is used both when StoreKit returns an unverified result and when my own transaction acceptance checks reject it. Therefore, that label alone does not prove that StoreKit signature verification failed. I have not confirmed an actual Apple sandbox purchase or restore. Earlier automated StoreKitTest work on this machine used the same app product identifier; the current tests use a separate test-only identifier. I do not know whether the earlier tests are related. I do not yet have a focused minimal reproduction project. The app checks the product ID, app bundle ID, non-consumable type, and revocation date; in builds without the test-only flag it also rejects .xcode transactions. Its diagnostics iterate Transaction.currentEntitlements and report .xcode only for a verified matching transaction. Questions What determines whether a development-signed macOS app launched outside Xcode uses Xcode StoreKit testing or the Apple sandbox? What non-destructive checks can identify any remaining Xcode/StoreKitTest configuration associated with this app or process, without deleting unrelated apps’ transactions or resetting shared test data? What is the recommended way to transition this app to an Apple sandbox account and confirm the transaction environment before testing purchase and restore? No account details, receipts, certificates, provisioning profiles, user files, or transaction identifiers are included. I can provide a focused reproduction or additional diagnostics if needed, after preparing them.

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.

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

My app, At My Table, has a subscription issue on one TestFlight device. Version: 1.0.0, Build 26 Library: expo-iap 6.4.1 Product: com.atmytable.premium.monthly Affected device: iPhone 15 Plus, iOS 27.0.1 Tapping Subscribe displays Apple’s “You’re currently subscribed” message. However, the app reports zero active subscriptions, no current entitlement, no latest transaction, and zero available purchases. Restore Purchases prompts for Apple sign-in and then fails with: service-error: The operation couldn’t be completed. (SKInternalErrorDomain error 14.) The error persists after restarting the phone and testing separately on Wi-Fi and cellular. Another tester’s iPhone 14 Pro Max, running the same iOS version and TestFlight build, recognizes its active membership and saves changes successfully. What diagnostics would help distinguish a sandbox account or device issue from an integration problem? I have screenshots but do not yet have a minimal native Xcode reproduction.

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.

After a REFUND_REVERSED notification, with no new purchase or renewal, is the transaction’s signedDate in signedTransactionInfo from Get All Subscription Statuses guaranteed to be strictly later than the reversal notification’s outer signedDate? Or can the API return an active subscription with a transaction signedDate equal to or older than the reversal’s timestamp? We’re deciding whether a strictly newer timestamp is a reliable condition for restoring access.

Device: iPhone 11, iOS 26.5 Build: development build, built with Xcode 26.6, iOS SDK 26.5, using the StoreKit sandbox Problem For a non-consumable in-app purchase, Product.displayName and Product.description (StoreKit 2, fetched with Product.products(for:)) always return the English (U.S.) localization, which is the product's primary language, instead of the approved Portuguese (Brazil) one. The App Store purchase sheet shows the English (U.S.) display name too. Setup The product is Approved. Its English (U.S.), Portuguese (Brazil) and Indonesian localizations are all Approved in App Store Connect. The app's App Store localizations include Portuguese (Brazil). The iPhone's preferred languages are Português (Brasil) first, then English (U.S.) and Svenska. The app's language in Settings → Apps → [app] → Language is Português (Brasil). The app's Info.plist declares pt-BR in CFBundleLocalizations. The sandbox tester was newly created in App Store Connect with Brazil as its country or region. Prices come back in BRL, so the Brazil storefront is in use. Questions TN2413 says the language follows the test account's store, and an App Store Commerce Engineer said in thread 756918 that a sandbox account set to the desired country should return that country's language. Our setup matches both, yet we get the primary language. Is localized product metadata expected to be served in the sandbox environment? If so, what else determines the language StoreKit returns, and why would it fall back to the primary language when an approved localization exists for the storefront's default language? How can we verify product localizations before releasing to production?

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.

Hello, I’m investigating a persistent StoreKit 2 restoration issue in My Drop Music. I would appreciate help identifying the cause or collecting more useful diagnostics. Environment: iPhone 17, iOS 26.6.2 TestFlight version 6.22.60 (62260.12) Transaction environment: Sandbox Storefront: USA, currency: USD What works: Product.products(for:) returns both expected non-consumable products. The full-unlock product returns a price of USD 6.99. The free trial product returns a price of 0. Transaction.currentEntitlements returns verified transactions for both products, with no unverified transactions reported. The app recognizes full access. What fails: When I tap “Restore purchases,” AppStore.sync() fails with StoreKitError.unknown. An Apple authentication prompt appears during restoration, but the operation still fails after submitting credentials. Latest diagnostic output: My Drop Music 6.22.60 (62260.12) iOS 26.6.2 Storefront=USA; currency=USD AppStore.sync=failed Kind: StoreKitError.unknown Reference: StoreKit.StoreKitError:2 Before: cached app state: full=true; trialPresent=true After: full=1; trial=1; unverified=0; environment=Environment(rawValue: “Sandbox”) Tests already performed: Reproduced over both Wi-Fi and cellular. Signed out of and back into Media & Purchases. Modified the restoration flow so AppStore.sync() is the first awaited operation after the user taps Restore. Entitlement and storefront diagnostics are collected afterward. The failure persists. Created a separate Sandbox tester. Attempting authentication with that tester produced a system alert saying “Verification Failed — An unknown error occurred.” I have not established whether that is the same underlying issue. I currently have only one iPhone available for testing. Does this pattern suggest any specific account, device, or integration checks? Which device logs or additional error details would help distinguish a Sandbox authentication issue from an app integration issue? I am not assuming this is an Apple bug; I’m trying to determine the cause. Thank you!

Filed as FB24069273. Sandbox POST /inApps/v1/notifications/test consistently returns 404 {"errorCode":4040007} for our app (Apple ID 6765662617), although GET /v1/apps via the App Store Connect API confirms both subscriptionStatusUrl and subscriptionStatusUrlForSandbox are set (V2). With the same JWT, sandbox POST /inApps/v1/notifications/history returns 200 with an empty history — so the key and app resolve correctly. No organic sandbox notifications have ever been delivered, despite active TestFlight sandbox subscription activity. Exhausted remediations (4040007 persists after each, with 30-60+ minute waits): Re-saving the URLs in the App Store Connect UI (two locales) Deleting and re-adding the Sandbox URL PATCH /v1/apps setting the sandbox URL + version V2 twice, with two different valid endpoints (verified by GET each time) Removing the Sandbox URL entirely to rely on the documented Production fallback Deleting BOTH URLs, waiting a full hour, and re-creating them from scratch Testing with both an App Store Connect team key and a freshly generated In-App Purchase key — identical results Endpoints are publicly reachable (HTTPS, TLS 1.2+, port 443). Production App Store Server API returns 401, which we understand is expected for an app not yet released. This looks like a desync between App Store Connect metadata and the notification delivery registry consulted by the test-notification endpoint. Any help 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!