App Store Connect displays the In-App Purchases and Subscriptions section on your app's version page when your app has an In-App Purchase or subscription with a Ready to Submit status. To locate the In-App Purchases and Subscriptions section: In Apps, select the app you want to view. In the sidebar, select the app version. On the version page, scroll down to the In-App Purchases and Subscriptions section. For more information, see Submit an In-App Purchase.

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

Hello, I would like to clarify the exact technical behavior of the App Store Server API (V2) and StoreKit under the following two specific scenarios: Case A (Production Account on Sandbox Endpoint): If a user with a production Apple Account attempts to purchase through a build pointing to the Apple Sandbox environment (or Sandbox API), how does the Apple server handle this transaction and its data lifecycle? (Does StoreKit block this at the client-side, or does the API return a specific error code?) Case B (Restoring Cleared Sandbox Data): If a Sandbox tester's purchase history is cleared/deleted on the Apple server, and the app subsequently requests a "Restore Purchase" or queries the App Store Server API using a previously valid transactionID from that account, what specific error code (such as 4040010 TransactionNotFound) or empty response does the Apple server return? I would highly appreciate your confirmation or any technical insights on these behaviors. Thank you!

Hello, I would like to clarify the best practices and timing for our backend server to transition its main connection to the production App Store Server API. Currently, we are considering the following approach: We plan to switch our backend’s primary API endpoint from Sandbox to Production once our app passes the App Store review and its status changes to "Ready for Sale." Could you please confirm if this timing is standard and correct? Additionally, to handle App Store reviews (which run in the Sandbox environment) and TestFlight tests seamlessly without manual configuration changes, we are planning to implement an automatic fallback mechanism: Our backend always requests the Production App Store Server API first. If it returns a "TransactionNotFound" (e.g., 4040010) error, the backend automatically retries the request using the Sandbox API. Is this automatic fallback from Production to Sandbox considered a safe and recommended practice by Apple, especially for App Store reviews and post-release testing? Any advice or insights on backend transition timing and fallback strategies would be highly appreciated. Thank you!

Hi, During the App Review process, a test purchase was made using what appeared to be a production Apple account. When our app server sent this transactionId to the Production App Store Server API, it returned the error code 4040010 (TransactionIdNotFoundError). To handle this gracefully and prevent review rejections, we are considering implementing a dynamic fallback mechanism on our app server. Specifically, when the Production API returns 4040010, the server will automatically retry the request using the Sandbox App Store Server API URL. Could you please clarify the following points regarding this design? Is it expected behavior for an App Review purchase to return 4040010 on the Production API, and can it be successfully verified by routing it to the Sandbox API? Is this dynamic fallback logic (Production API ➔ if 4040010 ➔ Sandbox API) a recommended and officially supported best practice for handling App Review and TestFlight transactions? Any confirmation or advice from Apple engineers or the community would be greatly appreciated.Thank you.

Hi, I am designing a database schema to store App Store transaction data for our backend system, and I have a question regarding the uniqueness of transactionId. According to the documentation (apple.com), transactionId is a unique identifier for a transaction. However, it is not explicitly clear whether this uniqueness is guaranteed across different environments.Could you please clarify the following points? Is transactionId guaranteed to be unique across both the Production and Sandbox environments? (i.e., Is there any possibility that the exact same transactionId is generated in both environments?) For database design, is it safe to use transactionId alone as a Primary Key? Or is it strongly recommended to use a composite key consisting of both environment and transactionId? Any insights or best practices from Apple engineers or the community would be highly appreciated.Thank you.

