General: Forums topic: StoreKit Forums tag: In-App Purchase App Store Pathway Simple and safe In-App Purchases Auto-renewable subscriptions In-App Purchase documentation Getting started with In-App Purchase using StoreKit views documentation Supporting business model changes by using the app transaction documentation Testing at all stages of development with Xcode and the sandbox documentation App Store Server Notifications documentation App Store Server API documentation Simplifying your implementation by using the App Store Server Library documentation TN3185: Troubleshooting In-App Purchases availability in Xcode technote TN3186: Troubleshooting In-App Purchases availability in the sandbox technote TN3188: Troubleshooting In-App Purchases availability in the App Store technote Understanding StoreKit workflows sample code Implementing a store in your app using the StoreKit API sample code What’s new in StoreKit and In-App Purchase video

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

App Store Server Notification returns successful purchase while customer's payment remains Pending We have encountered an edge case with a Non-Renewing Subscription and would appreciate clarification on the expected developer behavior. Steps to reproduce User initiates an in-app purchase using a credit card. The purchase succeeds in the app. Our backend receives an App Store Server Notification V2 (ONE_TIME_CHARGE). We successfully verify the signed JWS transaction. The same transaction is also returned by the App Store Server API. Based on the verified transaction, we grant the user's entitlement. However, on the customer's Apple account: The purchase is shown as Pending in Purchase History / Report a Problem. The customer reports that their credit card has not yet been charged. Question From a developer's perspective, should entitlement be granted immediately after receiving a valid App Store Server Notification and successfully verifying the transaction, even if the customer's purchase is still shown as Pending? Is there any App Store Server API or transaction field that indicates the payment has not yet been settled, allowing developers to delay granting entitlement until the payment is finalized? Or is the expected implementation to grant entitlement upon successful transaction verification and revoke it only if Apple later sends a refund notification? Any clarification on the expected workflow would be greatly appreciated. Thanks in advance. :)

Hello, I’m experiencing an issue with App Store Server Notifications Version 2 in the sandbox environment. Initially, an old sandbox callback URL was configured. I then replaced it with a new callback URL in App Store Connect. The new URL was saved successfully, but newly created sandbox TEST notifications continued to be sent to the old URL. To investigate further, I removed both the production and sandbox callback URLs completely. App Store Connect showed both fields as empty, and the App Store Connect API returned null for the corresponding URL attributes. However, newly created sandbox TEST notifications were still sent to the same old URL. I later used the “Modify an App” API to configure the new production and sandbox callback URLs. The PATCH request returned HTTP 200, and a subsequent GET request confirmed the new URLs and Version 2 settings. Despite this, new sandbox TEST notifications continued to use the old hostname in the HTTP Host header. I confirmed that these are new notifications, not retries: Every test returns a new testNotificationToken. The notificationUUID matches the UUID in that new testNotificationToken. The new callback URL is publicly accessible over HTTPS. The new URL returns HTTP 200 and doesn’t redirect to the old URL. The behavior is therefore: Configure a new URL → notifications still go to the old URL. Remove all configured URLs → notifications still go to the old URL. Update the URLs through the App Store Connect API → notifications still go to the old URL. It appears that the notification delivery service is using a stale callback configuration that isn’t synchronized with App Store Connect. Is there a separate cache or routing configuration for App Store Server Notifications? Is there a way to force the effective callback URL to refresh? Thank you.

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

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

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

I provide a paid feature behind an annual auto-renewable subscription, using StoreKit 2 and Transaction.currentEntitlements. Many of my users work in remote places with no connectivity for days at a time, so I need to know what happens when a device is offline at the moment the current period ends. The renewal succeeds server-side, but the device cannot fetch the updated signed transaction, so the cached transaction still carries the previous expirationDate, now in the past. Does Transaction.currentEntitlements stop returning the subscription once the cached transaction's expiration date has passed, even though the renewal has already succeeded server-side? Is there any built-in tolerance window on the device that keeps the entitlement alive until the next successful sync with the App Store? Does grace period effect the outcome? I want to avoid revoking access from a paying subscriber who happens to be offline when renewal falls due. Many thanks.

