Hi Apple team, We’re evaluating how we generate appAccountToken for in-app purchases. For privacy and security reasons, rather than using a stable UUID associated with an account across all purchases, we’re considering generating a different opaque value for each purchase/context. Internally, our backend would maintain the mapping needed to associate each value with the correct customer account and, potentially, additional purchase context. In other words, the same customer account may result in different appAccountToken values across separate purchases, while our backend can still deterministically resolve each token to the correct account. We’d like to confirm: Does Apple expect or recommend that appAccountToken remain stable for the same app account across purchases? Are there any concerns with this approach for non-subscription / one-time purchases, assuming we maintain the account association on our backend? Our goal is to avoid exposing a stable account-correlatable identifier while still maintaining reliable server-side attribution. Thanks!

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

Since we configured App Store Server Notifications V2 on 15 October 2026, every notification for our app is recorded as TIMED_OUT, with the attemptDate equal to the signedDate (same second), and no HTTP request ever reaches our server. 35 Sandbox notifications (TEST, SUBSCRIBED, DID_RENEW, EXPIRED): one attempt each, TIMED_OUT. 2 Production TEST notifications: retried 5–6 times over a week, all TIMED_OUT. Our endpoint is public, TLS 1.3, valid certificate, answers in < 400 ms, and processes the signedPayload correctly when we POST it ourselves. Today we pointed the Sandbox URL to a webhook.site URL and requested a test notification: TIMED_OUT within 10 s, nothing received on webhook.site either. The app (com.virginactive.revolution, appAppleId 1620160868) was transferred to our current developer account on 2 October 2026; notifications have never been delivered under the new team, so we suspect a server-side state issue after the transfer. Latest test tokens: Sandbox: be12b40b-19a7-4723-aebf-764db83b4690_1793289992274 (29 Oct 2026 16:06 UTC) Production: 80597167-2939-4cc9-a43c-2c3c29c6a161_1792741270174 (23 Oct 2026 07:41 UTC) Feedback Assistant: FB25363489 Is there anything on our side that could make the App Store server fail before attempting the connection, or does this need to be fixed on Apple's side?

We use Apple's official App Store Server Library for Node.js, version 3.1.0. Our latest Production Get Notification History check, on 24 October 2026 at 15:21 UTC, returned HTTP 401 with an empty response body. The request ran from our deployed backend. We verified the ES256 signature, JWT claims, 300-second token lifetime, Authorization header and system clock alignment. On 23 October, notification-history requests using the same JWT and server environment returned: Sandbox: HTTP 200 Production: HTTP 401 A separate Production Request a Test Notification also returned 401; no test notification token was issued. The latest check was only a history query, not another TEST request. The account owner confirmed that the existing In-App Purchase key is Active. Our first app version remains PREPARE_FOR_SUBMISSION and has never been publicly released. Separate Production and Sandbox notification URLs are saved with Version 2 selected. An Apple App Store Commerce Engineer described a first-production-release prerequisite in this discussion: https://developer.apple.com/forums/thread/806452 Does that prerequisite apply specifically to both Get Notification History and Request a Test Notification? Neither request uses a transaction ID. If these endpoints should authenticate before the first release, which additional app-specific authorization prerequisite or non-sensitive diagnostics should we check? Apple request IDs can be provided privately through an appropriate Apple support channel if requested.

