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

Summary: In Sandbox, Product.products(for:) returns all 3 of my IAPs with correct JPY prices and Japanese localizations, but product.purchase() fails immediately — the payment sheet is never presented — with ASDServerErrorDomain Code=3504 (Product.PurchaseError.productUnavailable). All 3 products fail identically. Reproduction captured in the sysdiagnose attached to FB24067333: 2026-07-30 18:43:58 JST — in-app purchase() on app.negaiboshi.placement; 18:44:40 JST — OS-level test (Settings > Developer > Sandbox Apple Account > Manage > Start Transaction), same product ID. Server correlation keys from the device log: inAppBuy → AMSServerCorrelationKey HNB5UGLE72AXSMY5KY7G4NAXQY (failureType 3504); Start Transaction → FQN4Y4JOEHYBW2GIR7KPTYTB2A (AMSServerErrorCode 3766, "provided product ID or bundle ID is invalid"). Environment App: Negaiboshi — Apple ID 6794682125, Bundle ID app.negaiboshi, Team 778QPP83C4 App status: first submission in preparation (never reviewed); build 1.0 (1) on TestFlight IAPs (all "Ready to Submit" since 2026-07-27 JST, attached to the 1.0 submission): app.negaiboshi.pro.monthly (auto-renewable, ¥480, group 22264517), app.negaiboshi.placement (non-consumable, ¥720), app.negaiboshi.nightsky (non-consumable, ¥1,200) IAP base country: Japan (JPY); availability 145/175 countries Device: iPhone, iOS 26.5.2; development build from Xcode; StoreKit Configuration = None Sandbox Apple Account: (address in FB24067333), region Japan, no purchase history; signed in under Settings > Developer Storefront.current = JPN. No Screen Time restrictions. Actual error (verbatim): Error Domain=ASDServerErrorDomain Code=3504 "このアイテムは見つかりませんでした。" UserInfo={AMSServerErrorCode=3504, client-environment-type=Sandbox, storefront-country-code=JPN} TN3186 checklist fully verified, none apply (Paid Apps Agreement, banking, tax all active; bundle ID + IAP capability; signing; membership). Also tried: Sandbox sign-out/sign-in, device restart — no change. Consistent across all 3 products and relaunches. Reproduced with zero app code involved (decisive): Settings > Developer > Start Transaction with product ID app.negaiboshi.placement and bundle ID app.negaiboshi fails: "The provided product ID or bundle ID is invalid. [Environment: Sandbox]" — Apple's own OS-level tool, no third-party code. Calibration: a deliberately nonexistent ID (app.negaiboshi.zzz) yields the identical error — the backend treats my real product like a nonexistent one. A price change (¥720→¥700, "now", 2026-07-29) propagated to the sandbox metadata catalog within minutes (products(for:) returned "¥700") — purchase() still 3504. Reverted. A full base-country change (2026-07-30): Japan (¥720) → United States ($4.99) at 15:52 JST — this deletes and recreates the price schedule and is the exact operation that resolved the identical symptom in thread 839557. It propagated to the metadata catalog (auto-converted ¥800 shown in ~20 min), yet purchase() and Start Transaction still failed at 16:10 and 16:55 JST. Reverted to ¥720 at 16:59 JST. Every lever that rewrites the price schedule reaches the metadata catalog but never the commerce/purchase catalog. Timeline: the products reached Ready to Submit hours after the 2026-07-26 15:22–17:58 PDT In-App Purchases outage (Message ID 1000005803), and the failure still reproduces after the 2026-07-29 16:20–19:30 PDT emergency maintenance on In-App Purchases + Advanced Commerce API (messageId 1000005805). Peer reports with the same metadata-vs-commerce-catalog split in the same window: threads 839220, 839441, 839437, 839645, 839557. Questions: Why does purchase() fail server-side with 3504 ("item not found") while products(for:) succeeds for the same IDs in the same JPN storefront? Can someone check the sandbox commerce-catalog state of the 3 product IDs above (Apple ID 6794682125)? This looks like a server-side provisioning failure that no developer-side action can repair. Is any additional App Store Connect state required before sandbox purchases can complete for a never-yet-reviewed app?

