In our app we are running into a few issues with pending purchases staying on receipt indefinitely. These are consumable purchases where we received the purchase succeeded from apple but then something went wrong on our servers to validate and confirm the purchase. At this point the purchase stays on the apple receipt indefinitely or until we confirm it. The problem is there are lots of scenarios where we can't confirm purchases anymore (like a game world expired/banned player/etc). So there's a few things I'd like to know to see how this could be handle correctly. 1- Was the user already charged, and if yes would they ever be refunded if the purchase is not confirmed (some sort of expiry)? 2- Is there a way to cancel this sort of pending transaction directly from the app or backend? 3- If one of these users asked for a refund from apple would this clear the purchase from the receipt? Any information would be greatI couldn't find a lot of info on this topic.

I tested a subscription with my developer account, it never charges but at the same time I can't cancel it anymore. It does not appear in the list of my official purchsed subscriptions. I tried to login to the sandbox with my developer account, but then when I click on "Manage" I just keep getting the error "Can't connect - retry". I have already tried to logout from all the services, App store, etc. and re-login, nothing worked. Is there anything I can do? Thanks in advance to anyone who can give any tips.

Question on token testing in development: Hello, I'm developing a React Native application using StoreKit External Purchase. I'm having difficulties testing the transaction token retrieval in the development environment. Specific questions: Is it possible to test the transaction token retrieval in development/sandbox environment? Is there a special testing mode for developers that would allow simulating token reception without going through the App Store? Are there specific debugging tools to verify proper token reception? Question on native implementation: Regarding the native implementation of StoreKit External Purchase: Is there detailed documentation on creating native modules for React Native that implement StoreKit External Purchase? Can you confirm if the following approach is correct for native implementation: Using NSClassFromString(@"ExternalPurchase") Calling presentNoticeSheetWithURL:completion: Retrieving the token in the completion block Are there any code examples for complete native implementation? Question on implementation validation: For validating StoreKit External Purchase implementation: How can we verify that our implementation is correct before App Store submission? Are there validation tools or automated tests to check compliance? What are common errors to avoid during implementation? Question on best practices: Regarding implementation best practices: What's the best way to handle potential errors during token retrieval? How to handle cases where the user cancels the transaction? What are the recommended security checks for server-side token validation? Question on documentation: I'm looking for additional resources on StoreKit External Purchase: Is there specific documentation for integration with frameworks like React Native? Are there complete code examples for native implementation? Where can I find information about testing and debugging best practices? Additional technical question: Technical implementation details: What's the correct way to handle the ExternalPurchase class initialization in React Native native modules? Are there specific requirements for the URL passed to presentNoticeSheetWithURL? How should we handle the token in the completion block to ensure it's properly passed back to React Native? Question on testing workflow: Testing workflow questions: What's the recommended testing workflow for External Purchase implementation? How can we verify the token format and validity before production deployment? Are there any tools or methods to simulate the complete purchase flow in development?

I would like to inquire about the originalTransactionId of StoreKit2. Users who purchase auto-renewal subscription products To re-purchase the same subscription item after cancellation and prior to refund If you receive a refund after cancellation and re-purchase the same subscription item If you do not renew immediately after expiration and re-purchase the same subscription after a long period of time I would like to ask if 1, 2, and 3 all use the same value as the original Transaction Id at the initial subscription. In the case of 3, if you re-purchase more than a few days after the last subscription purchase, please let me know if there are any detailed conditions such as the original Transaction Id not maintained.

I’m trying to determine the most appropriate modern method for detecting whether a user originally downloaded a paid app (prior to transitioning the app to freemium/IAP-based access). Historically, this was done by checking for a valid App Store receipt and using SKReceiptRefreshRequest to ensure a fresh one was available. However, SKReceiptRefreshRequest and many related aspects of StoreKit receipt handling are now deprecated in iOS 17+. The current Apple documentation on receipt validation still refers to SKReceiptRefreshRequest, which makes things unclear. With so many deprecations and the push toward StoreKit 2, what’s the recommended path to: Check for a valid App Store receipt Confirm that the app was originally purchased (as a paid app, not via IAP) Persist this info to exempt the user from paywalling the app in the future I don’t need to validate purchases of IAPs — just to detect a legacy paid app download. Any guidance on best practice for this use case, preferably using non-deprecated APIs (StoreKit 2 or otherwise), would be appreciated.

💬 Post Content Hello everyone, I’m currently testing In-App Purchases (auto-renewable subscriptions) for my iOS app, and I’m experiencing an issue where the product information cannot be fetched from StoreKit. ❓ Questions For sandbox testing, is it absolutely necessary to submit a new app version for review (with the in-app purchase included)? Or can I test subscriptions without submitting a new build to App Review? Under what conditions does the error IAPError(code: storekit_no_response, source: app_store, message: StoreKit: Failed to get response from platform.) 🧪 What I’ve Tried • Confirmed that the bundle identifier matches the App Store Connect record • Verified that In-App Purchase capability is enabled in Xcode • Ensured the sandbox tester account is logged in (Settings → App Store) • Removed the StoreKit configuration file to use the sandbox environment • Tried both real device and simulator (same error) • Accepted the Paid Apps Agreement in App Store Connect • Products are created but currently not yet submitted for review 🔍 Environment • App type: iOS app built with Flutter (using in_app_purchase plugin) • Build type: Archive build installed via Xcode (Run on device) and testFlight • StoreKit Configuration File: Currently removed (for sandbox test); • Status: Ready to submit in App Store Connect