I have 2 iOS app products. One can fetch subscription product information normally, while the other fails with the error errorCode 4040004 'App not found' in Sandbox. The App Store Connect backend configuration should be fine, and the subscription code on the app side is the same codebase for both. I really can't find the root cause anymore — if anyone knows what's going on, please point me in the right direction. Also, I'm able to sync/download the StoreKit product configuration file from App Store Connect directly in Xcode, which should also confirm that my App Store Connect backend configuration is correct.

We have a new iOS app in App Store Connect with six consumable in-app purchases. Environment: Bundle ID: live.mymi.ios TestFlight version: 1.0.4 (70) Storefront: KOR Environment: Sandbox Example product ID: ios_spark_5000 StoreKit product queries return all six products with localized KRW prices. For example, ios_spark_10000 is returned as ₩12,000. However, requesting a purchase fails with Product.PurchaseError.productUnavailable / “This item is not available.” The issue can also be reproduced independently of the app: Settings > Developer > Sandbox Apple Account > Test Transactions Entering bundle ID live.mymi.ios and product ID ios_spark_5000 is rejected with a message stating that the product ID or bundle ID is invalid. The previous app/product pair live.mymi.app + spark_5000 still works on the same device and with the same Sandbox tester. We verified the following: Paid Apps Agreement, banking, and tax information are active The explicit App ID has the In-App Purchase capability enabled The TestFlight build uses the correct bundle ID Product pricing, localization, and availability in all 175 storefronts are configured All six IAPs are attached to the first app version review submission No local StoreKit configuration is involved This has persisted for multiple days. It appears that the product-query catalog contains the products, while the Sandbox transaction service does not recognize the product-to-bundle association. Has anyone seen this with a newly created App Store app/IAP catalog? Did Apple need to re-index the products?We have a new iOS app in App Store Connect with six consumable in-app purchases. Environment: Bundle ID: live.mymi.ios TestFlight version: 1.0.4 (70) Storefront: KOR Environment: Sandbox Example product ID: ios_spark_5000 StoreKit product queries return all six products with localized KRW prices. For example, ios_spark_10000 is returned as ₩12,000. However, requesting a purchase fails with Product.PurchaseError.productUnavailable / “This item is not available.” The issue can also be reproduced independently of the app: Settings > Developer > Sandbox Apple Account > Test Transactions Entering bundle ID live.mymi.ios and product ID ios_spark_5000 is rejected with a message stating that the product ID or bundle ID is invalid. The previous app/product pair live.mymi.app + spark_5000 still works on the same device and with the same Sandbox tester. We verified the following: Paid Apps Agreement, banking, and tax information are active The explicit App ID has the In-App Purchase capability enabled The TestFlight build uses the correct bundle ID Product pricing, localization, and availability in all 175 storefronts are configured All six IAPs are attached to the first app version review submission No local StoreKit configuration is involved This has persisted for multiple days. It appears that the product-query catalog contains the products, while the Sandbox transaction service does not recognize the product-to-bundle association. Has anyone seen this with a newly created App Store app/IAP catalog? Did Apple need to re-index the products?

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

Hello, We are investigating a discrepancy during an auto-renewable subscription test in Apple’s Sandbox. We would appreciate guidance on read-only diagnostics that preserve the original attempt. Environment: A development-signed, unpublished QA app on a physical iPhone, separate from our production app. A monthly auto-renewable subscription. The original purchase flow uses RevenueCat. The Apple purchase sheet displayed “Environment: Sandbox” and indicated that no charge would occur. Observed behavior: After entering the Sandbox account password, the tester reported seeing a purchase-completion message. The app subsequently displayed a cancellation message. We did not capture a verified StoreKit success transaction, so we cannot establish that the purchase actually completed. The dedicated QA RevenueCat project showed no purchases or subscriptions, and no actual purchase webhook arrived. The next day, subscription management for the same Sandbox account showed no subscription for this QA app. Read-only investigation: RevenueCat’s purchase and subscription queries returned HTTP 200 with empty results and no additional page. We updated the same app, retaining its bundle identifier and installation, with a native StoreKit diagnostic. Enumerating StoreKit.Transaction.all completed normally with zero results. There were no unverified results, filtered-out transactions, timeouts, or count limits. This diagnostic did not invoke purchase, synchronization, or transaction-finishing operations. One earlier restore attempt also returned no purchase. We have not made another purchase, cleared purchase history, or recreated the Sandbox account. We understand that an empty result in this app context does not prove that no transaction exists anywhere in Apple’s systems. No transaction identifier or signed transaction has been recovered. Questions: What read-only checks can distinguish an incomplete or cancelled purchase from an account/environment mismatch or a transaction-delivery issue? Is there a supported way to investigate the original attempt without a transaction identifier and without making another purchase? Which existing device logs or diagnostic captures would be useful? If investigation requires identifiers or unredacted diagnostics, what private Apple reporting channel should we use? Our goal is to investigate the original attempt while preserving purchase history and leaving production untouched. Thank you.

