I am seeing different StoreKit storefronts and localized prices between a direct Xcode installation and TestFlight on the same iPhone. Environment: App: CountAdd iPhone 15 Pro In-App Purchases: non-consumable App Store Connect base country/region for IAP pricing: Japan (JPY) Japan is enabled for app and IAP availability Results on the same device with the same app code: Xcode Debug: Storefront: JPN Prices: JPY Xcode Release: Storefront: JPN Prices: JPY (¥250 / ¥1,250 / ¥2,500) TestFlight Build 10: Storefront: USA Prices returned/displayed by StoreKit: USD ($1.99 / $7.99 / $14.99) Using macOS Console with the physical device connected, I confirmed that the TestFlight build logs: Storefront updated to ... countryCode: "USA" For the Xcode Release build, the same device reports: countryCode: "JPN" I also deleted the TestFlight app and reinstalled Build 10 to eliminate local app data as a possible cause. The issue remained: TestFlight returned USA/USD. The Sandbox Apple Account is configured for Japan. In some tests, although the app displays the StoreKit product price in USD, Apple's purchase confirmation sheet displays the price in JPY. I am not manually converting or hardcoding prices. The app displays the localized product price returned by StoreKit. I have already reported this through Feedback Assistant: FB25014147 I also contacted Apple Developer Support: Case 102983767864 Developer Support advised that they cannot investigate technical issues involving Sandbox IAP testing and directed me to Feedback Assistant. My main questions are: Is it expected or a known issue for a TestFlight/Sandbox build to receive a USA storefront and USD product metadata while a direct Xcode build on the same device receives JPN/JPY? More importantly, can this TestFlight/Sandbox behavior affect the production App Store version? When a user in Japan installs the production app from the App Store, should StoreKit return the Japanese storefront and JPY localized prices? I am trying to determine whether it is safe to submit/release the app without implementing any manual currency conversion or hardcoded pricing.

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!

In my TestFlight app, StoreKit reports the Japan storefront (JPN, ID 143462), but product prices are returned in USD. Environment: iPhone 15, iOS 26.6.2 TestFlight version 0.4.2 (build 52) Product ID: line_stamp_8pack_1980 Product type: consumable Feedback Assistant report: FB25133058 Steps to reproduce: Sign out of the regular account under Media & Purchases. Sign in to a Sandbox Apple Account configured for Japan under Settings > Developer. Launch the TestFlight app and request product information. Expected result: The current Japan price configured in App Store Connect is JPY 1,980. The base country is Japan, and no future price changes are listed. Actual result: Storefront country: JPN Storefront ID: 143462 Product price: 11.99 Currency: USD Display price: $11.99 StoreKit 1 priceLocale: en_US@currency=USD I compared native StoreKit 2 Product.products(for:), StoreKit 1 SKProductsRequest, and expo-iap fetchProducts. All three returned the same USD price without errors. The storefront remained JPN before and after each request. The issue persists after restarting the app and rebooting the iPhone. No purchase was performed. What additional diagnostics or configuration checks would help identify why the product currency differs from the reported storefront? Is there a supported workaround for testing Japanese prices in this situation?

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.

We are testing an annual auto-renewable subscription with the monthly 12-payment commitment in App Store Sandbox. The Sandbox tester is configured for 3-minute monthly renewals. Is commitmentExpiresDate supposed to follow that accelerated schedule? Our signed transactions initially report an end almost six days away, but the commitment actually completes in about 41 minutes. In one complete 12-payment lifecycle on 8 Oct 2026 (all times UTC): Payment 1: purchased at 16:34:04; installment ends at 16:37:04; commitmentExpiresDate is 14 Oct 06:13:04 — almost six days away. Payment 2: commitmentExpiresDate is 13 Oct 19:04:04. Payment 3: commitmentExpiresDate is 8 Oct 17:28:04. Payment 4: commitmentExpiresDate is 12 Oct 18:24:02 — jumping forward by about four days. Payments 6 and 9 again report ends on 8 Oct, while payments 7 and 8 report dates days away. Payment 12: both expiresDate and commitmentExpiresDate are 8 Oct 17:14:44, followed by EXPIRED/VOLUNTARY. The actual elapsed time since payment 1 was 40 minutes 40 seconds, including delayed Sandbox renewals. We compared all 12 signed App Store Server Notifications V2 transactions with independently fetched signed transactions from the Sandbox Get Transaction Info API. The values match. billingPeriodNumber advances from 1 through 12 on the same commitment. There was no DID_RENEW/BILLING_RECOVERY. The first date changes occurred before we disabled post-commitment renewal after payment 3. Apple’s documentation says to use commitmentExpiresDate from the latest transaction and describes a changed date after billing recovery. Here it changes drastically on ordinary renewals, and the initial date appears incompatible with the Sandbox renewal rate. Is this a known Sandbox issue? Should commitmentExpiresDate reflect the 3-minute/month schedule? Can we rely on it remaining consistent across ordinary payments in production, or is there another recommended source for the full commitment end date? We can provide the transaction IDs and all 12 decoded transactions privately for investigation.

