Hi, I'm integrating in-app subscriptions using StoreKit 2 in my iOS app, and I've run into an issue where I'm unable to fetch any subscription products via: let products = try await Product.products(for: productIDs) This consistently returns an empty result (products.count == 0) when running on a real device using a sandbox account. Here's some relevant context of my current setup: This is the first version of the app adding in-app purchase subscriptions. In-App Purchase products are configured in App Store Connect, and marked as "Ready to Submit". The products are attached to the app version, and fully saved. A sandbox account is logged in on the test device. StoreKit Configuration local debug works fine — I can simulate purchases locally from Xcode. However, in the real sandbox environment, any attempt to fetch products returns no results. In App Store Connect > Agreements, Tax, and Banking, I currently see: Paid Application Agreement: Status = "Waiting for User Info" Banking Info: “In Progress” Tax Info: Not yet submitted ❓❓❓ My key question is: Does the "Paid Applications Agreement" need to be fully active (including bank + tax info complete) before in-app purchase products can be fetched in the sandbox environment? If so, it seems that this may be blocking my ability to: Test real subscription flows with sandbox accounts Pass App Store Review (since products cannot be loaded) Any clarification would be greatly appreciated! Thanks in advance.

Hi Apple Developer Support, We're currently implementing auto-renewable subscriptions in a React Native app using the react-native-iap library. The subscription purchases are working as expected in Sandbox. We receive the transaction and purchaseUpdatedListener gives us a valid-looking transactionReceipt However, when we attempt to validate this receipt with Apple's servers, the response consistently returns status code 21002, indicating that the receipt data is either malformed or missing. We’ve confirmed the receipt is well-formed, properly passed as received, and well above the minimum size expected. The shared secret is correctly configured and matches the subscription group. We're using the correct sandbox endpoint and ensuring no modification is done to the receipt before validation. Despite this, validation fails every time. We are looking for guidance or clarification on what might cause this status, especially when the receipt is coming directly from the system after a successful test purchase. const purchaseUpdateSub = purchaseUpdatedListener(async (purchase) => { console.log("🛒 Purchase Updated:", purchase); const receipt = purchase.transactionReceipt; if (!receipt) { Alert.alert("Error", "No receipt found."); setLoading(false); return; } }); the response is: { "status": 21002 } Any guidance on why this might be happening would be appreciated. Thanks!

We are trying to implement / test in-app purchase for our subscription purchase in the app. We have done all the steps listed in the documentation on apple's website; and Our subscription plan is sitting in 'Ready to Submit' state. However, we are getting an empty response from, final response = await _iap.queryProductDetails({'com.company.xyz.basic1m'}); debugPrint(" Check: ${response.toString()}"); debugPrint("❌ Responses: ${response.productDetails.map((ProductDetailsResponse)=>ProductDetailsResponse.toString()).toList()}"); debugPrint("❌ Responses: ${response.productDetails.length}"); if (response.notFoundIDs.isNotEmpty) { debugPrint("❌ Not found: ${response.notFoundIDs}"); } else if (response.productDetails.isNotEmpty) { debugPrint("✅ Product loaded: ${response.productDetails.first.title}"); } The response we get is, flutter: Check: Instance of 'ProductDetailsResponse' flutter: ❌ Responses: [] flutter: ❌ Responses: 0 flutter: ❌ Not found: [com.company.xyz.basic1m] Note: We are testing with a real device iphone 13 mini via Xcode. We tried to test using, ''com.apple.test.Subscription1.monthly'', as instructed but we have not been successful with that. And seems like (based on online search), it doesn't work all the time. We also searched online for a solution, and some of the forums suggest that we have to submit the app for review when adding subscription for the first time. It doesn't mention the same that in the apple documentation. It confusing. Help and guidance in this regard would be really appreciated.

I am stuck. Apple asked me to modify the Name/Description of one of my Subscriptions. But the subscription is "In Review" and everything (including the save button) is disabled. It's lierally impossible for me to update the Name/Description like they are asking for. I have tried rejecting my submission but they are still locked. I have asked Apple Review for help - like changing the status so that I can edit them but they won't. I can't get out of review until I modify the Name/Description of a Subscription but I can't update the Name/Description of a Subscription until I'm out of review. HELP!! 😭

