Hello, We are facing an issue with In-App Purchases (subscriptions) in two iOS apps built with React Native + react-native-iap. Issue Some users receive the error: E_CONNECTION_CLOSED during the purchase flow. However: The payment is successfully deducted via the App Store. The subscription appears in the user's Apple ID subscription list. But on our side: The app does not receive the StoreKit transaction callback No receipt or transaction ID is delivered Our backend cannot validate the purchase. Restore Purchases When affected users try Restore Purchases, StoreKit returns: No purchases found even though the subscription is visible in their Apple ID. Most affected users are from India, and many payments are made via UPI through App Store billing. Has anyone experienced a case where: *the user is charged *the subscription exists in Apple ID *but StoreKit never returns the transaction or receipt? Any suggestions on how to recover these transactions would be greatly appreciated. Thanks!

Thanks!

Hi everyone, I’ve been encountering a recurring issue with the App Store Server API over the past 48 hours, specifically regarding the Get Transaction Info endpoint. Endpoint: GET /inApps/v1/transactions/{transactionId} Environment: Production Error Code: 4040010 (TransactionIdNotFound) The Issue When a user completes a purchase in our app, the client-side sends the transactionId to our backend for validation. However, when our server immediately calls the Get Transaction Info API using that ID, it frequently returns a 4040010 error, stating that the transaction ID cannot be found. Key Observations Eventual Consistency Delay: If we implement a retry logic and wait for 2 to 5 minutes, the exact same transactionId eventually becomes queryable and returns a valid signedTransactionInfo. Notifications vs. API: Interestingly, our server receives the App Store Server Notifications V2 (webhook) for these transactions almost instantly. The notifications contain the correct data, but the "Pull" API seems to lag behind the "Push" notification system. Recent Spikes: This behavior started occurring frequently within the last 2 days. Prior to this, the API was almost always near-instant. Questions Has anyone else noticed a spike in 4040010 errors or increased indexing latency in the Production environment recently? Is there a recommended "grace period" or backoff strategy when querying for a new transactionId? Apple's documentation doesn't explicitly mention an expected delay between a successful purchase and its availability via the Server API. Any insights or confirmation of similar issues would be greatly appreciated!

Hello, We are currently testing subscription purchases in the Sandbox environment, and we are seeing an issue that we do not fully understand. When we attempt a single subscription purchase, multiple purchase signals or transaction events are sometimes delivered from Sandbox for what appears to be just one payment attempt. In some cases this happens twice, and in other cases we have seen it occur as many as five to seven times. The number is inconsistent each time, and we have not been able to identify any clear pattern. At this point, we are not sure whether this is a known instability or limitation of the Sandbox testing environment, or whether there may be something incorrect in our own implementation or configuration. Has anyone experienced similar behavior when testing auto-renewable subscriptions in Sandbox? If so, we would really appreciate any guidance on what to check. Thank you.

Hi everyone, I’ve been encountering a recurring issue with the App Store Server API over the past 48 hours, specifically regarding the Get Transaction Info endpoint. Endpoint: GET /inApps/v1/transactions/{transactionId} Environment: Production Error Code: 4040010 (TransactionIdNotFound) The Issue When a user completes a purchase in our app, the client-side sends the transactionId to our backend for validation. However, when our server immediately calls the Get Transaction Info API using that ID, it frequently returns a 4040010 error, stating that the transaction ID cannot be found. Key Observations Eventual Consistency Delay: If we implement a retry logic and wait for 2 to 5 minutes, the exact same transactionId eventually becomes queryable and returns a valid signedTransactionInfo. Notifications vs. API: Interestingly, our server receives the App Store Server Notifications V2 (webhook) for these transactions almost instantly. The notifications contain the correct data, but the "Pull" API seems to lag behind the "Push" notification system. Recent Spikes: This behavior started occurring frequently within the last 2 days. Prior to this, the API was almost always near-instant. Questions Has anyone else noticed a spike in 4040010 errors or increased indexing latency in the Production environment recently? Is there a recommended "grace period" or backoff strategy when querying for a new transactionId? Apple's documentation doesn't explicitly mention an expected delay between a successful purchase and its availability via the Server API. Any insights or confirmation of similar issues would be greatly appreciated!

