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

On both iOS & macOS 27.2 Beta 2 the call: let token = try await MusicDataRequest.tokenProvider.developerToken(options: [.ignoreCache]) is throwing an error. I can reproduce this on all of my 27.2 Beta 2 devices and I have users worldwide reaching out to me with this issue. The error that gets thrown is: Unknown error "Error returned from daemon: Error Domain=com.apple.accounts Code=9 "(null)"" Have raised FB24895830.

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!

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!

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.

Hi, I am designing a database schema to store App Store transaction data for our backend system, and I have a question regarding the uniqueness of transactionId. According to the documentation (apple.com), transactionId is a unique identifier for a transaction. However, it is not explicitly clear whether this uniqueness is guaranteed across different environments.Could you please clarify the following points? Is transactionId guaranteed to be unique across both the Production and Sandbox environments? (i.e., Is there any possibility that the exact same transactionId is generated in both environments?) For database design, is it safe to use transactionId alone as a Primary Key? Or is it strongly recommended to use a composite key consisting of both environment and transactionId? Any insights or best practices from Apple engineers or the community would be highly appreciated.Thank you.

For our app, we saved a sandbox App Store Server Notifications URL with V2 enabled and independently read the configuration back. A subsequent test-notification request returned HTTP 404 / 4040007. An authenticated sandbox notification-history request shortly beforehand returned HTTP 200. We restored the original settings after collecting diagnostics. The recorded failure is covered by Feedback Assistant report FB24885397. What could explain this discrepancy, and what additional diagnostics would help Apple investigate?

