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

Hi, I can't get into "manage" sandbox account. I either get to a screen to put my password in. Here there is no way to click "next" or "login". (I have tried pressing "enter" on my keyboard to no effect). Or I get directly into "Cannot Connect" page. I have tried this two days in a row. I have tried turning it off and on again. I have tried logging out and in. Device: iPhone 13 pro max, iOS: 16.0.3 (also tried the version before this)

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?

Hi, We're currently experiencing an issue with consumable In-App Purchases on our production iOS app. Until the end of May, everything was working as expected, but starting in early June, our app no longer receives any products when calling queryProductDetails() using Flutter’s in_app_purchase plugin (which utilizes StoreKit). Here’s what we’ve confirmed so far: The product IDs are correctly configured in App Store Connect, and all items are marked as “Approved.” No recent changes have been made to the bundle ID or the product IDs. The “Base Territory” setting was updated for each IAP item in early May. After that change, product retrieval and purchases were working normally through the end of May. This issue is happening on real devices in production, and multiple users are affected. The same functionality continues to work correctly on Android. All requested product IDs are being returned in the notFoundIDs list of the queryProductDetails() response. We're quite puzzled by this issue as no clear cause has been identified so far. Any thoughts on this issue would be much appreciated. Thank you!

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 added my first subscription to my app using StoreKit's SubscriptionStoreView. Everything worked as expected in the debug environment and also in TestFlight. So I submitted my app and subscriptions to App Store Connect, got everything Approved and released. After updating my app through App Store and checking the Subscription View, it just says "Subscription Unavailable. The subscription is unavailable in the current storefront." I waited around 3 days and still getting the same message. Now the very strange behavior starts. I went to App Store Connect, I made and edit to the subscription description, saved, removed the edit, saved, and submitted to review. 15 minutes later the subscriptions appear in my app and everything works as expected. After getting the edit approved, the Subscription View in my app again only showed the message "Subscription Unavailable. The subscription is unavailable in the current storefront." No user is able to see the subscriptions anymore, even though it worked as expected before the edit was approved. So I did the same as before. Again, make an edit to the subscription description, save, remove the edit, save, submit to review. 15 minutes later the subscriptions are again available in my app and it works as expected. This is definitely not the expected behavior and submitting the subscription edits every day is wasting the App Review Team's time as well as mine. I contacted Apple Developer Support but I didn't get any reply back (at least yet). I am not the only one experiencing this. I found a friend online who has the exact same issue, and is able to temporarily solve it by making an edit to the subscription description as well. So far it has been a huge headache, and we are losing customers this way. Please if anyone has experience with this problem, or has any suggestions, they will be greatly appreciated. Thank you so much, Tomas

I has sandbox account with Japanese local. When i build app directly to check, price is displayed in Japanese Currency. But when I install app from the Test Flight, price is always displayed in USD Currency. the issue is appear in iOS 18.5 How can i fix this issue ?

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.

Hi everyone, I’m seeing a consistent one-day discrepancy between the expiresDate returned by the App Store Server API and the “Expires on” date shown in the iOS Settings / App Store subscription list. I’d like to confirm whether this behavior is expected or if I’m misunderstanding the way Apple rounds dates. Reproduction steps Step Action Result 1 Purchase a 1-month auto-renewable subscription on 23 June 2025 14:00 JST (UTC+9) Transaction succeeds 2 Immediately fetch the transaction with GET /inApps/v1/subscriptions/{transactionId} Response contains "expiresDate": "2025-07-23T05:00:00Z" (= 23 July 2025 14:00 JST) 3 On the same device open Settings › Apple ID › Subscriptions (or App Store › Account › Subscriptions) UI shows Expires on: 22 July 2025 The same happens for every monthly renewal and on multiple devices. Region is Japan, device time zone Asia/Tokyo. What I understand so far (and my hypothesis) Apple’s docs say a monthly subscription renews “on the same calendar date” of the next month, so renewal in this example is 23 July. If the renewal is scheduled for 23 July at 14:00 JST, the subscription is fully usable until the end of 22 July in calendar terms, because the new billing period starts the moment the 23rd begins in Apple’s canonical time zone. Therefore, it might be intentional for the UI to display 22 July—i.e., “you can keep using it through the 22nd; on the 23rd it renews.” This hypothesis makes sense internally, yet it still looks confusing to end users who read “Expires on 22 July” and assume access ends at 00:00 on the 22nd, a whole day earlier than in reality. Questions Is showing the day before the renewal date the official/expected behavior? If so, could Apple clarify that the “Expires on” label represents the last full calendar day rather than the exact expiry timestamp? Which value should we surface in-app when telling users “Your subscription is valid until …”? The server’s expiresDate (precise to the second, converted to user time zone), or A UI-style date that’s one day earlier, matching Settings / App Store? Does Apple have a public document describing this rounding/visual convention? Have other developers encountered user confusion about the apparent 1-day “shortening” and, if so, how did you word your in-app messaging? Any insight from Apple engineers or fellow developers would be greatly appreciated. Thank you!

