Issue Description When using the App Store Server API endpoint GET v2/history/{transactionId} to retrieve transaction history for a specific transaction, I'm observing unexpected changes in the appTransactionId field across related transactions in the same subscription group. Important Context: This is a "clean" auto-renewable subscription with no user intervention - the user has had continuous auto-renewals without any upgrades, downgrades, cancellations, or resubscriptions. The subscription has been renewing automatically and successfully throughout the entire period. API Call GET v2/history/1000000000000001 Response Data The API returns the following transaction history, where I notice the appTransactionId values are inconsistent across what should be a straightforward auto-renewal sequence: Note: The data below has been sanitized for privacy protection (IDs, bundle identifiers, etc. have been replaced with example values), but the logical relationships, date sequences, and the core issue remain identical to the original data. Array ( [0] => Array ( [transactionId] => 1000000000000001 [originalTransactionId] => 1000000000000001 [webOrderLineItemId] => 1000000000000001 [bundleId] => com.example.myapp [productId] => MonthlySubscription [subscriptionGroupIdentifier] => 20000000 [purchaseDate] => 1743784032000 [originalPurchaseDate] => 1743784034000 [expiresDate] => 1746376032000 [quantity] => 1 [type] => Auto-Renewable Subscription [inAppOwnershipType] => PURCHASED [signedDate] => 1751868174651 [environment] => Production [transactionReason] => PURCHASE // Original purchase [storefront] => USA [storefrontId] => 143441 [price] => 100000 [currency] => USD [appTransactionId] => 700000000000000001 // Different value ) [1] => Array ( [transactionId] => 1000000000000002 [originalTransactionId] => 1000000000000001 [webOrderLineItemId] => 1000000000000002 [bundleId] => com.example.myapp [productId] => MonthlySubscription [subscriptionGroupIdentifier] => 20000000 [purchaseDate] => 1746376032000 [originalPurchaseDate] => 1746347349000 [expiresDate] => 1749054432000 [quantity] => 1 [type] => Auto-Renewable Subscription [inAppOwnershipType] => PURCHASED [signedDate] => 1751868174651 [environment] => Production [transactionReason] => RENEWAL // First auto-renewal [storefront] => USA [storefrontId] => 143441 [price] => 100000 [currency] => USD [appTransactionId] => 700000000000000002 // Same for renewals ) [2] => Array ( [transactionId] => 1000000000000003 [originalTransactionId] => 1000000000000001 [webOrderLineItemId] => 1000000000000003 [bundleId] => com.example.myapp [productId] => MonthlySubscription [subscriptionGroupIdentifier] => 20000000 [purchaseDate] => 1749054432000 [originalPurchaseDate] => 1749025657000 [expiresDate] => 1751646432000 [quantity] => 1 [type] => Auto-Renewable Subscription [inAppOwnershipType] => PURCHASED [signedDate] => 1751868174651 [environment] => Production [transactionReason] => RENEWAL // Second auto-renewal [storefront] => USA [storefrontId] => 143441 [price] => 100000 [currency] => USD [appTransactionId] => 700000000000000002 // Same as previous renewal ) [3] => Array ( [transactionId] => 1000000000000004 [originalTransactionId] => 1000000000000001 [webOrderLineItemId] => 1000000000000004 [bundleId] => com.example.myapp [productId] => MonthlySubscription [subscriptionGroupIdentifier] => 20000000 [purchaseDate] => 1751646432000 [originalPurchaseDate] => 1751617840000 [expiresDate] => 1754324832000 [quantity] => 1 [type] => Auto-Renewable Subscription [inAppOwnershipType] => PURCHASED [signedDate] => 1751868174651 [environment] => Production [transactionReason] => RENEWAL // Third auto-renewal [storefront] => USA [storefrontId] => 143441 [price] => 100000 [currency] => USD [appTransactionId] => 700000000000000002 // Same as previous renewals ) ) Questions Is this behavior expected? Should the appTransactionId change between the original purchase and subsequent renewals within the same subscription group, especially when there are no user actions (upgrades/downgrades/cancellations/resubscriptions)? What determines the appTransactionId value? The documentation doesn't clearly explain when this identifier might change or what triggers a new value. This is particularly puzzling since this is a straightforward auto-renewal scenario. How should we handle this in our backend logic? Should we treat transactions with different appTransactionId values as separate entities, or should we rely on originalTransactionId for grouping related subscription transactions? Is this a known issue? We've seen similar concerns in the community regarding transaction ID inconsistencies, but this specific case involves a clean auto-renewal flow without any complicating factors.

