Product.SubscriptionInfo.isEligibleForIntroOffer(for: "21340582") In the production environment, I have already used the intro offer for this group, but this method still returns true.

A purchase can result in success with verificationResult .unverified. Is there a list of reasons for which the transaction might be unverified and how should i handle it in my app? From my understanding, a successful unverified transaction means the user has already paid for the purchase. So, do i just ignore the unverified transaction or do i provide content to the user anyways?

Some users cannot repurchase a subscription SKU after it has expired. Flow: User previously subscribed. User canceled and the subscription fully expired. After weeks, user reinstalls the app and taps the same SKU. StoreKit does not create a new purchase transaction. Instead, StoreKit always returns the old expired transaction in updatedTransactions. Therefore, the user is permanently unable to purchase the SKU again. We have already tried: Adding payment observer at app launch Calling finishTransaction for all transactions Clearing queue at startup SKReceiptRefreshRequest Server-side verifyReceipt Ensuring subscription is truly expired (not in grace/retry) Not calling restoreCompletedTransactions None of these resolved the issue. StoreKit still only sends the old transaction and never generates a new one. Expected behavior: A new purchase transaction should be created when user taps the expired subscription SKU. Actual behavior: StoreKit repeatedly pushes the old expired transaction, blocking new purchases. We can provide: Some users cannot repurchase a subscription SKU after it has expired. Flow: User previously subscribed. User canceled and the subscription fully expired. After weeks, user reinstalls the app and taps the same SKU. StoreKit does not create a new purchase transaction. Instead, StoreKit always returns the old expired transaction in updatedTransactions. Therefore, the user is permanently unable to purchase the SKU again. We have already tried: Adding payment observer at app launch Calling finishTransaction for all transactions Clearing queue at startup SKReceiptRefreshRequest Server-side verifyReceipt Ensuring subscription is truly expired (not in grace/retry) Not calling restoreCompletedTransactions None of these resolved the issue. StoreKit still only sends the old transaction and never generates a new one. Expected behavior: A new purchase transaction should be created when user taps the expired subscription SKU. Actual behavior: StoreKit repeatedly pushes the old expired transaction, blocking new purchases. We can provide: Affected user’s base64 receipt verifyReceipt full response Transaction logs (transactionIdentifier, original_transaction_id, productIdentifier, state) Please help investigate why StoreKit is not allowing a new subscription purchase. Affected user’s base64 receipt verifyReceipt full response Transaction logs (transactionIdentifier, original_transaction_id, productIdentifier, state) Please help investigate why StoreKit is not allowing a new subscription purchase.

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.

We are running into exceptions when trying to parse Purchase Date and Original Purchase Date from the base64 encoded receipt. Expected RFC 3339 format of ASN.1 Field Value is: yyyy-MM-ddTHH:mm:ssZ but we end up getting back 2025-04-22T19.49.03Z. Started to happen on 3rd Dec 2024.

Environment iOS 18.1+ StoreKit External Purchase Link Entitlement (EU) App distributed via App Store in France Problem Summary I'm implementing external purchase links for EU users using ExternalPurchaseCustomLink. While the implementation works correctly in my TestFlight testing, some production users experience token(for:) returning nil. Implementation Following Apple's documentation, my flow is: Check eligibility using ExternalPurchaseCustomLink.isEligible If eligible, call ExternalPurchaseCustomLink.token(for: "ACQUISITION") Store the token for use in the external purchase flow // Simplified implementation guard #available(iOS 18.1, *) else { return } let isEligible = await ExternalPurchaseCustomLink.isEligible guard isEligible else { return } // This returns nil for some users despite isEligible being true let token = try await ExternalPurchaseCustomLink.token(for: "ACQUISITION") Configuration Entitlement: com.apple.developer.storekit.external-purchase-link is present Info.plist: SKExternalPurchaseCustomLinkRegions set to ["fr"] App is only available in France via App Store Observed Behavior For affected users: ExternalPurchaseCustomLink.isEligible returns true token(for:) returns nil (not throwing an error) The token generation was never previously called for these users Questions Under what conditions does token(for:) return nil when isEligible is true? Is there additional validation I should perform before calling token(for:)? Are there known issues with token generation on specific iOS versions? Any guidance on debugging this issue would be appreciated.

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

We have 2 monthly subscription tiers that are part of a subscription group, and always have been part of this group. Both are configured with a 1 month trial introductory offer. According to the documentation for auto-renewable subscriptions,: Users can subscribe to one subscription product per group at a time. And yet several users have managed to start trials of both products in this group simultaneously, which converted to paid subscriptions after the expiration of the trials, and now are being concurrently billed by Apple for both. How do we completely prevent this from happening?

Hello, Since updating to iOS 26 Beta 3, I’ve been experiencing an issue where transactions purchased through the normal in-app purchase flow continue to be reported as updated and unfinished—even after calling the finish() function. Please resolve this promptly.

