Dear Apple Support Team, Hello! I am currently developing the in-app subscription functionality using Apple IAP API and have encountered a serious technical issue while processing subscription data. I would like to report this issue to you. Issue Description: When calling the subscription API endpoint, the same OriginalTransactionId returns inconsistent results. Specifically, a particular transaction ID (let's call it TransactionId_A) should belong to the subscription order with OriginalTransactionId_A, but it is currently incorrectly associated with OriginalTransactionId_B. This issue severely affects our ability to accurately manage and process subscription data. Here are the relevant log details for your reference: API Endpoint Requested: https://api.storekit.itunes.apple.com/inApps/v1/subscriptions/{TransactionId_A} (Note: The link is a placeholder for the actual API endpoint.) Log Information on February 21, 2025, at 09:40:09: { "AppAccountToken": "{AppAccountToken}", "BundleId": "{BundleId}", "Currency": "CNY", "Environment": "Production", "ExpiresDate": {ExpiresDate}, "InAppOwnershipType": "PURCHASED", "IsUpgraded": false, "OfferDiscountType": "", "OfferIdentifier": "", "OfferType": 0, "OriginalPurchaseDate": {OriginalPurchaseDate}, "OriginalTransactionId": "{OriginalTransactionId_A}", "Price": {Price}, "ProductId": "{ProductId}", "PurchaseDate": {PurchaseDate}, "Quantity": 1, "RevocationDate": 0, "RevocationReason": 0, "SignedDate": {SignedDate}, "Storefront": "CHN", "StorefrontId": {StorefrontId}, "SubscriptionGroupIdentifier": "{SubscriptionGroupIdentifier}", "TransactionId": "{TransactionId_A}", "TransactionReason": "PURCHASE", "Type": "Auto-Renewable Subscription", "WebOrderLineItemId": "{WebOrderLineItemId}" } Log Information on March 21, 2025, at 09:38:49: { "AppAccountToken": "{AppAccountToken}", "BundleId": "{BundleId}", "Currency": "CNY", "Environment": "Production", "ExpiresDate": {ExpiresDate}, "InAppOwnershipType": "PURCHASED", "IsUpgraded": false, "OfferDiscountType": "", "OfferIdentifier": "", "OfferType": 0, "OriginalPurchaseDate": {OriginalPurchaseDate}, "OriginalTransactionId": "{OriginalTransactionId_B}", "Price": {Price}, "ProductId": "{ProductId}", "PurchaseDate": {PurchaseDate}, "Quantity": 1, "RevocationDate": 0, "RevocationReason": 0, "SignedDate": {SignedDate}, "Storefront": "CHN", "StorefrontId": {StorefrontId}, "SubscriptionGroupIdentifier": "{SubscriptionGroupIdentifier}", "TransactionId": "{TransactionId_A}", "TransactionReason": "PURCHASE", "Type": "Auto-Renewable Subscription", "WebOrderLineItemId": "{WebOrderLineItemId}" } From the above logs, it is evident that the same transaction (TransactionId_A) returns different OriginalTransactionId values at different times, which is clearly not expected and severely impacts our ability to correctly process and manage subscription data. I hope you can address and investigate this issue as soon as possible. If you need any further information or assistance, please feel free to contact me. Thank you for your support! Best regards!

While reviewing the Apple Documentation, I came across a potential issue in one of the examples that I believe is worth addressing. The example appears to compare strings instead of integers, which could lead to unexpected behavior in production environments. Specifically, in the line where originalMajorVersion (a string) is compared with newBusinessModelMajorVersion (also a string) using <: if originalMajorVersion < newBusinessModelMajorVersion This comparison performs a lexicographical check rather than evaluating the numerical values of the strings. As a result, strings like "10" would incorrectly be considered less than "2", which is not the desired behaviour when comparing version numbers. I have reported this via the Feedback assistant (FB16432337) but at the time of posting this there has been no reply at all (23 days) Supporting business model changes by using the app transaction do { // Get the appTransaction. let shared = try await AppTransaction.shared if case .verified(let appTransaction) = shared { // Hard-code the major version number in which the app's business model changed. let newBusinessModelMajorVersion = "2" // Get the major version number of the version the customer originally purchased. let versionComponents = appTransaction.originalAppVersion.split(separator: ".") let originalMajorVersion = versionComponents[0] if originalMajorVersion < newBusinessModelMajorVersion { // This customer purchased the app before the business model changed. // Deliver content that they're entitled to based on their app purchase. } else { // This customer purchased the app after the business model changed. } } } catch { // Handle errors. }

Hello, For In App Purchases with a renewable subscription, does the originalTransactionId change in the following scenarios? Case 1: A user subscribes to a subscription A within a Subscription Group SG1. The user then cancels it at the end of the month. Comes back later to subscribe to the same subscription A within the same Subscription Group SG1. Case 2: A user subscribes to a subscription A within a Subscription Group SG1. The user then cancels it at the end of the month. Comes back later to subscribe to subscription B within the same Subscription Group SG1.

Both the legacy StoreKit API and the new StoreKit 2 API return the incorrect storefront countryCode. My actual Apple ID region is Germany, and my Sandbox test user is set to France, yet the SDK consistently returns USA. Expected Results: The returned storefront countryCode should reflect the correct region - sandbox user region if signed in and real user region if not signed in with sandbox). Actual Results: Returned country code is USA with both SKPaymentQueue.default().storefront?.countryCode and await Storefront.current?.countryCode. Signing out/in, device reboot and even reset do not help, I'm stuck with USA storefront.

I am getting the subject error while simulating Free trial. It is in console. Free trial proceeds but I cant figure out the error meaning. I could not find anything similar on the net or documentation. iOS 18.1 StoreKit2 SwiftUI Has anyone had similar issue that could advise ?

I’m testing an auto-renewable subscription on TestFlight. Now the user can't re-purchase the same product – Apple just restores the old (expired) one, and no payment sheet appears. How can I let the same TestFlight user re-subscribe to an expired product? Do I have to create a new productId for every test cycle?

Hi. If the app is in landscape only and when the SKStoreProductViewController is presented, the safeArea changes to what looks like a portrait mode safe area. When the SKStoreProductViewController is dismissed, the safeArea does NOT revert back to the original values. Is there a way to force the safeArea to "reset"? I've submitted some bug tickets through Apple Feedback but I haven't received any response about it. The below code will pop up the SKStoreProductViewController and if you have a UIView that is constrained to the safe area, then you can visibly notice that the safe area is changed and doesn't go back. I have tested this on iPhone 14 Pro, iPhone 15, and iPhone 16 Pro and in the Simulators. The incorrect behavior happens on those and probably more. Thanks. #import "ViewController.h" #import &amp;lt;StoreKit/StoreKit.h&amp;gt; @interface ViewController () @property (nonatomic, strong) SKStoreProductViewController *productViewController; @end @implementation ViewController - (IBAction)buttonTapped:(id)sender { self.productViewController = [[SKStoreProductViewController alloc] init]; NSDictionary *parameters = @{ @"id" : @"6443575749" }; [self.productViewController loadProductWithParameters:parameters completionBlock:^(BOOL result, NSError * _Nullable error) { [self presentViewController:self.productViewController animated:YES completion:^{ // presented // The panel that is constraint to the safe area visibly shows that the safe area is no longer correct. }]; }]; } @end

I try to call Get Transaction Info from App Store Server API, and the transactionId is for a Non-consumable type product, but it is odd that there are so many different transactionId and they have a same originalTransactionId { "bundleId": "${bundleId}", "environment": "Production", "inAppOwnershipType": "PURCHASED", "originalPurchaseDate": 1691220528000, "originalTransactionId": "${originalTransactionId}", "productId": "${productId}", "purchaseDate": 1691220528000, "quantity": 1, "signedDate": 1692590989925, "storefront": "USA", "storefrontId": "143441", "transactionId": "${originalTransactionId}", "transactionReason": "PURCHASE", "type": "Non-Consumable" } the defination of Non-Consumable is can only purchase once for same apple account. But why there would have originalTransactionId?

Our application is currently under review, and we are still facing issues because we receive a 401 Unauthorized response from the App Store Connect API when using the production environment. Our app integrates with Chargebee for subscription management, and in production, Chargebee is unable to authenticate with the App Store Server API. This results in a 401 Unauthorized error, preventing the user’s subscription from being synced correctly into our system. Interestingly, the same configuration works in the sandbox environment, but fails in production. We’ve tried authenticating using JWTs generated from multiple keys (including App Store Connect API / Team Keys with both Admin and App Manager access, and also In-App Purchase keys), all with the same result — sandbox access works, production does not. Here is our example code for testing with JWT token: const jwt = require('jsonwebtoken'); const fs = require('fs'); const https = require('https'); const config = { keyId: '<key_id>', issuerId: 'issuer_id', bundleId: 'bundle_id', privateKey: fs.readFileSync('path_to_key') }; const { keyId, issuerId, bundleId, privateKey } = config; const now = Math.floor(Date.now() / 1000); const jwtToken = jwt.sign( { iss: issuerId, iat: now, exp: now + 60 * 10, // 10 minutes is fine for test aud: 'appstoreconnect-v1', bid: bundleId }, privateKey, { algorithm: 'ES256', header: { alg: 'ES256', kid: keyId, typ: 'JWT' } } ); console.log('Generated JWT:\n', jwtToken); // prod const originalTransactionId = '<prod_transaction_id>'; const hostname = 'api.storekit.itunes.apple.com'; // sandbox // const originalTransactionId = '<sandbox_transaction_id>'; // const hostname = 'api.storekit-sandbox.itunes.apple.com' const options = { hostname, port: 443, path: `/inApps/v1/history/${originalTransactionId}`, method: 'GET', headers: { Authorization: `Bearer ${jwtToken}`, 'Content-Type': 'application/json', }, }; const callAppStoreConnectApi = async () => { const req = https.request(options, (res) => { console.log(`\nStatus Code: ${res.statusCode}`); let data = ''; res.on('data', (chunk) => { data += chunk; }); res.on('end', () => { console.log('Response Body:\n', data || '[Empty]'); }); }); req.on('error', (e) => { console.error('Request Error:', e); }); req.end(); }; callAppStoreConnectApi(); With this code, we were able to authenticate successfully in the sandbox environment, but not in production. I read in this discussion: https://developer.apple.com/forums/thread/711801 that the issue was resolved once the app was published to the App Store, but I haven’t found any official documentation confirming this. Does anyone know what the issue could be?

Hi everybody! I'm desperately looking for help as I'm stuck with a rather fundamental problem regarding StoreKit2 - and maybe Swift Concurrency in general: While renovating several freemium apps I'd like to move from local receipt validation with Receigen / OpenSSL to StoreKit2. These apps are using a dedicated "StoreManager" class which is encapsulating all App Store related operations like fetching products, performing purchases and listening on updates. For this purpose the StoreManager holds an array property with IDs of all purchased products, which is checked when a user invokes a premium function. This array can have various states during the app's life cycle: Immediately after app launch (before the receipt / entitlements are checked) the array is empty After checking the receipt the array holds all (locally registered) purchases Later on it might change if an "Ask to Buy" purchase was approved or a purchase was performed It is important that the array is instantly used in other (Objective-C) classes to reflect the "point in time" state of purchased products - basically acting like a cache: No async calls, completion handler, notification observer etc. When moving to StoreKit2 the same logic applies, but the relevant API calls are (of course) in asynchronous functions: Transaction.updates triggers Transaction.currentEntitlements, which needs to update the array property. But Xcode 16 is raising a strict error because of potential data races when accessing the instance variable from an asynchronous function / actor. What is the way to propagate IDs of purchased products app-wide without requiring every calling function as asynchronous? I'm sure I'm missing a general point with Swift Concurrency: Every example I found was working with call-backs / await, and although this talk of WWDC 2021 is addressing "protecting mutable states" I couldn't apply its outcomes to my problem. What am I missing?

Hi all, I have a simple prototype subscription for a recurring monthly for $0.29 cheap! And it works great! But it only works great at sub time. It's stuck in the sandbox, constantly giving me "currently subscribed" status even though I’ve done a bunch of things: Force-quit the app. Deleted and re-installed it. Rebooted my phone. Signed out of media purchases. Looked on AppStore connect to try to find anything that seems like it’d let me fix this All efforts in vain. I'm trying to avoid fully logging out of my iCloud account on my phone. Any other thoughts?

works perfectly on android but doesn't work at all on IOS and i have used the same bundle id and product ids on both stores. The error that i get on IOS is : "IAP initialization failed: NoProductsAvailable - No Product returned from store" Here are the things that i've done: Created an App ID on the apple developer portal with the correct capabilities I have enabled the correct capabilities on the xcode project Unity Framework is embed and signed, Storekit (do not embed) In singin and capabilities in-app purchases is there I am using testflight to submit the app with a distribution certificate that appears to be valid I've checked the the bundle identifier and it's the same everywhere (unity project, xcode project, App ID) All of the products are cleared for sale and are in the status "ready to submit" I always uninstall the old app version before testing the new one My banking updates are still processing does this effect TestFlight IAP Paid Apps Agreement is in Pending User Info state does this effect also I still haven't filled out the tax forms, so I'm wondering if I need to complete them before my app's in-app purchases (IAPs) work in TestFlight.

Hello, I’m experiencing an issue with StoreKit 2 when passing a new appAccountToken for each purchase request. Case-ID: 15948169 (for DTS reference) Description of the Problem When initiating a purchase, I generate a new UUID to use as the appAccountToken: let serverTransactionId = UUID() let options: Set<Product.PurchaseOption> = [ .appAccountToken(serverTransactionId) ] let result = try await product.purchase(options: options) Expected Behavior: Each new purchase should return the updated appAccountToken that I pass into the purchase options. Actual Behavior: The payload response after success always contains the same appAccountToken from the very first transaction. It ignores subsequent UUIDs I pass and keeps reusing the original one. This causes issues because the same identifier is being reused across multiple transactions, making it difficult to map purchases to the correct user session. Steps to Reproduce Generate a fresh UUID using UUID(). Pass it as .appAccountToken when calling purchase(). Complete the transaction in the sandbox environment. Inspect the payload response → The appAccountToken value is always the same as the first one used, not the newly provided one. Additional Info I do have a focused test project that reproduces this issue. The issue appears specific to appAccountToken persistence across multiple transactions. Has anyone else experienced this behavior with StoreKit 2? Is this expected (Apple caching the first token) or could this be a bug?

I am implementing promotional codes for auto-renewing subscriptions in my app. I need to create the codes and have them link to a discounted auto-renewing subscription. So my normal 1 month subscription is $24.99, I would like to offer users (new subscribers and existing/expired subscribers) the ability to enter a promo code that discounts the price of the first month to $4.99, then $24.99 after the initial first month. All users, regardless of whether or not they have has a previous subscription or not should be able to use this code for this discount. From what I am seeing in documentation, promo codes are only available to users that have had a subscription previously? Currently I am receiving the response "Offer Not Available" with the error: <SKPaymentQueue: 0x2815f0d60>: Payment completed with error: Error Domain=ASDServerErrorDomain Code=3904 "Offer Not Available" UserInfo={NSLocalizedDescription=Offer Not Available I simply do NOT understand why apple engineers have to make something that should be somewhat straightforward, be SO COMPLEX, then when you try to figure out whats going wrong, no meaningful error to troubleshoot. WTF I have tried this on users that have had a previous subscription and still the same error.

We are facing an issue where some users send receipts with an empty 'in_app' attribute during server validation. We are using the API described here: https://developer.apple.com/documentation/appstorereceipts/verifyreceipt After a purchase, we validate the receipt on the server and call finishTransaction in the app. Most receipts are fine, but this issue affects some users. The documentation states that an empty 'in_app' attribute means no valid purchases: https://developer.apple.com/documentation/appstorereceipts/responsebody/receipt/in_app#discussion Our questions are: When is a receipt with an empty 'in_app' attribute generated? How should we handle such receipts? Thank you for your help. Best regards,

In my app’s IAP products, before enabling free trials, the App Store Server Notifications V2 callbacks all returned the correct notificationType. For auto-renewable subscriptions, when they were about to expire, the notificationType was either DID_RENEW or EXPIRED. A small number of cases(DID_FAIL_TO_RENEW) failed to renew due to billing issues, which was expected. However, after I enabled a 7-day free trial for the auto-renewable products, I noticed that in the App Store Server Notifications V2 callbacks, almost all users (except those who manually turned off auto-renewal) received notificationType = DID_FAIL_TO_RENEW. According to the documentation, DID_FAIL_TO_RENEW indicates a billing issue renewal failure, but in this case it seems like all renewals are being marked as failed. I’ve observed that for users who cancel during the free trial, the callbacks look normal: first a DID_CHANGE_RENEWAL_STATUS notification, then an EXPIRED notification when the trial ends. That flow seems correct. However, for users who do not cancel the trial, almost all callbacks show DID_FAIL_TO_RENEW. Does this mean every remaining user has a billing issue? I also noticed on the Developer Forums that other developers have reported the same issue — receiving a large number of DID_FAIL_TO_RENEW notifications specifically when free trials convert to paid subscriptions: https://developer.apple.com/forums/search?q=DID_FAIL_TO_RENEW Could someone clarify: under normal circumstances, when a free trial transitions to a paid subscription and fails, should the App Store Server Notifications V2 notificationType indeed be DID_FAIL_TO_RENEW, or should it be a different type(e.g. EXPIRED)? And is it expected behavior that almost all free trial conversions return DID_FAIL_TO_RENEW?

You can still renew your membership within the next 8 days and your apps will remain available on the App Store during this time. Open the Apple Developer app on your iPhone, iPad, or Mac. Sign in to your account, tap/click Renew, and follow the prompts. I'm getting this message but renew button is not visible in Developer App or on website. How to to renew?

I have a macOS app where I am testing the in app subscription purchase using Xcode. When I trigger the purchase using this code, a dialog is shown in the upper right of my screen, which cannot be moved and just has a "cancel" button. How can I accept the test purchase? let result = try await product.purchase()

There is an issue with StoreKit. The line let products = try await StoreKit.Product.products(for: ids) doesn't always work correctly. Sometimes it returns an array with the correct data, and sometimes it returns an empty array. I'm passing the correct ids to products(for:). This problem only occurs when using the sandbox environment (in TestFlight builds). In the App Store version, everything works fine. StoreKit configuration is none. All IAPs are approved. Everything was working fine before this. The problem was discovered on May 1, 2025.

Hello all, I am new to implementing payments in an app, and thus completely at sea here. I have created a small app that I have set a one-time (non-consumable) payment for a premium version. In the Xcode simulator (on all platforms) and on any physical test devices I have tried, the payment works as expected. I have a sandbox account and various test accounts, both dummy and actual real accounts (friends and family). Everywhere everything works perfectly fine. Yet, when I submit for review I get a rejection with this contents: We found that your in-app purchase products exhibited one or more bugs which create a poor user experience. Specifically, the app still failed to load the in-app purchase. Please review the details and resources below and complete the next steps. Review device details: Device type: iPad Air (5th generation) OS version: iPadOS 18.6 Next Steps When validating receipts on your server, your server needs to be able to handle a production-signed app getting its receipts from Apple’s test environment. The recommended approach is for your production server to always validate receipts against the production App Store first. If validation fails with the error code "Sandbox receipt used in production," you should validate against the test environment instead. Additionally, note that the Account Holder must accept the Paid Apps Agreement in the Business section of App Store Connect before paid in-app purchases will function. Resources Learn how to set up and test in-app purchase products in >the sandbox environment. Learn more about validating receipts with the App Store. Steps I have done: I have signed all agreements and all bank account details are in order. Everything in the In-app-purchases section of the AppStoreConnect in an Active state. I have triple checked that the configuration of the in-app purchases is correct (product IDs, amounts, etc.) I have created test accounts and tested in sandbox What I don't understand from the reviewer's response is what receipts validation are they talking about? I have no payment servers (the whole concept of using Apple's in-app-purchases service is to not have to deal with my own payment implementation). The StoreKit documentation specifically reads: For each transaction that represents a current purchase, your app delivers the purchased products. To validate purchases, you can verify transactions on your server, or rely on StoreKit’s verification. So now I am confused. The reviewer's response is so vague, and so completely deprived of details that I have no idea what to do... Does the problem concern the product purchase trigger and the that in production environment it does not trigger? Is it that I haven't implemented a receipt validation? Do I need to? Although the documentation mentions that it can be done by StoreKit, I couldn't find anything concerning how to do it :( Can someone give me a hand please? Cheers, Alex