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

Hello, We are contacting you regarding an issue we are currently experiencing during the App Review process related to In-App Purchases and StoreKit product retrieval. After extensive internal testing and investigation, we believe the behavior we are seeing is identical to the issue discussed in the following Apple Developer Forum thread: https://developer.apple.com/forums/thread/827016 Our application was rejected under Guideline 2.1 - Performance because the subscription plans reportedly failed to load during review. According to the review notes, the In-App Purchase product list appeared empty in the review environment, which prevented the paywall from loading correctly. We would like to provide additional technical context because, despite significant testing efforts on our side, we have been unable to reproduce this behavior outside of the App Review environment. The exact same binary that was reviewed by App Review has been thoroughly tested by us through TestFlight on multiple physical devices, including iPhone and iPad devices, using multiple Sandbox tester accounts and different network conditions. In all of our tests, the subscription system functions correctly and consistently. Specifically, we verified that: StoreKit successfully retrieves all configured subscription products RevenueCat offerings load correctly without timeout or empty states Localized pricing information is displayed properly Subscription packages appear correctly in the paywall UI Purchase flows complete successfully Restore purchases functionality works correctly Products are returned both on cold launch and repeated application launches The issue does not occur intermittently in TestFlight or Sandbox testing on our side We also carefully reviewed our App Store Connect configuration and verified the following items multiple times: All In-App Purchase subscriptions are attached to the submitted app version Product identifiers used in the application code exactly match the identifiers configured in App Store Connect All products are marked as “Cleared for Sale” Paid Applications Agreement has been accepted and remains active Tax and banking information are complete and active Subscription localization settings are configured properly Pricing information is active and visible The products are available in the storefronts being tested The submitted binary is identical to the binary tested successfully through TestFlight Additionally, we implemented defensive handling in the application to minimize the impact of temporary StoreKit failures. The application now includes: Retry logic for offerings retrieval Graceful fallback handling for empty offerings Protection against infinite loading states Additional RevenueCat and StoreKit logging UI fallbacks when products temporarily fail to load Despite these safeguards, the review feedback still indicates that the products are not being returned in the App Review environment. At this point, because the issue cannot be reproduced externally and only appears during App Review, we suspect there may be an intermittent or environment-specific issue affecting StoreKit product retrieval in the review sandbox environment. One important detail is that the exact same build consistently works in TestFlight immediately before and after submission. This makes the behavior particularly difficult for us to diagnose because there appears to be no configuration difference between our successful tests and the App Review scenario. We also understand from Apple documentation and previous App Review communication that In-App Purchases are tested within an Apple-provided sandbox environment. Based on the evidence currently available to us, the failure appears to occur specifically within that review sandbox process rather than within the application logic itself. If possible, we would greatly appreciate assistance with the following: Verifying whether StoreKit product retrieval is functioning correctly in the App Review sandbox environment Confirming whether the review device successfully established communication with App Store sandbox services Providing any available diagnostic logs related to the failed product request Confirming whether the product identifiers were visible to StoreKit during review Sharing any guidance on how we may reproduce the App Review behavior locally Clarifying whether there are known intermittent issues affecting StoreKit product loading during App Review We are fully committed to resolving the issue and ensuring complete compliance with App Store requirements. However, because the issue currently appears environment-specific and non-reproducible from our side, we are struggling to determine what additional changes are necessary. If there are any additional diagnostics, logging methods, StoreKit verification steps, or App Review recommendations you would like us to implement, we would be happy to do so immediately. Thank you very much for your assistance, support, and time. We sincerely appreciate your help in investigating this issue. Best regards, Mert Akgün

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.

Does App Review accept multiple In-App Purchases in the same app sharing an identical display name (for example ten non-renewing subscriptions all named 'Example Digital', differing only in price and duration)? The purchase sheet always shows the price alongside the name. App Store Connect Help documents a 2–30 character limit for the display name but states no uniqueness rule.

