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.

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’m implementing subscriptions and running tests, and I noticed a behavior I’d like to confirm. Plans in the app Basic — Monthly Basic — Annual Premium — Monthly Premium — Annual Test environment Sandbox (where ~1 day ≈ under 1 minute of real time) steps Start Basic (Monthly) using an introductory offer (free trial). Create a crossgrade to Basic (Annual) (scheduled/queued). 3.After receiving a RENEWAL App Store Server Notification indicating the plan will move from trial to paid Basic (Annual), but before the trial actually expires, upgrade the user to Premium (Monthly). Observed behavior (Sandbox) & questions Even though there is still up to ~1 day of trial remaining (≈ under 1 minute in Sandbox), upgrading to Premium (Monthly) immediately ends the trial and activates the paid Premium plan right away. Will this same behavior occur in Production? If yes, is this the expected/acceptable behavior when upgrading during an active trial after a pending crossgrade? Note: If we upgrade to Premium before the RENEWAL notification arrives, the remaining trial time is carried over in our tests. In this flow, we see a RENEWAL notification for Basic (Annual) (moving from trial → paid), but then the user immediately upgrades to Premium (Monthly) and the trial ends at that moment. In Production, would the charge for Basic (Annual) be refunded automatically since the user effectively switches to Premium immediately (and Basic Annual does not remain active)? In Sandbox there’s no real charge, but I want to ensure we won’t see a situation in Production where Basic (Annual) is billed and not refunded, even though the subscription effectively moved to Premium right away. Thanks in advance!

I’m implementing subscriptions and running tests, and I noticed a behavior I’d like to confirm. Plans in the app Basic — Monthly Basic — Annual Premium — Monthly Premium — Annual Test environment Sandbox (where ~1 day ≈ under 1 minute of real time) steps Start Basic (Monthly) using an introductory offer (free trial). Create a crossgrade to Basic (Annual) (scheduled/queued). After receiving a RENEWAL App Store Server Notification indicating the plan will move from trial to paid Basic (Annual), but before the trial actually expires, upgrade the user to Premium (Monthly). Observed behavior (Sandbox) & questions Even though there is still up to ~1 day of trial remaining (≈ under 1 minute in Sandbox), upgrading to Premium (Monthly) immediately ends the trial and activates the paid Premium plan right away. Will this same behavior occur in Production? If yes, is this the expected/acceptable behavior when upgrading during an active trial after a pending crossgrade? Note: If we upgrade to Premium before the RENEWAL notification arrives, the remaining trial time is carried over in our tests. In this flow, we see a RENEWAL notification for Basic (Annual) (moving from trial → paid), but then the user immediately upgrades to Premium (Monthly) and the trial ends at that moment. In Production, would the charge for Basic (Annual) be refunded automatically since the user effectively switches to Premium immediately (and Basic Annual does not remain active)? In Sandbox there’s no real charge, but I want to ensure we won’t see a situation in Production where Basic (Annual) is billed and not refunded, even though the subscription effectively moved to Premium right away. Thanks in advance!

this error occurred during the StoreKit1 payment process. Could you please tell me the reason? SKErrorDomain Code=0 "发生未知错误\" UserInfo= {NSLocalizedDescription=发生未知错误，NSUnderlyingError=0x17652ee50 {Error Domain=ASDErrorDomain Code=500"(null)\"Userlnfo={NSUnderlyingError=0x17652d530 {Error Domain=AMSErrorDomain Code=203 "(null)" Userlnfo= {NSUnderlyingError=0x17652c3c0 {Error Domain=AMSErrorDomain Code=203"(null)\"UserInfo=0x1663e5940(not displayed)}}}