Hello, I submitted my mobile game to the App Store with in-app purchase items. I initially sent my in-app purchases for review for the first time. I had fixed a bug before and thought I could submit a new build with the fix. (Before too much time has passed)I withdrew the previous build and re-submitted the new one. Now, I cannot select in-app purchase items in the new build, and the in-app purchases are still in “Waiting for Review.” Did they get stuck? It has been one day. Even if the in-app purchases get approved, I am unable to choose them in the new build.

Hi, I'm reaching out to report a recurring issue with in-app purchases on iOS that seems to be related to Apple’s transaction handling — not to third-party libraries. In my Flutter application, I use both StoreKit2 and StoreKit1 (for comparison) via different packages, including the official in_app_purchase package. However, in both cases, I’m experiencing unexpected reuse of transactionId and appTransactionId values, even when initiating fresh purchases with unique appAccountToken values. Problem Summary: Purchase Stream Returns Old Purchases When calling buyNonConsumable() with a new product, the purchase stream still returns data for a previously purchased product, despite clearing all Sandbox transactions and using a new applicationUserName for each attempt. Transaction IDs Reused Across Distinct Purchases Even when generating a new UUID for appAccountToken on each purchase, the returned appTransactionId and transactionId are reused — this breaks our server-side logic, which expects these fields to uniquely identify purchases and users. Example Logs: // First purchase { "appAccountToken": "2d5a0880-f68e-44a7-a414-f51204e63904", "appTransactionId": "704464472748013865", "transactionId": "2000000928154716" } // Second purchase (different user context) { "appAccountToken": "2d5a0880-f68e-44a7-a414-f51204e63904", "appTransactionId": "704464472748013865", "transactionId": "2000000928429780" } Even when using a different productId, the appTransactionId stays the same. When using StoreKit1, the productId updates properly, but the transactionId still matches the previous one. This behavior also affects App Store Server Notifications (V2): we have observed notifications tied to appAccountTokens from completely different user accounts (based on internal logs), sometimes delayed by days or weeks. I’ve prepared a reproducible example using the official Flutter in_app_purchase sample with minimal changes — you can find it here: Github gist The code is almost identical to the package example. I only added UUID generation for applicationUserName in _getToken(). In the actual app (not in this example), I retrieve the token from an API. Additional Observations from the Community: We’ve also found similar issues reported in other frameworks and languages. For instance, a developer using react-native-iap observed that App Store Server Notifications in TestFlight were tied to previously deleted users, even after signing up with a new user account and generating a new appAccountToken. Details here: User A deleted → User B signs up → receives upgrade event with User A’s token Notification uses appAccountToken from old account, not the new one This strengthens the suspicion that the issue may be related to how Apple associates transactions with Apple IDs in test environments. Questions: Is it expected for transactionId or appTransactionId to persist across purchases within the same Apple ID, even for different user contexts (e.g., separate logins in the same app)? Is there any official recommendation for avoiding this kind of data reuse in Sandbox or TestFlight environments? Should I expect appAccountToken in server notifications to always match the latest value provided during the purchase? Thank you in advance for your assistance. I would appreciate any clarification or advice regarding this issue, as it impacts production logic that relies on these identifiers being unique and consistent.

I'm getting really frustrated with emails from my App users who believe they've been charged for a free in-app purchase when they haven't. My App offers many in-app purchases of digital items and I give 4 of these away for free to let users get comfortable with how it works in-app. Over the last couple of years I've had a steady increase in angry emails from users who accuse me of fraud by charging them for a free item. I couldn't figure out for a while what this was as they would leave a 1 star rating, delete the app and ignore my emails for more information. Recently I had someone a bit more patient engage and explain it to me. The purchase for some reason popped up on my notifications right when I bought the [Free Item in my app]. It was from a movie I bought and the bill was delayed. The timing of that notification is what is misleading users about the free in-app purchase. Can someone take note of this please and perhaps delay any payment notifications so they aren't sent when the in-app purchase is for FREE? Thanks!

I’m facing an issue with In-App Purchases. I’ve completed the setup successfully. I logged in with User A's Apple account on an iPhone and completed a purchase. After that, I logged in with User B's account on the same iPhone. When I try to make the same purchase, I get the following error: “Purchase is a duplicate and will not be reported.” Because the purchase was already made using User A’s Apple ID, I’m unable to make the same purchase again using User B’s account on the same device. Could you please guide me on how to handle this situation?

