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

Our first submission has now been rejected under Guideline 2.1(b), with the message: "the in-app purchases do not load successfully." Each review was performed on an iPad Air 11-inch (M3) running iPadOS 26.6. The app sells only auto-renewable subscriptions. We cannot reproduce the failure, and we have verified every part of the configuration we can think of. WHAT WE VERIFIED (via the App Store Connect API, not just the UI) Two subscriptions in one group, state READY_TO_SUBMIT Product IDs exactly match what the app requests Available in 175 territories, including the United States Prices set, en-US localizations present for both products and for the group App review screenshots attached to both, state COMPLETE Both subscriptions are included in the review submission (READY_FOR_REVIEW) Paid Apps Agreement: Active. Bank account: Active. Tax forms: Active. WHAT WORKS On our own devices, installed via TestFlight (sandbox environment), the products load correctly and a purchase completes and activates as expected. This works on both a real Apple ID and a Sandbox Tester account. WHAT WE OBSERVED FROM THE REVIEW SESSION We use RevenueCat. Their server-side API returns our offering with both packages and the correct product identifiers, so the offering metadata is fine. Our backend also shows that the reviewer's session reached our servers and signed in successfully at the review timestamp, so the device had working network connectivity. That leaves StoreKit itself returning no products on the reviewer's device, which is what empties the offering. QUESTIONS Are there known conditions under which StoreKit returns no products in the App Review sandbox for subscriptions that are in "Ready to Submit" and are attached to the same submission as the binary? For an app that has never been approved, is product loading during review handled differently from a normal sandbox session on a released app? Is there any way to obtain diagnostics from a review session, or to ask the reviewer for a screenshot of the failing screen? Replies in Resolution Center so far have only repeated the original rejection text. Is there anything specific to iPadOS 26.6 that could affect StoreKit 2 product lookups? For the next submission we have added a timeout and automatic retries around the product lookup, plus a visible retry control instead of a spinner, in case the failure is a transient cold-start timeout. But we would rather understand the actual cause than keep guessing. Any pointers appreciated.

Every sandbox purchase of our auto-renewable subscriptions cancels right after AuthKit sign-in succeeds. It's blocking our 1.0 release. Filed as FB25469063, no reply yet. Capacitor iOS app, bundle io.xrplive.app, 1.0.0 (TestFlight), products io.xrplive.app.pro.monthly / .yearly, iPhone 17 Pro Max on iOS 27.0.1, StoreKit via @capgo/native-purchases. Console on every attempt: (1) AMSAuthKitUpdateTask: "The AuthKit authentication succeeded." (2) Then: Error Domain=AMSServerErrorDomain Code=-5000 UserInfo={failureType=-5000, m-allowed=false, cancel-purchase-batch=true, customerMessage=Check the account information you entered and try again.} Also AMSErrorDomain Code=100 (Authentication Failed), Code=2 ("Password reuse not available for account"), and a 401 from sandbox.itunes.apple.com/commerce/messages/app/inbox. We already fixed a purchase(confirmIn:) presentation issue. This failure is in sandbox verification after a successful sign-in, which we can't fix from the client. Is -5000 with cancel-purchase-batch a known sandbox account or commerce issue? Is there a sandbox tester or storefront state that fixes it when AuthKit succeeds but verification still fails?