As a developer I have a question I would like cleared up. We offer two tiers of annual subscriptions in our apps. These subscriptions are under the same subscription group in App Store connect. My question is, if a user purchases tier 1 of the annual subscription for $10.00, and uses it for 6 months; then chooses to upgrade to tier 2 which costs $20.00 per year. Would the user be pro-rated the difference in price i.e. charge only another $10.00 at the time of the upgrade., or are they charged $20.00 and then refunded the difference in their remaining lower tier subscription? I keep finding inconsistent answers across the Apple community forums on this.

I am attempting to test non-consumable sandbox purchases, however I am unable to select the "Approve Transaction" option after initiating a purchase. Leaving the transaction in a permanent pending state. I can view the transaction in the transaction manager by navigating to Debug -> Storekit -> Manage Transactions.. but the only available options to select are "Refund Transaction" or "Delete Transaction". What am I missing about Xcode or my environment that is preventing me from testing this purchase flow? Some more information about my set up. I have a .storekit file synced to AppStore Connect with my product Id. There's a StoreKitTestCertificate.cert saved in the project. I've tried running the build on my phone as Debug, Release and ReleaseForRunning all with the same behavior after making a purchase. My phone is logged into a sandbox test user apple account in the developer iOS settings

Looking to update one of my apps that uses SKStoreReviewController +requestReview (deprecated) to AppStore.requestReview(in:) umm...I have a few of questions... Why is an NSViewController parameter required? It's really not so uncommon for an AppKit app to just use NSWindowController with a window that does not use NSViewController... It should be possible to present the review request in a standalone alert (attached to a window is preferred IMO but it still should be possible to ask in separate window). 3)...why Swift..(err nevermind) Ideally: AppStore requestReview should take a NSWindow parameter but that parameter should be optional. If nil the request should be presented in a standalone window (like an alert). If non nil..present as a sheet on the window. Why a view controller? Maybe I'm missing something.

Regarding the offer codes in https://developer.apple.com/help/app-store-connect/manage-subscriptions/set-up-offer-codes, I set up some incorrect offer codes by mistake. Currently, I can only deactivate it but I can't delete it. Is it possible to let me delete the incorrect offer codes due to the below reasons? Thank you. I can't recreate the offer code due to error message This reference name is or has been used by another offer in this subscription group. When I use the offer code redemption view in https://developer.apple.com/documentation/SwiftUI/View/offerCodeRedemption(isPresented:onCompletion:), it shows all the deactivated offer codes. I don't want them to be displayed in the page.

Scenario: User is actively subscribed to Monthly Package From the Device App (Manage Subscriptions), user upgrades to Yearly Package Purchase completes successfully on device Issue: Do not receive any server notification for this action Month Package Purchase Date: 2025-11-11 19:06:45.537 +0600 Month to Yearly Upgradation Date: 2025-12-11 paymentReferenceId: 510002270528780

Is there an API Endpoint that I can call to check if user still have valid subscription? I want to be sure that his subscription renewal was succesful (ie: I dont want to give him another month/year/.. if his latest renewal wasnt successful) Would GET https://api.storekit.itunes.apple.com/inApps/v1/transactions/{transactionId} be the correct API endpoint to call? But I wonder, after subscription auto-renews, do we still use the same transactionId to check whether his subs is still valid?