I cannot test IAP using sandbox account that I logged on from settings, it keeps show my regular Apple ID when I try to test IAP from TestFlight This issue frustrate me and bunch of my colleagues, we cannot manage our subscription when sandbox account is default choosing Apple ID I've seen people complaining about this issue a lot Any help on resolving this issue would be really appreaciated

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?

Where the problem occurs: In-app purchase Non-ApplePay Non-local authentication login Environment where the problem occurs: Sandbox environment (Development environment, TestFlight environment) Problem handling process: Open page A in the app and purchase product B (auto-renewable subscription) on that page. User authentication is required to purchase product B. During the authentication process, the user needs to enter the Apple account and Apple account password. After completing the authentication, complete the purchase of product B. Problem in step 3: Why is FaceID or TouchID not used for authentication? Note: Face ID and Password -> iTunes Store and App Store -> Status is Enabled

In my understanding, with the latest court ruling in the US, iOS apps may decide to support web-based payments for subscriptions and in-app purchases. However, are we allowed to exclusively support web-based payments and not implement StoreKit at all?

I've been stuck with this rejection. Trial button 'greyed out' or non responsive. What they are seeing is my subscriptions not loading into the pay wall. We think its because the subscriptions haven't been reviewed and approved in order for them to populate the pay wall (activating the pay wall so it isn't 'greyed out'. Has anyone had and solved this issue?

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

In the app we're distributing, we've identified a user where the Get All Subscription Statuses API returns two original transaction IDs in the data response. This user has gone through cancellations and re-subscriptions since their initial purchase. Meanwhile, despite maintaining a continuous subscription, a notification suddenly arrives on the renewal date with original_transaction_id2. +---------------------------+---------------------------+---------------------+ | original_transaction_id | notification_type | subtype | +---------------------------+---------------------------+---------------------+ | original_transaction_id1 | SUBSCRIBED | INITIAL_BUY | ~ Repeated cancellations and re-subscriptions ~ | original_transaction_id1 | SUBSCRIBED | RESUBSCRIBE | | original_transaction_id2 | SUBSCRIBED | INITIAL_BUY | +---------------------------+---------------------------+---------------------+ Although it can be inferred from the interface definition of the API itself that multiple original transaction IDs may be returned, what causes multiple original transaction IDs to be returned? Furthermore, is it possible to reproduce the case where multiple original transaction IDs are returned in the sandbox environment provided by Apple? As for this app, it: Uses subscriptions through in-app purchases. Does not offer upgrades, downgrades, or crossgrades, having only one product. Has never undergone price increases or decreases. Is distributed exclusively in Japan.

Hello All, We continue to receive post backs for campaigns which were run 6 months back. Our understanding is post back window is only 3 months, so checking to see if this is expected or any documentation will help. We are on SKAN4.0

I want to build an app for ios using react native. preferably expo. The app will be for recording user experiences with technology. the SLUDGE that they face while navigating through technology. I want to have basic login, signup. The main feature would be to have 2 recording modes. First is record the screen and the front camera simultaneously. Second is to record the back camera and the front camera simultaneously. I can then patch the two outputs later on that is the screen recording and the front camera clip in post processing. I want to know if this is possible as I was told that react native and expo does not have the support yet. if not is there any library or another approach to make this app come alive.

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!

I enter the payment wall, there it takes more or less 3 to 4 minutes to show the plans, when I select the monthly plan the loader is shown and from there the pop up to make the purchase in sandbox does not appear, I have waited until a maximum of 50 minutes and it is not shown, I go back and close the app I do the same steps and I am still there, without showing the pop up. Doing this same process in xcode, everything happens immediately without any interruption.

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!

Hi, I am trying to obtain the subscription expiry date or purchase date from server using Storekit2 for my project. I have an account which is already having an active subscription but it still says no purchase found. Thanks

Hello, Can someone please tell me why the unlock button was unresponsive when tapped? The restore button worked. if let price = store.product?.displayPrice { Text(price) .font(.title2.bold()) .padding(.top, 4) } Button { Task { await store.purchase() } } label: { ZStack { if store.isLoading { ProgressView() .tint(.white) } else { Text("paywall.buy") .font(.headline) } } .frame(maxWidth: .infinity) .padding() } .background(.blue) .foregroundStyle(.white) .clipShape(RoundedRectangle(cornerRadius: 14)) .disabled(store.product == nil || store.isLoading) Button { Task { await store.restorePurchases() } } label: { Text("paywall.restore") }