Live App Store app. Since 2026-09-01 PDT, StoreKit no longer returns our approved auto-renewable subscriptions on signed builds. The same SKUs load normally in Xcode when using a local StoreKit configuration file. New purchases are blocked. Monthly auto-renewals that were collecting normally through August 31 began failing their renewal attempts starting September 1, with all observed attempts entering Billing Grace / Billing Retry. App Name: Moonlit Bundle ID: moonlit.reading Versions affected: 1.1.1 — App Store version that was already live and working normally before September 1 1.1.2 — subsequently released to the App Store specifically to test whether a fresh production release would restore StoreKit behavior. It did not. Approved auto-renewable subscriptions, both in the same subscription group: moonlit.monthly.subscription moonlit.yearly.subscription Paid Apps Agreement, banking, and tax are Active in App Store Connect. We use an explicit App ID with the In-App Purchase capability enabled. Distribution builds do not contain a StoreKit Configuration file. The local .storekit file is used only for Xcode Run. Through August 31, 2026, Product.products(for:) and SubscriptionStoreView returned both SKUs and their prices correctly on production builds. Beginning September 1, 2026, and continuing through at least September 11: Every production paywall we can measure receives an empty StoreKit catalog with no product IDs, no prices, and no thrown StoreKit error. SubscriptionStoreView remains on its loading state. Our Terms / Privacy footer still renders because it does not depend on StoreKit. showManageSubscriptions / manageSubscriptionsSheet also hangs or fails to connect on the same signed builds. App Store Connect subscription events for the monthly SKU show a complete reversal beginning September 1. All observed renewal attempts in the affected window entered Grace from Paid, with no successful renewals, whereas the comparable August window showed normal successful renewals. Sales reports show no IAP proceeds for the affected September window. App downloads continue to appear normally, so the app itself remains available for sale. What still works Xcode + local StoreKit Configuration: Both products load Prices display The purchase sheet presents normally Analytics and logging continue to function, so this is not an app crash or missing paywall UI. The subscriptions are not Rejected and are not in Developer Action Needed. TN3186 / TN3188 checks have already been completed. This appears similar to other recent reports where App Store Connect contains a valid product catalog but StoreKit does not serve the products to signed builds: https://developer.apple.com/forums/thread/838171 https://developer.apple.com/forums/thread/841722 https://developer.apple.com/forums/thread/838773 https://developer.apple.com/forums/thread/836183 Developer Support case: 102959783559 Request Could an App Store Commerce or StoreKit engineer verify whether the app-to-IAP catalog association for moonlit.reading is populated and being served correctly on Apple’s side, and refresh or reprocess the production catalog if appropriate?

Guideline 2.3.6 - Performance - Accurate Metadata Issue Description Please note that the app includes tips, tools, predictions or other information related to real money gambling, real money betting, or real money skill-based gaming, you must select "Yes" for "Gambling" in App Store Connect. Apps must be rated accordingly for the highest level of content that the user is able to access in the app. Next Steps Update the Age Rating selections in App Store Connect to select "Yes" for "Gambling." The Age Rating selections can be found on the App Information page after selecting the app in App Store Connect. I have had multiple releases with just having "Social Gaming" Set to Frequent as my app has wagering in it but can NEVER be exchanged for real currency which puts it in the bucket of SOCIAL GAMBLING/WAGERING. This reviewer has no idea how to interpret what Guideline 2.3.6 actually means and this reviewer keeps rejecting my app..... Apple can you please change the reviewer with someone who actually can comprehend what the guidelines means. Because in my privacy and tos I specifically state the words gambling and no in-game exchange or out of game exchange for real currency can occur - not sure why I fail the guideline only this ONE TIME because this reviewer cannot understand what the guideline means. This is holding up my app release for the gazilianth time and costing yourselves and myself money. APP ID : 6767430745