The sample code provided in https://developer.apple.com/wwdc21/10114 doesn't appear to call finish() on unverified transactions, and I haven't been able to find any documentation regarding what to do with unfinished transactions. However, Apple has always emphasized the importance of finishing transactions, and since a transaction object is provided even with the unverified state, I'd love some guidance!

One of our apps has 85% stuck in Billing Retry -- We are so confused. All the users are from the US, and have a one-week free trial. We had 1,000 subscriptions expire from this issue. So any help would be so appreciated.

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.

I want to add in-app purchasing to my app, but I can't figure out what part of my workflow is wrong. I created a product for my app in iTunes Connect (the product ID is com.mycompany.products.***) and it's in "Ready to submit" status. I created a sandbox test user for this app. I connected to iTunes on a real device using the sandbox AppleID. I went back to XCode and added in-app purchasing to my app. I turned on developer mode on the real device and logged in as the sandbox user. I built the app and ran it on a real device (not the simulator). I tried to get product information (com.mycompany.products.***) but nothing was returned. In-app purchasing is registered in App Store Connect and the status is "Ready to submit". The code only retrieves product information in a simple way, so I don't think there's a problem. inAppPurchase.getProducts(["com.mycompany.products.***"]).then(console.log).catch(console.error); But it only returns an empty array. What could be wrong? Any help would be much appreciated.

I'm developing storekitV2, my app is providing the way to refund some product, and I use method below. func beginRefundRequest(in scene: UIWindowScene) async throws -> Transaction.RefundRequestStatus however when i call the method, the modal view presented but the view shows error with message 'cannot connect'. when I select retry button, something done with indicator and get same result. how can I solve this problem?

We are seeking clarification on the behavior of App Store Server Notifications V2. Summary In our production environment, we received a notification with notificationType: DID_FAIL_TO_RENEW and subtype: GRACE_PERIOD. However, the gracePeriodExpiresDate field in the payload was null. We understand this notification indicates that a user's subscription has entered a grace period. The null value for its expiration date is unexpected, and we are looking for an official explanation of this behavior and the correct way to handle it. The Scenario Here are the details of the notification we received: Notification Type: DID_FAIL_TO_RENEW Notification Subtype: GRACE_PERIOD Environment: Production Upon decoding the signedRenewalInfo JWS from the responseBodyV2, we found that the gracePeriodExpiresDate field inside the JWSRenewalInfoDecodedPayload was null. The notificationUUID for this event was in the format xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Our Implementation and its Impact Our backend is designed to ensure service continuity during a grace period, as recommended in the documentation. Current Logic: Receive the DID_FAIL_TO_RENEW / GRACE_PERIOD notification. Extract the gracePeriodExpiresDate. Extend the user's subscription expiration date in our database to match this date. Because the gracePeriodExpiresDate was null in this case, our logic failed, creating a risk of service interruption for the user. Context and Investigation We have performed the following checks: App Store Connect Settings: We have confirmed that Billing Grace Period is enabled for the relevant subscription group. Sandbox Environment: We have been unable to reproduce this scenario in the Sandbox. User Context: We believe the user in this case was experiencing a failed payment when attempting to renew for the first time after a free trial period. Questions To ensure we handle this scenario correctly, we would appreciate clarification on the following points: Conditions for Null: Under what specific conditions does a DID_FAIL_TO_RENEW notification with a GRACE_PERIOD subtype contain a null gracePeriodExpiresDate? Expected Behavior: Is this null value an expected behavior for certain scenarios, such as the first failed renewal after a free trial? Best Practice: If this is an expected behavior, what is the correct way to handle it? How should our backend interpret a null gracePeriodExpiresDate to ensure service continuity for the user?

Hi, I'm new to AppStore Connect, and I'm learning how subscriptions work. I'm finalizing my first app, but on my TF, I'm having some issues with the price: it's always displayed in US dollars on my paywall. When I tap "subscribe," the Apple sheet correctly offers the price in euros. I'm using Product.displayPrice to display the price in my paywall. The documentation did mention it is The localized string representation of the product price, suitable for display. So, is it normal in my case for the price in dollars to be displayed and not the price in euros like the Apple sheet? Thank you in advance for your help.

