Hi everyone, I’m based in Europe, and I’m trying to fully understand the current App Store payment rules for an iOS app that sells digital services or premium functionality used inside the app. My goal is not to bypass App Store rules, but to implement the correct, compliant payment flow depending on the user’s region and the App Store requirements that apply there. The app would offer things like premium features, credits, or access to digital functionality inside the iOS app. The payment flow I would ideally like to support, where allowed, is: iOS app -> Cloud ahndling -> Stripe Checkout page -> user pays -> Stripe handling -> my backend marks the user as premium What I’m trying to understand is whether this flow is allowed, restricted, or prohibited depending on the user’s App Store storefront / region. My questions are: For digital goods, subscriptions, credits, or premium features used inside an iOS app, is Apple In-App Purchase still required by default? In which regions, exactly, can an iOS app use or link to an external payment provider such as Stripe for digital services used inside the app? For users in the United States, after the Epic Games v. Apple changes, can an app show an external payment option such as “Subscribe on the web” or “Pay with Stripe”? If yes, what are the exact requirements, limitations, wording rules, Apple fees, or reporting obligations? For users in the European Union, under the DMA-related rules, does Apple allow external purchases through Stripe or a web checkout? If yes, do I need specific Apple entitlements, StoreKit External Purchase APIs, Apple approval, transaction reporting, or payment of Apple fees? For the rest of the world, should I assume that Apple IAP is mandatory for digital content, subscriptions, credits, and premium app functionality unless Apple has a specific regional program allowing external payments? What is the correct way to determine which payment flow a user should see? Should this be based on the user’s App Store storefront / StoreKit storefront, rather than IP address, device locale, billing address, or country selected manually by the user? Would a regional routing approach like this be compliant? if App Store storefront == US: show Apple-compliant external purchase link / Stripe option if allowed elif App Store storefront is in the EU and the app has the required Apple entitlement: show Apple-compliant external purchase flow else: show Apple In-App Purchase only If a user pays through Stripe or another external checkout in a region where external payments are allowed, can my backend unlock premium features inside the iOS app? Or are there restrictions on granting access inside the app when the purchase was not completed through Apple IAP? For a first App Store release, is the safest approach to launch with Apple IAP only, then later add external payment options only in regions where Apple explicitly allows them? For developers who have recently submitted apps with external payment links for digital services: Which countries or storefronts were accepted? Did App Review require special entitlements? Were there specific wording or UI requirements? Did Apple require transaction reporting or apply additional fees? Were there differences between the US, EU, and other regions? In short, I’m trying to understand the practical compliant architecture: iOS app = Apple IAP by default external Stripe / web checkout = only where regionally allowed by Apple backend = unlock premium access after valid payment, whether Apple IAP or approved external payment payment UI = adapted based on App Store storefront / region I would really appreciate answers from developers, App Review experiences, or anyone familiar with the current Apple rules after the Epic ruling, DMA changes, and Apple’s External Purchase Link / StoreKit External Purchase programs. Thanks!

Hello! My subscriptions have been stuck in review for a while. I have been chasing my tail trying to get the sandbox purchases to work but the subscriptions are not returning after "sale". Is this because the subscriptions are still in review? Will the purchase ever return a product in the sandbox environment if the products are still in review? How do we get the subscriptions approved? I have submitted them with the app multiple times. The app is rejected because I can't complete it without the subscriptions but the subscriptions are never reviewed. Help!

Hi everyone, I’m currently developing an iOS app using React Native and implementing consumable In-App Purchases (IAP). I'm facing an issue where getProducts returns an empty array without any error messages when testing on a TestFlight build. I have already completed the following setup: Agreements, Tax, and Banking: All forms are signed and the status is "Active" in App Store Connect. Product Configuration: The Consumable product is created in App Store Connect with the status "Ready to Submit". App Store Connect Integration: The product is correctly linked under the "In-App Purchases and Subscriptions" section of the App version. Xcode Capability: The "In-App Purchase" capability has been added to the project. Implementation: The Product ID in my React Native code (using react-native-iap) matches the ID in App Store Connect exactly. Despite these steps, the product list remains empty. Are there any hidden requirements or specific configurations for TestFlight that I might have missed? Any guidance would be greatly appreciated. Thanks!

