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, 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.

We are stuck in a review rejection loop regarding In-App Purchases (IAP) and Subscriptions, and we need advice on how to break out of it. The Background: A few weeks ago, we submitted a companion app that included IAPs and auto-renewable subscriptions. The App Review team rejected the build because the app forced users to create an account (using an OTP verification system) to access or view the IAPs, which prevented the reviewers from testing the purchase flow properly. What We Did: Because building a comprehensive guest checkout flow would take too long for our current launch timeline, we decided to completely remove all IAP and subscription features from this version. We did the following: • Removed all IAP/subscription code, UI elements, and references from the source code binary. • Deleted the IAP and subscription products inside App Store Connect (they are no longer attached to the version submission). • Submitted a new build along with a supporting video demonstrating the updated user flow. The Current Loop: App Review continues to reject our new submissions. However, the rejection reason has flipped: they are now claiming they cannot locate the IAP and Subscriptions that were previously there. It seems the review team is stuck looking at old metadata or cached project states, even though the binary and App Store Connect configuration have zero traces of IAP left. Has anyone experienced a similar "ghost" IAP rejection? How can we force App Review to recognize that this is now a strictly free app so we can get out of this rejection loop? Thank you!

We are stuck in a review rejection loop regarding In-App Purchases (IAP) and Subscriptions, and we need advice on how to break out of it. The Background: A few weeks ago, we submitted a companion app that included IAPs and auto-renewable subscriptions. The App Review team rejected the build because the app forced users to create an account (using an OTP verification system) to access or view the IAPs, which prevented the reviewers from testing the purchase flow properly. What We Did: Because building a comprehensive guest checkout flow would take too long for our current launch timeline, we decided to completely remove all IAP and subscription features from this version. We did the following: • Removed all IAP/subscription code, UI elements, and references from the source code binary. • Deleted the IAP and subscription products inside App Store Connect (they are no longer attached to the version submission). • Submitted a new build along with a supporting video demonstrating the updated user flow. The Current Loop: App Review continues to reject our new submissions. However, the rejection reason has flipped: they are now claiming they cannot locate the IAP and Subscriptions that were previously there. It seems the review team is stuck looking at old metadata or cached project states, even though the binary and App Store Connect configuration have zero traces of IAP left. Has anyone experienced a similar "ghost" IAP rejection? How can we force App Review to recognize that this is now a strictly free app so we can get out of this rejection loop? Thank you!

Hello, We have two apps on the same developer account: FORGED: Online Fitness Coach (Apple ID 6818932334), iOS 1.0 build 84, submitted on October 11, 2026, together with one subscription group and four auto-renewable subscriptions. It has been "Waiting for Review" for 10 days with no change. A second, newer app (free, no in-app purchases) that we submitted later. It was reviewed within 24 hours. For the first app we have: Sent App Review status inquiries (October 13, 17 and 20). Submitted an expedited review request. Called Apple Developer Support, who said there is no fixed review time. Confirmed that agreements, tax and banking are Active and that there are no messages in App Store Connect. Since the newer app was reviewed so quickly, we are worried the first submission may be stuck. Could there be an issue with this submission that keeps it in the queue? Would cancelling and resubmitting the same build help, or would it only put us back at the end of the queue? Any guidance would be appreciated. Thank you.

Hello Apple Developer Community, I'm developing an iOS app called Rozděluj – společné výdaje (Bundle ID: cz.rozdeluj.rozdelujapp). StoreKit returns no products for any of our four In-App Purchases in TestFlight. Environment iPhone running iOS 27.0.1 Flutter 3.47.5 in_app_purchase 3.3.1 in_app_purchase_storekit 0.4.13 TestFlight builds 57, 58 and diagnostic build 59 Products cz.rozdeluj.plus.yearly — auto-renewable subscription cz.rozdeluj.unlimited.yearly — auto-renewable subscription cz.rozdeluj.plus.lifetime — non-consumable cz.rozdeluj.unlimited.lifetime — non-consumable Diagnostic results Flutter IAP: isAvailable: true Products returned: 0 Not found IDs: all four Error: storekit_no_response Message: StoreKit: Failed to get response from platform. We also added an independent native Swift StoreKit 2 diagnostic using Product.products(for:) with the same four identifiers. Native result: status: ok count: 0 foundIDs: [] missingIDs: all four The native query completed without throwing an error, but returned an empty product array. Configuration verified Bundle ID matches App Store Connect. In-App Purchase capability is enabled. Paid Apps Agreement, bank account and tax forms are Active. Product IDs match exactly. Pricing and worldwide availability are configured. Czech localization is configured for the inspected product. Automatic App Store distribution signing is enabled in Codemagic. All four IAPs currently have Rejected status following an App Review Guideline 3.1.2 rejection related to missing Terms of Use links. The app has since been updated to address that issue. Questions Could the Rejected status prevent these products from being returned by StoreKit 2 in TestFlight Sandbox? Is there another App Store Connect or Sandbox configuration that could cause Product.products(for:) to return an empty array without throwing an error? What additional diagnostics would help identify the cause? I would appreciate guidance before recreating any products or modifying the purchase implementation. Thank you!