Hello everyone, I am encountering a persistent date discrepancy between the subscription expiration date returned by the App Store Server API and the date displayed to the user in the native iOS Settings UI. Our app receives the renewal timestamp via the App Store Server Notifications in UTC milliseconds. For a recent transaction, we received renewalDate = 1820988823000, which is September 15, 2027, at 06:13 AM UTC. Following standard practices, our app formats this UTC timestamp to the user's local device timezone. On a device set to India Standard Time (IST, UTC+5:30), the app correctly displays the expiration as September 15. However, on the exact same device, navigating to iOS Settings > Apple ID > Subscriptions shows the expiration date as September 14. Converting 06:13 AM UTC to Pacific Time (PT) results in September 14 at 11:13 PM PDT. This leads me to suspect that the iOS Settings page anchors its display strictly to Cupertino/Pacific Time, completely bypassing the device's local timezone. I noticed another developer raised this exact issue regarding KST back in September 2025 (Thread ID: 800332), but that post remains unanswered. My questions for the community and Apple Engineers: Can anyone officially confirm if the native iOS Settings > Subscriptions screen intentionally displays dates anchored strictly to Pacific Time (PT) rather than the device's local timezone? If so, how are you handling user inquiries when your app correctly displays the local time, but Apple's UI displays the day prior? Any official references or guidance on this behavior would be greatly appreciated to help us clarify this for our QA teams and end-users.