Hi, I am planning to show the StoreKitError as alerts, I have corresponding custom Error so that I can show meaningful error messages. Reason I wanted to display error alert messages that describe the underlying error so that when in production and user faces this error I would be able to reason about the error and try to resolve the error in a app update or Appstore Connect change. If I display a generic error I wouldn't know the cause of the error, but is there is a security risk in display the following kind of messages? Proposed UI error messages: | Error | UI alert message | | ------------------------------------ | ----------------------------------------------- | | StoreKitError.notEntitled | App is not entitled to make this request. | | PurchaseError.invalidOfferSignature | Invalid offer signature. | Questions From a security / user perspective is it risky / wrong to show an error message like the ones pasted above? Or are there some errors I shouldn't explicitly state? Or is there a better / preferred approach?

Hi, I'm testing my first auto-renewable subscription using StoreKit 2 and TestFlight. When loading products via: let products = try await Product.products(for: ids) the product is returned successfully, but product.displayPrice shows: $4.99 even though: My App Store account is located in Germany. The app is only intended for the German market. The native Apple purchase sheet displays the correct price in EUR. The subscription pricing is configured correctly in App Store Connect. The subscription is still in "Ready to Submit / Prepare for Submission" state and has not yet been approved. Example: print(product.displayPrice) returns: $4.99 while the StoreKit purchase dialog shows: 5,99 € Has anyone seen this behavior before? Is this expected for new subscriptions in TestFlight/Sandbox before the first App Review approval, or could there be another reason why displayPrice differs from the actual purchase dialog? Thanks!

I am testing a StoreKit 2 non-consumable IAP through TestFlight. Product ID: com.metabolla.plus.lifetime Type: Non-Consumable Environment: TestFlight / Sandbox Transaction.currentEntitlements keeps returning an active entitlement for this product even after: configuring a Sandbox Apple Account clearing Sandbox Purchase History reinstalling the app rebooting the device Important detail: the first TestFlight purchase was completed before configuring the Sandbox Apple Account on the device. If I temporarily change the Product ID in code, the entitlement disappears, so the issue seems tied to the original Product ID/account/receipt. Question: Can a non-consumable TestFlight purchase made before Sandbox Apple Account configuration remain associated with the original TestFlight/Apple ID identity? Is there any supported way to clear this entitlement for testing?

General: Forums topic: StoreKit Forums tag: In-App Purchase App Store Pathway Simple and safe In-App Purchases Auto-renewable subscriptions In-App Purchase documentation Getting started with In-App Purchase using StoreKit views documentation Supporting business model changes by using the app transaction documentation Testing at all stages of development with Xcode and the sandbox documentation App Store Server Notifications documentation App Store Server API documentation Simplifying your implementation by using the App Store Server Library documentation TN3185: Troubleshooting In-App Purchases availability in Xcode technote TN3186: Troubleshooting In-App Purchases availability in the sandbox technote TN3188: Troubleshooting In-App Purchases availability in the App Store technote Understanding StoreKit workflows sample code Implementing a store in your app using the StoreKit API sample code What’s new in StoreKit and In-App Purchase video

Could you help clarify the expected behavior in downgrade scenarios during a Free Trial period? Does Apple trigger billing immediately for the downgraded plan, or does the change take effect only after the Free Trial window completes?

I'm testing IPhone and iPad Apps on Apple Silicon Macs. When I purchase In-app product in the app on Apple Silicon Mac, the payment receipt is not created, so the purchase fails. In console log, it says it doesn't have permission to write to the file. storekitagent [6913DE38_SK1] Error writing receipt (5095 bytes) to file:///Users/XXXX/Library/Containers/90FE2A60-9FDF-4ECF-848F-CE3D396322CA/Data/StoreKit/sandboxReceipt: Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “sandboxReceipt” in the folder “StoreKit”" UserInfo={NSFilePath=/Users/XXXX/Library/Containers/90FE2A60-9FDF-4ECF-848F-CE3D396322CA/Data/StoreKit/sandboxReceipt, NSUnderlyingError=0x14202c920 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}} The App is using Original API for In-App Purchase written in Objective-C. When I purchase in-app product, the app calls SKPaymentQueue::addPayment. And then it gets paymentQueue:updatedTransactions callback with SKPaymentTransactionStatePurchased. This means that the payment was successful. But the receipt is not created so I can't continue the after process. I'm testing with sandbox in-app purchase. I have tested several times and confirmed that on macOS Monterey 12.2 the receipt is created successfully, but on macOS Ventura 13.2 the receipt isn't created. I think there is something to do with macOS version. Does anyone have any solutions? Here is a very similar thread on apple developer forum. (And there too has no anwsers)  https://developer.apple.com/forums/thread/719505