Many of my purchases are encountering an issue when using a promotional offer (with a promo offer signature included). On the client side, everything works properly, and the purchase triggers the .success() callback. However, there are no updates in either the transaction/renewal info or via webhooks. According to the documentation, at least one of these server notifications should be triggered: OFFER_REDEEMED or SUBSCRIBED/RESUBSCRIBED. My server did not receive any signals. Furthermore, when I fetched the subscription status using the App Store Server API, the offer identifier did not appear in either the renewal info or the transaction info.

Hello, I am the sole owner of a single-member LLC registered in Wyoming, USA. I am not a US person and I live outside the United States. For US tax purposes the LLC is a foreign-owned disregarded entity, so as I understand it the correct form is a W-8BEN in my name as the foreign owner, not a W-9. In App Store Connect, under Business > Agreements, Tax, and Banking, the tax form section only offers the W-9 because the account is set up as a US entity. Because of this I cannot complete the tax information, and the Paid Apps Agreement stays inactive. My app is ready and has in-app purchases, so I cannot submit it for review until this is resolved. I have already contacted Apple Developer Support and I am waiting for a reply. Questions: Has anyone with a foreign-owned single-member US LLC solved this? How did you submit a W-8BEN instead of a W-9? Is there a way to change the tax form type in App Store Connect, or does Apple need to change it from their side? Is there a specific contact or form for this case? Any guidance would be appreciated. Thank you.

Hello, I am the Account Holder of an Individual Apple Developer Program membership based in the Russian Federation. I am trying to request the StoreKit External Purchase Link Entitlement (RU) for my iOS app. The app itself is free to download. It does not use and is not intended to use Apple In-App Purchase. Premium digital content is provided through a subscription purchased on our external website. Apple currently documents StoreKit External Purchase Link support for Russia. However, when I open the official StoreKit External Purchase Link Entitlement (RU) request form, I cannot submit the request unless I have accepted the latest Paid Applications Agreement. The problem is that the Paid Applications Agreement is not available in my App Store Connect account. Apple Developer Support informed me that, because my Apple Developer Program membership is located in the Russian Federation, I am currently unable to distribute paid applications or applications using In-App Purchases due to applicable sanctions. This creates a circular situation: StoreKit External Purchase Link (RU) is officially available for Russia. The entitlement request form requires the Paid Applications Agreement. My Russian developer account cannot accept the Paid Applications Agreement. Therefore, I cannot submit the entitlement request. My intended purchase flow is: Free iOS app → user account → StoreKit External Purchase Link → external website → digital subscription → access activated in the app. Has anyone with a Russian Apple Developer account successfully obtained the StoreKit External Purchase Link Entitlement recently? Is there an official manual process for Russian developers who cannot accept the Paid Applications Agreement? Can this entitlement request be processed manually by Apple Developer Support or another Apple team? I would especially appreciate guidance from an Apple engineer regarding the officially supported path for this situation. Thank you.

Hello Apple Developer Team, Our first app was submitted on October 11, 2026 and has stayed in "Waiting for Review" for 7 days. The submission includes the app version, one subscription group and four auto-renewable subscriptions. Apple ID: [6818932334] What we have done so far: Called Apple Developer Support. We were told there is no fixed timeline for App Review. Sent two App Review status inquiries through Contact Us (October 13 and October 17). No reply yet. Submitted an expedited review request. No reply or status change yet. What we have checked: Paid Apps Agreement, tax and banking are all Active. Membership is active with nothing pending. No messages from App Review in App Store Connect. We have not changed any metadata or cancelled the submission, so we don't lose our place in the queue. Is this waiting time expected for a first submission that includes subscriptions, or is there anything we should check on our side? Any guidance from the App Review team would be greatly appreciated. Thank you.