Honestly, don't know how to test it in sandbox. I'm confused on if I need a sandbox to actually test out my in app purchase. Do I need to download something? Someone please help.

I tried to apply a promotional offer to a subscribed user. When I tested it in the Sandbox environment, it did not show the promotional payment popup but returned a “restored” status. However, when I tested it in the Xcode environment, it correctly displayed the payment popup, but after I tapped the Subscribe button, it showed an “Unable to Purchase” popup like this: And in the console I could see this error: Received error that does not have a corresponding StoreKit Error: Error Domain=AMSErrorDomain Code=305 "Server Error The server encountered an error" UserInfo={AMSURL=http://localhost:56862/WebObjects/MZBuy.woa/wa/inAppBuy, AMSDescription=Server Error, NSDebugDescription=Server Error The server encountered an error, AMSServerErrorCode=3903, AMSStatusCode=200, AMSServerPayload={ "cancel-purchase-batch" = 1; dialog = { defaultButton = ok; explanation = "Contact the developer for more information.\n\n[Environment: Xcode]"; initialCheckboxValue = 1; "m-allowed" = 0; message = "Unable to Purchase"; okButtonString = OK; }; dsid = 17322632127; failureType = 3903; jingleAction = inAppBuy; jingleDocType = inAppSuccess; pings = ( ); }, AMSFailureReason=The server encountered an error} Could someone help me resolve this issue? I’ve been struggling with it for two days and feeling exhausted...

If an app on the App Store still uses StoreKit 1 (a.k.a. the Original StoreKit) to handle In-App Purchases, would IAPs work for users who download such app on iOS 26.2? Would the app allow the users to purchase an IAP via StoreKit 1 or would it be impossible to buy the IAP on iOS 26? The iOS Documentation says that SKPaymentQueue (which is a part of StoreKit 1) is "Deprecated" and "No longer supported.", with the support being for iOS 3.0–18.0. Does this mean that apps using StoreKit 1 won't be able to make IAP purchases when running on iOS 26?

Hi, I am experiencing an issue where my in-app purchase products cannot be fetched from App Store Connect during sandbox testing, despite all products being properly configured. ERROR MESSAGE: When testing on a physical iOS device, I receive the following error: "Error fetching offerings - The operation couldn't be completed. (RevenueCat.OfferingsManager.Error error 1.) There's a problem with your configuration. None of the products registered in the RevenueCat dashboard could be fetched from App Store Connect (or the StoreKit Configuration file if one is being used)." All products show status "READY_TO_SUBMIT" with the warning: "This product's status (READY_TO_SUBMIT) requires you to take action in App Store Connect before using it in production purchases." I have 2 subscriptions and 4 Consumable in-app purchases set up in App Store Connect. VERIFICATION COMPLETED: Bundle ID matches exactly in App Store Connect, Xcode project, and RevenueCat dashboard Product IDs match exactly between App Store Connect, RevenueCat, and application code Paid Applications Agreement is signed and active (Signed on 12/9 morning, everything shows as active) All products are in "Ready to Submit" status with complete metadata All products are properly linked to the app in App Store Connect Testing on physical iOS device (not simulator) with sandbox account signed in via Settings > Developer section Products have been in "Ready to Submit" status for 8 hours I have researched this error and verified the common causes (Paid Agreements, Product ID mismatches, Bundle ID mismatches) are all correctly configured on my end. QUESTION: Is this an issue on Apple's end, or are there additional requirements for products in "Ready to Submit" status to be available in sandbox testing? I have been unable to test my in-app purchases despite all configuration appearing correct. Thank you for your assistance.

Hi everyone, I’m experiencing an issue with In-App Purchases during App Review. What works My consumable IAP products load correctly using StoreKit2. TestFlight (sandbox) purchases work perfectly. Localizations are filled in and valid. Paid Apps Agreement, banking, and tax forms are active. IAP products are properly created in App Store Connect and marked as “Developer Action Needed” only because they wait for approval with the new binary. What fails During review I received: “We found that your in-app purchase products exhibited one or more bugs which create a poor user experience. Specifically, we were not able to complete a purchase.” They didn’t provide any more technical details. Additional context The StoreKit configuration file is not included in the app archive. Product identifiers perfectly match those in App Store Connect. StoreKit2 purchase() works as expected on TestFlight. The app does not use server-side receipt validation - purchases are handled purely through StoreKit2 APIs, as recommended. My questions What could cause a situation where TestFlight purchases work but App Review cannot complete a purchase? Does Apple expect server-side receipt validation even for simple one-time consumables? Could there be a delay or sync issue causing IAP products to not be available to the reviewer yet? Is there anything I should check on the App Store Connect side beyond what I already verified? Any help or hints would be greatly appreciated - I’m stuck because everything works in sandbox but fails only for reviewers. Thanks!

I'm encountering a crash on app launch. The crash is observed in iOS version 17.6 but not in iOS version 18.5. The only new notable thing I added to this app version was migrate to store kit 2. Below is the error message from Xcode: Referenced from: <DCC68597-D1F6-32AA-8635-FB975BD853FE> /private/var/containers/Bundle/Application/6FB3DDE4-6AD5-4778-AD8A-896F99E744E8/callbreak.app/callbreak Expected in: <A0C8B407-0ABF-3C28-A54C-FE8B1D3FA7AC> /usr/lib/swift/libswift_Concurrency.dylib Symbol not found: _$sScIsE4next9isolation7ElementQzSgScA_pSgYi_tYa7FailureQzYKFTu Referenced from: <DCC68597-D1F6-32AA-8635-FB975BD853FE> /private/var/containers/Bundle/Application/6FB3DDE4-6AD5-4778-AD8A-896F99E744E8/callbreak.app/callbreak Expected in: <A0C8B407-0ABF-3C28-A54C-FE8B1D3FA7AC> /usr/lib/swift/libswift_Concurrency.dylib dyld config: DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/usr/lib/libLogRedirect.dylib:/usr/lib/libBacktraceRecording.dylib:/usr/lib/libMainThreadChecker.dylib:/usr/lib/libRPAC.dylib:/System/Library/PrivateFrameworks/GPUToolsCapture.framework/GPUToolsCapture:/usr/lib/libViewDebuggerSupport.dylib``` and Stack Trace: ```* thread #1, stop reason = signal SIGABRT * frame #0: 0x00000001c73716f8 dyld`__abort_with_payload + 8 frame #1: 0x00000001c737ce34 dyld`abort_with_payload_wrapper_internal + 104 frame #2: 0x00000001c737ce68 dyld`abort_with_payload + 16 frame #3: 0x00000001c7309dd4 dyld`dyld4::halt(char const*, dyld4::StructuredError const*) + 304 frame #4: 0x00000001c73176a8 dyld`dyld4::prepare(...) + 4088 frame #5: 0x00000001c733bef4 dyld`start + 1748``` Note: My app is a Godot App and uses objc static libraries. I am using swift with bridging headers for interoperability. This issue wasn't observed until my last version in which the migration to storekit2 was the only notable change.

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.

Hello — quick question about App Store Server Notifications migration. We have a live app using Production V1 notifications for recurring in-app subscriptions. We plan to switch the Production webhook to V2. After the switch: Will notifications for existing subscriptions be delivered in V1 format, V2 format, or will it depend (e.g., queued V1 retries vs new V2 deliveries)? If V1 retries are queued, how long should we expect overlap/retries to continue? Any recommended cutover best practices (support both formats, revert process, etc.)? Happy to share additional details. Thanks.

We’ve recently observed an escalating number of complaints from AlipayHK users regarding duplicate charges when completing transactions via Apple Pay. While no similar issues have been reported by users of other credit card providers integrated with Apple Pay, the problem appears isolated to AlipayHK transactions. Key Details: Multiple users confirm being charged twice for single transactions. Complaints are increasing in frequency, indicating a potential systemic issue. No overlapping reports from non-AlipayHK payment methods at this time. To safeguard customer trust and ensure seamless payment experiences, we kindly request Apple’s support in: Investigating whether the root cause stems from Apple Pay’s transaction handling. Collaborating with AlipayHK (if necessary) to resolve the issue promptly. Providing guidance on interim measures to prevent further duplicate charges. Could Apple confirm if this is a known issue and share a timeline for resolution? We’re eager to assist in any way possible to mitigate impact on users. Thank you for your urgent attention to this matter.

We are facing a serious issues with in app purchases in our app. We offer 3 IAP: auto-renewable subscription 1W, auto-renewable subscription 1Y, non-consumable one-time purchase (LifeTime access) In our case 90-95% of transactions fail and we mostly get SKError code=2 . Sometime purchase fails several times for the same user so it’s very hard to believe that user intentionally cancels transaction for the same product 4 or even 5 times in a row. It happens regardless iOS version, device model, our app version. We've checked multiple threads with the same issue but coudn't find any solution. We do not offer any promotions, product identifiers are valid... Some users are able to make a purchases without any issues.

关于通过Advanced commerce API 创建SKU，有几个问题： 1、通过Advanced commerce API创建的自动续费订阅的SKU是否支持推介优惠、促销优惠？如果可以，是在苹果connect设置吗？ 2、已订阅通过connect创建的SKU的用户，是否可以重复订阅通过Advanced commerce API创建的SKU？还是要通过Advanced commerce API变更订阅？ 3、Advanced commerce API创建的SKU ,用户订阅成功后，续费的扣款是否仍由苹果发起？还是由开发者自行发起？