Hi, I’m experiencing a StoreKit 2 issue with my iOS app Live Gigs. App: Live Gigs Bundle ID: com.leicomusic.LiveGigs App Apple ID: 6817866296 Subscription Product ID: livegigsmaandelijks Subscription Apple ID: 6817868044 The auto-renewable subscription is Approved in App Store Connect and is available in all countries and regions. Pricing, localization, subscription group, Paid Apps Agreement, banking and tax have all been checked and are active. The actual problem is that the subscription does not appear in the app at all. When a customer opens the subscription screen, there is no product and therefore the Apple purchase sheet cannot be opened. The customer cannot purchase the subscription. The app calls: Product.products(for: ["livegigsmaandelijks"]) StoreKit returns an empty array without throwing an error. I have tested this on a physical iPhone using a signed build. Interestingly, the same product works correctly when using a local Xcode StoreKit Configuration: the €6.99/month product appears and the purchase flow can be started. I have checked the requirements described in TN3186/TN3188, including the Bundle ID, product ID, subscription status, availability, pricing, localization, agreements, banking, tax, IAP capability and signing. Has anyone else experienced an approved subscription suddenly disappearing from the StoreKit catalog like this? Could this be an Apple-side StoreKit/App Store Commerce catalog issue? Any advice from Apple engineers or developers who experienced the same issue would be greatly appreciated.

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?

Hello everyone, In our iOS app, we offer multiple auto-renewable subscription tiers within the same subscription group: Lite (Monthly / Yearly) Basic (Monthly / Yearly) Plus (Monthly / Yearly) Pro (Monthly / Yearly) We are using Apple's native Offer Code redemption sheet (SKPaymentQueue.default().presentCodeRedemptionSheet() / AppStore.presentOfferCodeRedeemSheet). The Issue We Are Facing: The user navigates to our subscription screen and selects the Pro Plan. The user taps our in-app "Redeem Offer Code" button, which presents Apple’s native redemption sheet. The user inputs an offer code that was created in App Store Connect specifically for the Basic Plan. When the user taps "Continue", Apple accepts the code and immediately presents the Apple Pay / Face ID confirmation to charge/subscribe the user to the Basic Plan. Because presentCodeRedemptionSheet() does not take any product ID parameter, Apple accepts the code for whichever product it was created for, regardless of the tier the user had selected on our paywall. By the time our transaction observer receives the transaction callback (paymentQueue(_:updatedTransactions:)), the payment/purchase has already been finalized by Apple. Questions: Can we restrict the native sheet to a specific Product ID? Is there any way with StoreKit 1 or StoreKit 2 to pass an expected productID to the redemption sheet so Apple only accepts codes eligible for that specific product? Can we intercept or validate the code before payment? Is there any delegate callback or hook when the user taps the "Continue" button on the "Redeem Offer" sheet so we can validate if the code matches the selected plan before the transaction is charged? What is Apple's recommended best practice? If a user redeems a code for a different tier (e.g., Basic instead of Pro), is the recommended approach to automatically switch and activate the redeemed plan on our backend since Apple has already completed the purchase, rather than rejecting it? Any guidance from Apple engineers or developers who have handled this multi-tier scenario would be greatly appreciated!

