Our app offers auto-renewable subscriptions using StoreKit Original API for In-App Purchase and App Store Server Notifications V1. Starting around 2025-03-15, we found some cases where original_transaction_id which was associated to web_order_line_item_id of already purchased subscription had changed in the receipt information of verifyReceipt response or App Store Server Notifications V1. The detailed steps are: Around February 2025, re-purchase from the app the same subscription product which was canceled and expired some time ago, using StoreKit Original API for In-App Purchase Receive the following 2 notifications from App Store Server Notifications V1 almost at the same time INITIAL_BUY DID_CHANGE_RENEWAL_STATUS In both notifications, latest_receipt_info contains the receipt for the re-purchased subscription period with new original_transaction_id and web_order_line_item_id pending_renewal_info contains both new original_transaction_id and original one which was generated at first purchase, and original one has "is_in_billing_retry_period": "1" Starting around 2025-03-15, the following happens When we receive another "DID_CHANGE_RENEWAL_STATUS" notification from App Store Server Notifications V1, original_transaction_id which is associated to web_order_line_item_id of the re-purchased subscription period has changed back to the original one (the one which was generated at first purchase) in latest_receipt_info. When we call verifyReceipt with the receipt obtained from appStoreReceiptURL, the response does not seem to contain new original_transaction_id which was generated at re-purchase We have some questions regarding this original_transaction_id behavior. When a user re-purchase the same subscription product which was canceled and expired some time ago, it seems that new original_transaction_id is generated. Is this an expected behavior? If yes, it seems that, at some point, original_transaction_id which is associated to web_order_line_item_id of the re-purchased subscription changed back to the original original_transaction_id which had been generated at first purchase. Is this an expected behavior? What triggers the original_transaction_id change to the original one? Is it related to some user actions or subscription status change?

Hi everyone, I'm submitting my watchOS-only app and its In-App Purchase for the very first time (both app and IAP submitted simultaneously). After multiple rejections, I still can't resolve the issue and would appreciate any guidance. Environment: App type: watchOS-only (no iOS companion app) First submission of both the app and IAP IAP type: Non-Consumable, Product Apple ID: 6770497337 The problem: The reviewer (App Review) states that the IAP product information cannot be retrieved in the review environment. According to the reviewer, they are testing in the production environment, not the sandbox. However: In my TestFlight build, the app correctly retrieves the IAP product I have successfully completed the full purchase flow using a sandbox account All business agreements (including Paid Apps Agreement) are accepted and active in The Bundle ID and Product ID are correctly configured in both Xcode and App Store Connect Current IAP status in App Store Connect: Overall status: "Developer Action Needed" All localizations (English US/UK/AU/CA, Japanese, Simplified Chinese, Traditional Chinese): "Rejected" No specific rejection reason is shown anywhere in App Store Connect Any help would be greatly appreciated. Thank you! 🙏

My auto-renewable subscription products are approved in App Store Connect, but fetchProducts() returns 0 products when testing in Production & Testflight. Debug output shows: "products.size is 0 - no products fetched! Expected 6 products." All my business agreements are active. Has anyone faced this before? What do you recommend? Thank you.

APP被下架后是否会影响之前已经订阅了自动续费产品用户的定期扣费

Hi, I'm experiencing an issue with StoreKit 2 in my iOS app where Product.products(for:) always returns an empty array on a real iPhone device. 📱 Environment iOS: 26 Device: iPhone 16 pro max Xcode: 26.5 StoreKit: StoreKit 2

Hi, I’m experiencing an issue with StoreKit 2 in my iOS app where Product.products(for:) always returns an empty array on a real iPhone device. iOS: 26 Device: iPhone 16 pro Max Xcode: 26.5 StoreKit: StoreKit 2

Greetings fellow devs, After accepting the Alternative Terms Addendum for Apps in the EU and adding the Storekit External Purchases or Offers capability via App Store Connect in our app identifier, the entitlement showing up in xcode is com.apple.developer.storekit.custom-purchase-link.allowed-regions and has the value 'jp'. How can we change the value for that entitlement to 'gr'? We tried changing it in xcode, but we get the error <Provisioning profile "iOS Team Provisioning Profile: [app identifier]" doesn't match the entitlements file's value for the com.apple.developer.storekit.custom-purchase-link.allowed-regions entitlement.>. In Certificates, Identifiers and Profiles in the developer account there is no way to configure that capability. We sent a request to support and they only gave a link to documentation and to the forum here. We have a completed every business agreement requested and we have chosen Greece as the organisation region and the app's availability region wherever possible. We haven't found anywhere that Japan would be chosen to explain the entitlement given. So where can this entitlement about allowed regions be configured? Xcode version is 16.4 and iOS minimum deployments is 18