Our approved app is held at Pending Developer Release because the production App Store Server API cannot find our notification URL, even though the Production Server URL is saved in App Store Connect. The failure has been constant since August. On October 20 we ran two tests that isolate it, and we would appreciate someone from App Store Server engineering checking the request UUIDs below. What works Sandbox Request a Test Notification, same In-App Purchase key, same bundle ID, same URL string as Production: HTTP 200, token issued, Get Test Notification Status reports sendAttemptResult SUCCESS 280 ms later. 2026-10-20 16:31:13 UTC · request UUID ad1708d2-8536-4204-9a7b-32ded5800d48 · correlation key VULQRUUFGZBAJGT3GLPNLAANJA Production Get Notification History, same key: HTTP 200 (0 records, app not yet released). 2026-10-20 16:40:08 UTC · request UUID 7aedd431-fcf1-b104-42cd-17cc599425e4 · correlation key PLW5IMP46GYQIQWNC7GFTFBF4Q What fails Production Request a Test Notification (both api.storekit.itunes.apple.com and api.storekit.apple.com): HTTP 404, errorCode 4040007, "No App Store Server Notification URL found for provided app." No testNotificationToken is issued, so Apple never contacts our endpoint. Most recent: 2026-09-30 11:25 UTC · request UUID 22a1e218-4cdc-3577-9e18-3e25caf64052 · correlation key EKQ6EGCM3Q2XPHQYHYS4V5SAKI Earlier: f0cf352f-828e-fd40-8c14-2000fb8181e3 (Sept 23), 74a8bbbd-cd43-a18b-c4ac-bba619232d1d (Sept 14), 412d6c9f-511c-4402-ba18-d33fcda1b916 and 4f88fc30-3a4c-b7da-5d67c2f88570 (Sept 4, two different keys) Already done Production Server URL verified as saved in App Store Connect; removed, saved, re-added, waited, retested. No change. Reproduced with Apple's App Store Server Library (Swift) and with a minimal client. Feedback filed: FB24641446. Developer Support escalated the case to engineering on September 18; no engineering response yet. The question In thread 806452 an App Store Commerce Engineer wrote that production API access is unlocked once an app has a release in production. Our production history call succeeds for an unreleased app, so we cannot tell from outside whether the notification URL lookup behind /inApps/v1/notifications/test is gated on first release. If it is, we will release today and retest; a one-line confirmation would end a seven-week hold. If it is not, the production notification URL record for this app appears to be missing or unreadable, and we would ask that it be inspected and rebuilt. Happy to run a fresh reproduction in any time window and post the UUID. App Apple ID 6793806173, bundle com.haullynx.app.

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!

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?