Hi, I have an user experiencing networkError(Foundation.URLError(_nsError: Error Domain=NSURLErrorDomain Code=-1008 "(null)")) when my app calls AppTransaction.shared on macOS 15.6. They have tried multiple internet connections, but the issue persists. What could be the root cause ?

Hello, We are troubleshooting product discovery for three consumable In-App Purchases in our first iOS game, ION RUSH. All three remain unavailable in TestFlight. Environment and result: Physical iPhone 13, iOS 27.0.1 (24A446). App version 1.0 (80), installed through TestFlight. Direct native StoreKit 2; no RevenueCat or other purchase SDK. Product.products(for:) returns zero products before application filtering, without throwing an error. Earlier independent development-build diagnostics also returned zero products for batch and individual StoreKit 2 requests; SKProductsRequest reported all three identifiers as invalid. Checks completed: Product IDs exactly match App Store Connect: nova_pack_5, nova_pack_15, nova_pack_40. The explicit bundle identifier matches the app record and code; In-App Purchase is enabled for the App ID. All three consumables show Ready for Review, have prices and localizations, and are available in all 175 configured territories, including the US. Developer membership, Paid Apps Agreement, bank account and tax forms are active. The Account Holder checked the Developer account for outstanding agreement signatures; none were visible. The Developer Program agreement was accepted September 29. Tax forms were submitted October 3 and now show Active. The financial setup was only recently completed, so delayed activation remains a possibility. The release scheme has no local StoreKit Configuration override. TestFlight reinstallation, device restart and repeated product refreshes did not restore the products. A re-export of the exact build 80 archive with the original App Store Connect signing settings selected an explicit App Store profile with beta-reports-active=true and get-task-allow=false. This checks the signing configuration; the original uploaded IPA was not available for direct inspection. Selected storekitd messages from October 4, 2026 (UTC+3): 09:59:22.963356 Requesting Media API product batch ["nova_pack_15", "nova_pack_40", "nova_pack_5"] 09:59:22.990339 summary for task success {transaction_duration_ms=1, response_status=200, cache_hit=true} 09:59:22.991595 Ignoring empty product response The request targets amp-api.sandbox.apple.com/v1/catalog/us/in-app-purchasables with the correct bundle and product IDs. Its account mediaType is com.apple.AppleMediaServices.accountmediatype.appstore.beta. A second request one second later produced the same HTTP status, cache flag and empty-product message. We did not capture the raw HTTP response body. Local StoreKit configuration tests work, but we understand this does not validate the live Sandbox catalog. We also understand that prior IAP review approval is not required for Sandbox testing. Questions: What additional developer-side check would distinguish incomplete account activation, product configuration or cached catalog state in this situation? Has anyone resolved this after completing agreements/banking/tax, especially when the products were created before financial activation? What exact action or elapsed time resolved it? If all TN3186 checks pass, what evidence and official escalation route should we use to request investigation of the app-to-product catalog association? Related reports: https://developer.apple.com/forums/thread/849165 (same storekitd messages, but after membership lapse/renewal; our situation differs) https://developer.apple.com/forums/thread/844545 (zero StoreKit 2 products and invalid StoreKit 1 identifiers after TN3186 checks) We can provide further redacted diagnostics and account details privately to Apple. Thank you.

Hello all, I'm posting here today in hopes the internet can help me find a solution for an issue I'm having with integrating with subscriptions created in App Store Connect. I'm receiving no products back from StoreKit 2 for my list of product IDs. Things I've verified so far: No errors are coming from StoreKit The product IDs I'm requesting match the configured product IDs in the subscriptions The provisioning profile matches the bundle ID of the built app. The provisioning profile includes the in-app purchases capability. All subscriptions are priced, include localization, have an availability region set, and include a tax category. The subscriptions have been set for a week. Well over the typical one hour metadata update window. My banking, tax info, and paid apps agreement are up to date and active. I'm signed out of Media & Purchases and signed into a sandbox account under developer mode on the test device. The region of the sandbox account matches the region availability of the subscriptions. Under Signing & Capabilities in Xcode, my team matches the team the app is created under in App Store Connect, In-App Purchase is included, and we are signing with my team's certificate. The app under test is a production release build installed via Test Flight. Logging the StoreKit environment shows that it's in the sandbox and matches the region configured for the sandbox user and subscriptions Device: iPhone 14 OS: iOS 26.5.2 Thanks in advanced for any help and insight you may have.