I am testing a situation when user cancels auto renewable subscription (via StoreKit->Manage Transactions window). The problem is StoreKit2 does not provide an update when subscription was cancelled. I started using demo from apple developer.apple.com/documentation/storekit/in-app_purchase/implementing_a_store_in_your_app_using_the_storekit_api to test this behaviour in order to get rid of possible mistakes in my implementation, but result is the same - when user cancels subscription app does not receive any storekit events (change in renewal info, update in current entitlements, transaction status - nothing) and only after app's relaunch it fetches everything from scratch and finally updates UI. I tried to wait for up to 20 minutes to check whether this update in transaction (subscription) status will be delivered to the app - still nothing. So the problem, as I see it, is that if user cancels subscription and then does not relaunch the app he can continue to use the app for free for a long time. In this regard I have several questions: is it expected behavior of StoreKit2? If yes - why? Does it happen in Test Flight mode or in production env as well? If it's not expected behavior then is it correct to fix it with checking (lets say once in an hour) user's current entitlements (I tried and it seems to work ok) or there are better solutions?

I'm implementing EU external purchase using ExternalPurchaseCustomLink. No IAP transactions are offered on EU storefronts — payment happens entirely on our external website. I want to call Product.products(for:) on EU storefronts solely to fetch localized product metadata (displayName, displayPrice, currency formatting) for display. Product.purchase() will never be called. Is it acceptable to use Product.products(for:) for read-only product info display on EU storefronts where only external purchase is offered?

We are seeing trial conversions for our auto-renewable monthly subscription wingman_monthly (App ID 6758346525) land in a persistent "Pending" state in users' iOS Purchase History after the 3-day free trial ends, with no debit reaching the user's payment method. App Store Server Notifications V2 indicate the renewals succeeded — each affected transaction is delivered as DID_RENEW (subType BILLING_RECOVERY not present) with is_trial_conversion: true, period_type: NORMAL, a new expires_date set 31 days in the future, AUD 19.99 attributed, no expirationIntent, no is_in_billing_retry_period, and no cancellation_reason. So Apple's billing layer reports the renewals as successful, but settlement does not appear to complete. The same trial-to-paid flow on our yearly product wingman_yearly in the same subscription group converts and debits cleanly. The pattern is specific to wingman_monthly.

Hey! App is approved for Advanced Commerce API and have generic product id (Consumable) for digital items purchasing. Uncertain on ho to test flow of pending purchase changing it's status to failed. As by docs BE side handling creating jws for purchase (also creates order to keep track of which items user bought) app with signed jws initiate purchase via product.purchase (send data for advancedCommercialData in options). If product purchase returns status .pending (still no transaction created) I notify BE that for that item (using item SKU) user has pending status for purchase, so that when user attempts to buy this exact item we do not create order duplicate. So the first question - do we need to check if user already made an attempt to buy this item and if item purchasing is pending decline another attempt of buying it? If user sends several requests to buy item under similar SKU for advanced commerce api do all of them will be charged or only one (does apple check SKU value when making a purchase of consumable product via advanced commerce api)? Another question is how to test purchase returns pending status for consumable item via advanced commerce api and then for that item (by SKU) changes status from pending to success? How to know (and eventually) test that after purchase of item via advanced commerce api firstly returns .pending status and then changes to .failure? I want to prevent users from trying to create order duplicates for single item, so when product purchase returns pending status I sent to BE id of item and order for this item on BE side will be marked as pending. So if user tries to buy this exact item once more and status of order on BE still .pending no new purchase will be initiated. So I need to know when purchase changes it's status to failed and then delete pending order on BE side, so that user will have an ability to initiate purchase for this item once more. How to tell whether .pending status for item changes to failed, will I be able in case of failed gather SKU that I previously passed in advancedCommercialData)?

My first auto-renewable subscriptions have been stuck in “In Review” for almost two weeks. Apple’s notice says the first subscription must be submitted with a new app version and selected from the “In-App Purchases and Subscriptions” section on the version page. However, my version page does not show that section, even after creating a new version in Prepare for Submission. The only place I can see the subscriptions is from the Subscriptions side tab. The app itself has already been approved, but StoreKit does not return the products in production, so my paywall cannot sell subscriptions. Has anyone found a working fix for this, or does Apple need to manually reset/review the subscription state?