DTS recommended that we post this question in the Developer Forums. We would like clarification on the supported production behavior of originalTransactionId in the App Store Server API, particularly after a subscription expires and the customer resubscribes. Our main backend design question is: Can we continue using a stored originalTransactionId to identify and retrieve subsequent subscription activity within the same subscription group, or must we support discovering and associating new identifiers? Integration context Our backend uses: GET /inApps/v1/subscriptions/{transactionId} GET /inApps/v2/history/{transactionId} App and subscription details: Bundle ID: com.lgeha.nuts Subscription group identifier: 22350255 Product A: thinq_g_unlimitedpro Product B: thinq_g_single We use originalTransactionId as a key for subscription records and associate those records with user accounts in our service. We do not use it as an identifier for the Apple Account itself. Please assume the same Apple Account and app, with both products in the same subscription group, using ordinary auto-renewable subscriptions without a special subscription migration. This question concerns the identifiers and lookup behavior exposed to our backend by the App Store Server API. Sandbox observation and scope During sandbox testing, purchase history was cleared, and a new originalTransactionId was subsequently observed. We understand that this observation involved a sandbox history reset and does not establish production behavior. Our questions below concern production behavior without any purchase-history reset. Preservation across subscription lifecycle events For each scenario below, is originalTransactionId guaranteed to remain unchanged for subsequent transactions, or can Apple assign a different value? Automatic renewal of the same product. An upgrade, downgrade, or crossgrade between products A and B while the subscription is active. Turning off automatic renewal, then re-enabling it before expiration. Turning off automatic renewal, allowing the subscription to expire, and later resubscribing to the same product. Turning off automatic renewal for product A, allowing it to expire, and later subscribing to product B within the same subscription group. Scenarios 4 and 5 are our primary concern. We would like to distinguish commonly observed behavior from supported guarantees that a backend can rely on. Conditions for a new identifier after expiration For scenarios 4 and 5, can a new purchase legitimately receive a different originalTransactionId in production despite the Apple Account, app, and subscription group remaining unchanged? If so, what conditions determine this? Does it depend on: Time elapsed since expiration. Billing retry or billing grace-period status or history. Whether the purchase uses StoreKit 1 or StoreKit 2. Whether the customer resubscribes inside the app or through App Store subscription management. Our concern is whether these factors affect the identifiers subsequently returned by the App Store Server API. Stability of an existing transaction Separately from a new purchase receiving a new identifier, if the same transactionId is retrieved at two different times, is its associated originalTransactionId guaranteed to remain unchanged? Can an Apple-supported correction process change that association, or should such a result be treated as an inconsistency and reported through Feedback Assistant? This question concerns the same returned transactionId, rather than a different latest transaction returned by a subsequent status query. We have not confirmed such a change in production. Lookup behavior using a previously stored identifier If resubscription can create a new originalTransactionId, how does that affect each endpoint? For GET /inApps/v1/subscriptions/{transactionId}: Can a request using the previous originalTransactionId return the current status of a later resubscription with a different originalTransactionId, assuming the same Apple Account, app, and subscription group? Or must the backend obtain the new identifier separately? For GET /inApps/v2/history/{transactionId}: Can a request using the previous originalTransactionId return transactions from that later resubscription, assuming all applicable pages are retrieved and no filters exclude those transactions? Please clarify any endpoint-specific guarantees or limitations on using an older identifier to discover subsequent subscription activity. Backend account association If resubscription can create a new identifier, should our backend support multiple originalTransactionId values for one service user within the same subscription group? Is there a documented server-side relationship that links subscriptions with different originalTransactionId values? Alternatively, should that association rely on an application-managed identifier such as appAccountToken, where available? Please clarify any limitations, especially for resubscriptions initiated outside the app. Related discussions We reviewed these discussions as background: Transaction ID Misassociation in IAP Subscription API (https://developer.apple.com/forums/thread/777433) original_transaction_id associated to web_order_line_item_id of auto-renewable subscription changed (https://developer.apple.com/forums/thread/778301) We do not assume that these reports establish supported behavior or share the cause of our sandbox observation. Could Apple clarify the supported preservation or replacement rules, particularly after expiration and resubscription, and point us to documentation describing the behavior a backend can rely on? If investigating a specific inconsistency requires a separate Feedback Assistant report, please indicate which server-side request and response details should be included. 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.

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!

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!

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

We handle App Store Server Notifications V2 for an auto-renewable subscription. When we receive REFUND for the current period, we revoke the customer's access. We now want to reinstate access on REFUND_REVERSED, as the documentation says: "If your app revoked content or services as a result of the related refund, it needs to reinstate them." Before reinstating, our server verifies the transaction in signedTransactionInfo and rejects it if revocationDate is present or expiresDate is in the past. We'd like to confirm a few behaviors so that the reinstatement doesn't get rejected by our own checks: In a REFUND_REVERSED notification, does the signedTransactionInfo still contain revocationDate (and revocationReason), or are they removed? Likewise, after the reversal, does Get Transaction Info / Get All Subscription Statuses return the transaction without revocationDate? An App Store Commerce Engineer explained in thread/757119 that when a customer requests a refund, the subscription's auto-renew status is set to false. Does this apply to every refund path (for example, refunds initiated by Apple or via chargebacks), or only to refunds requested by the customer? After REFUND_REVERSED, does the auto-renew status stay off, or can it be turned back on automatically? If it stays off, is the customer expected to re-enable auto-renew themselves? We have seen reports that REFUND_REVERSED can arrive weeks after REFUND, even when expiresDate has already passed. In that case, is it correct to reinstate access only up to the original expiresDate (i.e. nothing to reinstate if it has already passed)? 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.

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?

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.

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

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