I am seeking guidance from an Apple App Store Connect or StoreKit engineer regarding a submission issue that prevents the initial release of my standalone watchOS application. Application configuration App: My Curl Clock Developer: Frostline Labs Inc. Platform: Standalone watchOS (watch-only) App version: 1.0, Build 5 Architecture: Xcode-generated iOS wrapper containing the watchOS application Monetization: Two auto-renewable subscriptions (Basic Annual and Pro Annual) Subscription group: My Curl Clock Background My application was previously rejected under App Review Guideline 2.1(b). App Review instructed me to submit the subscriptions together with a new app binary. I have configured both subscription products and their subscription group in App Store Connect. I then created a draft submission containing: My Curl Clock Version 1.0 (Build 5) Basic Annual subscription Pro Annual subscription My Curl Clock subscription group However, App Store Connect prevents submission with the following validation error: In-app purchases and subscriptions are currently not supported on Apple Watch. To submit this app version, you must remove all in-app purchases or subscriptions from this submission. Conflicting requirements Apple's App Store Connect documentation states that the first auto-renewable subscription must be submitted with a new app version. The same documentation also states that in-app purchases and subscriptions cannot be included in an Apple Watch app-version submission. Apple's documentation for independent watchOS applications describes an iOS wrapper architecture and supports purchases directly on Apple Watch. These requirements appear to create a circular submission problem: The first subscription requires an app version. App Store Connect blocks adding subscriptions to the Apple Watch app-version submission. Removing the subscriptions conflicts with App Review's instructions. Steps already taken Confirmed that both subscriptions and their subscription group are included in the draft submission. Contacted Apple Developer Support (Case 103004272249). Provided the exact validation error and supporting screenshot. Submitted a formal report through Feedback Assistant (FB25450734). Developer Support has recommended posting in the Developer Forums but has not identified a supported submission procedure or workaround. Questions for Apple engineers What is the supported procedure for submitting the first auto-renewable subscriptions for a standalone watchOS application? Can the initial subscription group and products be submitted separately or associated with the app version through an alternative supported process? Does App Store Connect require a functional iOS companion app for the initial approval of subscriptions, despite StoreKit supporting purchases directly on Apple Watch? Is this a known App Store Connect limitation, particularly following the changes to the submission process in July 2026? Is there a supported workaround that allows compliance with both App Review's instructions and App Store Connect's validation requirements? References Apple — Creating independent watchOS apps: https://developer.apple.com/documentation/watchos-apps/creating-independent-watchos-apps Apple — Submit an In-App Purchase: https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/submit-an-in-app-purchase Related developer discussion: https://developer.apple.com/forums/thread/842983 Feedback Assistant: FB25450734 I would appreciate guidance from an Apple engineer familiar with App Store Connect submissions and StoreKit on watchOS. At present, this issue completely prevents the initial release of an otherwise completed application.

We are experiencing the same issue with two independent native iOS apps on an iPhone running iOS 27.0.1, using TestFlight in France. Our annual subscription displays US$34.90 instead of €39.90, and our non-consumable purchase displays US$5.99 instead of €6.99. Both apps displayed the correct EUR prices during local Xcode testing. In TestFlight, Apple's native purchase sheets still show the correct EUR prices, and both purchases work successfully. We have contacted Apple Developer Support (case 103017935062). As this issue is delaying the time-sensitive release of our educational app, could Apple confirm whether a workaround is available or whether a fix is planned? https://developer.apple.com/forums/thread/845478 Thank you.

Hello! I'm glad that Xcode 27.2 could fix many StoreKit testing issues (27.2 release notes). While refreshing my unit tests for Xcode 27.2, I noticed a new behavior of "Ask to Buy" transactions. Since Xcode/iOS 27.2 at least, it seems that declining an Ask to Buy request in an SKTestSession makes StoreKit 2 record a purchase. Is this the intended new behavior? To reproduce: let session = try SKTestSession(configurationFileNamed: "ConfigFile") session.askToBuyEnabled = true session.resetToDefaultState() session.disableDialogs = true session.clearTransactions() let result = try await product.purchase() // .pending let pending = session.allTransactions().first! // state .deferred try session.declineAskToBuyTransaction(identifier: pending.identifier) // a few seconds later for await t in Transaction.all { print(t.unsafePayloadValue) }In my case the purchased product is an auto-renewable subscription with a free-trial intro offer, from a local .storekit file, in a unit test run inside a host app. After the decline, I could observe the following iOS 26.2 simulator SKTestTransaction.state = .deferred Transaction.updates : nothing Transaction.all : empty iOS 27.2 simulator SKTestTransaction.state = .failed Transaction.updates : emits a transaction Transaction.all : 1 transaction: ownershipType = .purchased, reason = .purchase, no revocation, expires at the end of the trial. The test session marks the request as failed, yet StoreKit 2 reports an active subscription... My understanding was that a declined "Ask to Buy" request never produces a transaction. With the new behavior, apps relying on Transaction.all or currentEntitlements would grant access that the Apple user refused... Is the new behavior expected? Or is it a regression (and is it limited to SKTestSession) ? Thanks for your help!