The developer payment page is returning a 503 error, preventing me from making the payment. Why is this happening? I need to complete this payment urgently.

Hello, My app was rejected on iPad (iPad Air 11-inch M3, iPadOS 26.2.1) with two related issues: Guideline 2.1 – Performance – App Completeness “The app exhibited one or more bugs that would negatively impact users. Bug description: the premium subscription cannot be loaded properly.” Guideline 3.1.2 – Business – Payments – Subscriptions “The submission did not include all the required information for apps offering auto-renewable subscriptions.” I am using StoreKit 2 with SubscriptionStoreView to present the auto-renewable subscription. During development: Subscriptions load correctly in the simulator (sandbox). On real devices, I test without a local StoreKit configuration file to fetch products from App Store Connect. The subscription UI (title, duration, price) displays correctly when products are returned. At the time of review, the Paid Apps Agreement was not active. I suspect this may have caused the subscription products to fail loading on the review device. Since then: Paid Apps Agreement is now Active. SubscriptionStoreView should automatically show required metadata. Because the subscription failed to load on iPad during review, the required information (title, price, duration) was not visible, which likely triggered the 3.1.2 rejection. Additionally, in TestFlight I sometimes see inconsistent behavior where the app appears but cannot be installed (“App Not Available”). Also, my app was rejected, but the subscription is still waiting for review. I would really appreciate guidance on the following: Am I potentially missing any required configuration that could prevent products from loading in production? Is there any propagation delay after activating the Paid Apps Agreement that could affect product availability? If I am overlooking something in configuration or testing, please let me know what I should specifically verify before resubmitting. Thank you very much for your help.

We are implementing promo/offer codes for our iOS app’s subscription in-app purchases and have several technical questions regarding validation, receipt data, and integration. Could you please provide guidance on the following points? Testing/Validating Custom Codes Without Production Release: How can we validate custom promo/offer codes in a non-production environment? Current documentation indicates promo codes only work in production, requiring app submission and future release date setup for testing. Receipt Data for Redeemed Codes: The receipt currently includes only offer_code_ref_name, not the exact redeemed code (e.g., “ABC123”) entered by the user. Is there a way to retrieve the specific offer code used via receipts, App Store Server API, or other endpoints? Server-Side Validation Best Practices: What are the recommended best practices for server-side validation of offer codes, including using App Store Server API for transaction verification? Passing appAccountToken for Coupons: How can we pass an appAccountToken when users redeem coupon/offer codes (e.g., via presentOfferCodeRedeemSheet or redemption flows)? StoreKit purchase options support it for regular purchases but not redemption sheets. Callbacks on Coupon Redemption: Is there a client-side callback or notification (e.g., via updatedTransactions or StoreKit observers) when a user successfully redeems a coupon code in the app? Server notifications are received, but app-side feedback appears unreliable.