Hello, I need to set up the Paid Apps agreement in App Store Connect (to offer in-app purchases), but I don't see any button or link to request it. In App Store Connect under Business (Agreements, Tax, and Banking) I only see the Free Apps agreement as Active. There is no "View and Agree to Terms" banner and no option to add or activate the Paid Apps agreement anywhere. What I already checked: I'm signed in as the Account Holder (not Admin or another role). The Apple Developer Program membership is active and paid. I tried both the new "Business" section and the old "Agreements, Tax, and Banking" page — no Paid Apps row, no request button. Tried different browsers and clearing cache, same result. Questions: What conditions must be met for the Paid Apps agreement option to appear for an account? Is there a known delay or eligibility/verification step (e.g., for individual accounts or specific regions) before it shows up? Is contacting Apple Developer Support the only way to resolve this, or is there something I can do myself in the account? Thanks in advance for any pointers.

Our app BandPro (Apple ID 6793207475) has been rejected three times under Guideline 2.1(b) because the In-App Purchase products were "not submitted for review". Everything is ready on our side, but App Store Connect will not let us put the app version and the IAPs into the SAME review submission: New binary uploaded: iOS 1.0 (build 22), attached to the version. 7 IAPs in "Ready to Submit": 4 auto-renewable subscriptions in the group "BandPro Pro" + 3 consumables. All have prices, availability in 175 storefronts, review screenshots and review notes. The app version is locked inside the REJECTED submission ("Unresolved Issues"). The only action available there is "Resubmit to App Review", which sends the version ALONE - exactly what caused the 2nd and 3rd rejections. Adding the IAPs for review creates a SEPARATE draft submission. That draft cannot be sent: it shows "To submit your items for review, add an app version for the selected platform" - but the version cannot be added because it is held by the rejected submission. We replied to App Review in the Resolution Center on Aug 1 explaining this. No response yet. We also saw the recent reply from an App Store Commerce Engineer saying the In-App Purchase submission experience was recently updated and an issue affected some submitted IAPs - our timeline matches that window. Could someone from Apple help us either: (a) attach the 7 ready IAPs to the existing submission so everything is reviewed together, or (b) release the app version from the rejected submission so we can create ONE new submission containing the version + all IAPs? We would like to avoid deleting and recreating the subscription group, since the product IDs are already live in our billing stack and on Google Play. Thank you!

Hi everyone, We have already migrated our app to StoreKit 2 for the latest release. However, we are currently planning our long-term strategy (such as implementing forced app updates) for when StoreKit 1 eventually stops working on legacy app versions. I’ve already checked several discussions here regarding the deprecation of the server-side /verifyReceipt endpoint and its potential impacts. Aside from backend validation, I’m particularly curious about the overall client-side StoreKit 1 framework timeline. While I understand that there is no official sunset date announced yet, it would cause significant issues and delays in handling our legacy apps if it were shut down without warning. I was wondering: Has anyone heard or seen any official guidance on how Apple typically handles full deprecations for core frameworks like this? Can we reasonably expect Apple to issue an official announcement (via Developer News, etc.) with a sufficient grace period before StoreKit 1 is fully retired? I'd love to hear your thoughts or if anyone has received any insights from Apple Developer Support regarding this. Thanks in advance!

I’m unable to retrieve a newly configured auto-renewable subscription from the Apple Sandbox environment. Product information Bundle ID: com.reynaga.Imoox Product ID: com.reynaga.Imoox.subscription.monthly Subscription status: Prepare for Submission Price: USD 1.99 per month Introductory offer: one-week free trial Result The app requests the product using StoreKit 2: let products = try await Product.products( for: ["com.reynaga.Imoox.subscription.monthly"] ) The request doesn’t throw an error, but the returned products array is empty. I also tested with SKProductsRequest. The Sandbox response is: Valid products: [] Invalid product identifiers: ["com.reynaga.Imoox.subscription.monthly"] Configuration already verified The Bundle ID and Product ID match App Store Connect exactly. The app uses an explicit App ID, not a wildcard. In-App Purchase is enabled for the App ID. The development certificate and provisioning profile are valid. There is no StoreKit Configuration file active in the Run scheme. The Apple Developer Program membership is active. The Paid Applications Agreement is active. Banking and all required tax forms show an Active status. The subscription has a price, localizations, tax category, and availability. Mexico and the United States are included in its availability. The Sandbox Apple Account belongs to the same developer team. The app is development-signed and installed from Xcode 26.2 on a physical iPhone. I signed out and back into the Sandbox account, deleted and reinstalled the app, restarted the device, and cleaned the Xcode build. The issue has persisted well beyond the documented metadata propagation period. Apple Developer Support reviewed the administrative configuration and referred me to the Developer Forums. According to Apple’s documentation, an In-App Purchase doesn’t require prior App Review approval to work in Sandbox. Could an Apple StoreKit or App Store Connect Commerce engineer verify whether the app-to-subscription catalog association is correctly provisioned in Sandbox and refresh or reprocess it if necessary?