On devices configured to use the Buddhist calendar (primarily Thai users) Transaction.currentEntitlements returns an empty async sequence even when the customer holds a legitimate, non-revoked, non-expired entitlement for a non-consumable in-app purchase or subscription. The same transaction is correctly returned by Transaction.all. Switching the device calendar back to Gregorian immediately restores correct behavior: the entitlement is yielded by currentEntitlements again. No reinstall, sign-out, or AppStore.sync() is required. The defect is purely client-side, deterministic, and reproducible at will. Is this a known bug introduced in iOS 26? It is causing me significant problems with in-app purchase validation and restore flows in that market. Is anyone else experiencing this issue?

Hi all, I've been observing what appears to be a timing mismatch in how Apple handles Korea trial-to-paid consent, and I wanted to see if other developers are seeing the same thing. Per Korean regulations effective Feb 14, 2025, Apple must obtain explicit user consent before converting a free trial to a paid subscription. Apple handles this via email, push notifications, and an in-app consent option accessible from Settings > Subscriptions. For a 7-day trial in the Republic of Korea storefront, I'm observing: Consent push notifications (Agree to continue your subscription without interruption) start arriving ~1 day after trial redemption, at roughly hourly frequency. However, when the user taps the push and navigates to Settings > Subscriptions, there is no consent option available. The only visible action is "Cancel Free Trial". The consent option only becomes available around day 4 of the trial (i.e., 3 days before renewal, matching Apple's documented messaging cadence [1]). For the first ~3 days, users receive hourly push notifications they cannot act on. The only way to stop them is to cancel the subscription entirely. This is happening across multiple apps in the Korean App Store, so it appears to be a platform-level behavior rather than an app-specific issue. Is anyone else observing this behavior? Any insight from Apple engineers or other developers would be greatly appreciated. [1] https://developer.apple.com/help/app-store-connect/reference/in-app-purchases-and-subscriptions/consent-for-subscription-offer-conversions

We get this error in our App when users try to purchase a subscription. "Invalid Product ID" The respons from Apple backend is: (NOBRIDGE) LOG {"code": "E_DEVELOPER_ERROR", "debugMessage": "Invalid product ID.", "message": "Invalid product ID.", "productId": "com.familycal.daysi.one.month.version71"}

I had published an App, and my app has App Clip supported. The issue I faced is that I had received complaints where the user keep seeing the pop up "Apple Media Services Terms and Conditions Have Changed" when user clicked on the "Open" Button in the App Clip. What we had tried so far: Let user switch the Apple Id's region to our supported region. Let user try to log out and log in to Apple Id within the supported region.

Hi everyone, I have a question regarding App Store subscriptions and tax country / storefront changes. If a customer originally purchased a subscription while their App Store country was France (so we reported France as the tax country), and later updates or renews that same subscription while located in Hungary, which country should we report going forward? Should we continue using the original country (France)? Or should we start sending the new country (Hungary) once it changes? Also, what happens if the customer changes their App Store region entirely, for example from France to the US? How is Apple’s commission calculated after the region change? If anyone has experience with this scenario or knows the official Apple behavior, I’d really appreciate your help. Thanks!

I'm trying to distribute one-time use offer codes for a non-consumable IAP, but every redemption attempt fails at the App Store with the error: Unable to Purchase This promotional offer is not available. My setup: the app is in Ready for Distribution state, the IAP is Non-Consumable and Approved, and the offer is a Free one-time use offer available in all 175 territories. I generated a batch of 500 production codes which are active and were created more than 24 hours ago. I've already ruled out the usual suspects: the app is installed from the public App Store (not TestFlight), the test Apple IDs have never purchased this IAP before, the storefront is included in the offer's territories, and the IAP works correctly when purchased at regular price. The error reproduces across multiple users, devices, and Apple IDs, and each failing code is still unredeemed. Has anyone successfully shipped non-consumable offer codes since the October 2025 rollout? Thanks!

I am testing auto renewing subscriptions for a macOS program in Xcode with a local Storekit file. I have renewals set to occur every minute for testing. I quit the app, and watch renewals appear in the Debug transaction manager window. Each is marked unfinished. When I start the app, I call a function that is supposed to get unfinished transactions and finish them. In one of those "I swore it worked the other day", I am now finding it isn't working. The unfinished transaction remain marked as unfinished. func getUnfinished() async { for await verificationResult in Transaction.unfinished { guard case .verified(let transaction) = verificationResult else { continue } await transaction.finish() } } If I add an AppStore.sync() right before looping on Transaction.unfinished, it works (i.e., cleans up unfinished transactions), but I get an alert I have to click through. do { try await AppStore.sync() } catch { print("DEBUG UNFINISHED: AppStore.sync() failed: \(error)") } Any idea why Transaction.unfinished isn't fetching unfinished transactions for me (without the AppStore.sync)?

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!