I have an iOS app with two auto-renewable subscriptions (monthly and annual) that are fully configured and ready for their first submission. Both products have complete metadata, pricing, localizations, review screenshots, and review notes. The problem: The "In-App Purchases and Subscriptions" section does not appear on the version preparation page. It should appear between "App Review Information" and "App Store Version Release," but it's missing entirely. This means I cannot link the subscriptions to my app version for a combined submission. How I got here: I initially submitted the subscriptions for review independently (via the "Submit for Review" button on the subscription product page), not realizing they needed to be submitted alongside a binary. This resulted in a Guideline 3.1.1 rejection. I then created a new app version with a build, but the "In-App Purchases and Subscriptions" section did not appear on the version page. Not realizing this section should exist, I submitted the app — it was approved and published without the subscriptions. I have since created another new version with a fresh build. The app version, monthly subscription, and yearly subscription are all in "Ready to Submit" state. The section still does not appear. What I've verified: All subscription metadata is complete (pricing, localizations, review screenshots, review notes) Subscription group has a localization A new app version is in "Prepare for Submission" with a build uploaded All business/agreements/tax/banking setup is complete The app has no consumable or non-consumable IAPs — only auto-renewable subscriptions All subscription testing appears to work I've reviewed other forum threads with the same issue (e.g., https://developer.apple.com/forums/thread/778258) and followed all suggestions Environment: App uses StoreKit 2 via Flutter in_app_purchase plugin Two products: monthly and annual auto-renewable subscriptions First-time IAP submission for this app App is currently live on the App Store I opened a Developer Support ticket 7 days ago and have not yet received a resolution. Has anyone encountered this issue and found a workaround? Is there a way to reset the subscription review state so they can be properly linked to a version?

Hi, We've implemented age assurance logic in our app using the DeclaredAgeRange framework to comply with regulations in Brazil (Digital ECA, effective March 17, 2026) and Utah (App Store Accountability Act, effective May 6, 2026). Our implementation calls AgeRangeService.shared.isEligibleForAgeFeatures on app launch to determine whether the current user is subject to age assurance requirements, and proceeds to call requestAgeRange(ageGates:) accordingly. However, after monitoring in production since the Brazil enforcement date, we've consistently observed isEligibleForAgeFeatures returning false for users in regulated regions, with no age range data being returned. What we'd like to clarify: Is isEligibleForAgeFeatures currently returning true for users in Brazil in production (not sandbox)? For Utah — given that HB 498 pushed the developer compliance deadline to May 6, 2027, will isEligibleForAgeFeatures reflect the original May 6, 2026 activation date or the revised 2027 date? Is there a known rollout schedule or gradual activation plan for these regions that would explain why the flag remains false even after the legal enforcement dates have passed? We've seen similar reports from other developers on these forums, so it seems this may be a widespread issue rather than an implementation problem on our end. Any official guidance on the current status of the API in regulated regions would be greatly appreciated. Thanks.

I am implementing device authentication for a macOS app. Our iOS app uses App Attest, but App Attest is not available on macOS, so we are evaluating StoreKit's AppTransaction plus AppStore.deviceVerificationID as the macOS equivalent signal. The issue: in a macOS app installed through TestFlight, AppStore.deviceVerificationID is available, but AppTransaction.shared throws StoreKitError code=2. I reproduced this in a focused standalone macOS test app with no backend and no custom dependencies. Environment: Platform: macOS Distribution: TestFlight App Store Connect app ID: 6769568350 Bundle ID: com.soundcity.AppTransactionProbe App version: 1.0 Build: 1 Observed output from the TestFlight-installed app: Bundle ID: com.soundcity.AppTransactionProbe App version: 1.0 Build: 1 deviceVerificationID available: true deviceVerificationID prefix: CA91ED5D... AppTransaction.shared threw error: StoreKitError; domain=StoreKit.StoreKitError; code=2 The relevant code path is essentially: import StoreKit let deviceVerificationID = try? AppStore.deviceVerificationID let appTransaction = try await AppTransaction.shared In the TestFlight-installed build: AppStore.deviceVerificationID succeeds. AppTransaction.shared throws StoreKitError code=2. Questions: Is AppTransaction.shared expected to work for macOS apps distributed through TestFlight? If yes, what does StoreKitError code=2 indicate in this context, and what setup might be missing? If no, is there an Apple-supported way to obtain an AppTransaction JWS, or equivalent signed App Store/TestFlight app-install assertion, for macOS TestFlight builds? For macOS apps that need a device-bound trust signal comparable to iOS App Attest, is AppStore.deviceVerificationID intended to be used without AppTransaction.shared, or should these APIs be used together? I have a focused Xcode test project that demonstrates the issue and can share it if helpful.