Product Timeout, In App purchase is approved in App Store Connect. The Product ID and Bundle ID match. Environment macOS App in TestFlight Bundle ID: com.streamtime.StreamTime App Version: 1.1 (Build 51) StoreKit 2 Product ID: com.streamtime.premium Status: App & Subscription Approved Issue StoreKit product request (Product.products(for:)) consistently times out after 60 seconds in TestFlight, despite all connectivity checks passing. The same code works perfectly in Xcode with local StoreKit configuration. Diagnostic Results ✅ Successful checks: App Store connectivity (HTTP 200 from buy.itunes.apple.com) Backend API connectivity (HTTP 200) StoreKit 2 API available AppStore.canMakePayments: true Valid receipt exists Bundle ID matches Product ID matches approved subscription ❌ Failing: Product request times out after 60 seconds No products returned Code Implementation // Direct product request (fails in TestFlight) let products = try await Product.products(for: ["com.streamtime.premium"]) Logs 🔍 App Bundle ID: com.streamtime.StreamTime 🔍 Product ID: com.streamtime.premium 🔍 AppStore.canMakePayments: true 🔍 Apple Store connectivity: HTTP 200 🔵 Direct request for product ID: 'com.streamtime.premium' ⏱️ Direct request start time: 2025-08-30 10:21:32 +0000 ❌ TIMEOUT: Product request took longer than 60 seconds What I've Tried Removed manual in-app-purchase entitlement (per Apple's guidance) Using automatic signing Verified subscription is approved in App Store Connect Using Sandbox Apple ID in TestFlight Verified all network connectivity Questions Why does StoreKit timeout only in TestFlight when all other connectivity works? Are there additional configuration steps needed for macOS apps vs iOS? Could this be related to the automatic in-app purchase entitlement? Any guidance would be greatly appreciated as this is blocking our TestFlight validation.

When trying to login with sandbox account in my simulator, nothing happens, it just become inactive for few seconds and then it become active again prompting that I can login, again and again.

アプリに課金を実装しようと思うのですが、もし不正利用された場合、アプリ側は基本的にApp Storeを通じて対応するよう案内するのが一般的と思いますが、Apple ID不正利用時とクレジットカード不正利用時で、アプリ側が行う標準的な対応プロセスは変わるのか教えていただきたいです。 また下記内容は標準的な対応プロセスとして問題ないでしょうか？
 ■Apple ID不正利用時 → ユーザー自身がAppleサポートに連絡し、パスワード変更・二段階認証の設定・不正購入の返金申請などを行うよう案内する。 ■クレジットカード不正利用時 → まずカード会社への連絡を促すが、アプリ内決済に関してはAppleのカスタマーサポート経由で返金や調査手続きを案内する 不正利用されたユーザーへの対応に備えて、アプリ側が考慮すべきことがあれば教えてください。

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.

For years I've been using Receigen for receipt verification for the Mac App Store build of my application. However, with the deprecation of exit code 173, I am moving to StoreKit-based verification and have a couple of questions. I have followed the instructions from https://developer.apple.com/documentation/storekit/apptransaction/shared and have something like this (simplified): Swift: @objc class ValidateReceipt: NSObject { @objc func validate() async -> Bool { do { let verificationResult = try await AppTransaction.shared switch verificationResult { case .verified(_ /*let appTransaction*/): // StoreKit verified that the user purchased this app and // the properties in the AppTransaction instance return true; default: // The app transaction didn't pass StoreKit's verification return false; } } catch { // Handle errors return false; } } } Objective-C: ValidateReceipt *validateReceipt = [[ValidateReceipt alloc] init]; [validateReceipt validateWithCompletionHandler:^(BOOL result) { if (result) { // Successful app purchase validation } else { // App purchase validation failure } }]; Thing is, I always get a valid result, i.e., in ValidReceipt.validate(), the case .verified block always runs. Even when exporting a new release build of my app and running it (without any _MASReceipt). When using exit code 173, an .app without a _MASReceipt would prompt for app store login. Nothing of the sort happens now. Am I misunderstanding the documentation / doing something wrong / missing something obvious?

In my app’s IAP products, before enabling free trials, the App Store Server Notifications V2 callbacks all returned the correct notificationType. For auto-renewable subscriptions, when they were about to expire, the notificationType was either DID_RENEW or EXPIRED. A small number of cases(DID_FAIL_TO_RENEW) failed to renew due to billing issues, which was expected. However, after I enabled a 7-day free trial for the auto-renewable products, I noticed that in the App Store Server Notifications V2 callbacks, almost all users (except those who manually turned off auto-renewal) received notificationType = DID_FAIL_TO_RENEW. According to the documentation, DID_FAIL_TO_RENEW indicates a billing issue renewal failure, but in this case it seems like all renewals are being marked as failed. I’ve observed that for users who cancel during the free trial, the callbacks look normal: first a DID_CHANGE_RENEWAL_STATUS notification, then an EXPIRED notification when the trial ends. That flow seems correct. However, for users who do not cancel the trial, almost all callbacks show DID_FAIL_TO_RENEW. Does this mean every remaining user has a billing issue? I also noticed on the Developer Forums that other developers have reported the same issue — receiving a large number of DID_FAIL_TO_RENEW notifications specifically when free trials convert to paid subscriptions: https://developer.apple.com/forums/search?q=DID_FAIL_TO_RENEW Could someone clarify: under normal circumstances, when a free trial transitions to a paid subscription and fails, should the App Store Server Notifications V2 notificationType indeed be DID_FAIL_TO_RENEW, or should it be a different type(e.g. EXPIRED)? And is it expected behavior that almost all free trial conversions return DID_FAIL_TO_RENEW?

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

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