Hello everyone! We are currently developing our application with an approved "External Link Account Entitlement." During development, we encountered an issue regarding the display language of the modal window triggered by the ExternalLinkAccount.open() function. It consistently appears in English when installed via Xcode or TestFlight. The physical device is located in Israel, the account is set to the Israel region, and the selected language is Hebrew. We have tried changing the language and region settings on the device, but nothing has changed. Since the application is intended for the Israeli market, it is crucial that the window appears in Hebrew. I have reviewed the relevant forum threads and tried the solution suggested by an Apple engineer, but it did not resolve the issue: External Link Account Modal language My main questions are as follows: Does this modal window support Hebrew? Could the absence of Hebrew be a specific behavior related to using Xcode and TestFlight, while the language will display correctly in the App Store version? Which account settings influence the language of the triggered modal window?

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?

Hello. I have setup a StoreKit testing in the app that was and still is perfectly working on iOS 18. Unfortunately when run on iOS 26 the following error gets printed in the console after calling Transaction.currentEntitlement(for:) method: Failed to verify certificate chain due to client recoverable failure: Error Domain=NSOSStatusErrorDomain Code=-67843 "“StoreKit Testing in Xcode” certificate is not trusted" UserInfo={NSLocalizedDescription=“StoreKit Testing in Xcode” certificate is not trusted, NSUnderlyingError=0x109de7e10 {Error Domain=NSOSStatusErrorDomain Code=-67843 "Certificate 0 “StoreKit Testing in Xcode” has errors: Root is not trusted;" UserInfo={NSLocalizedDescription=Certificate 0 “StoreKit Testing in Xcode” has errors: Root is not trusted;}}} I'm not seeting any StoreKit Testing certificates in phone's certificate trust settings. This test was performed on iOS 26.0 (23A341) with app built in Xcode 16.4. FB20339145

Hello Apple Developer Support / StoreKit team, I am testing auto-renewable subscriptions on a real iPhone device using Settings > Developer > Sandbox Apple Account > Test Transactions. I found that subscriptions work correctly for one of my apps, but fail for another app under the same Apple Developer account. Working app Bundle ID: com.benbendou.pinyincharacter Product ID: xpyxhz.quarterly Result: The sandbox purchase sheet appears and the subscription flow can be completed successfully. Failing app Bundle ID: com.benbendou.chengyudaquan Product ID: cydq.quarterly Result: The Test Transactions flow fails. In my app, Product.products(for:) can load some subscription products successfully. However, when trying to purchase cydq.quarterly, the purchase fails with: errorCode = 4040004 errorMessage = "App not found. Please try again." Because the same issue also happens in iPhone Settings > Developer > Sandbox Apple Account > Test Transactions, using the exact Bundle ID and Product ID, this does not seem to be caused by my app’s StoreKit code. The strange part is that another app under the same developer account works correctly with Test Transactions, but this app does not. Could Apple please help check whether the Bundle ID / app record / subscription group / in-app purchase products for com.benbendou.chengyudaquan are correctly linked in the StoreKit Sandbox backend? It looks like the sandbox environment can load the product metadata, but cannot complete the purchase or find the app during transaction lookup. Thank you.