Hello everyone, I'm facing a very frustrating situation with App Review for my indie app, CoffeePomodoro, and I'm hoping someone here or an Apple engineer can help shed some light on how to escalate and resolve this. My recent update (Version 1.3.1, Submission ID: 59763b52-7c14-4b27-a2cf-2799d2bafe35) was rejected under Guideline 3.1.1 - In-App Purchase. The rejection message states: "We found that the app includes a feature to restore previously purchased In-App Purchase products by entering the user's Apple Account and password. However, In-App Purchases cannot be restored in this manner." The Reality: There is absolutely zero custom UI, form, or TextField in my app that asks for an Apple ID or password. When a user taps "Restore Purchases", the app simply calls Purchases.shared.restorePurchases() via the RevenueCat SDK, which directly wraps Apple's native SKPaymentQueue.restoreCompletedTransactions(). The credential prompt the reviewer saw is the native iOS system-level authentication dialog that appears automatically in the sandbox/TestFlight environment. This usually happens if the device or simulator being used for the review doesn't have an active Sandbox Apple ID already logged in. I have explained this in the App Store Connect Resolution Center. I provided screen recordings showing it's the system dialog, and I attached code snippets proving the app only calls native APIs. Unfortunately, my explanations seem to be ignored, and I keep facing the same roadblock. It feels like the reviewers are mistaking their own OS's native prompt for a custom credential-harvesting screen. Meanwhile, my users are waiting for this update to resolve their subscription issues, and I am stuck in a rejection loop for using Apple's own native API exactly as intended. Has anyone else experienced this specific misunderstanding by the review team? How can I escalate this so someone actually reviews the screen recording and code snippets I provided? Thank you for your time.