Does changing the price of an already-approved In-App Purchase trigger a new App Review, or does the new price take effect without review? App Store Connect Help states that changes to localized information require review and that 'New pricing will go into effect immediately', but never says explicitly whether a price change alone is exempt from review. We need this for a non-renewing subscription sold in the Saudi Arabia storefront.

Can an In-App Purchase that has reached the 'Approved' state ever be deleted from App Store Connect, either in the UI or through the App Store Connect API? App Store Connect Help documents no deletion procedure and no 'deleted' status. If deletion is possible, is it blocked while the product has existing purchases, or while it is still available for sale?

Does the App Store send a CONSUMPTION_REQUEST App Store Server Notification when a customer requests a refund for a non-renewing subscription? The documentation is inconsistent: the notificationType page lists only 'a consumable In-App Purchase or auto-renewable subscription', beginRefundRequest(in:) mentions only consumables, but the Send Consumption Information endpoint states it applies to 'any product type (consumable, non-consumable, non-renewing subscription, or auto-renewable subscription)'. Which is correct for a non-renewing subscription sold in the Saudi Arabia storefront?

On both iOS & macOS 27.2 Beta 2 the call: let token = try await MusicDataRequest.tokenProvider.developerToken(options: [.ignoreCache]) is throwing an error. I can reproduce this on all of my 27.2 Beta 2 devices and I have users worldwide reaching out to me with this issue. The error that gets thrown is: Unknown error "Error returned from daemon: Error Domain=com.apple.accounts Code=9 "(null)"" Have raised FB24895830.

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

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

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

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

For our app, we saved a sandbox App Store Server Notifications URL with V2 enabled and independently read the configuration back. A subsequent test-notification request returned HTTP 404 / 4040007. An authenticated sandbox notification-history request shortly beforehand returned HTTP 200. We restored the original settings after collecting diagnostics. The recorded failure is covered by Feedback Assistant report FB24885397. What could explain this discrepancy, and what additional diagnostics would help Apple investigate?