My app has been rejected twice under Guideline 2.1(b) because its In-App Purchases did not load during review. Both reviews used an iPad Air 11-inch (M3); the latest was on iPadOS 27.0.1. The reviewer's screenshots show the app's fallback state, which appears when StoreKit 2's Product.products(for:) returns none of the products. I can't reproduce it The same build loads all four products with their prices in every test I've run: TestFlight on iPhone and iPad (iPadOS 27.0), with a US account Run from Xcode with StoreKit Testing disabled, using a brand-new US sandbox account and a fresh install Starting offline and then reconnecting Signed out of the sandbox With In-App Purchases restricted in Screen Time Setup Four non-consumables, $0.49 USD, available in all countries, with localizations and review screenshots Submitted together with the app version (status: Waiting for Review) Paid Apps Agreement, banking and tax all active I've worked through Technote TN3186 (Troubleshooting In-App Purchases availability in the sandbox) Code Loading is a single call, retried a few times, and the user can tap Try Again: let products = try await Product.products(for: productIDs)Questions Is there anything that can stop products from being returned in the App Review environment but not in the sandbox? Is there a way to check what the review environment sees? Any help is appreciated.

Since January 28, 2026, we’ve noticed an increase in StoreKit-related errors during purchase flows. Specifically, we’re seeing a spike in errors reported as “Unable to Complete Request”, categorized as unknown StoreKit errors. This correlates with a noticeable drop in the overall purchase success rate. A few observations: The issue is not limited to the latest app version, it also affects older versions. It appears to occur only on iOS 17+. The impact seems country-specific: some regions are affected more heavily, while others show no significant change compared to previous days. At the moment, there are no related incidents reported on Apple’s System Status page. Given these symptoms, this looks like a potential StoreKit / Apple API issue, but we haven’t found any official confirmation yet. Has anyone else observed similar StoreKit behavior recently on iOS 17+? Any insights or known issues would be greatly appreciated.

Our universal-purchase app (iOS + macOS, StoreKit 2) offers a 14-day trial as a non-consumable priced ¥0/free in all storefronts (approved, available everywhere), plus a paid non-consumable unlock. Since late September we have 3 separate Apple Accounts (Japan storefront) where the iPhone purchase flow fails: Product.products(for:) returns the product, the App Store purchase sheet appears with the correct product and account. After confirming, the sheet shows "支払いを完了できませんでした" (Payment could not be completed). No .success result. Redeeming a FREE one-time offer code for the paid non-consumable (via the apps.apple.com/redeem URL) fails the same way on the same iPhones. The very same Apple Account, same day, on the Mac app: both the ¥0 purchase and the offer code succeed immediately, and the entitlement then shows up on the iPhone through Transaction.currentEntitlements. OS correlation so far: iOS 27.0.1: fails (2 accounts) iOS 26.7.1: fails (1 account) iOS 26.6.2: succeeds Sales and Trends shows 9 iPhone + 1 iPad successful trial purchases between Sep 26 and Oct 12, so this is not account- or product-specific. The accounts have valid payment methods (paid purchases in other apps work), no Screen Time restrictions, not Ask to Buy. Filed as FB25186860 with a sysdiagnose. Has anyone else seen free purchases failing on 27.0.1 / 26.7.1? Any known workaround besides directing users to the Mac app?

Hello, I have 2 subscription group. Each group have different plans and promotional offer. I was set 1 month free promotional offer in all plans. While I subscribe any plan IAP sheet is not showing 1 month free promotional offer. I already used with new sandbox account. How can I get promotional offer in IAP sheet?

We use Apple's official App Store Server Library for Node.js, version 3.1.0. Our latest Production Get Notification History check, on 24 October 2026 at 15:21 UTC, returned HTTP 401 with an empty response body. The request ran from our deployed backend. We verified the ES256 signature, JWT claims, 300-second token lifetime, Authorization header and system clock alignment. On 23 October, notification-history requests using the same JWT and server environment returned: Sandbox: HTTP 200 Production: HTTP 401 A separate Production Request a Test Notification also returned 401; no test notification token was issued. The latest check was only a history query, not another TEST request. The account owner confirmed that the existing In-App Purchase key is Active. Our first app version remains PREPARE_FOR_SUBMISSION and has never been publicly released. Separate Production and Sandbox notification URLs are saved with Version 2 selected. An Apple App Store Commerce Engineer described a first-production-release prerequisite in this discussion: https://developer.apple.com/forums/thread/806452 Does that prerequisite apply specifically to both Get Notification History and Request a Test Notification? Neither request uses a transaction ID. If these endpoints should authenticate before the first release, which additional app-specific authorization prerequisite or non-sensitive diagnostics should we check? Apple request IDs can be provided privately through an appropriate Apple support channel if requested.