Hello Apple Developer Support / StoreKit Team, We recently observed a behavior regarding the appAccountToken in App Store Server Notifications v2 that seems to completely contradict the official documentation. According to the Set App Account Token documentation: The same appAccountToken continues to apply to renewal transactions if the customer upgrades, downgrades, or cross-grades the subscription. However, we encountered a scenario where an active in-app crossgrade resulted in an updated/overwritten appAccountToken inside the subsequent JWSRenewalInfoDecodedPayload, despite our backend never calling the Set App Account Token REST API. Our Observation: A user subscribes to our 1-month plan (Product A). Apple generates an originalTransactionId bound to their initial appAccountToken (Token A). Later, a crossgrade to a 1-year plan (Product B) is initiated from within the app while the user is logged into a different account in our system (Token B), but using the same underlying Apple ID on the device. When the crossgrade takes effect at the next renewal date, we receive a DID_RENEW webhook. The Anomaly (See Attached Screenshots): Upon decoding the JWSRenewalInfoDecodedPayload from the webhook, we noticed that the appAccountToken had unexpectedly changed to the new token (Token B). As shown in the attached redacted screenshots: Screenshot 1 (Before/Original): JWSRenewalInfoDecodedPayload for Product 00001 shows the appAccountToken ending in ...e9a. Screenshot 2 (After Crossgrade): JWSRenewalInfoDecodedPayload for Product yearly_saver shows the appAccountToken has mutated to ending in ...507, even though the originalTransactionId remains exactly the same. To reiterate, our server did not call the POST /inApps/v1/subscriptions/appAccountToken/{originalTransactionId} endpoint to manually overwrite this token at any point. Our Questions: Is this the intended StoreKit 2 behavior? Does Apple automatically overwrite the base appAccountToken in the RenewalInfo if a new token is somehow associated during an active in-app crossgrade transaction? If this is intended, could the documentation be clarified? The current phrasing strongly suggests the token is permanently locked to the initial purchase and will never change during crossgrades unless the REST API is explicitly called. While this behavior is actually quite helpful for our backend to track multi-account users, we want to ensure we aren't relying on an undocumented bug that might be patched unexpectedly. Any insights from the StoreKit engineering team would be highly appreciated. Thank you!

iOS 26.4系统上，我们发现三个问题： 1.调用了finishTransaction接口，但是在App重新启动后，[SKPaymentQueue defaultQueue].transactions仍然会有这笔订单。 2.支付完成后，[[NSBundle mainBundle] appStoreReceiptURL]]，拿到的票据解析出来里面的商品是空的，需要延迟2秒钟左右在调用[[NSBundle mainBundle] appStoreReceiptURL]]才能获取有效票据。 3.支付完成后，如果用户没有点击最后弹出的确认弹框，等待5秒钟，系统会自己回调 - (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray<SKPaymentTransaction *> *)transactions; 代理方法。正常应该是用户点击了最后弹出的确认弹框，在回调- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray<SKPaymentTransaction *> *)transactions;方法。 我们在苹果开发者论坛上面找到其他开发者反馈的类似问题，链接如下： https://developer.apple.com/forums/thread/817700 https://developer.apple.com/forums/thread/792437?answerId=849557022#849557022 https://developer.apple.com/forums/thread/817834 https://developer.apple.com/forums/thread/817706 https://developer.apple.com/forums/thread/818586 我们有大量用户升级到了26.4系统，这对于我们造成了巨大的困扰，我们需要你们的帮助，感谢！

Prerequisites We plan to sell non-consumable items via in-app purchases. The app includes a restore button. We understand that after a payment is completed on a smartphone, the server must verify the receipt and activate the item in the database, and the app must then execute the transaction finish process. Due to our app’s constraints, there are specific cases where we must execute the transaction finish process on the app side without first performing the item activation process in the database. We do not know exactly what the transaction finish process entails. Questions What are the implications in the following cases? The payment was completed, but the product activation process in our database failed, and the transaction finish process was not executed on the app side. After restarting the app, an OS notification indicating an incomplete transaction appeared, and only the finish process was executed. In this scenario, we assume that the OS notification will not appear next time, and the user can simply activate the purchase by starting a transaction recovery. Are there any potential concerns or bugs that might occur? What are the implications if the product activation process in our database succeeds, but the finish operation fails to complete normally due to the user exiting the app or similar circumstances? Our assumption is that since the product is activated in our database, we can provide value for the charge without issue, and there is no deterioration in UX, such as the inability to process refunds in the app store. Are there any potential concerns or bugs that might arise? Regarding this inquiry, if you have any information—such as whether this scenario would result in a rejection during the app review process—we would appreciate it if you could share it with us.