-(void)paymentQueue:(SKPaymentQueue*)queue updatedTransactions:(NSArray<SKPaymentTransaction*>*)transactions In the sandbox environment this is called continuously every time my enters the foreground. I call -finishTransaction on approximately 22 transactions. Confirmed by: NSUInteger finishCount = 0; NSUInteger transactionCount = transactions.count; for (SKPaymentTransaction *aTransaction in transactions) { // Check state..if purchased or restored.. [[SKPaymentQueue defaultQueue]finishTransaction:aTransaction]; finishCount++; // Post notification telling everyone here! } NSLog(@"Finsihed %lu of %lu",finishCount,transactionCount); The log at the bottom says - finished 22 of 22 transactions. But every time the app enters the foreground the -paymentQueue:updatedTransactions: is called again with another batch of transactions. How Over and over again. Not sure how this is possible but the transactions seem to never clear from the queue. I hope this may be limited to the sandboxed environment. In this loop after finish transaction is called I then post a notification which kicks off receipt validation...and then I even store something in the keychain. Doing this work over and over again in a tight loop is very unexpected and causes my app to lock up. Yea I know this is deprecated. Will move to my Objective-C storekit 2 wrapper but breaking SK1 on purpose seems kind of um, rude. Hope this is only in the sandbox environment. This app got sidelined even though I got some plans to resurrect it in the back of my head.

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, We have a critical, release-blocking issue with the StoreKit External Purchase Link entitlement (com.apple.developer.storekit.external-purchase-link) and would appreciate an engineer's help. We submitted a request for the External Purchase Link entitlement earlier this year. After no updates since February, we followed up with Apple Developer Support. Support confirmed the entitlement has already been granted to our account, but advised that Xcode is unable to display/select it and directed us to Feedback Assistant / the Developer Forums. However, the capability still does not appear as enabled on our App ID, and it is not included in our provisioning profiles. Current impact We cannot build or sign the app. Automatic signing fails because the provisioning profile is missing the entitlement, which blocks both development builds and release. What we're seeing Xcode – Signing & Capabilities Automatic signing fails with: Provisioning profile "iOS Team Provisioning Profile: ...." doesn't include the StoreKit External Purchase Link capability. StoreKit External Purchase Link capability needs to be assigned to your team and bundle identifier by Apple in order to be included in a profile. And: Entitlement com.apple.developer.storekit.external-purchase-link requires approval from Apple to include in a profile. Please request access to the associated capability. To continue building for device during request processing, remove entitlement and add upon approval. Provisioning profile detail (Xcode) The managed profile shows: Capabilities: 4 Included, 1 Missing → Missing StoreKit External Purchase Link, and Entitlements: 7 Included, 1 Missing → Missing com.apple.developer.storekit.external-purchase-link. Local entitlement configuration The entitlement is correctly added in our Xcode project, but builds fail due to the missing support in the provisioning profile. Apple Developer Portal – Edit App ID Configuration In the capability list, "StoreKit External Purchase Link" shows "No Requests" and cannot be selected/enabled. (The separate "StoreKit External Purchase" entry shows "No Status".) So the capability is not actually attached to the App ID on the portal, despite Support confirming the grant at the account level. What we've already tried Confirmed the entitlement is present in the app's .entitlements file. "Try Again" / regenerating the automatically managed provisioning profile in Xcode. Verified with Apple Developer Support, who confirmed the grant but could not enable it in Xcode/portal and referred us here. Question / request Since Support confirms the entitlement is granted at the account level but it does not appear as an assignable capability on the App ID or in the provisioning profiles, could an engineer please: Confirm whether the External Purchase Link entitlement is actually associated with our Team and this specific App ID, and Assign/enable the capability so it can be selected on the App ID and included in the provisioning profile? Environment: Xcode version: 27.0 macOS version: 26.6.2 Screenshots of the Xcode signing error, the provisioning profile detail, the local entitlement configuration, and the Developer Portal capability list are attached. Thank you very much for any assistance.

Hello. I am having trouble because when I send a request to the External Purchase Server API from my own server, I receive a 400 error, but the response does not specify a reason. ・Sent data (some information is masked with ) marketplaceToken received from the client: eyJhcHBBcHBsZUlkIjo2NzU5MTg2MjcyLCJidW5kbGVJZCI6ImNvbS5IYWJiaXQuQW5hRG9zLlBh**************************************************************************************************************************************************************************************************************************CJ0b2tlblR5cGUiOiJDT1JFX1RFQ0hOT0xPR1kifQ== The content of the Bearer Token used when performing a cancellation operation for this payment transaction: {"iss":"a5******---****-3c08","iat":1790134367,"exp":1790135567,"aud":"appstoreconnect-v1","bid":"com...Pal"} The JWT actually sent: eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6Ikg5N1dOOTRLNjYifQ.eyJpc3MiOiJhNTU*************************************************************************************************************************N0LXYxIiwiYmlkIjoiY29tL********************************************************************************************************************************************************KVfupOI4wW-gMWjHSq2rppbzezTqqiHl0Q The request body actually sent: {"requestIdentifier":"01a0cc52-b3b4-71d4-99c9-e1df27c6193b","externalPurchaseId":"98******---****-****903174ab","status":"NO_LINE_ITEM"} ・Request endpoint (Production) PUT https://api.storekit.apple.com/externalPurchase/v1/reports ・Request endpoint (Sandbox) PUT https://api.storekit-sandbox.apple.com/externalPurchase/v1/reports ・API response response: ( 'status' => 400, 'content_length' => '0', 'body_size' => 0, 'body_position' => 0, 'body_string' => '', ) Whether the request is sent to the production environment or the sandbox environment, a "400 Bad Request" response is returned with an empty response body, making it impossible to determine the cause of the issue. Could you please point out what the problem might be?

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

I need the supported way to obtain an Apple-signed AppTransaction for a development-installed iOS app without initiating an in-app purchase. DTS directed me to ask on the forums. Environment at the time of reproduction Physical iPhone 17e, iOS 27.0 (24A437). Xcode 27.0 (27A266a), macOS 27.0 (26A428). Swift / SwiftUI / StoreKit; version 0.1.0, build 1. Explicit bundle identifier registered with App Store Connect; development signing. The executable signature, embedded profile and installed executable hash were checked. Installed and launched using devicectl. Network access allowed. No StoreKit Configuration file or StoreKitTest session. No IAP products or TestFlight builds. App Store Connect version 1.0: Prepare for Submission. Observed behavior Call try await AppTransaction.shared once. It throws; no verified transaction is returned. From a separate visible button, the user explicitly calls try await AppTransaction.refresh() once. No Apple Account authentication prompt appears. The refresh fails immediately. The refresh error is identified by Swift pattern matching as StoreKitError.systemError: Outer NSError: StoreKit.StoreKitError, code 1 Underlying NSError: SKInternalErrorDomain, code 14 The refresh was recorded at 2026-09-20T15:40:12Z. The original shared probe recorded only the outer error, so I am not claiming its underlying error was identical. I could not find a public definition of the internal error; I am not interpreting it as SKErrorDomain code 14. A Sandbox Test Account was subsequently created, but has not been signed in on the device. The user could not find the Sandbox Apple Account entry. No purchase has been attempted to make that entry appear. The later controlled refresh is described below. The device App Store account differs from the developer account; we have not established this as a cause. Controlled follow-up on 2026-09-22 A separate instrumented copy of RefreshProbe was development-signed, installed and launched with devicectl on the same phone. The user explicitly tapped refresh once at 2026-09-22T14:35:39Z. It again returned StoreKitError.systemError, outer StoreKit.StoreKitError code 1 and underlying SKInternalErrorDomain code 14. The runtime executable SHA-256 matched the locally validated signed binary. No verified AppTransaction was returned. Bounded traversal of the typed underlying error, NSUnderlyingErrorKey and multiple underlying errors exposed only those two domain/code nodes and no allowlisted numeric service status. We did not collect arbitrary userInfo, accounts or signed transactions. App stdout confirmed the result; no storekitd/appstored system log or Xcode IDE launch comparison is claimed. The user confirmed that this attempt also showed no Apple Account login or password prompt. This instrumented copy is separate from the original source ZIP described below. No automatic retry or purchase was performed. VPN-disabled follow-up on 2026-09-22 After the earlier controlled attempt, the user reported using a VPN. For a second controlled attempt the user confirmed that the VPN was disabled and the normal Apple Account remained unchanged. At 2026-09-22T14:48:25Z, one explicit button tap again returned StoreKitError.systemError, outer StoreKit.StoreKitError code 1 and underlying SKInternalErrorDomain code 14. The bounded error tree was identical to the preceding attempt. The user confirmed that no login or password prompt appeared. No verified AppTransaction was returned. The runtime executable hash matched this signed build. The StoreKit call and diagnostic logic were unchanged; only the run identifier and UI label changed to preserve earlier records, followed by installation/relaunch. VPN and account conditions are user observations, not captured network routing. Disabling the VPN did not resolve this attempt; this is not proof that all network causes are excluded. There were no automatic retries or purchases. Questions Is an Apple-signed sandbox AppTransaction supported in this development-install scenario without an IAP product or purchase attempt? What registration and authentication prerequisites apply? What supported diagnostics or corrective steps should we use when refresh fails before presenting authentication? Is there a supported sandbox authentication path for this case without initiating a purchase or signing out of the normal Apple Account? If logs are needed, which narrowly scoped StoreKit logs should we collect? Focused sample A small project with two targets (192 Swift source lines, no dependencies) is ready to provide. The source entry points match the probes used for the observations above. Both packaged targets passed unsigned generic iOS builds, but the newly assembled focused package has NOT itself been re-signed and run on a device. It performs no purchase or photo-library access and does not include credentials, provisioning profiles, device identifiers or signed transactions. I can provide the package to DTS in the existing email request with a link to this forum post. I have not uploaded the package publicly.

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