Can't add banking info in App Store Connect - getting 400 error when searching for any bank in any country. Steps: App Store Connect → Banking setup Search any bank, any country "We could not find banks matching criteria" + 400 error in dev tools Tried: Multiple browsers/incognito Different countries Clear cache This is blocking my Paid Apps Agreement (shows "Pending User Info") and my app review for in-app purchases. Anyone else having this issue? Any workarounds? Thanks!

Hi, I'm working on a macOS app that includes a non-consumable in-app purchase. The IAP works fine in local testing using StoreKit, but the app has been rejected a few times during review and I’ve resubmitted it after addressing the issues. Right now, both the app version and the in-app purchase are stuck in "In Review" status in App Store Connect. The IAP has never been approved before. The main issue is: on the app version page in App Store Connect, under "App Store" > "In-App Purchases", the entire option to add in-app purchases is now missing. I can’t link the IAP to this version anymore. Because of this, the reviewers get an error saying “Product not found”, which makes sense, since the IAP isn’t included in the submission anymore, and I have no way to reattach it. It feels like the app and IAP are both stuck in review, causing a deadlock that prevents me from progressing. Has anyone experienced something like this? Is there a way to escalate or fix this state? Any advice would be much appreciated, thank you! Antek

I am currently developing an auto-renewal subscription in-app purchase for my app. Currently, the subscription items have already been approved in appStoreConnect, and the .store file is synced with appStoreConnect, so the subscription items are displayed well and the test is also progressing well. However, when I build without using the .store file to perform sandbox testing, the subscription items do not appear and response.invalidProductIdentifiers appears. Is there anything I need to do additionally so that the subscription items can appear in response.products? ps. The bank account item in the contract is in 'processing' status, and the paid app contract status is 'waiting for user information'.

I'm encountering an issue with In-App Purchases on Apple TV (tvOS): When a user initiates an IAP for the first time, the system prompts them to sign in with their Apple ID, and the purchase proceeds normally. However, on subsequent purchase attempts, if the Apple ID session has expired or additional verification is required, the system redirects the user to the Settings app to sign in again. After the user signs in via Settings, the app does not automatically return to the foreground. The user must manually press the Menu button to come back. Is this is the normal behaviour of apple tv for InApp purchase? or did I need any code improvement to solve this? What I'm trying to achieve: I'd like the app to automatically return to the foreground once the user has completed the Apple ID login in Settings. Is this behavior supported on tvOS? If not, is there any known workaround or best practice to guide the user back to the app smoothly? Any advice or guidance from Apple or other developers would be greatly appreciated!

We're planning on increasing the price of our ios in-app subscription. We will select the option "Keep the current price for existing subscribers" Reading this https://developer.apple.com/help/app-store-connect/manage-subscriptions/manage-pricing-for-auto-renewable-subscriptions/, it's not clear if existing subscribers will be notified of the change in pricing (even though that change won't impact them) or not?

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.

Hello We submitted our app for the first time about a week ago. Then there was the usual back-and-forth between Review and us, things we did not think of when submitting the app. One of those things was that our subscriptions were not being submitted together with the app. So we did that and submitted it again, and both the app and the subscriptions went into status "Waiting for Review". Then the app was rejected again for some other reason that had nothing to do with the subscriptions. But the subscriptions stayed at status "Waiting for Review" - and in that status, they cannot be added again to review. So we thought, maybe the subscriptions are still in review, so we do not need to add them again explicitly. But now the app gets rejected because we didn't include the subscriptions in the submission. I submitted the app again and added a comment about the situation. Now both the app and the subscriptions are in "Waiting for Review". What can we do? Any way to get the subscriptions back to "Ready for Review", so they can be added again? Thanks Jonas

We've observed two refund cases where we only received REFUND notifications without the expected CONSUMPTION_REQUEST notifications. Both cases came from the same user account. According to documentation, we should first receive CONSUMPTION_REQUEST before any REFUND notification. Has anyone encountered similar selective missing notifications? Could this be user-specific or related to particular refund circumstances? Environment: Production environment Valid server notifications setup (other notifications work fine) Only these two cases from same user showed this behavior

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.

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

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

We are a group of 10 friends using the same device and Apple ID, but each of us has a different account within the same app. We want to purchase the same auto-renewable monthly subscription plan, each using our own app credentials. The issue: after the first person subscribes, the next user (with a different in-app account) is unable to buy the same plan—it shows "already subscribed" and only allows access after the next billing cycle. We don’t mind the auto-renewal being charged each month by a different person. We just want each app account to have access to the same package independently, for 1 month each. How can we achieve this without changing the Apple ID or device?