-(void)paymentQueue:(SKPaymentQueue*)queue updatedTransactions:(NSArray<SKPaymentTransaction*>*)transactions In the sandbox environment this is called continuously every time my enters the foreground. I call -finishTransaction on approximately 22 transactions. Confirmed by: NSUInteger finishCount = 0; NSUInteger transactionCount = transactions.count; for (SKPaymentTransaction *aTransaction in transactions) { // Check state..if purchased or restored.. [[SKPaymentQueue defaultQueue]finishTransaction:aTransaction]; finishCount++; // Post notification telling everyone here! } NSLog(@"Finsihed %lu of %lu",finishCount,transactionCount); The log at the bottom says - finished 22 of 22 transactions. But every time the app enters the foreground the -paymentQueue:updatedTransactions: is called again with another batch of transactions. How Over and over again. Not sure how this is possible but the transactions seem to never clear from the queue. I hope this may be limited to the sandboxed environment. In this loop after finish transaction is called I then post a notification which kicks off receipt validation...and then I even store something in the keychain. Doing this work over and over again in a tight loop is very unexpected and causes my app to lock up. Yea I know this is deprecated. Will move to my Objective-C storekit 2 wrapper but breaking SK1 on purpose seems kind of um, rude. Hope this is only in the sandbox environment. This app got sidelined even though I got some plans to resurrect it in the back of my head.

Live App Store app. Since 2026-09-01 PDT, StoreKit no longer returns our approved auto-renewable subscriptions on signed builds. The same SKUs load normally in Xcode when using a local StoreKit configuration file. New purchases are blocked. Monthly auto-renewals that were collecting normally through August 31 began failing their renewal attempts starting September 1, with all observed attempts entering Billing Grace / Billing Retry. App Name: Moonlit Bundle ID: moonlit.reading Versions affected: 1.1.1 — App Store version that was already live and working normally before September 1 1.1.2 — subsequently released to the App Store specifically to test whether a fresh production release would restore StoreKit behavior. It did not. Approved auto-renewable subscriptions, both in the same subscription group: moonlit.monthly.subscription moonlit.yearly.subscription Paid Apps Agreement, banking, and tax are Active in App Store Connect. We use an explicit App ID with the In-App Purchase capability enabled. Distribution builds do not contain a StoreKit Configuration file. The local .storekit file is used only for Xcode Run. Through August 31, 2026, Product.products(for:) and SubscriptionStoreView returned both SKUs and their prices correctly on production builds. Beginning September 1, 2026, and continuing through at least September 11: Every production paywall we can measure receives an empty StoreKit catalog with no product IDs, no prices, and no thrown StoreKit error. SubscriptionStoreView remains on its loading state. Our Terms / Privacy footer still renders because it does not depend on StoreKit. showManageSubscriptions / manageSubscriptionsSheet also hangs or fails to connect on the same signed builds. App Store Connect subscription events for the monthly SKU show a complete reversal beginning September 1. All observed renewal attempts in the affected window entered Grace from Paid, with no successful renewals, whereas the comparable August window showed normal successful renewals. Sales reports show no IAP proceeds for the affected September window. App downloads continue to appear normally, so the app itself remains available for sale. What still works Xcode + local StoreKit Configuration: Both products load Prices display The purchase sheet presents normally Analytics and logging continue to function, so this is not an app crash or missing paywall UI. The subscriptions are not Rejected and are not in Developer Action Needed. TN3186 / TN3188 checks have already been completed. This appears similar to other recent reports where App Store Connect contains a valid product catalog but StoreKit does not serve the products to signed builds: https://developer.apple.com/forums/thread/838171 https://developer.apple.com/forums/thread/841722 https://developer.apple.com/forums/thread/838773 https://developer.apple.com/forums/thread/836183 Developer Support case: 102959783559 Request Could an App Store Commerce or StoreKit engineer verify whether the app-to-IAP catalog association for moonlit.reading is populated and being served correctly on Apple’s side, and refresh or reprocess the production catalog if appropriate?

Hello, We have a critical, release-blocking issue with the StoreKit External Purchase Link entitlement (com.apple.developer.storekit.external-purchase-link) and would appreciate an engineer's help. We submitted a request for the External Purchase Link entitlement earlier this year. After no updates since February, we followed up with Apple Developer Support. Support confirmed the entitlement has already been granted to our account, but advised that Xcode is unable to display/select it and directed us to Feedback Assistant / the Developer Forums. However, the capability still does not appear as enabled on our App ID, and it is not included in our provisioning profiles. Current impact We cannot build or sign the app. Automatic signing fails because the provisioning profile is missing the entitlement, which blocks both development builds and release. What we're seeing Xcode – Signing & Capabilities Automatic signing fails with: Provisioning profile "iOS Team Provisioning Profile: ...." doesn't include the StoreKit External Purchase Link capability. StoreKit External Purchase Link capability needs to be assigned to your team and bundle identifier by Apple in order to be included in a profile. And: Entitlement com.apple.developer.storekit.external-purchase-link requires approval from Apple to include in a profile. Please request access to the associated capability. To continue building for device during request processing, remove entitlement and add upon approval. Provisioning profile detail (Xcode) The managed profile shows: Capabilities: 4 Included, 1 Missing → Missing StoreKit External Purchase Link, and Entitlements: 7 Included, 1 Missing → Missing com.apple.developer.storekit.external-purchase-link. Local entitlement configuration The entitlement is correctly added in our Xcode project, but builds fail due to the missing support in the provisioning profile. Apple Developer Portal – Edit App ID Configuration In the capability list, "StoreKit External Purchase Link" shows "No Requests" and cannot be selected/enabled. (The separate "StoreKit External Purchase" entry shows "No Status".) So the capability is not actually attached to the App ID on the portal, despite Support confirming the grant at the account level. What we've already tried Confirmed the entitlement is present in the app's .entitlements file. "Try Again" / regenerating the automatically managed provisioning profile in Xcode. Verified with Apple Developer Support, who confirmed the grant but could not enable it in Xcode/portal and referred us here. Question / request Since Support confirms the entitlement is granted at the account level but it does not appear as an assignable capability on the App ID or in the provisioning profiles, could an engineer please: Confirm whether the External Purchase Link entitlement is actually associated with our Team and this specific App ID, and Assign/enable the capability so it can be selected on the App ID and included in the provisioning profile? Environment: Xcode version: 27.0 macOS version: 26.6.2 Screenshots of the Xcode signing error, the provisioning profile detail, the local entitlement configuration, and the Developer Portal capability list are attached. Thank you very much for any assistance.

Hello. I am having trouble because when I send a request to the External Purchase Server API from my own server, I receive a 400 error, but the response does not specify a reason. ・Sent data (some information is masked with ) marketplaceToken received from the client: eyJhcHBBcHBsZUlkIjo2NzU5MTg2MjcyLCJidW5kbGVJZCI6ImNvbS5IYWJiaXQuQW5hRG9zLlBh**************************************************************************************************************************************************************************************************************************CJ0b2tlblR5cGUiOiJDT1JFX1RFQ0hOT0xPR1kifQ== The content of the Bearer Token used when performing a cancellation operation for this payment transaction: {"iss":"a5******---****-3c08","iat":1790134367,"exp":1790135567,"aud":"appstoreconnect-v1","bid":"com...Pal"} The JWT actually sent: eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6Ikg5N1dOOTRLNjYifQ.eyJpc3MiOiJhNTU*************************************************************************************************************************N0LXYxIiwiYmlkIjoiY29tL********************************************************************************************************************************************************KVfupOI4wW-gMWjHSq2rppbzezTqqiHl0Q The request body actually sent: {"requestIdentifier":"01a0cc52-b3b4-71d4-99c9-e1df27c6193b","externalPurchaseId":"98******---****-****903174ab","status":"NO_LINE_ITEM"} ・Request endpoint (Production) PUT https://api.storekit.apple.com/externalPurchase/v1/reports ・Request endpoint (Sandbox) PUT https://api.storekit-sandbox.apple.com/externalPurchase/v1/reports ・API response response: ( 'status' => 400, 'content_length' => '0', 'body_size' => 0, 'body_position' => 0, 'body_string' => '', ) Whether the request is sent to the production environment or the sandbox environment, a "400 Bad Request" response is returned with an empty response body, making it impossible to determine the cause of the issue. Could you please point out what the problem might be?

Hello everyone, I am encountering a persistent date discrepancy between the subscription expiration date returned by the App Store Server API and the date displayed to the user in the native iOS Settings UI. Our app receives the renewal timestamp via the App Store Server Notifications in UTC milliseconds. For a recent transaction, we received renewalDate = 1820988823000, which is September 15, 2027, at 06:13 AM UTC. Following standard practices, our app formats this UTC timestamp to the user's local device timezone. On a device set to India Standard Time (IST, UTC+5:30), the app correctly displays the expiration as September 15. However, on the exact same device, navigating to iOS Settings > Apple ID > Subscriptions shows the expiration date as September 14. Converting 06:13 AM UTC to Pacific Time (PT) results in September 14 at 11:13 PM PDT. This leads me to suspect that the iOS Settings page anchors its display strictly to Cupertino/Pacific Time, completely bypassing the device's local timezone. I noticed another developer raised this exact issue regarding KST back in September 2025 (Thread ID: 800332), but that post remains unanswered. My questions for the community and Apple Engineers: Can anyone officially confirm if the native iOS Settings > Subscriptions screen intentionally displays dates anchored strictly to Pacific Time (PT) rather than the device's local timezone? If so, how are you handling user inquiries when your app correctly displays the local time, but Apple's UI displays the day prior? Any official references or guidance on this behavior would be greatly appreciated to help us clarify this for our QA teams and end-users.

I need the supported way to obtain an Apple-signed AppTransaction for a development-installed iOS app without initiating an in-app purchase. DTS directed me to ask on the forums. Environment at the time of reproduction Physical iPhone 17e, iOS 27.0 (24A437). Xcode 27.0 (27A266a), macOS 27.0 (26A428). Swift / SwiftUI / StoreKit; version 0.1.0, build 1. Explicit bundle identifier registered with App Store Connect; development signing. The executable signature, embedded profile and installed executable hash were checked. Installed and launched using devicectl. Network access allowed. No StoreKit Configuration file or StoreKitTest session. No IAP products or TestFlight builds. App Store Connect version 1.0: Prepare for Submission. Observed behavior Call try await AppTransaction.shared once. It throws; no verified transaction is returned. From a separate visible button, the user explicitly calls try await AppTransaction.refresh() once. No Apple Account authentication prompt appears. The refresh fails immediately. The refresh error is identified by Swift pattern matching as StoreKitError.systemError: Outer NSError: StoreKit.StoreKitError, code 1 Underlying NSError: SKInternalErrorDomain, code 14 The refresh was recorded at 2026-09-20T15:40:12Z. The original shared probe recorded only the outer error, so I am not claiming its underlying error was identical. I could not find a public definition of the internal error; I am not interpreting it as SKErrorDomain code 14. A Sandbox Test Account was subsequently created, but has not been signed in on the device. The user could not find the Sandbox Apple Account entry. No purchase has been attempted to make that entry appear. The later controlled refresh is described below. The device App Store account differs from the developer account; we have not established this as a cause. Controlled follow-up on 2026-09-22 A separate instrumented copy of RefreshProbe was development-signed, installed and launched with devicectl on the same phone. The user explicitly tapped refresh once at 2026-09-22T14:35:39Z. It again returned StoreKitError.systemError, outer StoreKit.StoreKitError code 1 and underlying SKInternalErrorDomain code 14. The runtime executable SHA-256 matched the locally validated signed binary. No verified AppTransaction was returned. Bounded traversal of the typed underlying error, NSUnderlyingErrorKey and multiple underlying errors exposed only those two domain/code nodes and no allowlisted numeric service status. We did not collect arbitrary userInfo, accounts or signed transactions. App stdout confirmed the result; no storekitd/appstored system log or Xcode IDE launch comparison is claimed. The user confirmed that this attempt also showed no Apple Account login or password prompt. This instrumented copy is separate from the original source ZIP described below. No automatic retry or purchase was performed. VPN-disabled follow-up on 2026-09-22 After the earlier controlled attempt, the user reported using a VPN. For a second controlled attempt the user confirmed that the VPN was disabled and the normal Apple Account remained unchanged. At 2026-09-22T14:48:25Z, one explicit button tap again returned StoreKitError.systemError, outer StoreKit.StoreKitError code 1 and underlying SKInternalErrorDomain code 14. The bounded error tree was identical to the preceding attempt. The user confirmed that no login or password prompt appeared. No verified AppTransaction was returned. The runtime executable hash matched this signed build. The StoreKit call and diagnostic logic were unchanged; only the run identifier and UI label changed to preserve earlier records, followed by installation/relaunch. VPN and account conditions are user observations, not captured network routing. Disabling the VPN did not resolve this attempt; this is not proof that all network causes are excluded. There were no automatic retries or purchases. Questions Is an Apple-signed sandbox AppTransaction supported in this development-install scenario without an IAP product or purchase attempt? What registration and authentication prerequisites apply? What supported diagnostics or corrective steps should we use when refresh fails before presenting authentication? Is there a supported sandbox authentication path for this case without initiating a purchase or signing out of the normal Apple Account? If logs are needed, which narrowly scoped StoreKit logs should we collect? Focused sample A small project with two targets (192 Swift source lines, no dependencies) is ready to provide. The source entry points match the probes used for the observations above. Both packaged targets passed unsigned generic iOS builds, but the newly assembled focused package has NOT itself been re-signed and run on a device. It performs no purchase or photo-library access and does not include credentials, provisioning profiles, device identifiers or signed transactions. I can provide the package to DTS in the existing email request with a link to this forum post. I have not uploaded the package publicly.

Following the guidance in the locked thread "Reporting your App Store Server Notifications issue" (https://developer.apple.com/forums/thread/774053) and a DTS support request on the same topic, I am posting this issue with the Feedback Assistant ID requested there: FB24820430. Summary: This is a content anomaly in Apple-signed App Store Server payloads, not a notification delivery problem — our server receives and verifies every notification; the defect is in the field values themselves. For a stable subset of subscription families, purchaseDate in JWSTransactionDecodedPayload is consistently ~8 hours later than the signedDate of the very same JWS — a purchase recorded as happening after the signed document reporting it existed. Reproducible field comparison inside one and the same Apple-signed JWS: Field relation Affected transactions Unaffected (control) transactions purchaseDate − signedDate +7h54m … +7h59m (never ≤ 0) ≈ 0 (seconds) Webhook arrival at our server ≈ signedDate (seconds to minutes), never ≈ purchaseDate ≈ signedDate originalPurchaseDate carries the same ~8h shift (renewals inherit it) no shift expiresDate − purchaseDate exactly one subscription period exactly one subscription period expiresDate − signedDate period + ~8h period All fields are documented as "UNIX time, in milliseconds". Our iOS client passes StoreKit 2 Transaction.purchaseDate through unmodified; our backend stores the epoch-millisecond values verbatim as UTC with no timezone conversion. These payloads are generated and signed by Apple infrastructure. Scale (production, as of 2026-09-14): ≈710 subscription families (distinct originalTransactionId lineages), ≈2,700 transactions — roughly three quarters of all families with renewals. Affected purchases span early March 2026 to present, ~30–45 new affected transactions per day. Observed across US, PH, ID and GB storefronts and across app build versions. Sandbox is unaffected. Our interpretation (inference, not confirmed): the offset varies between 7h54m and 7h59m rather than being exactly 8h, consistent with a local wall-clock time in a UTC+8 environment having been encoded as if it were UTC when the original transaction record was created, then inherited by all renewals of that family. Questions for Apple engineers: Is this a known issue in App Store Server data, and is there a reference we can track? What conditions cause a family's purchaseDate to be recorded this way (storefronts/regions, purchase channels, offer types, original-receipt formats)? When purchaseDate and signedDate disagree, which field is authoritative for "when the customer was charged"? The public documentation defines each field only as "UNIX time, in milliseconds" and does not define its relationship. Is remediation planned on Apple's side, or what is the recommended way to obtain the true charge time? Evidence: A focused sample project (a ~85-line Swift tool plus four unmodified signedTransactionInfo JWS samples — three affected families and one unaffected control, each carrying Apple's x5c certificate chain) is included in Feedback Assistant report FB24820430, together with the raw HTTP notification bodies for an affected and a control notification, exactly as delivered to our endpoint. Thank you.

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.

Hello Apple Developer Forums, We are unable to authorize the Production App Store Server API Request a Test Notification endpoint. Environment: Production API: Request a Test Notification Library: Apple App Store Server Library for Java 5.2.0 Client: AppStoreServerAPIClient Result: HTTP 401 Unauthorized before a testNotificationToken is returned. We have verified the following: The key is an active In-App Purchase key created in App Store Connect under Users and Access > Integrations > In-App Purchase. The production server uses the matching .p8 private key, Key ID, Issuer ID, and bundle ID. The bundle ID is com.ansio.serviceproof.ios. The server clock is NTP-synchronized. The request uses the official Apple Java Server Library rather than a manually generated JWT. We rotated the production In-App Purchase key once and received the same 401 result. The notification URL is configured for the Production environment, uses HTTPS, and is reachable. Sandbox uses an independent key and notification configuration. We intentionally do not include the private key, JWT, Key ID, or Issuer ID publicly. According to the documentation, HTTP 401 means the JWT is invalid. Since the official library creates the JWT and the active In-App Purchase key configuration has been verified, could Apple clarify: Is any additional App Store Connect role, agreement, team activation, or entitlement required for a Production In-App Purchase key to authorize App Store Server API requests? Is there a known propagation or authorization issue that can cause a newly created active In-App Purchase key to return 401? What non-sensitive diagnostic details can help distinguish a JWT construction issue from a team-level authorization issue? Thank you.

I am designing a cross-platform application whose core application is a web/PWA application. I want to distribute a very small native wrapper through the Apple App Store. The customer would purchase the application once through the App Store. There would be no subscription, no developer-managed customer account, no developer password, and no cloud storage of the customer's data. The customer's songs remain entirely on their device. The native Apple wrapper would use StoreKit to determine whether the customer owns the application. If they do, the web application should operate in unlimited mode. If they don't, the web application should operate in a free mode limited to 10 songs. Can an App Store-distributed native wrapper securely communicate the verified StoreKit entitlement to the embedded web/PWA application, without requiring my own customer account or licensing server? If yes, what Apple-supported mechanism should be used to pass that entitlement from the native application to the web application? Additionally, does Apple's App Store license for a non-consumable purchase automatically allow the purchaser to use the application on multiple Apple devices associated with the purchaser's Apple Account?

Following the guidance in the locked thread "Reporting your App Store Server Notifications issue" (thread 774053), Feedback ID: FB24877994. Apple Developer Support case 102971044266 is open in parallel. Summary On our account no auto-renewable subscription renewal has ever succeeded, on either of our two products, while every customer-present initial purchase succeeds. In the last 48 hours 4 of 4 free trials that reached their renewal date with auto-renew ON failed with expirationIntent 2, in four countries (PK, GB, NL, US). What we observe Yearly product with a 7-day free introductory offer (all 175 territories, offerMode FREE_TRIAL, ONE_WEEK, 1 period). Monthly product with no offer. For each of the four, GET /inApps/v1/subscriptions/{originalTransactionId} returns status 3, and the renewal info has autoRenewStatus 1, expirationIntent 2, isInBillingRetryPeriod true, the correct renewalPrice and currency, no priceIncreaseStatus. Environment Production, inAppOwnershipType PURCHASED. The DID_FAIL_TO_RENEW notification (no subtype; billing grace period not enabled) arrives at the expiry time in each case. App Store Connect subscription events from 2026-08-01 to 2026-09-20: 18 free trial starts, 6 full-price starts, 4 voluntary churns from free trial, 4 from full price, 3 "Billing retry from free trial", 1 "Involuntary churn from full price", and no renewal event of any kind. So 5 of 5 unattended renewal charges ever attempted have failed, across two products and five countries, while the 6 paid monthly purchases in the same window (TR, FR, AU, MN, US) were charged normally at purchase time. The customers are in their own storefront countries (device time zones match), and none of the four cancelled. What we have verified Both products Approved, 175 price rows each, no scheduled or preserved prices; Paid Applications Agreement, Free Apps Agreement, banking, tax forms and both compliance items (DSA, MRDP) all show Active with nothing pending in App Store Connect > Business; our servers call no App Store Server API endpoint that modifies a subscription. Thread 847338 (posted today) describes every renewal on an account failing after an agreement issue, with expirationIntent 5. Ours is expirationIntent 2 and our agreements show Active, but the shape is the same: every renewal, no purchase affected. Questions for Apple engineers Is there any account, agreement or product condition that causes renewal charges to fail with expirationIntent 2 while initial purchases succeed? Is anything more than expirationIntent 2 available about these four renewals? The four original transaction IDs are in FB24877994. Is there a known issue affecting free-trial-to-paid renewals around 19 to 21 September 2026? Thank you.

I see different storefronts in StoreKit product queries and Apple’s purchase sheet when testing through TestFlight. Xcode-installed builds work normally. iPhone — iOS 26.6 (23G71), US Media & Purchases account Both StoreKit 1 and StoreKit 2 return CHN/CNY. The app displays CNY 128 for a non-consumable, but Apple’s sandbox purchase sheet shows USD 29.99 for the same product. This reproduces in a standalone 177-line Swift sample using Product.displayPrice directly, with no third-party dependencies, currency conversion, or local .storekit configuration. Reloading products and signing out of the sandbox account did not resolve it. Mac Catalyst — macOS 26.3 (25D125), China purchase account The original TestFlight app returns USA/USD. Purchasing shows “Account Not In This Store” and asks to switch to China, although the purchase account is already set to China. The Mac symptom has not yet been verified in the standalone sample. Reproduction on the affected iPhone: install via TestFlight, load products and log Storefront.current plus the SK1 storefront, open the purchase sheet for the same product, then compare currencies. No completed purchase is needed. Built with Xcode 26.1 (17B55). Has anyone found a workaround for this TestFlight-only mismatch? Should the app handle storefront updates differently, and which additional diagnostics would help distinguish a device/account-session issue from a StoreKit service issue? Feedback: FB24873070. A focused sample and diagnostic evidence are prepared for Apple Developer Technical Support. Reproduction on other devices/accounts is not yet confirmed.

Hello, We are currently seeing errors when validating receipts for every auto-renewable subscription purchased through both StoreKit 1 and StoreKit 2. Details below. Case 1 — StoreKit 1 Calling https://buy.itunes.apple.com/verifyReceipt with the subscription receipt returns: "status": 21006, "expiration_intent": "5" Case 2 — StoreKit 2 Calling https://api.storekit.itunes.apple.com/inApps/v1/subscriptions and reading the most recent transaction (LastTransactionsItem) returns status 3. Within JWSRenewalInfoDecodedPayload: autoRenewStatus = 1, expirationIntent = 5 Timeline We believe renewals stopped processing for essentially all auto-renewing subscribers of our app as of 2026-09-18 09:30 KST (UTC+9). After resolving an agreement/licensing issue on our side, new purchases and some receipt validations recovered as of 2026-09-21 11:49 KST. However, most existing receipts still return expirationIntent = 5 when we query receipt validation or subscription status. Questions Is any action required on our side — a server-side change, a configuration change in App Store Connect, or a further review of our agreements? Now that the agreement issue is resolved, when are the renewals that were left pending during the outage expected to be processed? Any guidance would be appreciated. Thank you.

Hello, I submitted a mass subscription renewal date extension request using the App Store Server API on September 9, 2026. The request was accepted successfully. However, when I check the request using getStatusOfSubscriptionRenewalDateExtensions, the status continues to return: complete: false As of September 20, the request has remained incomplete for 11 days. Request details: Extension: 1 day Reason: temporary service interruption Environment: Production The documentation states that a mass renewal date extension may take hours or even days to complete, but I have not been able to find guidance for a request that remains incomplete this long. Only three subscribers were affected by the service interruption, and I have their originalTransactionId values. I am considering using the individual subscription renewal date extension API instead. My questions are: Is it expected for a mass renewal date extension request to remain complete: false for 11 days? Could this mass request still complete at a later date? Is there any way to cancel or determine whether this mass request is stuck? If I extend the three affected subscriptions individually now, is there a risk that the pending mass request could later complete and extend them a second time? I would like to compensate the affected subscribers as soon as possible while avoiding duplicate extensions. Thank you for any guidance.