I am testing a consumable in-app purchase in the StoreKit sandbox and I am seeing behavior that does not seem correct on repeat purchase attempts. Product details Product ID: album.credit.v2 Type: Consumable Test environment: iOS device + StoreKit sandbox Purchase flow triggered from my Flutter app using Apple IAP What happens First purchase attempt works My backend receives the confirmation The album is granted correctly On the second purchase attempt of the same consumable, I do not get a normal new purchase flow Instead, StoreKit returns the product as restored My app then cancels the attempt because a restored transaction arrived during checkout Expected behavior Because this product is a consumable, each purchase attempt should behave like a new purchase and allow the user to buy it again. Actual behavior On the second attempt, the transaction update comes back as restored instead of a new successful consumable purchase. Relevant logs First successful purchase: [ProPurchasePage] ✅ Pay tapped. starting=false iap=true albumProd=album.credit.v2 proProd=pro.monthly [IAP] update: id=album.credit.v2 status=PurchaseStatus.restored pendingComplete=false err=null [IAP] expected=album.credit.v2 starting=true appleFlow=true [ProPurchasePage] album credit success status=PurchaseStatus.restored receiptLen=5334 [AppleIapService] Sending Apple IAP confirmation for albumId=ariie_west_pretty_girl_summer, buyerUid=PYjgu9TMCieCVDLIdTuawY5k4Ay2 [AppleIapService] appleIapConfirm response status: 200 [AppleIapService] appleIapConfirm applied for albumId=ariie_west_pretty_girl_summer buyerUid=PYjgu9TMCieCVDLIdTuawY5k4Ay2 After that, the purchase is written correctly on my side: "libraryAlbums": [ { "AlbumId": "ariie_west_pretty_girl_summer", "paid": true, "Quantity": 1 } ] Second and later attempts: [ProPurchasePage] ✅ Pay tapped. starting=false iap=true albumProd=album.credit.v2 proProd=pro.monthly [ProPurchasePage] buyConsumable (album.credit.v2) returned: true [IAP] update: id=album.credit.v2 status=PurchaseStatus.restored pendingComplete=false err=null [IAP] expected=album.credit.v2 starting=true appleFlow=true [IAP] restored arrived during album checkout — cancelling attempt Question Is this expected StoreKit sandbox behavior for a consumable, or does this suggest: a StoreKit sandbox issue, a problem with how the product is configured in App Store Connect, or a transaction-handling issue in the app/plugin layer? Also, is there any Apple-recommended handling for repeated consumable purchases when sandbox keeps surfacing a restored status?

Our game application is developed based on StoreKit 1, and an exception occurs on iOS 26.4: after players complete a payment, the finishTransaction method fails to properly remove the transaction from the SKPaymentQueue; as a result, when players restart the app, the system still triggers the retry process for this transaction (reconciliation of unpaid orders). Has anyone encountered this issue? If there is a solution, we would appreciate it if you could share it with us.

Hello, I have a question regarding how prorated refunds are reflected when a user upgrades a subscription. From my understanding, when a user upgrades to a higher-tier subscription, the remaining value of the current subscription is refunded as a prorated amount, typically represented as REFUND_PRORATED or PRORATED_CREDIT. However, when reviewing the available transaction history and refund-related data (including the App Store Server API and transaction history endpoints), I cannot find any field or record that clearly indicates: the actual prorated refund amount, or the credit applied when upgrading to another subscription In other words, while the concept of REFUND_PRORATED seems to exist conceptually, I cannot identify where the actual prorated value or credit applied to the upgrade is exposed in the transaction or refund history. My questions are: Is there any way to retrieve the actual prorated refund or credit amount when a user upgrades a subscription? Is this information available through the App Store Server API (e.g., Get Transaction History) or any other API endpoint? If not, is there any recommended method to determine how much of the previous subscription was credited toward the upgraded subscription? Any clarification would be greatly appreciated. Thank you for your help.

In Getting started with In-App Purchase using StoreKit views and the corresponding sample project, Store simultaneously enumerates Transaction.unfinished and Transaction.updates. Since, "if your app has unfinished transactions, the updates listener receives them once, immediately after the app launches," it appears that Transaction.unfinished would also receive the same unfinished transactions causing handle(updatedTransaction:) to be called for twice for each transaction, causing consumables to be double-counted. Is this a bug in the sample? Is there more information on concurrent execution of unfinished and updates?

I have an iOS and iPadOS app that also runs on macOS Catalyst. The user is able to view their subscription using the SubscriptionStoreView with two SubscriptionOptionGroups. The documentation does not mention these are supported on macOS Catalyst and the app crashes when attempting to show the SubscriptionStoreView on macOS Catalyst. If not supported, how can the user manage their subscription on macOS?