Hi everyone, I'm a new iOS developer, and my first app has been rejected twice because of In-App Purchase issues. Setup: Flutter, in_app_purchase 3.3.0, in_app_purchase_storekit 0.4.10 (StoreKit 1) One auto-renewable subscription and one non-consumable lifetime purchase Both products show "Ready for Review" in App Store Connect. Paid Apps Agreement is active. First review: The prices were visible on an iPad, but the subscription purchase failed (Guideline 2.1(b)). Second review: Neither product showed a price on an iPhone (Guideline 2.1(b)). Apple also noted missing subscription information (Guideline 3.1.2(c)). On my iPhone 15, both products load correctly and test purchases work in TestFlight using my regular Apple Account. Product IDs, pricing, availability, and localizations appear correct. My question: What could cause queryProductDetails / SKProductsRequest to return no products during App Review when everything works in TestFlight? Any suggestions would be greatly appreciated. Thanks! :)

Hello, I’m trying to make a payment for a 1-year subscription, but the payment keeps being declined. I have tried both my Visa and Maestro cards, and neither of them is accepted. I have already checked with my bank/card provider, and there is no issue or restriction on my cards. Both cards work normally for other online payments. It therefore appears to be a payment system issue on your side rather than an issue with my cards. Could you please check why my payments are being rejected and help me complete the payment for the 1-year subscription? Thank you.

I'm testing an In-App Purchase for the Indonesian storefront. In App Store Connect, the price is configured as Rp 1,299,000, and it is displayed correctly there. However, in the Sandbox purchase sheet, the price is shown as "Rp 1,299 juta" instead. I understand that "juta" means million in Indonesian. However, I'm not sure whether displaying the price as "Rp 1,299 juta" is the expected localization for users. Any confirmation or experience would be appreciated. Thank you!

I mistakenly deleted a subscription in App Store Connect, I know Apple permanently retains that Product ID in its system records to prevent reuse or conflicts but can Apple support purge or restore the deleted record? The app is still in review....

Hello, I'm doing the in-app purchase tests with a local .storekit file. When I declined a pending transaction on the "Manage Transactions..." form, my code got a record from the Transaction.updates immediately. This transaction was in 'verified' state and the 'revocationDate' was also nil. So my code treated this transaction as approved and went into wrong logic. In the apple online document about the storekit test, it mentioned that "Your app doesn’t receive a transaction because you declined Ask to Buy.". But in my tests, it always sent a 'approved' transaction to me after transaction declined on the "Manage Transactions..." form. Does any know why this happened? Any advice will be appreciated. Thanks in advance. Best, Steven

In one observed Restore Purchases attempt from a Release build distributed through TestFlight on a physical iPhone, try await AppStore.sync() threw an error that our Swift classifier matched to StoreKitError.unknown. Our Restore handler did not reach its subsequent entitlement-enumeration or backend-verification steps. Environment: iPhone 17 Pro Max. The device was independently checked afterward and was running iOS 26.7 (23H24); the OS version was not independently recorded at the exact failure time. Intended handler flow The user explicitly taps Restore Purchases. Call try await AppStore.sync(). Enumerate Transaction.currentEntitlements and accept only verified, eligible transactions for the expected subscription. Send the eligible signed transactions to our backend for verification. Observed attempt Narrow native Console events and a memory-only, sanitized in-app report matched the same attempt. The sync failure was recorded roughly 16 seconds after sync started. We are not treating that duration as evidence of a timeout. The owner reports completing Apple's authentication prompt during this specific attempt. The app displayed: “Purchases could not be restored. Please try again.” Existing Premium access remained displayed before and afterward. We do not count that as successful restoration. We have not retried since this captured attempt. The error matched StoreKitError.unknown. Our sanitized report did not capture an underlying error or numeric error code; this does not establish that no additional diagnostic information exists elsewhere. Current App Store Connect checks show the expected app/subscription-group association, subscription status Ready for Review, all countries or regions selected, and an active Paid Apps Agreement. These status checks do not establish that the configuration is the cause or that every configuration detail is correct. Question What supported, privacy-safe diagnostic should we collect to distinguish causes when AppStore.sync() throws StoreKitError.unknown, without exposing account details, transaction identifiers, receipts, or tokens? If a focused reproducer is needed, is there a recommended way to isolate this TestFlight StoreKit context without weakening transaction verification or changing account/purchase history? We are not asserting an Apple defect or an account/configuration problem. No raw logs or account/transaction data are attached.