I am unable to link my new non-consumable In-App Purchase (idea_think_pro) to my draft update page (iOS 2.0.0).The product is fully configured with required screenshots and metadata, and displays the blue "Add for Review" button. However, clicking it shows the hard validation block: "Your first non-consumable in-app purchase must be submitted with a new app version."Simultaneously, the "In-App Purchases and Subscriptions" section is completely missing from my iOS 2.0.0 version page, even when no app build is attached. I have cleared all active submissions and browser caches. Please manually link Product ID idea_think_pro to App Version 2.0.0 on your database or reset my version layout cache.

Summary Sandbox purchases of our first auto-renewable subscription fail with "This item cannot be found". Product metadata loads correctly, so this looks specific to commerce. Our App Store Connect configuration is complete and has been verified exhaustively, and four other apps on the same team sell in-app purchases in production without issue. The affected app has never been submitted or released, and the subscription sits in "Ready to Submit". Symptoms On device (TestFlight build, purchasing with the tester's real Apple Account - no sandbox Apple Account is configured, per the documented TestFlight flow), a purchase attempt returns storeProductNotAvailable and the system alert "Item Unavailable". Device logs (idevicesyslog) show: mzstorekit-sb.itunes.apple.com/inApps/v2/history -> HTTP 404, (4040004) App not found sandbox.itunes.apple.com/.../inAppBuy -> AMSErrorDomain 305, AMSServerErrorCode=3504, "This item cannot be found" Product.products(for:) returns the product and the paywall renders product.displayPrice, so product metadata resolves. Only the purchase fails. Server-side observation Using the App Store Server API in the sandbox environment with our team key, requesting a deliberately non-existent transaction ID: GET https://api.storekit-sandbox.itunes.apple.com/inApps/v1/history/1234567890 App Products Released? Result The affected app 1 subscription, Ready to Submit never HTTP 401, empty body Another app, same team non-consumable, Approved yes 404 4040010 Transaction id not found Another app, same team 2 non-consumables, Approved yes 404 4040010 Transaction id not found Another app, same team 2 non-consumables, Approved yes 404 4040010 Transaction id not found Another app, same team non-consumable, Approved yes 404 4040010 Transaction id not found Same key, same issuer, same team, same request shape - only the bid claim differs. We note openly that this is not a clean experiment: all four comparison apps differ from the affected app in two ways at once (they are released, and they have approved products), so the 401 may simply reflect an app with no approved commerce products rather than a missing app record. We include it because the difference is stark and reproducible, not because we think it is conclusive. What makes this app different Being unreleased does not by itself appear to be the barrier: we were able to test the in-app purchases of the four apps above in the sandbox before those apps were released. The difference we cannot account for is product type and approval state - those were one-time non-consumables, whereas this is our first auto-renewable subscription, which App Store Connect tells us "must be submitted with a new app version" and which has therefore never been approved. Timeline 2026-07-30 ~00:30 CEST - Pricing and Availability set for the app (it had been unset; that was the cause of an earlier, separate failure). 2026-07-30 09:26 CEST - captured the device logs above. 2026-07-31 00:50 CEST - toggled a territory's availability off and back on to force a re-propagation of the availability record. No change. 2026-07-31 - still failing 24+ hours on. Automated probes every 30 minutes throughout have returned the same result without exception. This is well beyond the "up to 1 hour" propagation window documented in TN3186. Already verified Account level - four other apps on this same team currently sell in-app purchases in production: Paid Apps agreement: Active Banking and tax information: complete and active App Store Connect configuration for the affected app: App availability: 175 of 175 territories, none excluded Subscription availability: 175 of 175 territories Subscription priced in all 175 territories Four localizations and the review screenshot present; group localized; subscription state Ready to Submit App price: Free Every territory reads CANNOT_SELL / AVAILABLE_FOR_SALE_UNRELEASED_APP, consistent with an app that has not yet been released Client / build: Product ID in code matches App Store Connect exactly Explicit App ID (no wildcard), In-App Purchase capability enabled Build signed with Apple Distribution, delivered via Transporter, tested from TestFlight (not a development build) No StoreKit configuration file active in the scheme Bundle ID matches the App Store Connect record Questions Is the subscription provisioned for commerce in the sandbox environment? The (4040004) App not found response suggests the app or its commerce record is not present there. TN3186 states that sandbox testing does not require submitting in-app purchases for review. Does that hold for an app's first auto-renewable subscription, given that such a subscription must be submitted alongside an app version and so cannot reach an approved state beforehand? If submitting the app version together with the subscription is in fact the prerequisite, please confirm - we are currently holding our submission specifically so we can complete one successful sandbox purchase first, since App Review purchases through this same environment. If that ordering is not possible, we would rather submit and have App Review encounter the working production path than keep waiting on a sandbox purchase that cannot succeed. Happy to provide the app's Apple ID and product identifier privately if that helps.

Hello Applet, I’m experiencing an issue with StoreKit on a TestFlight build. My app uses auto-renewable subscriptions through StoreKit and RevenueCat. Configuration already verified: App installed through TestFlight (not debug). Bundle Identifier: com.ciborgu.vytalai Paid Applications agreement is active. In-App Purchase capability is enabled. Three auto-renewable subscriptions exist in App Store Connect. Product IDs match exactly between App Store Connect, RevenueCat and the application. RevenueCat initializes successfully. A Sandbox test account has been created. Tested on a physical iPhone. Device restarted and app reinstalled from TestFlight. VPN and iCloud Private Relay disabled. When attempting to purchase a subscription, the Apple payment sheet never appears. Our diagnostics indicate that StoreKit does not return any available products for the configured Product IDs, preventing the purchase sheet from opening. Expected Product IDs: vytalai_premium_monthly vytalai_premium_yearly vytalai_premium_yearly_intro Could you please verify if there is any issue with the App Store Connect configuration, StoreKit availability, or the processing state of these subscriptions on Apple’s side? If additional logs or diagnostics are required, I can provide them. Thank you. I have already contacted Apple Developer Support regarding this same issue. Previously, I was advised to schedule a technical support meeting. However, when I requested the meeting, my request was declined because of the subject of my issue, so I was unable to speak with an Apple engineer. Since I have now completed all the recommended troubleshooting and the issue still persists, I would greatly appreciate it if this case could be reviewed by the appropriate technical team or a StoreKit engineer. Thank you for your assistance.

Well, here we go again. The subscription items are rejected because I have not submitted a binary. (Except I have, of course.) The binary is rejected because I have not submitted the IAP subscription items. (Except I have, of course.) Neither lets me submit the other again alongside it. Brilliant system.

Need to vent a bit before relaxing for Christmas... WatchOS IAP using Storekit 2 is such a mess...is nobody actually using this or does Apple just not care for the user experience here? Lots of users experience after the purchase confirmation double tap on the side button an instant return to the purchase screen with nothing actually happening. No error message whatsoever. There is just one remedy: users need to unpair and re-pair their watch, including restoring a backup and setting up their wallet again. Nobody really wants to do this, or doesn't believe me and think this is just typical support BS, because their watch is paired and most things just work as they expect. And it turns away a customer, often leaving a bad review. And I can't do anything about it. Other errors in the purchase process are reported, but like "process interrupted" in case the payment is not setup correctly (credit car no longer valid or sth.). How should the user know? There must be better ways of letting him know what exactly the problem is. You need to implement a "Restore Purchase" function, otherwise you're not passing the review. But it really asks every time for the AppStore password, and users with crazy passwords -- that they rightfully should have! -- have almost no chance of typing them successfully on the tiny AW keyboard. Why is it not also just a side button double tap like for purchase? At the very least you would need access to the keychain PWs or allow pasting of sth. copied on the paired iPhone. Promo Codes for IAP on AW-only apps just don't work. AW has no redemption at all, and on the iPhone the AppStore will try to talk to a companion app (which AW-only doesn't have) and the end up in a dead-end installation effort. This all feels like never really tested in the field, and people are of course blaming the 3rd party dev. for all these issues. And opening a ticket is just leading nowhere -- at best it's closed after months with the hint "duplicate" but w/o any chance for me to see that one that they then actually work on and track progress. It's all so frustratingly broken...

Hello, I'm developing a consumer iOS app (Capacitor + RevenueCat SDK) and I've been blocked for several weeks on a StoreKit issue: subscription products are never returned to the device, so the Apple payment sheet cannot open. I previously contacted Apple Support. I was told to request a phone call, but my call request was declined because of the topic (StoreKit / in-app purchases). I'm posting here hoping someone from Apple or the community can help. App details App name: Vytal AI Bundle ID: com.ciborgu.vytalai App Store Connect App ID: 6767160542 Team ID: JZF7CR3W8Z Distribution: TestFlight (physical iPhone, France) iOS deployment target: 15+ Subscription product IDs (auto-renewable) vytalai_premium_monthly vytalai_premium_yearly vytalai_premium_yearly_intro All three are in subscription group "Vytal AI" on the correct ASC app (not a typo bundle). Cleared for Sale is ON. Paid Apps Agreement is active. In-App Purchase capability is enabled on the App ID (checkbox is grayed out / locked, which I understand is normal). Problem On a real device via TestFlight: RevenueCat SDK configures successfully (public iOS API key present in build). Purchases.getProducts({ productIdentifiers: [...] }) returns { products: [] } — zero products. Because StoreKit returns an empty array, the Sandbox payment sheet never appears when the user taps Subscribe. This is NOT a UI issue — the native SDK call to Apple returns no products. What I've already verified Bundle ID in signed IPA matches ASC app: com.ciborgu.vytalai Subscriptions exist only on the correct app (not on an old typo bundle com.ciborgue.vytalai) Removed duplicate ASC app; old App ID cannot be deleted ("in use by App Store") but has no IAPs Regenerated EAS provisioning profile for com.ciborgu.vytalai Sandbox tester account configured on device (Settings → App Store → Sandbox Account) Tested without VPN / iCloud Private Relay Reinstalled app from TestFlight after ASC changes Waited for propagation after metadata / availability updates Associated Domains enabled (for deep links) — separate from IAP SDK / integration @revenuecat/purchases-capacitor 13.x Direct StoreKit fetch via Purchases.getProducts() (not only RevenueCat offerings) Same result: 0 products from Apple Expected vs actual Expected: StoreKit returns 3 subscription products in Sandbox; payment sheet opens on purchase. Actual: products array is always empty; no payment sheet. Questions Why would StoreKit return 0 products for valid auto-renewable subscriptions on TestFlight when metadata is "Waiting for Review" / in review — shouldn't Sandbox still return products per TN3186? Is there an ASC configuration state (availability, subscription group localization, missing review screenshot on yearly products, etc.) that causes StoreKit to return zero products even in Sandbox? Is there an internal flag or propagation delay on Apple's side I should ask to be reset for this app/bundle? I'm happy to provide additional logs, a sysdiagnose, or a short screen recording from TestFlight showing the empty product response. Thank you for any guidance — this is blocking App Review (Guideline 2.1) and I cannot test IAP at all. Nathan

Hi, I’m testing an iOS app with auto-renewable subscriptions in the Apple sandbox environment. The app has its own account system. A user can create/log in with different accounts inside the app. The issue I’m seeing is this: I subscribe to the Pro plan using one sandbox Apple ID. Then I log out of the app. I create or log in with a different account inside the app, but still on the same iPhone / same sandbox Apple ID. Inside the app, this new app account is not marked as subscribed. When I try to subscribe again, StoreKit returns: “Item already owned” So Apple recognizes that the Apple ID already owns the subscription, but our app account does not have Pro access yet. The only way to resolve this is to provide a “Restore Purchase” option, so the current app account can restore the subscription already owned by the Apple ID. My questions are: Is this expected behavior for auto-renewable subscriptions? Can this happen in production too, or is it mainly a sandbox behavior? If a user has multiple accounts inside the app but uses the same Apple ID, is the subscription considered owned by the Apple ID and restorable across those app accounts? Is it acceptable/recommended to keep a small “Already subscribed? Restore purchase” option visible on the paywall at all times? If the app wants to prevent the same Apple subscription from being used across multiple internal app accounts, what is the recommended approach? For brand new Apple IDs that have never subscribed before, the normal purchase flow works correctly. Thank you.

My app already has an approved subscription group with approved monthly and annual subscriptions. I later submitted a new non-consumable in-app purchase with an app version. App Review rejected the submission because the paywall also displays the existing subscriptions, stating that the subscriptions had not been submitted for review. However, App Store Connect will not let me add the approved subscriptions to the submission because they are already in Approved status and the Add for Review button is disabled. At this point I'm unsure what corrective action App Review expects. I've replied through the App Review message thread requesting clarification, but I have never received a response to messages sent through App Review. I also attempted to contact Apple Developer Support through the Dispute App Rejection support option, but after waiting on hold for over two hours I was still unable to reach anyone. Has anyone encountered this workflow before? Is there a way to include previously approved subscriptions in a new review that I'm missing, or does this require App Review to resolve internally?

I am experiencing an issue with a non-consumable in-app purchase in my iOS app. The product loads correctly from the App Store and is displayed in the app, but when attempting to complete the purchase, StoreKit returns the following error: Payment completed with error: Error Domain=ASDServerErrorDomain Code=3504 "This item cannot be found." UserInfo={ NSLocalizedFailureReason=This item cannot be found., AMSServerErrorCode=3504, client-environment-type=Sandbox, storefront-country-code=USA } The same issue was also encountered by the App Review tester when they attempted to purchase the non-consumable product during review. The product: Is correctly configured in App Store Connect Has active pricing Is available in the United States Was included in the app submission Loads successfully and displays the correct price Fails only when the purchase is initiated Since the product metadata can be retrieved successfully, but the transaction fails with “This item cannot be found,” this appears to be a possible inconsistency between the StoreKit product catalog and the purchase backend. Has anyone encountered ASDServerErrorDomain Code=3504 for a non-consumable product that loads correctly but cannot be purchased? Is there any known App Store sandbox or commerce backend issue that can cause this, or any additional App Store Connect configuration that should be checked?

Hello everyone, I'm a developer from Brazil and this is my first App Store payout. I've already reviewed Apple's documentation regarding payments, but I haven't been able to identify why I haven't received my payment yet. Here is my situation: My Paid Apps Agreement is active. My bank account is active and correctly configured. All required tax forms (Brazil + W-8BEN-E) are active. I can see my estimated proceeds in App Store Connect. My earnings reports are available and show the expected amounts. There is no "Balance Carried Forward" and no indication that the payment was returned. This would be my first payment from Apple. However: I have not received any payment in my bank account. I cannot find any Payment Date, Transaction ID (CCI), or indication that the payment has actually been sent. I've also opened a support ticket with Apple in Portuguese, but while waiting for their response I'd like to know if anyone has experienced something similar. My questions are: Is it normal for the first payout to take longer than subsequent payments? Is there any additional verification that Apple performs before sending the first payment? Is there any page in App Store Connect that I might be overlooking where I can verify the actual payment status? Has anyone from Brazil experienced delays with the first payout even with all agreements, banking information, and tax forms marked as Active? Any advice or shared experience would be greatly appreciated. Thank you!

App Store Server Notification returns successful purchase while customer's payment remains Pending We have encountered an edge case with a Non-Renewing Subscription and would appreciate clarification on the expected developer behavior. Steps to reproduce User initiates an in-app purchase using a credit card. The purchase succeeds in the app. Our backend receives an App Store Server Notification V2 (ONE_TIME_CHARGE). We successfully verify the signed JWS transaction. The same transaction is also returned by the App Store Server API. Based on the verified transaction, we grant the user's entitlement. However, on the customer's Apple account: The purchase is shown as Pending in Purchase History / Report a Problem. The customer reports that their credit card has not yet been charged. Question From a developer's perspective, should entitlement be granted immediately after receiving a valid App Store Server Notification and successfully verifying the transaction, even if the customer's purchase is still shown as Pending? Is there any App Store Server API or transaction field that indicates the payment has not yet been settled, allowing developers to delay granting entitlement until the payment is finalized? Or is the expected implementation to grant entitlement upon successful transaction verification and revoke it only if Apple later sends a refund notification? Any clarification on the expected workflow would be greatly appreciated. Thanks in advance. :)

Title: Sandbox allows free trial again on resubscribe to the same subscription Hi everyone, I'm testing an auto-renewable subscription using App Store Connect with a Sandbox tester (not a local StoreKit configuration file). My subscription has an introductory free trial configured. Scenario: Purchase the subscription for the first time using a Sandbox Apple ID. The user receives the introductory free trial as expected. Let the subscription expire. Purchase the same subscription product again using the same Sandbox Apple ID. I receive an App Store Server Notification with Notification Type = RESUBSCRIBE, and the transaction appears to have a price of 0, making it look like the user received another free trial. From Apple's documentation, my understanding is that an introductory offer can only be redeemed once per subscription group per Apple ID. Based on that, I expected the second purchase to be charged immediately rather than receive another free trial. My questions are: Is this expected behavior in the Sandbox environment? Does Sandbox sometimes allow introductory offers to be redeemed multiple times for testing? Or am I misinterpreting the RESUBSCRIBE notification and the $0 transaction? I did not intentionally reset the Sandbox tester's introductory offer eligibility, and I'm purchasing the same product in the same subscription group with the same Sandbox Apple ID. Has anyone observed this behavior or can clarify whether this is expected in Sandbox versus production? Thanks!

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!

Summary After setting a single auto-renewable subscription product (not the app) to "Developer Removed from Sale" in App Store Connect, the next scheduled renewal for an existing active subscriber failed with DID_FAIL_TO_RENEW v2 and expirationIntent = 5 ("expired for some other reason"). I expected expirationIntent = 4 ("product wasn't available for purchase at the time of renewal"), since the product was, in fact, not available for purchase. I would like to confirm whether 5 is the documented/expected value for this scenario, and how to deterministically distinguish "developer removed product from sale" from other renewal failures using the notification payload. Reproduction / observed sequence Day 15: Changed product annual_promo (auto-renewable subscription) status from "Approved" to "Developer Removed from Sale" in App Store Connect. The app itself remained Approved and on sale. Other subscription products in the same group remained Approved. Day 16: An existing active subscriber on that product had a scheduled automatic renewal date. Result: Renewal did not occur. We received a DID_FAIL_TO_RENEW v2 notification. Payload (relevant fields): JWSRenewalInfoDecodedPayload.expirationIntent = 5 JWSRenewalInfoDecodedPayload.autoRenewStatus = 0 Questions Is expirationIntent = 5 the correct/expected value when a renewal fails because the developer removed the product from sale? Or should it have been 4 ("product wasn't available for purchase at the time of renewal")? If 5 is intentional, what is the engineering rationale for not using 4 in this scenario? Given that expirationIntent = 5 is documented as a catch-all ("some other reason"), which other fields in the DID_FAIL_TO_RENEW payload (e.g., subtype, autoRenewStatus, gracePeriodExpiresDate, signedTransactionInfo) should we inspect to deterministically classify the failure cause and isolate "developer removed product from sale" from billing failure / customer cancel / price-increase not accepted / etc.? Context I'm aware of the docs page In-App Purchase statuses and Set availability for an auto-renewable subscription, but they describe the status semantics, not the resulting notification payload. Product has been reverted to "Approved" to avoid further impact on subscribers while this is clarified. Thanks in advance.

Hi everyone, I’m looking for advice on the best escalation path for an App Store Connect tax issue that is blocking our Paid Apps / In-App Purchase setup for a live app. Timeline: Jun 18, 2026: Opened a Finance Support case for tax information submissions. Since then: No update from Apple Finance. Current impact: Paid Apps / IAP cannot be completed, and users are already trying to purchase the Pro upgrade. I have also submitted a new Finance contact request under Tax information submissions. Has anyone dealt with a similar App Store Connect tax issue where Finance Support went quiet? Is there any escalation path beyond the Finance contact form and replying to the original iTSPayments email? Any guidance from Apple staff or developers who have been through this would be appreciated.

Since January 28, 2026, we’ve noticed an increase in StoreKit-related errors during purchase flows. Specifically, we’re seeing a spike in errors reported as “Unable to Complete Request”, categorized as unknown StoreKit errors. This correlates with a noticeable drop in the overall purchase success rate. A few observations: The issue is not limited to the latest app version, it also affects older versions. It appears to occur only on iOS 17+. The impact seems country-specific: some regions are affected more heavily, while others show no significant change compared to previous days. At the moment, there are no related incidents reported on Apple’s System Status page. Given these symptoms, this looks like a potential StoreKit / Apple API issue, but we haven’t found any official confirmation yet. Has anyone else observed similar StoreKit behavior recently on iOS 17+? Any insights or known issues would be greatly appreciated.

Getting 2.1(b) rejection. Reviewer sees "Purchase Failed" alert. Products configured correctly in ASC. Does App Review sandbox use same sandbox environment as developer testing? Can reviewer sandbox accounts trigger purchase failures that developer sandbox accounts cannot? Any known issues with first-time IAP products failing specifically during App Review sandbox session?

Hello everyone, I am currently refining our server-side transaction verification and purchase tracking using StoreKit 2 and the App Store Server API. We are looking into how our backend can accurately track the specific App Store commission rate applied to each individual transaction. With potential future regulatory changes in various markets that might introduce different fee structures between device types, it is becoming crucial for our system to distinguish these details at the transaction level. I contacted Apple Support regarding this but couldn't get a technical clarification, so I would like to ask the community and Apple engineers here: (1) Commission Rate: Is there any standard field in the StoreKit 2 Transaction payload or the JWS payload from the App Store Server API (V2) that explicitly indicates the applied commission rate (e.g., 15%, 30%) or a specific commission tier for that transaction? (2) Device Type: If the commission rate is not directly included, is there a native field in the real-time transaction payload to identify whether the purchase was made on an iPhone or an iPad? (I understand we can use appAccountToken as a workaround to link client-side device info to our backend, but I am wondering if there is a built-in identifier.) (3) Official Verification Method: If real-time API payloads contain neither, would using the App Store Connect API to retrieve the "Summary Sales Report" or "Subscriber Report"—and deriving the commission rate from Customer Price and Developer Proceeds—be the recommended approach? Are there any other best practices for handling this at scale? Any insights from Apple engineers or developers who have implemented similar tracking would be highly appreciated. Thank you in advance!

I’m seeing an App Store Connect / StoreKit product-availability issue for a universal iOS + macOS app. Product ID: com.vincentchu.VideoAtlas.pro.lifetime The product is a one-time, non-consumable lifetime purchase. Current state: Both iOS and macOS apps are approved. The IAP status is Approved. I waited more than 24 hours after IAP approval before retesting. The IAP is configured for the universal app, is available in 175 storefronts, and has an effective price. Paid Applications agreement, tax, and banking are active; this account already has other paid apps. In-App Purchase capability is enabled for both targets. The product ID exactly matches the App Store Connect product ID. Production schemes have StoreKit Configuration: None. iOS is tested from TestFlight, so it uses StoreKit sandbox. macOS is tested from a development-signed build against sandbox, also with no local StoreKit configuration. The app uses StoreKit 2: let products = try await Product.products( for: ["com.vincentchu.VideoAtlas.pro.lifetime"] ) The call does not throw an error, but returns an empty array on both platforms: StoreKit product request completed productIDs=com.vincentchu.VideoAtlas.pro.lifetime returnedCount=0 returnedProducts= StoreKit returned no products for requested productIDs= com.vincentchu.VideoAtlas.pro.lifetime As a result, the app cannot retrieve Product.displayPrice or offer the purchase. I have already followed "TN3186: Troubleshooting In-App Purchases availability in the sandbox", including checks for product identifier, bundle identifier, IAP capability, provisioning/signing, StoreKit configuration, sandbox testing, paid-app agreements, IAP approval, pricing, and storefront availability. Since this is an empty result rather than an error, and it persists more than 24 hours after approval on both TestFlight and macOS sandbox, is there an additional App Store Connect-side configuration or Apple-side issue that could cause an approved non-consumable IAP not to be returned by Product.products(for:)? Thanks.