After creating a new weekly subscription option, I get inconsistent results for subscriptionPeriod. In local testing with a synced or a un-synced StoreKit file I am getting unit == .week (as expected) whereas in TestFlight I am getting unit == .day. This makes unit.localizedDescriptionsomewhat unusable in the paywall. Am I missing something? Or is this bug or a limitation of StoreKit and/or TestFlight and/or newly created subscription options? Affected code (in a custom SubscriptionStoreControlStyle): private func priceDisplay(for pickerOption: Configuration.PickerOption) -> String { var result = "" if pickerOption.introductoryOffer != nil { result += NSLocalizedString("then", comment: "") + " " } result += pickerOption.displayPrice if let unit = pickerOption.subscriptionPeriod?.unit { result += " / " + unit.localizedDescription } return result } private func percentageSaved(for pickerOption: Configuration.PickerOption, allOptions: [Product]) -> Int? { guard let subscriptionPeriod = pickerOption.subscriptionPeriod, subscriptionPeriod != .weekly else { return nil } let weeklyOption = allOptions.first { otherOption in otherOption.subscription?.subscriptionPeriod == .weekly } guard let weeklyOption, weeklyOption.price > 0 else { return nil } let percentageSaved = 100 - (pickerOption.price / (weeklyOption.price * 52)) * 100 return Int((percentageSaved as NSNumber).doubleValue) }

I implemented consumable in-app purchases in an iPhone app using ProductView(). When I tap the payment button in ProductView(), I am taken to the payment screen and once the payment is completed the next code seems to be executed, so there doesn't seem to be a problem, but if I tap the payment button in ProductView() again, the next code is executed without taking me to the payment screen. This means that a single payment can be made multiple times. Can someone help? ProductView(id: "geminiOneMatch") .productViewStyle(.compact) .padding() .onInAppPurchaseCompletion { product, result in if case .success(.success(_)) = result { // 課金が成功した場合の処理 gemini.addOneMatch(amount: 20) popUpVM.geminiOneMatchPopUp = false dataManageVM.generateRespons(locale: locale) } }

Hello, I would like to ask about an Apple ID authentication behavior during in-app purchases. Our app uses a StoreKit 1 (SKPaymentQueue-based) implementation, and there are no differences in the in-app purchase logic between the TestFlight build and the App Store production build. However, we have observed that some users are prompted to enter their Apple ID password during in-app purchases. The observed behavior is as follows: On the first in-app purchase, the system prompts for the Apple ID password After the password is entered once, subsequent purchases proceed normally using Face ID (double side-button press) Even after deleting and reinstalling the app, or switching between TestFlight and App Store builds, the password prompt does not reappear if authentication has already occurred This behavior can occur even when the Apple ID already has an active auto-renewable subscription The only confirmed change on our side is: The app is now built with Xcode 26 instead of Xcode 18 Based on this, we are currently considering the following possible causes: A change in purchase authentication behavior due to the Xcode version update Expiration of the Apple ID purchase authentication session after a long period without purchases In addition to these points, we would like to ask: Are there any other common conditions or security policies in iOS or the App Store that may cause the system to require Apple ID password input during in-app purchases? Is this behavior considered expected under certain circumstances? We would appreciate your clarification on whether this is expected system behavior or if there are any implementation aspects we should further review. Thank you for your support.

I am trying to launch a PWA as an application on App Store, and got rejected cause of In-App Purchases. Application is about content generation and selling subscriptions for premium content. So thats why needed to implement In-App Purchases. I have created wrapper via PWABuilder. And it is looking great so far, now my question is about How can I implement In-App Purchases in the bundle which is already created. Any suggestions will be appreciated. More clarification:- I have that product running on Web right now, we have integrated Stripe for payment handling for subscriptions. If there is nothing we can do for In-App Purchases then we have to make purchases on website and then user will be able to experience the changes. We tried that, but then we got rejected for showing locked premium content on user's feed. Also can't show any CTA or Subscribe text or button.

Hello, is it allowed to include the action=write-review URL parameter in customer support emails to direct users to the App Store review page? Example: https://apps.apple.com/app/id[APP_ID]?action=write-review I want to make it easy for customers to leave feedback after positive support interactions, but only if it's compliant.