Hello, I am trying to ship the first auto-renewable subscription for my iOS app and I am facing what seems to be a workflow / availability issue involving App Store Connect and TestFlight. Product ID: seka_premium_yearly_ Current situation: The subscription exists in App Store Connect. Its status remains “Waiting for Review”. The subscription page says that the first subscription must be submitted with a new app version and attached through the “In-App Purchases and Subscriptions” section on the app version page. 4. However, this section does not appear on my iOS app version page in App Store Connect. 5. In TestFlight, when tapping “Subscribe”, the app shows: “The offer is not available yet. Please try again in a moment.” Additional context: Paid Apps Agreement is active The app uses expo-iap The product ID configured in the app is seka_premium_yearly_ We are not restricting access by storefront, region, or device configuration Sandbox testing has been attempted, but the issue remains reproducible in TestFlight Question: Is it expected that the subscription is unavailable in TestFlight while the first subscription is still in “Waiting for Review”? Does the missing “In-App Purchases and Subscriptions” section on the app version page indicate an App Store Connect issue? Has anyone encountered this specific first-subscription workflow problem? Any guidance would be appreciated.

how to disable streamline purchasing, when I click turn off, it show error Streamlined purchasing cannot be turned off because your latest approved binary doesn’t include the required StoreKit APIs My app has subscribe button to click before start to use though not need to login, chatgpt had done the store kit and subscription part, do not understand why it can not turn off streamlined purchasing

I have a $4 USD, one-time-purchase app (Dash Calc) and sales have been rough. In a crowded category, an paid-upfront app feels like a tough sell without a way to try it first. I’d like to offer a simple 7-day free trial followed by a single lifetime purchase, but App Store Connect still doesn’t officially support trials for paid apps. In Jan 2023, an App Store Commerce Engineer recommended the $0 non-consumable IAP + paid non-consumable IAP workaround: https://developer.apple.com/forums/thread/722874 I haven’t implemented it yet, but the subsequent discussion suggests the approach is overly complex. Handling refunds, reinstalls, activation timing, and purchase history requires non-obvious logic, and some developers report customer confusion and drop-off when presented with a $0 trial IAP. Has anything improved since 2023? Any new StoreKit APIs or App Store Connect changes that make this simpler or less error-prone? Is the $0 non-consumable IAP still the recommended approach in 2026? Any updated guidance for time-limited access on one-time purchases? I’m happy to use the workaround if it’s still the official path—I just want to confirm there isn’t a better option now.

how to disable streamline purchasing, when I click turn off, it show error Streamlined purchasing cannot be turned off because your latest approved binary doesn’t include the required StoreKit APIs My app has subscribe button to click before start to use though not need to login, chatgpt had done the store kit and subscription part, do not understand why it can not turn off streamlined purchasing