StoreKit 2 Product.products(for:) returns an empty array (no error) for all 6 in-app purchases of my app in TestFlight. Setup: App: Apple ID 6816296214, bundle ID com.nh2s.eggmage-dungeon (first version 1.0, not released yet) IAPs: egg_gems_80, egg_gems_500, egg_gems_1200, egg_gems_2500, egg_starter_pack (consumable), egg_no_ads (non-consumable) Each IAP: status Ready for Review, price set (175 regions, base KRW), English and Korean localizations Business: Paid Apps Agreement Active, Free Apps Agreement Active, bank account Active, W-8BEN, U.S. Certificate of Foreign Status and Korea tax form all Active. The latest Program License Agreement and Paid Applications Schedule are accepted. Explicit App ID with In-App Purchase capability enabled TestFlight build 1.0 (2610141319), canMakePayments = true, storefront USA (143441) The agreements and tax forms became Active yesterday, and the products still don't load after many full app restarts. The app uses Unity IAP 5.4.3, which calls Product.products(for:) with the six IDs above. Is there anything else on the account or app side that could make the sandbox return no products? This looks like the same issue as https://developer.apple.com/forums/thread/849426 (first app, consumables, tax forms activated recently, empty product response). Thank you.

We've been approved for the Advanced Commerce API. After receiving the approval, we completed the initial setup requirements (submitted a generic product ID and shared our subscriptions page deep link). When testing the Migrate Subscription to Advanced Commerce endpoint in the sandbox, we receive a 5000000 error. What could be the reason/s for it? There is no information, and the API call we make includes all required parameters. Could it be related to the fact that our new generic product ID status is "Missing Metadata"? Is there a way to understand what the issue is on Apple's side?

My app is live, I’ve already spent money promoting it, and people can’t subscribe. I’m losing potential customers while the fix sits in the review queue, and I’m honestly really frustrated. I was told my corrected submission would still get expedited review, but it’s been almost 5 hours with no movement. I contacted support around midnight and still haven’t had an actual response, just automated acknowledgements. I’ve tried calling too, but phone support has been unavailable all morning. Is there anyone from App Review who can please look into this? I need to know if something is holding it up or if there’s anything else I need to do. This is affecting my business right now.

I'm investigating a Restore Purchases failure in my app, PW Paycheck, which uses StoreKit 2. TestFlight purchases of consumable checks and an annual subscription have succeeded, but restoring purchases repeatedly fails. The failing call is: try await AppStore.sync() Apple displays an account password prompt. I enter my password and tap OK, after which the call throws. Our typed error classifier and NSError conversion report: StoreKitError.unknown StoreKit.StoreKitError: 2 This is the StoreKit.StoreKitError domain, not SKErrorDomain. We have not established whether authentication succeeded internally or what causes the failure. Environment: Physical iPhone 16 Pro; installed through TestFlight. App version 1.0 (20), bundle com.ggeller.pwpaycheck. In-app OS report: Version 26.6.2 (Build 23G90). Reported StoreKit price storefront: USA / 143491. Annual subscription: com.ggeller.pwpaycheck.pro.annual. Developed and uploaded using Swift Playgrounds on iPad. I have a Windows laptop and no Mac access. Steps: Open the TestFlight app with an existing unexpired annual test subscription. Open Payment Options and tap Restore Purchases. Enter the password in Apple's prompt and tap OK. AppStore.sync() throws the error above. The app then refreshes entitlements and displays a restore failure message. Observed results: Verified active subscription access is recognized before and after the failed operation. We do not count this as successful restoration. The subscription was canceled but still unexpired during the captured attempt. Build 19 produced the same NSError domain/code on Wi-Fi and cellular. Build 20 captured the typed .unknown classification on Wi-Fi. Our logger captured no additional underlying error. The latest attempt started at 2026-10-14T13:59:09Z and completed at 13:59:25Z, including the post-failure entitlement refresh. We are not treating this as evidence of a timeout. The restore action is user initiated, guarded against duplicate operations, and waits for an earlier entitlement refresh to finish before calling AppStore.sync(). What supported diagnostic or configuration check would help distinguish possible causes of this error, particularly without access to Xcode's device console? Also, how should we isolate a TestFlight-specific restore failure in a focused sample while preserving the relevant app/account context? A separate sample has been prepared, but compilation and reproduction are still pending.

