Could you tell me about the specifications of the winback offer? If a user is eligible for the winback offer, will the winback offer sheet be displayed every time the app is launched? Or will the OS adjust the display frequency in some way?

login sandbox account at setting > app store > sandbox account. download my app from testflight purchase subscription is fine. stop renew subscription. after subscription expired, delete app, then download from testflight again. tried to restore purchase, the result count always zero

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.

I have three questions about verify receipt I use this api （https://buy.itunes.apple.com/verifyReceipt）to verify receipt is success or not. But since last month, this interface has started to return an error(21002). I see this document (https://developer.apple.com/documentation/appstorereceipts/verifyreceipt) say its Deprecated. My question is, is the error suddenly returned recently because the interface has been deprecated or for some other reason? (I haven't modified my code about this recently) I can not understand this document: （https://developer.apple.com/documentation/appstorereceipts/validating_receipts_on_the_device） Does this mean that in the new version, as long as the app returns a payment success (purchaseDetails.status == PurchaseStatus.purchased), the payment is guaranteed to be successful, and my server does not need to request payment result verification from Apple's server? I try to use this (https://github.com/apple/app-store-server-library-java) to get TransactionInfo, but I dont konw to get Transaction status to know is success or not. my java server code : AppStoreServerAPIClient client = new AppStoreServerAPIClient(encodedKey, keyId, issuerId, bundleId, environment); TransactionInfoResponse response = client.getTransactionInfo(transactionId); (bug i can note get transaction status, how do i konw this Transaction is success or not)

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) } }

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 want to test the "Remove from Sale" scenario in Sandbox. I set my subscription to "Remove from Sale" for all territories in App Store Connect, but I can still make new purchases and auto-renewals continue in the Sandbox environment. Is this a known limitation? Or is there a specific way to make this work for testing? If it can't be tested, I'd like to know the expected production behavior. What changes occur in the App Receipt and what App Store Server Notification is sent?

We've been approved for the Advanced Commerce API. After receiving the approval, we completed the initial setup requirements (submitted a generic product ID and shared our subscriptions page deep link). When testing the Migrate Subscription to Advanced Commerce endpoint in the sandbox, we receive a 5000000 error. What could be the reason/s for it? There is no information, and the API call we make includes all required parameters. Could it be related to the fact that our new generic product ID status is "Missing Metadata"? Is there a way to understand what the issue is on Apple's side?

Hey guys, somehow I used my real ID(not sandbox test ID) to purchase a non-consumable item in the TestFlight package, no actual payment was made, but this payment record cannot be erased. Even though I know the transaction ID, I cannot initiate a refund like using refundRequestSheet(). Does anyone know how to deal with this, or there is no way to solve it?

I am currently developing an auto-renewal subscription in-app purchase for my app. Currently, the subscription items have already been approved in appStoreConnect, and the .store file is synced with appStoreConnect, so the subscription items are displayed well and the test is also progressing well. However, when I build without using the .store file to perform sandbox testing, the subscription items do not appear and response.invalidProductIdentifiers appears. Is there anything I need to do additionally so that the subscription items can appear in response.products? ps. The bank account item in the contract is in 'processing' status, and the paid app contract status is 'waiting for user information'.

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?

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

Cannot retrieve products for iap or subscription on simulator iPhone 16 and real device iPhone XR also. lutter: IAPError(code: storekit2_products_error, source: app_store, message: The operation couldn’t be completed. (NSURLErrorDomain error -1009.), details: The operation couldn’t be completed. (NSURLErrorDomain error -1009.)) flutter: Error fetching IAP products: IAPError(code: storekit2_products_error, source: app_store, message: The operation couldn’t be completed. (NSURLErrorDomain error -1009.), details: The operation couldn’t be completed. (NSURLErrorDomain error -1009.))

Hello! We are tryign to test refund notifications and we've implemented a debug button trigger the refund of a purchase done with a sandbox account. The problem is that the refund view displays a Cannot Connect message and nothing happens. No error messages appear in the console. Anything we are doing wrong?

Dear App Store Engineering Team, I am writing to request official confirmation regarding the behavior of App Store Server Notifications when migrating a live application from V1 to V2. Context: Our application has been live since 2008 and currently utilizes App Store Server Notifications V1. We have a large database of existing legacy subscribers. We are preparing to switch our Production environment setting in App Store Connect from "Version 1" to "Version 2". Our Questions: When we change the setting in App Store Connect to Version 2: Global Format Switch: Does this setting apply immediately to ALL notifications, including those triggered by subscriptions that originated years ago (legacy users)? Payload Consistency: Will renewals for existing legacy subscriptions continue to arrive in the JSON V1 format, or will they immediately start arriving in the V2 JWS (signedPayload) format? Our expectation is that the switch is global and all future notifications (regardless of subscription age) will be sent as V2 JWS payloads, but we require official confirmation to ensure our backend handles the migration without service interruption. Thank you for your assistance.

Can you implement storekit2 for in app purchases for a flutter project?

アプリ内課金を実装しようとしていますが、サーバサイドのセキュリティに関してについて質問です。 StoreKit２を使えばアプリとApp Store Connect間のレシート検証は不要だが、 購入情報をサーバーで管理する場合は アプリからサーバーに購入情報を渡す際にレシート検証する必要があると考えるがその認識であっているか教えていただきたいです。

The same store kit configuration file works in iOS and iPadOS, but not in macOS for the same multi platform application project with a single scheme. Here’s a more detailed write up with the sample code and screenshots. When the simple app is run on https://www.reddit.com/r/SwiftUI/s/KJsYcggWOa EDIT: I’m using Xcode 16.4

Hello, My app "MyCourses" (bundle id: com.ahmedbaqer.mycourses) was rejected under Guideline 2.1 because "No action followed when we tapped the button to subscribe to a course" on iPadOS 26.1. When I run the same code (version 1.0.0 (11)) from Xcode on a real device using a StoreKit configuration file (In App Purchase.storekit), the purchase flow works correctly: When I tap the "Subscribe via Apple" button, the App Store purchase sheet appears. The purchase completes successfully and unlocks the course. I use the in_app_purchase Flutter plugin and queryProductDetails to load products. However, when I install the build via TestFlight (and in App Review), tapping the same "Subscribe via Apple" button does nothing – which matches the behavior described by App Review. From my logs it looks like queryProductDetails is returning an empty productDetails list in that environment. For In‑App Purchases: I created 7 non‑consumable products in App Store Connect. Their Product IDs exactly match the IDs in my In App Purchase.storekit file (used only for local Xcode testing). All IAPs are now in "Waiting for Review" status and are linked to the iOS app version 1.0.0 (11) in the “In‑App Purchases and Subscriptions” section. At the time of the original review, some IAPs were in "Developer Action Needed / Rejected" state, so I suspect queryProductDetails may have returned no products and the reviewer saw no action after tapping the button. My questions: When IAP products are in "Waiting for Review" and linked to the app version, should queryProductDetails return them during App Review / TestFlight, or do they need to be fully approved first? Is there any additional configuration required so that the subscribe button reliably shows the App Store purchase sheet for reviewers (for example, any specific StoreKit / sandbox settings)? Are there recommended best practices to show a clearer error state when queryProductDetails returns no products, so that App Review understands this is a configuration / IAP-status issue rather than a UI bug? Any guidance from Apple engineers or other developers who faced a similar situation would be greatly appreciated. Thanks in advance.

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