Hello DTS team, the request review from StoreKit is not working in iOS 26.4 beta 3. I have filed a feedback (FB22157147). Sample code: import SwiftUI import StoreKit struct ContentView: View { @Environment(\.requestReview) private var requestReview @State private var count = 0 var body: some View { VStack { Button("Increase Count") { count += 1 } Text(count, format: .number) .font(.largeTitle) } .onChange(of: count) { if count == 3 { Task { try await Task.sleep(for: .seconds(2)) requestReview() print("Request Review triggered!") // On iPadOS 26.4 beta 2 & 3, requestReview() does not trigger any review system sheet when testing in Xcode 26.3 // Works on iOS 26.3.1 } } } } }

Hello, I am currently testing In-App Purchases for my app in the Sandbox environment. Our app has two types of products: Auto-renewable subscriptions Non-renewing subscriptions When testing auto-renewable subscriptions, I can see the subscription in the Sandbox account management screen, and I can perform actions such as: Viewing the active subscription Cancelling the subscription Upgrading or downgrading the subscription However, when testing non-renewing subscriptions, I cannot find the purchase history anywhere in the Sandbox account management screen. Because of this, I cannot verify whether the non-renewing subscription purchase was recorded correctly. My question is: Where can I check the purchase history for Non-Renewing Subscriptions in the Sandbox environment? Is there a specific place in: App Store Connect Sandbox account settings Or somewhere else where these purchases can be reviewed? Thank you in advance for your help.

在iOS 26.4 beta3版本中，当前支付完成，获取的票据是上次支付的票据，在拉起一笔支付成，获取的又是上次支付的票据

<Apple Developer Program许可协议>已更新并需要查阅。若要更新现有App和提交新 App，账户持有人必须登录账户，查看并接受更新后的协议。 app开发者会费 续费以后 app内购获取不到商品了，经排查可能是这个协议需要重新签署，签署以后多久可以重新在沙盒测试中获取到商品信息。

Hi, I am submitting auto-renewable subscriptions for the first time for a brand new iOS app (never approved before). Setup: App ID has In-App Purchase capability enabled Subscriptions created under a subscription group All metadata (pricing, localization, availability) completed Subscriptions currently show In Review Testing via TestFlight build Bundle ID matches App Store Connect Using react-native-iap (StoreKit under the hood) When calling: await getSubscriptions({ skus }) I consistently get: products fetched: 0 ProductsUnavailableError Also, the app version page does not show the “In-App Purchases and Subscriptions” section. Question: For a brand new app, will StoreKit return empty products while the first subscriptions are in review? Do the first subscriptions need to be approved and/or attached to a new app version before they become available in TestFlight sandbox? Thanks for any clarification.

Background: My app uses a third-party SDK for payments, and it uses Original StoreKit internally for IAP payments. Now I'm getting ready to migrate to StoreKit2, and during the transition, users may use either method to initiate payments, and there's no way to avoid the coexistence of StoreKit2 and Original StoreKit. Problem: When a user has an unfinished transaction, if the app is restarted, both StoreKit2 and Original StoreKit will receive a notification of the transaction: Original StoreKit's '-paymentQueue:updatedTransactions:' method StoreKit2's 'Transaction.updated' method resulting in duplicate calls to the shipping API. My current treatment is to only add '-paymentQueue:updatedTransactions:' to listen for unfinished transactions. Even if the user is using StoreKit2 to initiate the payment, if the transaction is not Finished, it will be fetched via this method after restarting the app to process this transaction. Is this approach feasible and are there any best practices for this scenario? To summarize: Is it feasible to fetch unfinished StoreKit2 transactions via Original StoreKit methods when StoreKit2 coexists with Original StoreKit? Is there a recommended way

I’d like to confirm the expected behavior of StoreKit 2 in the Sandbox environment regarding unfinished consumable transactions across devices. Scenario: Device A and Device B are signed in with the same Sandbox Apple ID A consumable in-app purchase is completed on Device A The transaction may be verified or unverified, but transaction.finish() is not called The app is then launched on Device B and listens for Transaction.updates Question: In this scenario, is it expected that Device B will or will not receive a callback for this unfinished consumable transaction? Or is it by design that unfinished consumable transactions are not guaranteed to be delivered across devices, regardless of verification state?