Hello, Our app has been released in Korea with an external payment feature. The function that must display the required modal for external payments is as follows: let result = try await ExternalPurchase.presentNoticeSheet() guard result != .cancelled else { return } However, while testing in the development environment, the API returns a result of continuedWithExternalPurchaseToken(token: String), but in the version distributed through the App Store, it returns cancelled. We would like to know how we can receive the continuedWithExternalPurchaseToken result in the App Store version. Thank you for your guidance. If anyone here has experienced a similar issue or found a solution, I would greatly appreciate your insights as well.

Hello I am trying to add payments on my app. I have added all products I need in subscriptions. I also tried by using storekit but from my understanding testing with storekit is nothing to rely on. My app works on Android (with the same product IDs same unction call) iOS is not why is that?

I have implemented in-app-purchase in one of my iOS application. I generated the consumable products and these are approved by Apple Showing with Green check. I used StoreKit-2 and locally testing with store sync configuration file. The products I have created on developer accounts automatically synced by Store Configuration file and showing no the screen and I can purchase the product with Xcode environment in development. When uploaded app to test flight, I am not getting products with sandbox email id. Cases I have tries: -Remove my original Apple ID from device and just testing with Apple Sandbox email id -> Not getting products. -Remove configuration file while uploading to test flight -> not fetching products. -Checked the archive build and its in Release mode. Note: I am as a (Admin) team member, not account holder. Issue: Not fetching products on Test flight with Sandbox & in live app. Is there something I have to track here: Agreements for Free Apps Agreement with EFFECTIVE DATE showing 3 Jul 2025 - 20 Sep 2025 & STATUS is Active Agreements for Paid Apps Agreement with EFFECTIVE DATE showing nothing & STATUS is New

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

We have received reports from users that their in-app purchases suddenly appear as unpurchased. We would like to know the cause of this issue. Our implementation does not use a server; purchases are determined solely on the client side. These reports often occur after updating the app version, but we have been unable to reproduce the issue in our development environment.

The phone is set up with the developer program to cancel subscriptions from the app we developed. However, after the OS update on the phone, the subscriptions no longer appear in the developer program, although the subscription does exist in the app itself. We are attaching the log. 🔖 8/9/2025, 10:59:44 AM ["expires_date_pst": 2025-09-08 21:58:36 America/Los_Angeles, "original_purchase_date_ms": 1753167687000, "original_purchase_date_pst": 2025-07-22 00:01:27 America/Los_Angeles, "purchase_date_ms": 1757307516000, "purchase_date_pst": 2025-09-07 21:58:36 America/Los_Angeles, "product_id": com.topwall.premium_trial.monthly.trial, "in_app_ownership_type": PURCHASED, "web_order_line_item_id": 2000000111040333, "purchase_date": 2025-09-08 04:58:36 Etc/GMT, "is_trial_period": false, "original_purchase_date": 2025-07-22 07:01:27 Etc/GMT, "expires_date_ms": 1757393916000, "expires_date": 2025-09-09 04:58:36 Etc/GMT, "transaction_id": 2000001002316107, "is_in_intro_offer_period": false, "subscription_group_identifier": 21733009, "original_transaction_id": 2000000966725103, "quantity": 1] 🔹🔹🔹🔹🔹🔹🔹🔹🔹🔹 🟢 8/9/2025, 10:59:44 AM StoreKit isActive: true до 2025-09-09 07:58:36 Why do you think the subscription created in the app doesn’t show up in the sandbox?

The appTransactionID was recently introduced and is documented here: https://developer.apple.com/documentation/storekit/apptransaction/apptransactionid From the documentation: "The App Store generates a single, globally unique appTransactionID for each Apple Account that downloads your app and for each family group member for apps that support Family Sharing." This seems like a really useful identifier, so I was wondering about some edge cases of when using it: What happens if a user logs out of his AppStore account and keeps using the app? Is it available when the app is installed from Xcode? is it possible to set it to some value using StoreKit testing? Thanks