App Store Server API: Sandbox returns 200, Production returns 401 with the same JWT We are seeing a reproducible authentication issue with the App Store Server API for our app FYRT. Bundle ID: com.fyrt.Fyrt We performed a fresh read-only test on September 29, 2026 using our In-App Purchase key BJ5HR5GSY6. Both requests used: the same In-App Purchase key the same Issuer ID the same Bundle ID ES256 the same JWT structure 300-second token lifetime correct system time with no relevant clock skew Only the environment changed. Sandbox: HTTP 200 Apple Request ID: 458b3b32-8e0d-1404-19fe-6c92ba2ccd27 Production: HTTP 401 Apple Request ID: 193406ac-80d2-d135-8cc8-34e4ebe76fc5 The Production response does not include an additional Apple error code. The request is read-only and requests notification history. No purchase is triggered and no Production data is changed. We verified: correct Key ID correct Issuer ID correct Bundle ID ES256 signing current iat valid exp correct Sandbox and Production endpoints no environment mixing fresh JWT generation for each request no clock skew The same behavior was already reproduced on September 11, 2026. Our existing Apple Support case is: 102960057430 Has anyone seen Sandbox accept the same authentication while Production returns 401? Could this be related to Production-side provisioning, app status, team/account authorization, or the fact that the app has not yet had a version released on the App Store? Any guidance from Apple engineers would be greatly appreciated.

Hello, We are investigating an auto-renewable monthly subscription in the Production environment. Timeline and observed behavior: On June 29, 2026, the user initiated the first subscription purchase. The Apple Account used WeChat Pay as its payment method. The WeChat charge failed because the balance was insufficient, and no funds were deducted from any available payment source. Nevertheless, StoreKit returned a verified transaction, the subscription purchase succeeded in the app, and App Store Connect Sales Analytics reports proceeds for the purchase. We grant entitlement based only on Apple's signed transaction and subscription status, so the user currently has access. As of July 20, 2026, Get All Subscription Statuses from App Store Server API returns: environment: Production status: 1 (Active) expiresDate: 2026-07-29T03:37:11Z autoRenewStatus: 1 no gracePeriodExpiresDate no revocationDate no expirationIntent no billing retry indication Our App Store Server Notifications endpoint has received only: SUBSCRIBED / INITIAL_BUY We have not received DID_FAIL_TO_RENEW, EXPIRED, REFUND, or REVOKE. Questions: Is it expected for Apple to issue a valid production initial-purchase transaction and report proceeds even when the underlying WeChat Pay charge failed and no money was deducted? Could this be an unpaid Apple Account balance or delayed settlement that is invisible to the developer? While the Server API returns status 1, should the developer continue granting entitlement until expiresDate? Is there another authoritative App Store Server API or signed field that indicates the payment has not actually been collected? If renewal or collection later fails, when should we expect DID_FAIL_TO_RENEW or a change to billing retry or expired status? We have intentionally omitted transaction IDs and account identifiers from this public post. I can provide them privately to Apple Support if needed. Thanks

For an In-App Purchase made by a customer whose App Store account is in the Saudi Arabia storefront, where Apple acts as commissionaire and remits VAT, does Apple issue the customer any tax document (a VAT invoice or a tax receipt), or is the customer's purchase history the only record available? Apple's support article 'View your purchase history for the App Store and other Apple media services' (support.apple.com/en-us/118212) documents viewing purchase history only — the words 'receipt', 'invoice' and 'tax' do not appear on that page.