[Repost: Somehow my original thread from Jan was deleted. I called dev support and they said to post again, if there's a better channel to get answer for this, please let me know.] I’m an indie dev with a paid, one-time-purchase app (Dash Calc, $4 USD), and sales have been rough. In a crowded category, an upfront-paid app feels like a tough sell without a way to try it first. I’d like to offer a simple 7-day free trial followed by a single lifetime purchase, but App Store Connect still doesn’t officially support trials for paid apps. In Jan 2023, an App Store Commerce Engineer recommended the $0 non-consumable IAP + paid non-consumable IAP workaround: https://developer.apple.com/forums/thread/722874 I haven’t implemented it yet, but the subsequent discussion suggests the approach is overly complex. Handling refunds, reinstalls, activation timing, and purchase history requires non-obvious logic, and some developers report customer confusion and drop-off when presented with a $0 trial IAP. Has anything improved since 2023? Any new StoreKit APIs or App Store Connect changes that make this simpler or less error-prone? Is the $0 non-consumable IAP still the recommended approach in 2026? Any updated policy guidance for time-limited access on one-time purchases? I’m happy to use the workaround if it’s still the official path—I just want to confirm there isn’t a better option now.

On iOS 26.5 simulator runtime, running UI tests via xcodebuild test from the command line does not push the scheme's StoreKitConfigurationFileReference to the destination simulator's storekitd AppGroup Octane container. As a consequence, SKTestSession(configurationFileNamed:) either silently falls through to the production App Store (surfacing a "Sign in to Apple Account" SpringBoard alert during paywall tests), or throws SKInternalErrorDomain Code=3 "Error saving configuration file" if you call any SKTestSession instance method. The same project, same scheme, same .storekit file works correctly when launched via Xcode IDE (Cmd+R / Cmd+U) — which uses DVTDevice.handleStoreKitConfigurationSyncForBundleID:configurationFilePath: via an internal IDELaunchSession XPC path that the public xcodebuild CLI does not invoke. This regression makes StoreKit Test unusable in CI for any project using xcodebuild test or xcodebuild test-without-building against an iOS 26.5 simulator. Environment macOS: 26.x Xcode: 26.4.1 (25E253) iOS Simulator runtime affected: 26.5 iOS Simulator runtime that does not exhibit the bug: 26.1 Test target: XCTest UI tests Test plan: *.xctestplan with "storeKitConfiguration": "MyApp.storekit" in defaultOptions Affected scheme actions: Test (CLI) Not affected: Run, Test (Xcode IDE) Steps to Reproduce Create a SwiftUI iOS app com.example.MyApp. Add a MyApp.storekit with one auto-renewable subscription. Add a UI test target. In the xctestplan: defaultOptions.storeKitConfiguration = "MyApp.storekit". In the UI test base case: private var storeKitSession: SKTestSession? override func setUpWithError() throws { storeKitSession = try SKTestSession(configurationFileNamed: "MyApp") app.launch() } Boot a fresh iOS 26.5 simulator. Run via CLI: xcodebuild test \ -project MyApp.xcodeproj \ -scheme MyApp \ -testPlan MyAppUITests \ -destination "platform=iOS Simulator,name=iPhone 17 Pro" In the test, trigger paywall and call Product.purchase(). Expected Product.purchase() presents the StoreKit Test sheet labeled "[Environment] Xcode". Same behavior as Xcode IDE Cmd+U. Actual Production App Store flow triggers. SpringBoard alert "Sign in to Apple Account" appears. Tests waiting on the "Xcode"-labeled sheet fail with Element does not exist. Evidence The simulator's ~/Library/Developer/CoreSimulator/Devices/<UDID>/data/Containers/Shared/AppGroup/<storekit-AGID>/Documents/Persistence/Octane/com.example.MyApp/Configuration.storekit: Present (≈100 KB) when launched via Xcode IDE. Missing when launched via xcodebuild test CLI on the same simulator UDID. Workarounds Attempted (all fail on iOS 26.5) No-op XCTestCase "warmup" that calls XCUIApplication.launch() + sleep — does not trigger the sync because XCUIApplication.launch() routes through XCTRunner, not IDELaunchSession. Multi-destination xcodebuild test with -parallelize-tests-among-destinations. Manually cp-ing the .storekit file into the AppGroup Octane container — storekitd only loads via the XPC channel. launchctl kickstart -k system/com.apple.storekitd — wipes in-memory state, does not pick up disk file. Only working workaround: open project in Xcode IDE, Cmd+R, wait ~20–30 sec, Cmd+., then Cmd+U. Not viable for CI. Related Open Feedback FB22237318 — SKTestSession instance methods (clearTransactions(), failTransactionsEnabled = true) throw SKInternalErrorDomain Code=3 "Error saving configuration file". Discussion thread: https://developer.apple.com/forums/thread/808030 The iOS 26.5 Release Notes (https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-26_5-release-notes) under StoreKit Test list this issue as resolved in 26.5: "Fixed: SKTestSession may fail to save its configuration file when invoked outside of an Xcode debug session." However, on the public iOS 26.5 simulator runtime the behavior is unchanged — SKTestSession still hits Code=3 on any mutation, and xcodebuild test from CLI still does not sync the .storekit configuration. The 26.5 fix either did not actually ship, or this report describes a distinct but related issue that the fix did not cover. Impact Any CI/CD pipeline running UI tests for apps with StoreKit subscriptions is broken when targeting an iOS 26.5 simulator. Workarounds are either: Pin CI simulator runtime to iOS 26.1. Manually run the project in Xcode IDE before each test run (impossible headless). Has anyone found a CLI-friendly workaround? Or is there an undocumented xcodebuild flag / simctl command that can trigger the same DVTDevice sync from outside the IDE?

All of a sudden both our development and production app stopped loading products for the subscription screens. Within our code I noticed that product.products is always returning 0 elements even after confirming product ids are correct and ensuring all agreements in App Store Connect are signed and active. What could be the issue?

I had everything working with Revenue Cat. Then my app got rejected for not loading subscriptions, which was odd because a previous built was rejected for wording on that same paywall. I checked, and realised I suddenly can't fetch products in testFlight either. I can only see products in Xcode using the store kit configuration file. I've found many issues like this online and everybody point to the same solutions (that seem to work for most), but here's what I tried so far: Checked that all my agreements in App Store Connect are active Checked that ids match between Xcode / revenue cat / App Store connect Store kit config file is syncing with App Store Connect correctly I removed revenue cat and used the store kit api directly to fetch products. The array of products is empty in all environments that don't have access to store kit config file. Checked status of all subscriptions (all waiting for review -- as they were when the paywall worked) Nothing seems to work... Any suggestions? Many thanks

Hi, I'm trying to run our StoreKit unit tests with Xcode26.5 on an iOS26.5 simulator. Host computer has macOS26.5. All tests are failing and in the console I see logs such as [SKTestSession] Error saving configuration file: Error Domain=SKInternalErrorDomain Code=3 "(null)" [SKTestSession] Error deleting all transactions: Error Domain=SKInternalErrorDomain Code=3 "(null)" [SKTestSession] Error clearing overrides: Error Domain=SKInternalErrorDomain Code=3 "(null)" [SKTestSession] Error setting value to 1 for identifier 2 for jp.unext.mediaplayer: Error Domain=SKInternalErrorDomain Code=3 "(null)" And the simulator asks me to provide my AppleID. Tests have been broken since at least 26.4 The release notes claims that it has been fixed but not for me. https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-26_5-release-notes#StoreKit-Testing-in-Xcode Does anyone else have the same issue? Reported FB22774836 just in case.

Our app offers auto-renewable subscriptions using StoreKit Original API for In-App Purchase and App Store Server Notifications V1. Starting around 2025-03-15, we found some cases where original_transaction_id which was associated to web_order_line_item_id of already purchased subscription had changed in the receipt information of verifyReceipt response or App Store Server Notifications V1. The detailed steps are: Around February 2025, re-purchase from the app the same subscription product which was canceled and expired some time ago, using StoreKit Original API for In-App Purchase Receive the following 2 notifications from App Store Server Notifications V1 almost at the same time INITIAL_BUY DID_CHANGE_RENEWAL_STATUS In both notifications, latest_receipt_info contains the receipt for the re-purchased subscription period with new original_transaction_id and web_order_line_item_id pending_renewal_info contains both new original_transaction_id and original one which was generated at first purchase, and original one has "is_in_billing_retry_period": "1" Starting around 2025-03-15, the following happens When we receive another "DID_CHANGE_RENEWAL_STATUS" notification from App Store Server Notifications V1, original_transaction_id which is associated to web_order_line_item_id of the re-purchased subscription period has changed back to the original one (the one which was generated at first purchase) in latest_receipt_info. When we call verifyReceipt with the receipt obtained from appStoreReceiptURL, the response does not seem to contain new original_transaction_id which was generated at re-purchase We have some questions regarding this original_transaction_id behavior. When a user re-purchase the same subscription product which was canceled and expired some time ago, it seems that new original_transaction_id is generated. Is this an expected behavior? If yes, it seems that, at some point, original_transaction_id which is associated to web_order_line_item_id of the re-purchased subscription changed back to the original original_transaction_id which had been generated at first purchase. Is this an expected behavior? What triggers the original_transaction_id change to the original one? Is it related to some user actions or subscription status change?

Hi everyone, I'm submitting my watchOS-only app and its In-App Purchase for the very first time (both app and IAP submitted simultaneously). After multiple rejections, I still can't resolve the issue and would appreciate any guidance. Environment: App type: watchOS-only (no iOS companion app) First submission of both the app and IAP IAP type: Non-Consumable, Product Apple ID: 6770497337 The problem: The reviewer (App Review) states that the IAP product information cannot be retrieved in the review environment. According to the reviewer, they are testing in the production environment, not the sandbox. However: In my TestFlight build, the app correctly retrieves the IAP product I have successfully completed the full purchase flow using a sandbox account All business agreements (including Paid Apps Agreement) are accepted and active in The Bundle ID and Product ID are correctly configured in both Xcode and App Store Connect Current IAP status in App Store Connect: Overall status: "Developer Action Needed" All localizations (English US/UK/AU/CA, Japanese, Simplified Chinese, Traditional Chinese): "Rejected" No specific rejection reason is shown anywhere in App Store Connect Any help would be greatly appreciated. Thank you! 🙏