Following the guidance in the locked thread "Reporting your App Store Server Notifications issue" (https://developer.apple.com/forums/thread/774053) and a DTS support request on the same topic, I am posting this issue with the Feedback Assistant ID requested there: FB24820430. Summary: This is a content anomaly in Apple-signed App Store Server payloads, not a notification delivery problem — our server receives and verifies every notification; the defect is in the field values themselves. For a stable subset of subscription families, purchaseDate in JWSTransactionDecodedPayload is consistently ~8 hours later than the signedDate of the very same JWS — a purchase recorded as happening after the signed document reporting it existed. Reproducible field comparison inside one and the same Apple-signed JWS: Field relation Affected transactions Unaffected (control) transactions purchaseDate − signedDate +7h54m … +7h59m (never ≤ 0) ≈ 0 (seconds) Webhook arrival at our server ≈ signedDate (seconds to minutes), never ≈ purchaseDate ≈ signedDate originalPurchaseDate carries the same ~8h shift (renewals inherit it) no shift expiresDate − purchaseDate exactly one subscription period exactly one subscription period expiresDate − signedDate period + ~8h period All fields are documented as "UNIX time, in milliseconds". Our iOS client passes StoreKit 2 Transaction.purchaseDate through unmodified; our backend stores the epoch-millisecond values verbatim as UTC with no timezone conversion. These payloads are generated and signed by Apple infrastructure. Scale (production, as of 2026-09-14): ≈710 subscription families (distinct originalTransactionId lineages), ≈2,700 transactions — roughly three quarters of all families with renewals. Affected purchases span early March 2026 to present, ~30–45 new affected transactions per day. Observed across US, PH, ID and GB storefronts and across app build versions. Sandbox is unaffected. Our interpretation (inference, not confirmed): the offset varies between 7h54m and 7h59m rather than being exactly 8h, consistent with a local wall-clock time in a UTC+8 environment having been encoded as if it were UTC when the original transaction record was created, then inherited by all renewals of that family. Questions for Apple engineers: Is this a known issue in App Store Server data, and is there a reference we can track? What conditions cause a family's purchaseDate to be recorded this way (storefronts/regions, purchase channels, offer types, original-receipt formats)? When purchaseDate and signedDate disagree, which field is authoritative for "when the customer was charged"? The public documentation defines each field only as "UNIX time, in milliseconds" and does not define its relationship. Is remediation planned on Apple's side, or what is the recommended way to obtain the true charge time? Evidence: A focused sample project (a ~85-line Swift tool plus four unmodified signedTransactionInfo JWS samples — three affected families and one unaffected control, each carrying Apple's x5c certificate chain) is included in Feedback Assistant report FB24820430, together with the raw HTTP notification bodies for an affected and a control notification, exactly as delivered to our endpoint. Thank you.

I reached out to Apple Developer Support and they directed me to the forums. This video "Explore Retention Messaging in App Store Connect" shows a "Retention Messaging" section at the 3:21 timestamp of the video, within "Subscriptions" below the "Billing Grace Period" section. For the apps in our account, there is no "Retention Messaging" section available within the Subscriptions area. I am not asking about the API. I do not believe the API is required in order to have the Retention Messaging section show up in App Store Connect. In the video, the speaker says “I'll share an overview of Retention Messaging, and how to set it up in App Store Connect” and she shows how to navigate there. While she explains that “Real-time Retention Messaging is powered by the Retention Messaging API” - she also says that you can “create the same views using real-time Retention Messaging as you can when using retention messages in App Store Connect.” Is there something that we need to do in order to get access to this area of App Store Connect so we can set up Retention Messaging? Thank you so much.

Hello, We would appreciate some guidance regarding an unexpected StoreKit currency result in a TestFlight build. Our iPhone language and region are both set to France. The Sandbox tester is also configured for France, and our subscription products have French availability and pricing configured in App Store Connect. In the TestFlight build we diagnosed, StoreKit reports the current storefront as France with EUR: storefront=FRA/143442/EUR However, all 10 subscription products are returned with USD product metadata: products=10/10 formatCurrencies=USD localeCurrencies=USD error=NONE Example: formatCurrency=USD locale=fr_US_currency_USD localeCurrency=USD display=1,99 $US price=1.99 We first observed this through Flutter's in_app_purchase integration. To determine whether the Flutter plugin was involved, we added a native StoreKit 2 diagnostic to the same TestFlight build. The native result was identical: receipt=sandboxReceipt storefront before=FRA/143442/EUR storefront after=FRA/143442/EUR products=10/10 formatCurrencies=USD localeCurrencies=USD error=NONE The issue appears specific to the TestFlight distribution. When the application is installed directly from the development computer, prices are returned in euros on the same device. We also tested with the regular Media & Purchases account signed out and a French Sandbox tester connected. Once the products loaded successfully, StoreKit still returned USD metadata. In another configuration, the application displayed the USD price while Apple's purchase sheet displayed the price in euros. We are using the price and formatting information returned directly by StoreKit. We do not want to infer the currency from the device region or perform a client-side currency conversion, because StoreKit should remain the authoritative source. Could you please help us understand: Is it expected for Storefront.current to report FRA/EUR while Product.priceFormatStyle.currencyCode, its locale currency, and Product.displayPrice use USD? Could a TestFlight or App Store Connect configuration cause product metadata to use a different currency from the current storefront? Is there another account, availability, pricing or distribution setting that we should verify? Is there a recommended way to refresh or invalidate the product metadata used by a TestFlight installation? We have already filed Feedback Assistant report FB24723329, which is currently under investigation. Thank you very much for any clarification or additional diagnostic steps you can suggest.

Hello Apple Developer Forums, We are unable to authorize the Production App Store Server API Request a Test Notification endpoint. Environment: Production API: Request a Test Notification Library: Apple App Store Server Library for Java 5.2.0 Client: AppStoreServerAPIClient Result: HTTP 401 Unauthorized before a testNotificationToken is returned. We have verified the following: The key is an active In-App Purchase key created in App Store Connect under Users and Access > Integrations > In-App Purchase. The production server uses the matching .p8 private key, Key ID, Issuer ID, and bundle ID. The bundle ID is com.ansio.serviceproof.ios. The server clock is NTP-synchronized. The request uses the official Apple Java Server Library rather than a manually generated JWT. We rotated the production In-App Purchase key once and received the same 401 result. The notification URL is configured for the Production environment, uses HTTPS, and is reachable. Sandbox uses an independent key and notification configuration. We intentionally do not include the private key, JWT, Key ID, or Issuer ID publicly. According to the documentation, HTTP 401 means the JWT is invalid. Since the official library creates the JWT and the active In-App Purchase key configuration has been verified, could Apple clarify: Is any additional App Store Connect role, agreement, team activation, or entitlement required for a Production In-App Purchase key to authorize App Store Server API requests? Is there a known propagation or authorization issue that can cause a newly created active In-App Purchase key to return 401? What non-sensitive diagnostic details can help distinguish a JWT construction issue from a team-level authorization issue? Thank you.

Following the guidance in the locked thread "Reporting your App Store Server Notifications issue" (thread 774053), Feedback ID: FB24877994. Apple Developer Support case 102971044266 is open in parallel. Summary On our account no auto-renewable subscription renewal has ever succeeded, on either of our two products, while every customer-present initial purchase succeeds. In the last 48 hours 4 of 4 free trials that reached their renewal date with auto-renew ON failed with expirationIntent 2, in four countries (PK, GB, NL, US). What we observe Yearly product with a 7-day free introductory offer (all 175 territories, offerMode FREE_TRIAL, ONE_WEEK, 1 period). Monthly product with no offer. For each of the four, GET /inApps/v1/subscriptions/{originalTransactionId} returns status 3, and the renewal info has autoRenewStatus 1, expirationIntent 2, isInBillingRetryPeriod true, the correct renewalPrice and currency, no priceIncreaseStatus. Environment Production, inAppOwnershipType PURCHASED. The DID_FAIL_TO_RENEW notification (no subtype; billing grace period not enabled) arrives at the expiry time in each case. App Store Connect subscription events from 2026-08-01 to 2026-09-20: 18 free trial starts, 6 full-price starts, 4 voluntary churns from free trial, 4 from full price, 3 "Billing retry from free trial", 1 "Involuntary churn from full price", and no renewal event of any kind. So 5 of 5 unattended renewal charges ever attempted have failed, across two products and five countries, while the 6 paid monthly purchases in the same window (TR, FR, AU, MN, US) were charged normally at purchase time. The customers are in their own storefront countries (device time zones match), and none of the four cancelled. What we have verified Both products Approved, 175 price rows each, no scheduled or preserved prices; Paid Applications Agreement, Free Apps Agreement, banking, tax forms and both compliance items (DSA, MRDP) all show Active with nothing pending in App Store Connect > Business; our servers call no App Store Server API endpoint that modifies a subscription. Thread 847338 (posted today) describes every renewal on an account failing after an agreement issue, with expirationIntent 5. Ours is expirationIntent 2 and our agreements show Active, but the shape is the same: every renewal, no purchase affected. Questions for Apple engineers Is there any account, agreement or product condition that causes renewal charges to fail with expirationIntent 2 while initial purchases succeed? Is anything more than expirationIntent 2 available about these four renewals? The four original transaction IDs are in FB24877994. Is there a known issue affecting free-trial-to-paid renewals around 19 to 21 September 2026? Thank you.

Hello, I'm the developer of FOS Social (Apple ID: 6755471015), a creator-membership marketplace currently in TestFlight. I've submitted the Advanced Commerce API access request form twice and have not received any response, confirmation, or status update. My most recent submission has Request ID: UVQ7FUZVV3. Our use case: FOS Social is a social platform where viewers subscribe to individual content creators through independent auto-renewable monthly subscriptions across three tiers ($10 / $17 / $29). A single viewer must be able to hold concurrent active subscriptions to multiple creators at the same tier — for example, subscribed to Creator A at Gold and Creator B at Gold simultaneously. This matches Apple's stated eligibility model for the Advanced Commerce API: "exceptionally large catalogs of subscription content — apps that include frequently added content from multiple creators, where each creator's offering is merchandised as a single auto-renewable subscription." Why standard StoreKit doesn't work for us: We currently reuse one product ID per tier across all creators (e.g. com.fosssocial.creator.gold.monthly). When a viewer already subscribed to one creator at Gold tries to subscribe to a second creator at Gold, StoreKit returns "already subscribed" and treats it as a renewal rather than a new independent subscription. Pre-creating a separate subscription group per creator in App Store Connect is not feasible since our creator base is dynamic and growing. My questions: Is there any way to check the status of an Advanced Commerce API access request, or a typical response timeframe we should expect? Is there anything that commonly causes these requests to go unanswered (e.g. submission not made by the Account Holder, app still in TestFlight, missing information)? Is there a recommended escalation path when the request form has been submitted multiple times with no reply? I've also opened a support case (Case ID: 102934491974) but wanted to ask here as well in case anyone from the community or Apple has guidance. Thank you!

Hello, We are currently seeing errors when validating receipts for every auto-renewable subscription purchased through both StoreKit 1 and StoreKit 2. Details below. Case 1 — StoreKit 1 Calling https://buy.itunes.apple.com/verifyReceipt with the subscription receipt returns: "status": 21006, "expiration_intent": "5" Case 2 — StoreKit 2 Calling https://api.storekit.itunes.apple.com/inApps/v1/subscriptions and reading the most recent transaction (LastTransactionsItem) returns status 3. Within JWSRenewalInfoDecodedPayload: autoRenewStatus = 1, expirationIntent = 5 Timeline We believe renewals stopped processing for essentially all auto-renewing subscribers of our app as of 2026-09-18 09:30 KST (UTC+9). After resolving an agreement/licensing issue on our side, new purchases and some receipt validations recovered as of 2026-09-21 11:49 KST. However, most existing receipts still return expirationIntent = 5 when we query receipt validation or subscription status. Questions Is any action required on our side — a server-side change, a configuration change in App Store Connect, or a further review of our agreements? Now that the agreement issue is resolved, when are the renewals that were left pending during the outage expected to be processed? Any guidance would be appreciated. Thank you.

Hi everyone, I'm planning an iOS app that provides a personalized invitation-card creation service, and I'm trying to determine the correct payment method before starting development. The flow would be: User selects an invitation template. User enters their event/invitation details. The app generates a watermarked preview. User proceeds to checkout. User pays for the creation of the final personalized PDF. After successful payment, our backend places the request into a processing queue. The PDF is generated asynchronously on our server. Once completed, the user receives a notification and can download the final PDF. The purchase does not unlock an app feature, subscription, membership, or ongoing access to digital content. The user is paying for a specific personalized invitation document to be generated based on their selected template and information. Each template can have a different price. My question is: Would this type of personalized document-generation service be required to use Apple's In-App Purchase, or could an external payment processor such as Razorpay be used? I have reviewed the App Store Review Guidelines, particularly the sections concerning In-App Purchase and physical goods/services, but I'm not certain how Apple classifies a personalized digital document-generation service like this. If anyone has implemented a similar business model or can point me to the relevant Apple guideline or an official Apple clarification, I would really appreciate it. I'm asking before development so that the payment architecture can be designed correctly from the beginning. Thanks!

Hi everyone, I'm planning an iOS app that provides a personalized invitation-card creation service, and I'm trying to determine the correct payment method before starting development. The flow would be: User selects an invitation template. User enters their event/invitation details. The app generates a watermarked preview. User proceeds to checkout. User pays for the creation of the final personalized PDF. After successful payment, our backend places the request into a processing queue. The PDF is generated asynchronously on our server. Once completed, the user receives a notification and can download the final PDF. The purchase does not unlock an app feature, subscription, membership, or ongoing access to digital content. The user is paying for a specific personalized invitation document to be generated based on their selected template and information. Each template can have a different price. My question is: Would this type of personalized document-generation service be required to use Apple's In-App Purchase, or could an external payment processor such as Razorpay be used? I have reviewed the App Store Review Guidelines, particularly the sections concerning In-App Purchase and physical goods/services, but I'm not certain how Apple classifies a personalized digital document-generation service like this. If anyone has implemented a similar business model or can point me to the relevant Apple guideline or an official Apple clarification, I would really appreciate it. I'm asking before development so that the payment architecture can be designed correctly from the beginning. Thanks!

One user of my app reached out reporting an interesting in-app purchase issue. Has anyone encountered this or have an idea what's going on here? Proceed to purchase the non-consumable IAP in the app downloaded from the App Store iOS shows the price sheet as expected Confirm with the side button iOS shows an alert "You've already purchased this. Would you like to get it again for free?" Tap OK iOS shows an alert "You're all set. Your purchase was successful." Tap OK The app's content remains locked Tap Restore Purchases iOS shows an alert to sign (with the same account shown in step 2) Input the password and tap OK iOS shows an alert "Unable to Complete Request" (which is the error.localizedDescription thrown from AppStore.sync())

To the Apple Review and Developer Support Teams, I am writing to request guidance and assistance regarding a persistent rejection my React Native application is facing under Guideline 2.1 - Performance (In-App Purchases). My app has been rejected multiple times with the following specific note: "The In-App Purchase products in the app still exhibited one or more bugs which create a poor user experience. Specifically, the subscription screen failed to load any subscription plans. Review the details and resources below to troubleshoot this issue." The screenshot provided by the review team shows a completely black screen where our paywall options are intended to populate, indicating that the product array is returning completely empty during the review process. The Dilemma: We are completely unable to reproduce this behavior on our end. Everything functions flawlessly within our TestFlight builds across multiple physical test devices and various sandbox tester accounts. On TestFlight, the paywall renders instantly, local pricing fetches immediately via SKProductsRequest, and test transactions process without a single error. Our Current Implementation & Verification: Product Status: All subscription products are explicitly marked as "Waiting for Review" in App Store Connect with one In-App product Rejected for not being attached with a bin but I've since submitted the app once again. All the subscriptions and the in-app product have been actively attached to this specific app submission version. Agreements: The Paid Apps Agreement is active, signed, and fully up to date within our Agreements, Tax, and Banking configurations. Identifiers: We have strictly verified that the hardcoded product identifiers in our React Native codebase match the App Store Connect product IDs exactly. Because this error only occurs within the App Review environment and never in TestFlight or local sandboxes, we are at a loss for how to debug or resolve this issue. Could the App Review team or the Developer Support technical team please clarify if there is a known environment mismatch, storefront routing discrepancy, or specific network configuration (such as IPv6 handling in the review sandbox) that would cause production-ready StoreKit products to return an empty array exclusively to the reviewer? Any direct guidance, logs, or steps on how we can successfully surface our plans to your review team would be deeply appreciated. Review Environment Submission ID: 5a35279c-1621-4972-b6c6-7c1fb202b2f0 Review date: May 20, 2026 Review Device: iPad Air 11-inch (M3) Version reviewed: 1.0.2 (8) Thank you for your time and assistance.

We are seeing a consistently reproducible StoreKit Sandbox issue involving Apple’s refund request sheet. Our app uses: Transaction.beginRefundRequest(for:) The refund sheet is successfully presented, but instead of loading the refund reason form, the Apple-provided sheet consistently displays: “Cannot Connect” This prevents the Sandbox refund request from being submitted. Environment: App: BTY Norebang Admin iOS: 26.6.1 Physical iPhone StoreKit environment: Sandbox Product type: Consumable Product: BTY Room – 1 Hour Development-signed build We have confirmed: Normal consumable purchase succeeds Transaction retrieval succeeds beginRefundRequest successfully presents Apple’s refund sheet App Store Server API calls succeed App Store Server Notifications V2 TEST delivery succeeds Get Test Notification Status reports sendAttemptResult = SUCCESS The problem persists after rebooting the device The problem persists after signing out and back into the Sandbox Apple Account Different network conditions have been tested The issue reproduces in an isolated Xcode/StoreKit test project with no BTY backend, authentication, or app networking dependency Expected behavior: The Sandbox refund request sheet should load the refund reason selection and allow the refund request to be submitted. Actual behavior: The Apple-provided refund sheet opens but displays “Cannot Connect.” No refund is submitted and no App Store Server Notification V2 REFUND event is generated. Feedback Assistant report: FB24527792 The Feedback Assistant report includes sysdiagnose and relevant diagnostic logs. This is currently the only remaining external blocker preventing us from completing full and prorated Sandbox refund end-to-end validation before enabling Production App Store Server Notifications. Could an Apple StoreKit / App Store Commerce engineer confirm whether this is a known Sandbox issue or advise whether any additional configuration or diagnostic information is required? We can provide a focused reproduction Xcode project, additional sysdiagnose logs, and Sandbox transaction details if needed.

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?