Hello, I got Purchase Error Couldn’t communicate with a helper application. when button 'Buy Pro' clicked in my app it uses storekit subscription created (correct id in configuration.storekit) got this error in console: Purchase did not return a transaction: Error Domain=ASDErrorDomain Code=5115 "Received failure in response from Xcode" UserInfo={NSDebugDescription=Received failure in response from Xcode, NSUnderlyingError=0xc5bc1c510 {Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service created from an endpoint was invalidated from this process." UserInfo={AMSDescription=An unknown error occurred. Please try again., AMSURL=http://localhost:49913/WebObjects/MZBuy.woa/wa/inAppBuy, NSDebugDescription=The connection to service created from an endpoint was invalidated from this process., AMSStatusCode=200, AMSServerPayload={ "app-list" = ( Thx for any help : )

**Environment Platform:** iOS Distribution: TestFlight Product type: Consumable In-App Purchase Account used for testing: Real Apple ID (not Sandbox) StoreKit: StoreKit 1 iOS version: iOS 17+ (also reproduced on earlier versions) Issue Description We are encountering an issue when testing consumable in-app purchases in a TestFlight build using a real Apple ID. Under normal circumstances, consumable products should be purchasable repeatedly. However, in TestFlight, after a successful purchase flow, the same product may become unavailable for repurchase, and the transaction appears to be stuck, even though: • finishTransaction: is correctly called • The transaction state is .purchased • No pending transactions are left in the payment queue Once this happens, subsequent purchase attempts result in behavior similar to a non-consumable product (e.g. “already purchased” or no purchase UI shown).

Environment OS: iOS 26.2 ~ 26.3 SDK: Xcode 16.4 (Target: iOS 17.6) Framework: StoreKit 2 Environment: Production (Cannot reproduce in Sandbox or Xcode Configuration) Issue Description We are encountering a critical purchase failure that occurs exclusively in the Production environment. When a user who has a "Pending Downgrade" (scheduled for the next renewal date) attempts to re-purchase their current higher-tier product to cancel the downgrade, StoreKit 2 returns an error. Steps to Reproduce User is currently on "Product A" (Higher Tier). User schedules a downgrade to "Product B" (Lower Tier). The status changes to "Pending Downgrade". User attempts to purchase "Product A" again via Product.purchase(). The system purchase sheet appears, and the user confirms the purchase. Immediately after authentication, a system alert from StoreKit appears saying: "Cannot process request at this time. Please try again later." (現在リクエストを一時的に処理できません。しばらくしてからもう一度お試しください。) After dismissing the alert, the app receives StoreKitError code 2 (unknown) with the localized message: "Request could not be completed" (リクエストを完了できません). Technical Observations Transaction.currentEntitlements: Does not change. App Store Server Notifications (V2): No notifications are sent to our server. Sandbox Behavior: Works perfectly. Re-purchasing Product A successfully cancels the downgrade and the subscription remains at the Higher Tier. AppStore.sync(): Running a manual sync does not resolve the pending state after the error. Question Since we cannot debug production-level logs, we are stuck. Is this a known regression in the StoreKit 2 commerce engine regarding state synchronization for downgrades? Has anyone found a workaround for this specific scenario? Any insights would be greatly appreciated.

In iOS 26.4 beta 4, the receipt returned by StoreKit payments via [[NSBundle mainBundle] appStoreReceiptURL] corresponds to the previous transaction; the content only becomes correct after restarting the app.

Hello, I am investigating a case where two different transaction IDs appear to refer to the same purchase, and I would like clarification on whether this behavior is expected. Additional context StoreKit version: StoreKit 1 (SKPaymentTransaction) Environment: Production Product type: Auto-renewable subscription Transaction sources The values are obtained from the following APIs: transaction_id from SKPaymentTransaction https://developer.apple.com/documentation/storekit/skpaymentqueue receipt_data from the App Store receipt https://developer.apple.com/documentation/foundation/bundle/appstorereceipturl Observed behavior After an In-App Purchase completes, the app receives: a transaction_id from SKPaymentTransaction the corresponding receipt_data for the purchase When inspecting the receipt, the transaction_id inside latest_receipt_info differs from the transaction_id received directly from the purchase transaction. For clarity: A = transaction_id received from the purchase flow (SKPaymentTransaction) A' = transaction_id found in receipt_data.latest_receipt_info The two values are different, but they differ only by 1. Additional observation The original_transaction_id for A and A' is identical, which suggests that both transaction IDs belong to the same subscription purchase chain. Pattern observation on the ID difference We have observed that the difference between A and A' is consistently exactly 1 (i.e., A' = A + 1) across multiple transactions, not just a single case. This appears to be a reproducible pattern rather than a coincidence. This observation raises an additional question (Question 6 below). API verification When calling: GET /inApps/v1/transactions/{transactionId} Both A and A' return what appears to be the same purchase record. The response data is effectively identical except for the transactionId field. However, when calling: GET /inApps/v2/history/{transactionId} A does not appear in the transaction history only A' appears in the history response Questions If A does not appear in transaction history, where does this transaction ID originate from? Why does Get Transaction Info (/inApps/v1/transactions/{transactionId}) return a valid response for A even though it is not present in the transaction history? Why do A and A' both resolve to what appears to be the same purchase? In this situation, which transaction ID should be treated as the canonical transaction ID for server-side validation? Is this difference related to how StoreKit 1 (SKPaymentTransaction) and the App Store Server API represent transactions? Is the consistent off-by-one difference between the transaction_id from SKPaymentTransaction and the one recorded in latest_receipt_info an intentional behavior of StoreKit 1's internal transaction ID assignment? Specifically, we are wondering whether StoreKit 1 applies some form of internal offset when delivering the transaction ID to the client, while the App Store server records a different (adjacent) ID in the receipt. If so, is this documented anywhere? Note We are currently in the process of migrating to StoreKit 2, but this behavior was observed while investigating our existing StoreKit 1 implementation. Any clarification would help us better understand the correct transaction model during the migration.

Hi, We are facing issue with purchases on iOS 26.4. The app store receipt received is from previous transaction leading to receipt validation failures. There are some purchase success observed for pending transactions but success rate for pending transactions is also very low. We are using Unity In-App Purchasing (IAP) 4.13.0. Let us know for any more details and any fix / workaround available. Thanks.

I just spent way too many hours trying to figure out why my in-app subscription was stuck in “Missing Metadata” in App Store Connect, even though I had filled out everything. If you're here because you're in the same boat, this is the solution Apple doesn't make obvious. The Problem I created an auto-renewable subscription (Kanabloom Premium) and filled in all required fields. The subscription was still marked "Missing Metadata", preventing me from submitting it. The “In-App Purchases” section wasn’t showing up in my App Store version submission, which meant I couldn't even attach the subscription to my app version. I triple-checked the metadata, pricing, tax settings, review screenshot, and even resaved everything, but nothing worked. What I Tried (Before Finding the Fix) Checked that pricing was set up correctly for all countries. Uploaded the required review screenshot for the subscription. Made sure the subscription group existed and was linked properly. Refreshed, logged out/in, and tried different browsers. Read every Stack Overflow, Reddit, and Apple Developer Forum post I could find. Even tried creating a dummy subscription to see if that would reset the system. The Solution: Localizing the Subscription Group Here’s the stupidly hidden requirement that finally fixed it: ✅ Your subscription group itself (not just the subscription) needs a localized display name. App Store Connect requires each subscription group to have at least one localized display name for it to be valid. If this is missing, all subscriptions inside that group will stay stuck in “Missing Metadata” no matter how complete they are. How to Fix It: Go to App Store Connect > Subscriptions > Subscription Group Click on your subscription group (not the individual subscription). Check if there's a localization added under "Group Reference Name." If missing, add a localization (e.g., English) and save. Refresh the page and boom – the subscription will finally be "Ready to Submit." Conclusion Apple really needs to make this requirement clearer. Now that I’ve finally figured it out, hopefully, this post helps someone else avoid losing hours of their life to the same issue. If you're still stuck, double-check that: You’ve set pricing and enabled "Cleared for Sale." You’ve uploaded a review screenshot for the subscription. You’ve signed all App Store agreements and banking/tax documents. Your app's In-App Purchase capability is enabled in Xcode. Let me know if this helped you! I wish I had found a post like this sooner. 😂 This should make for a useful and searchable post in case other devs run into the same headache. Let me know if you want any tweaks before posting! 🚀

We're seeing some strange behavior of the appAccountToken when passing it to a purchase in the sandbox environment. Normally we'd expect the same account token to be set on the resulting verfication, but that's not the case. Instead the token seems to be persisted on the API side and reused for some amount of time, meaning there's a mismatch and the connection between account and purchase is lost. This happens consistently even if we send new tokens on each purchase. Has there been any updates to purchase flow in the sandbox environment on Apple's side? .purchase( options: [.appAccountToken(token)] )

I have a bunch of Audio Unit v3 plugins that are approaching release, and I was considering using subscription-model pricing, as I have done in a soon to be released iOS app. However, whether this is possible or not is not at all obvious. Specifically: The plugin can, depending on the host app, be loaded in-process or out-of-process - yes, I know, Logic Pro and Garage Band will not load a plug-in in-process anymore, but I am not going to rule that out for other audio apps and force on them the overhead of IPC (I spent two solid weeks deciphering the process to actually make it possible for an AUv3 to run in-process - see this - https://github.com/timboudreau/audio_unit_rust_demo - example with notes) Depending on how it is loaded, the value of Bundle.main.bundleIdentifier will vary. If I use the StoreKit API, will that return product results for my bundle identifier when being called as a library from a foreign application? I would expect it would be a major security hole if random apps could query about purchases of other random apps, so I assume not. Even if I restricted the plugins to running out-of-process, I have to set up the in-app purchases on the app store for the App container's ID, not the extension's ID, and the extension is what run - the outer app that is what you purchase is just a toy demo that exists solely to register the audio unit. I have similar questions with regard to MetricKit, which I would similarly like to use, but which may be running inside some random app. If there were some sort of signed token, or similar mechanism, that could be bundled or acquired by the running plugin extension that could be used to ensure both StoreKit and MetricKit operate under the assumption that purchases and metrics should be accessed as if called from the container app, that would be very helpful. This is the difference between having a one-and-done sales model and something that provides ongoing revenue to maintain these products - I am a one-person shop - if I price these products where they would need to be to pay the bills assuming a single sale per customer ever, the price will be too high for anyone to want to try products from a small vendor they've never heard of. So, being able to do a free trial period and then subscription is the difference between this being a viable business or not.

I'm building an app that sells non-consumable in-app purchases. I want to implement a partner/referral discount system using the following approach: Create multiple IAP products in App Store Connect for the same content at different price points (e.g. full price at €10, 10% off at €9, 20% off at €8) When a user enters a partner or referral code in the app, my backend validates the code and returns which product to present The user then completes the purchase through the standard StoreKit IAP flow — Apple processes the transaction normally at the discounted price No purchase is unlocked without going through Apple IAP. No external payment system is involved. The only difference from a standard purchase is which product SKU is shown based on a backend-validated code. My questions: Is this approach compliant with App Store guidelines? Is there any guideline that requires developers to use Apple's native Offer Codes system instead of this approach for discounted purchases? Any guidance would be appreciated before we invest in building this out.

When my app tries to access a subscription, StoreKit's products(for:) always returns zero results. Similarly, SubscriptionStoreView always shows "Subscription Unavailable" followed by "The subscription is unavailable in the current storefront". The app is a watch-only app (no iPhone companion app). The app and the subscription product were each approved in App Store Connect over two weeks ago. The problem occurs when the app is installed from TestFlight, when the app is installed from the App Store (production), and when run in the Xcode debugger. The only time the app successfully accesses the subscription when simulating it in Xcode with a .storekit file. How should my app access the subscription? Repro: App Store bundle ID: com.toolsay.hoopref Phone app target (unused) bundle ID: com.toolsay.hoopref Watch app bundle ID: com.toolsay.hoopref.watchapp Subscription product ID: com.toolsay.hoopref.pro.annual Subscription availability: All countries and regions App Store listing let products = try await Product.products(for: ["com.toolsay.hoopref.pro.annual"]) products.count is 0.

I am working on an application where I want to add InApp Purchase. The application is offering storage to users. The user will be presented with different level of storage. He will be able to buy one level of storage through InApp Purchase. Is it possible to add some restrictions in the Product so that a user can not downgrade from a large Storage to a smaller storage? Because if he does so, then all the datas in the large storage can not be migrated to the smaller storage.

Hello, I’m trying to understand which Apple subscription offer best fits a coupon-like flow in our app. Our ideal case is a 1-month Pro benefit that users can trigger inside the app: without entering a code manually possibly more than once over time then continue into a normal paid auto-renewable subscription Ideally, this would work for new, existing, and lapsed users, and if possible, even for users who are already actively subscribed (though that part is not required). From the docs, I understand that: Offer Codes require redemption Promotional Offers are for existing or previously subscribed users Introductory Offers are for new eligible users Win-Back Offers are for lapsed subscribers So my questions are: Is there any Apple-supported way to do this without manual code entry? Can the same user receive this kind of 1-month benefit multiple times over time? Which offer type is the closest fit? Is this use case partly incompatible with Apple’s subscription system? Thanks.