Our universal-purchase app (iOS + macOS, StoreKit 2) offers a 14-day trial as a non-consumable priced ¥0/free in all storefronts (approved, available everywhere), plus a paid non-consumable unlock. Since late September we have 3 separate Apple Accounts (Japan storefront) where the iPhone purchase flow fails: Product.products(for:) returns the product, the App Store purchase sheet appears with the correct product and account. After confirming, the sheet shows "支払いを完了できませんでした" (Payment could not be completed). No .success result. Redeeming a FREE one-time offer code for the paid non-consumable (via the apps.apple.com/redeem URL) fails the same way on the same iPhones. The very same Apple Account, same day, on the Mac app: both the ¥0 purchase and the offer code succeed immediately, and the entitlement then shows up on the iPhone through Transaction.currentEntitlements. OS correlation so far: iOS 27.0.1: fails (2 accounts) iOS 26.7.1: fails (1 account) iOS 26.6.2: succeeds Sales and Trends shows 9 iPhone + 1 iPad successful trial purchases between Sep 26 and Oct 12, so this is not account- or product-specific. The accounts have valid payment methods (paid purchases in other apps work), no Screen Time restrictions, not Ask to Buy. Filed as FB25186860 with a sysdiagnose. Has anyone else seen free purchases failing on 27.0.1 / 26.7.1? Any known workaround besides directing users to the Mac app?

Hello everyone, I am designing an in-app subscription and pass extension/upgrade system for an iOS app and want to ensure full compliance with App Store Review Guideline 3.1.1. Because pricing in our system depends on the user's historical purchase price rather than static store catalog prices, direct fixed-SKU purchases aren't sufficient on their own. Business Logic Overview Extensions: An extension costs 50% of the price the user originally paid for their plan. Example: If a user bought Plan A at $200, their extension cost is $100 (even if Plan A currently retails at $150). Upgrades: An upgrade charges the delta between the target plan's current price and the user's original purchase price. Example: A user bought Plan A for $200, and Plan B currently costs $250. The upgrade cost is $\max(0, 250 - 200) = 50$. Proposed Technical Solution User requests an extension or upgrade from the iOS client. The backend server calculates the exact delta amount based on user purchase history. The backend maps this calculated amount to a pre-defined Tiered StoreKit Product ID (e.g., com.app.tier_50). The iOS app receives the Product ID and executes the transaction via StoreKit 2 (Product.purchase()). The backend validates the transaction JWS signature with Apple and updates the user's access duration. Questions for the Community & Apple Engineers Has anyone implemented backend-resolved dynamic Tiered SKUs for top-ups or price deltas? Did this pass App Review without issues under Guideline 3.1.1? Are there recommended patterns when configuring price-point tier SKUs (Consumable vs Non-Renewing Subscription) in App Store Connect for variable delta payments? For auto-renewing subscriptions, is it preferred to handle extensions strictly via StoreKit 2 Promotional Offers rather than delta SKUs? Any feedback or real-world experience with similar pricing structures would be greatly appreciated!

I'm investigating a price/currency mismatch in a TestFlight app. Environment: iPhone 15, iOS 26.6.2 App version 0.4.2 (Build 47), distributed through TestFlight Consumable product ID: line_stamp_8pack_1980 Diagnostic comparison: October 5, 2026, at 11:22:47 JST (UTC+09:00) For the same product, all three product lookup paths returned price 11.99, currency USD, and display price $11.99: StoreKit 1: SKProductsRequest / SKProduct StoreKit 2: Product.products(for:) expo-iap: fetchProducts The direct StoreKit calls were made through native Swift diagnostics in the app. All three lookups succeeded without errors. StoreKit 2 reported storefront country USA and ID 143462 before and after its lookup. expo-iap also reported USA before and after its lookup. StoreKit 1's storefront was unavailable before its request. Afterward, it reported USA, with storefront identifier "143462-9,29". Our diagnostic initially labeled this as a storefront change, but an unavailable-to-available result does not establish an actual country change. During the same testing session, Apple's purchase confirmation sheet for this product displayed ¥1,980 and stated that the purchase was for testing only. I canceled the sheet without completing the purchase. The Media & Purchases account's country/region is Japan. App Store Connect pricing for this product is ¥1,980 in Japan and $11.99 in the United States. What could cause the product lookup APIs to return the US storefront price while the purchase confirmation sheet displays the Japanese price? What additional diagnostics should I collect to identify the cause and obtain a product price consistent with the purchase sheet? Thank you.