It seems that beta 3 broke StoreKit Testing when running against an iOS 26 simulator device. Specifically, when validating product IDs, the debug console displays messages like the following: [492a4cfa_SK1] Could not parse product: missingValue(for: [StoreKit.ProductResponse.Key.price], expected: StoreKit.BackingValue) [492a4cfa_SK1] Could not parse product: missingValue(for: [StoreKit.ProductResponse.Key.price], expected: StoreKit.BackingValue) [492a4cfa_SK1] Could not parse product: missingValue(for: [StoreKit.ProductResponse.Key.price], expected: StoreKit.BackingValue) [492a4cfa_SK1] Could not parse product: missingValue(for: [StoreKit.ProductResponse.Key.price], expected: StoreKit.BackingValue) [492a4cfa_SK1] Could not parse product: missingValue(for: [StoreKit.ProductResponse.Key.price], expected: StoreKit.BackingValue) [492a4cfa_SK1] Could not parse product: missingValue(for: [StoreKit.ProductResponse.Key.price], expected: StoreKit.BackingValue) [492a4cfa_SK1] Could not parse product: missingValue(for: [StoreKit.ProductResponse.Key.price], expected: StoreKit.BackingValue) [492a4cfa_SK1] Could not parse product: missingValue(for: [StoreKit.ProductResponse.Key.price], expected: StoreKit.BackingValue) In addition, the SKProductsResponse (I am using the original StoreKit API), lists all requested product IDs in invalidProductIdentifiers. The products array is empty. StoreKit Testing behaves as expected when Xcode 26 beta 3 is run against an iOS 18.4 simulator device.

On iOS 26 beta 3, after a user purchases an item, initiating a second order for the same product fails to process payment. The system returns the same transaction ID and displays an interface message stating: "You've already purchased this In-App Purchase. It will be restored for free."​​ ​​I’ve tested this – not only did the legacy StoreKit finishTransaction method fail to work, but StoreKit2 finish method also malfunctioned.​​ ​​When will Apple fix this issue? If unresolved, it will prevent a large number of users from making purchases normally, leading to disastrous consequences.​

Dear Apple Developer Support, Our iOS application offers subscriptions with a free trial period. We understand that in South Korea, due to local subscription regulations, users must explicitly provide consent for recurring payments before the subscription converts from a free trial to a paid period. We have the following questions regarding how StoreKit handles this scenario: When a free trial is about to convert to a paid subscription for a user in South Korea, does StoreKit send a StoreKit.Message (or SKStorefront.Message) to the application to obtain the required consent for recurring payments? If such a message is sent, would the Reason for this message be StoreKit.Message.Reason.priceIncreaseConsent, or would it be another specific reason related to initial recurring payment consent after a trial? If our application receives such a message and we choose to defer its display, what is the maximum recommended or permissible deferral period? Is it possible to save the data of a received StoreKit.Message and display it to the user at a later time, for instance, after the application has been closed and subsequently reopened? Are there any best practices or limitations regarding this? We need this information to ensure our application correctly handles these consent requirements in compliance with South Korean policies and provides a smooth user experience. Thank you for your guidance.

My app has a couple of consumable IAP items. I have tested this extensively and it works in all test scenarios including loads of beta testers using testflight. However, Apple's production reviewer reports that loading of the products hangs in their setup. This is very frustrating as I have no means of recreating the problem. My first product was tested ok an all my IAP items are approved for release. However, I did not explicitly assign them to my build. I read somewhere that you need to do that but could not find in App Store Connect after my first product was approved. Below is the relevant code section. What am I missing? class DonationManager: NSObject, ObservableObject, SKProductsRequestDelegate, SKPaymentTransactionObserver { @Published var products: [SKProduct] = [] // This is observed by a view. But apparently that view never gets populated in Apple's production review setup @Published var isPurchasing: Bool = false @Published var purchaseMessage: String? = nil let productIDs: Set<String> = ["Donation_5", "Donation_10", "Donation_25", "Donation_50"] override init() { super.init() SKPaymentQueue.default().add(self) fetchProducts() } deinit { SKPaymentQueue.default().remove(self) } func fetchProducts() { print("Attempting to fetch products with IDs: \(productIDs)") let request = SKProductsRequest(productIdentifiers: productIDs) request.delegate = self request.start() } func productsRequest(_ request: SKProductsRequest, didReceive response: SKProductsResponse) { DispatchQueue.main.async { self.products = response.products.sorted { $0.price.compare($1.price) == .orderedAscending } print("Successfully fetched \(self.products.count) products.") if !response.invalidProductIdentifiers.isEmpty { print("Invalid Product Identifiers: \(response.invalidProductIdentifiers)") self.purchaseMessage = NSLocalizedString("Some products could not be loaded. Please check App Store Connect.", comment: "") } else if self.products.isEmpty { print("No products were fetched. This could indicate a problem with App Store Connect configuration or network.") self.purchaseMessage = NSLocalizedString("No products available. Please try again later.", comment: "") } } } ...and the view showing the items: @StateObject private var donationManager = DonationManager() var body: some View { VStack(spacing: 24) { Spacer() // Donation options ------------------- if donationManager.products.isEmpty { ProgressView(NSLocalizedString("Loading donation options...", comment: "")) .foregroundColor(DARK_BROWN) .italic() .font(.title3) .padding(.top, 16) } else { ForEach(donationManager.products, id: \.self) { product in Button(action: { donationManager.buy(product: product) }) { HStack { Image(systemName: "cup.and.saucer.fill") .foregroundColor(.pink) Text("\(product.localizedTitle) \(product.priceLocale.currencySymbol ?? "$")\(product.price)") } .buttonStyle() } .disabled(donationManager.isPurchasing) } }