I am handling the buy subscription with this function const handleBuySubscription = async (productId) => { try { await requestSubscription({ sku: productId, }); setLoading(false); } catch (error) { setLoading(false); if (error instanceof PurchaseError) { errorLog({ message: [${error.code}]: ${error.message}, error }); } else { errorLog({ message: "handleBuySubscription", error }); } } }; but the requestSubscription({ sku: productId, }) does not return anything, and it is stuck at await

Hi everyone. I'm trying to use https://developer.apple.com/documentation/appstoreserverapi/get-transaction-info to retrieve order information. How can I get the refund status of an order through this API? Also, Apple's webhook notification for refunds includes fields like revocationReason and revocationType. Can these be retrieved through the API? I've noticed that some refund orders have these fields when retrieved using get-transaction-info api, but others don't. I don't know the reason for these differences. Could you please explain? Thank you very much.

I cannot explain how frustrating this is. Not that I want to compare to Android, but in 3 years of QA Testing my app, Android works like a dream, while iOS fights with me EVERY SINGLE STEP OF THE WAY. Hopefully someone here can tell me what I am missing/doing wrong/which god I must appease to get this to work. I have 3 REAL iPhones of varying iOS versions and ages. But they are all proper actual iPhones. We use google accounts at this company, so my primary email is a gmail one. I have created MANY sandbox accounts inside App Store Connect. Currently I have 2, and 2 of my devices (both 14's one of which is a Pro) have my Primary account as the main account for the device. But they both also have a Sandbox account which is simply my main email with a +sandbox in it to make it a new unique email. Here is the problem, nothing works as expected ever. I can install my Staging and Production apps from TestFlight, then I can make a subscription purchase as a customer would and I SHOULD see that subscription in my Sandbox right? That's the point of a Sandbox and TestFlight is it not? But in ALL cases whenever I try to view my 'Sandbox Subscriptions' it tells me I don't have any. Now, sometimes, very occasionally, I get a specific error message inside my app when attempting to make a purchase, this one states something like 'You already have a subscription, please restore it instead...' which makes no sense. Since it clearly states that I have none. But this message has a 'Manage' button to manage my subscriptions, tapping it lads me to a windows which amazing DOES have a subscription in it. But attempting to 'Cancel' it does nothing, just refreshes the screen to be the same. Now I think that this subscription is actually attached to the primary account on the device and NOT the sandbox account. So when this happens I cannot subscribe, I cannot restore, and I cannot manually alter the subscription within iOS. So I am stuck at this point. What am I doing wrong, am I setting this all up in the wrong order? Do I need to install some kind of profile or security cert, do I need to give a pint of blood to Imhotep? What am I missing. I even once sat on the phone for 90 minutes with an Apple Support Rep who took me through it step by step, same result. Also I just noticed that inside 'App Store Connect' when you look at the list of 'Sandbox' accounts there is a column for 'Last Purchase' which is entirely blank, apparently after a year of use I have NEVER purchased on the Sandbox, which is another reason I think my subs are going to the main email, not the sandbox one. I tried using the sandbox email as the main account for the whole device, I can't recall the result but it was worse and didn't work at all. So that's not it. https://developer.apple.com/help/app-store-connect/test-in-app-purchases/create-a-sandbox-apple-account/ The instructions on this page are not detailed enough and were not helpful to me. All I really want to know is how to fully setup a real actual iPhone for TestFlight and Sandbox testing of a app. WHat order do I create accounts, validate emails, attach to devices, login with etc etc etc. Step by step, nothing no matter how mundane missed out. A true idiots guide to making this work for me. Testing this on Android always takes 5 mins. iPhone, I'm lucky if I am done in half a day. Please help and thanks for reading!

Description of the Issue We are encountering issues with App Store Server Notifications, where the notification type received does not align with our expectations for subscription changes. Specifically, we receive DID_RENEW notifications in scenarios involving downgrades or intra-tier upgrades, which disrupts our backend subscription management logic and may lead to incorrect user subscription states and billing errors. Below are two reproducible scenarios with associated transaction data. Scenario 1: Downgrade from Premium Yearly (with 7-Day Trial) to Standard Yearly Steps to Reproduce: A user purchases the Premium Yearly subscription with a 7-day free trial (initial transaction ID: 700002116066502). On the day before the trial ends, the user downgrades to the Standard Yearly subscription via the App Store’s subscription management interface. Expected Behavior: We expect to receive a DID_CHANGE_RENEWAL_STATUS or a similar downgrade notification (e.g., DID_CHANGE_RENEWAL_PREF) to indicate the subscription plan has been downgraded, enabling immediate updates to the user’s subscription status. Actual Behavior: Upon downgrade, our server receives a DID_RENEW notification instead of a downgrade-specific notification. This causes our system to incorrectly interpret the action as a renewal of the Premium subscription rather than a downgrade to Standard, with no subsequent downgrade confirmation received. Relevant Transaction Data: New Transaction ID: 700002122810952 Notification Type: DID_RENEW Notification UUID: 26de9b0e-5d61-4893-b679-0bd18ae3d208 Original Transaction ID (Trial): 700002116066502 Scenario 2: Intra-Tier Upgrade from Standard Monthly to Standard Yearly Steps to Reproduce: A user purchases the Standard Monthly subscription. On the day before the monthly subscription expires, the user switches to the Standard Yearly subscription via the App Store’s subscription management interface. Expected Behavior: The original Monthly subscription expires normally, with a DID_EXPIRE notification received. Upon expiration, we expect a DID_RENEW or SUBSCRIBED notification for the new Yearly subscription to confirm its activation, allowing seamless transition of the user’s subscription plan. Actual Behavior: Immediately after the upgrade, our server receives a DID_RENEW notification for the new Yearly plan. No further notifications are received, including no DID_EXPIRE for the original Monthly subscription. This leaves our system unable to confirm the expiration of the Monthly plan, potentially resulting in duplicate active subscriptions in our records. Relevant Transaction Data: Transaction ID: 70002902074491 Notification Type: DID_RENEW Notification UUID: 3d35bc2f-e769-4549-bf50-d84d41b10342 Impact These notification discrepancies disrupt our subscription lifecycle management, potentially causing incorrect user entitlements, over-billing, and a degraded user experience. Requested Assistance Please confirm the correct notification types for these scenarios as per Apple’s documentation (e.g., App Store Server Notifications V2). Provide guidance on handling these edge cases, including any recent changes to notification logic. If this is a backend issue, please investigate the provided transaction IDs and Notification UUIDs. Thank you for your prompt assistance. We look forward to your response to help resolve this issue for our users. 问题描述： 我们在处理 App Store 订阅变更通知时发现，服务器接收到的通知类型与预期不符，具体表现为降级或同级升级场景下错误接收到 DID_RENEW 通知。这影响了我们后端订阅管理的逻辑，可能导致用户订阅状态和计费出现偏差。以下是两个可重现的场景及相关交易数据。 场景 1：高级年费（含 7 天试用）降级至标准年费 重现步骤： 用户购买高级年费订阅并开启 7 天免费试用（初始交易 ID：700002116066502）。 在试用期结束前一天，用户通过 App Store 的订阅管理界面降级至标准年费订阅。 预期行为： 我们预期会收到 DID_CHANGE_RENEWAL_STATUS 或类似的降级通知（如 DID_CHANGE_RENEWAL_PREF），以表明订阅计划已降级，从而允许我们立即更新用户订阅状态。 实际行为： 降级后，服务器立即收到 DID_RENEW 通知，而非降级相关通知。这导致系统误认为高级订阅仍在续订，而非降级为标准订阅，且后续未收到任何降级确认通知。 相关交易数据： 新交易 ID：700002122810952 通知类型：DID_RENEW 通知 UUID：26de9b0e-5d61-4893-b679-0bd18ae3d208 原始交易 ID（试用）：700002116066502 场景 2：标准月费订阅升级为标准年费订阅 重现步骤： 用户购买标准月费订阅。 在月费订阅到期前一天，用户通过 App Store 的订阅管理界面切换至标准年费订阅。 预期行为： 原月费订阅正常到期，预期收到 DID_EXPIRE 通知。 月费到期后，预期收到新年费订阅的 DID_RENEW 或 SUBSCRIBED 通知，以确认年费订阅开始，方便我们无缝切换用户订阅计划。 实际行为： 升级后，服务器立即收到新年费订阅的 DID_RENEW 通知。 后续未收到任何通知，包括原月费订阅的 DID_EXPIRE 通知。这导致我们无法确认月费订阅的到期状态，可能在记录中出现重复的活跃订阅。 相关交易数据： 交易 ID：70002902074491 通知类型：DID_RENEW 通知 UUID：3d35bc2f-e769-4549-bf50-d84d41b10342 影响： 这些通知异常干扰了我们的订阅生命周期管理，可能导致用户权益错误、潜在的重复计费以及用户体验下降。 请求协助： 请确认根据 Apple 文档（例如 App Store Server Notifications V2）在上述场景中应返回的正确通知类型。 请提供处理此类边缘场景的指导，包括通知逻辑的任何最新变更。 如果这是后端问题，请调查提供的交易 ID 和通知 UUID。 感谢您的及时协助，期待您的回复以帮助我们为用户解决问题。

Hey everyone, This might be a simple fix that I’m just overlooking, but I’ve been stuck on it for the past 48 hours. The issue is on my subscription screen — after a user completes a successful in-app purchase, the app doesn’t navigate to the main app like it’s supposed to. I’ve added logs, tried various fixes, and even asked AI for help, but nothing has worked. From what I can tell, it seems like my listeners aren’t being registered properly after the transaction. I’ve tried reinitializing them, moving them around, and testing different flows, but still no luck. If anyone has insight into how they’ve set this up or any suggestions I might not have considered, I’d really appreciate it. Thanks in advance!

According to the App Store Server API documentation , https://developer.apple.com/documentation/appstoreserverapi/price the price field "shows the total amount of the transaction for the quantity the customer purchased." However, in actual transaction notifications and responses from App Store Server API, the price field appears to represent the unit price, not the total price. For consumable in-app purchases with quantity > 1, the price field equals the unit price of a single item. The total user payment is only correct after multiplying by the quantity. When quantity > 1, the actual amount paid by the user only matches price × quantity, which contradicts the documentation. Please confirm whether the price field is intended to be: The unit price of a single item (requiring multiplication by quantity), or The total price including all quantities (as currently documented). If the former is correct, please update the documentation to clarify that the value represents the unit price, not the total amount.

Hi, I have a setup using App Store Server notifications, which has worked fine for a while now. However, I've never been able to successfully verify a purchase via Xcode, only via TestFlight. The reason for this is that the StoreKit transactions have numerical IDs (e.g. starting from 0, incrementing one-by-one), instead of UUIDs like in TestFlight/production. This means that often the backend will detect an existing transaction with the same ID and not complete the purchase. What are we meant to do here? If I send a custom ID to make it unique the backend won't accept this - I can ask them to change this for our dev environment but it's not ideal. What I'm after is a way to use UUIDs for transaction IDs when running via Xcode. Thanks

I’m implementing StoreKit External Purchase Custom Links (EU) and so far it is really painful. I am running into a strange, device-specific issue. On 3/4 devices it works. On one device I never get a token at launch nor before a transaction. isEligible is true everywhere. All devices have versions 18.5 and are located in Germany. Info.plist: SKExternalPurchaseCustomLinkRegions is set to EU storefront codes and I have followed every step in the documentation: https://developer.apple.com/documentation/storekit/externalpurchasecustomlink Good device: At launch → ACQUISITION = nil, SERVICES = token present. Works consistently. Faulty device: At launch → ACQUISITION = nil, SERVICES = nil. Same before transaction. No token ever reaches my server from this device. isEligible is true on both devices. Any experts or help on the matter?