Since November 5, in-app subscriptions have suddenly stopped working in all three of my apps on the App Store. Everything worked perfectly before, and no changes were made to the apps. The subscription purchase buttons no longer display prices, only a dash ("–"). Existing apps can still be downloaded normally. I reproduced the problem in Xcode on my own device. StoreKit reports: STOREKIT: Received 0 products STOREKIT: Invalid IDs = ( "TEE_year", "TEE_month", "TEE_week" ) All subscription products are still configured in App Store Connect, and the agreements appear to be active. Interestingly, the problem started around the time I accepted updated Apple agreements and changed my address in my developer account. I don't know whether this is related. Several customers have already independently reported the same problem, so this is not limited to my own device or Apple ID. I strongly suspect an App Store Connect or StoreKit backend issue rather than an app-specific programming error. I've contacted Apple Developer Support (case ID is 30000008123797) but haven't received a solution yet. Has anyone else experienced subscriptions suddenly becoming unavailable across multiple apps? Could this be related to updated agreements or account information?

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.

Our app's auto-renewable subscription (Product ID: istanbul.membership.monthly, Bundle ID: com.mehmetozenen.ustaistanbulapp) has been returning zero products from Product.products(for:) since August 24, 2026, blocking 100% of new iOS subscriptions on our live production app. Verified correct on our side: Subscription status: Approved Paid Applications Agreement: Active (continuously since Feb 2026, no gaps) Territory pricing: set, including Turkey Product ID matches exactly, correct app No changes to Agreements/Tax/Banking around the failure date Steps to reproduce: Call Product.products(for:) (or via react-native-iap's fetchProducts) with SKU istanbul.membership.monthly, type auto-renewable subscription. Result: empty product array, no error thrown. Purchase sheet never appears since there is no product to purchase. Reproduced on: 4+ independent physical iOS devices Multiple different Apple IDs Both Sandbox and Production StoreKit environments (identical failure in both) Both Wi-Fi and cellular networks A historical app build (from before Aug 24) that was never modified and worked correctly as recently as Aug 23 — ruling out any client-side code cause This same product worked correctly as recently as 2026-08-23 (server-side purchase verification log confirms a real successful transaction that day). It broke starting 2026-08-24, with no corresponding change on our end. I've already opened a Developer Technical Support case (Case-ID 21790415) and submitted a full sysdiagnose with reproduction timestamps, but have not received a substantive update in over a week. Posting here in case others have hit the same regression, or in case anyone from Apple can help escalate. Has anyone else seen Product.products(for:) / fetchProducts silently returning empty for an otherwise valid, Approved auto-renewable subscription starting around late August 2026?

Hello, I am developing a wellness app out of Pakistan with an initial regional launch, expanding globally afterward. The app features a hybrid business model that combines physical commerce, food delivery, and human service consultations. I want to ensure my payment processing strategy aligns perfectly with App Store guidelines before I build the billing infrastructure. Our app provides three distinct offerings: Live Human Nutritionist Plans: Users purchase monthly, quarterly, or 6-month consulting plans. A certified, real-life human nutritionist reviews their profiles and manually drafts customized diet templates (Weight Loss, Muscle Gain, Women's Health/PCOS management). Fresh Cooked Meal Delivery: Users can subscribe to have macro-counted meals (rice, healthy proteins, etc.) cooked and delivered fresh to their doorstep daily based on their chosen plan. E-Commerce Health Store: An in-app storefront where users purchase physical shelf-stable goods like premium peanut butter, organic honey, and organic dry fruits shipped via local courier services. My Payment Route Strategy: • For Offerings 2 and 3 (Meals & Physical Marketplace Goods): Since these are explicitly physical goods and real-world delivery logistics, we intend to integrate third-party mobile payment gateways (Local credit/debit card processors and mobile wallets) in compliance with Guideline 3.1.5(a). • For Offering 1 (Human Nutritionist Consulting): Under Guideline 3.1.3(d) for Person-to-Person Services, we intend to also route these through our third-party checkout since real human professionals manually evaluate and generate these programs rather than a software algorithm. Questions for the Community & Apple Engineers: Does Apple allow a single unified shopping cart using a third-party gateway if a user checks out with physical goods (e.g., peanut butter) and a human service plan simultaneously? Or do we need to separate the checkouts? Because the app deals extensively with physical delivery and human services, is it permissible to bypass Apple In-App Purchases completely across all three tiers, or will Apple view the custom-drafted PDF diet templates as digital content under 3.1.1? If we decide to use Apple IAP for the Human Nutritionist subscription plans out of developer convenience, can we safely maintain our third-party gateway side-by-side inside the app exclusively for the meal deliveries and physical pantry products? Any insights from developers who have successfully launched hybrid/physical-delivery apps would be highly appreciated!

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.