Environment: Production. Bundle ID: com.filmixpro.filmix. (Team ID / notification URL available privately or via Feedback Assistant.) We received 7 App Store Server Notifications V2 (SUBSCRIBED) whose JWS signatures we successfully verified against Apple root CAs (decoded payloads show environment=Production, bundleId=com.filmixpro.filmix). However, querying the App Store Server API (production) for these originalTransactionIds returns 404 (4040010) "Transaction id not found" on EVERY endpoint: Get All Subscription Statuses, Get Transaction Info, Get Transaction History, Get Refund History, and Get Notification History (filtered by transactionId). The same API key resolves all other transactions correctly (these are 7 out of 3231 chains scanned). The IDs are also absent from the global Get Notification History (last 180 days). Sandbox returns 404 as well. One of them, 520002039865757, previously generated a REFUND_DECLINED notification (a refund was requested and DECLINED — i.e. not refunded), yet it too now returns 404 on every endpoint including Get Refund History, so the disappearance is not explained by a refund. Affected originalTransactionIds: 590002039736765, 590002053449909, 430002231597484, 70003114793852, 100002338147592, 520002039865757, 340001586213801 Questions: Why do Apple-signed, Production transactions return 404 "Transaction id not found" on all App Store Server API endpoints? Have these transactions been removed/invalidated (fraud, chargeback, account deletion, refund reversal)? If so, which category? We recently signed a previously-unsigned Paid Applications Agreement — does this affect API visibility of historical transactions, and what is the propagation time? How should we reconcile entitlement for transactions that were signed/notified but are not found in the Server API?

Environment: Production. Bundle ID: com.filmixpro.filmix. (Team ID / notification URL available privately or via Feedback Assistant.) We extended the renewal date of 3 auto-renewable subscriptions on 2026-02-28 using the Extend Subscription Renewal Date API, and received the matching RENEWAL_EXTENDED notifications. After the extended period ended, auto-renewal failed and all 3 are now in billing retry: Get All Subscription Statuses returns status=3 with expirationIntent=2 (billing error), isInBillingRetryPeriod=true, and no grace period. However, Get Notification History (production, last 180 days, filtered by transactionId) returns ONLY the RENEWAL_EXTENDED notification for each — there is no DID_FAIL_TO_RENEW (nor EXPIRED / DID_RENEW). Per the documentation, entering billing retry should produce a DID_FAIL_TO_RENEW notification. This is not a missed/undelivered webhook on our side: over the same 180-day window the global Get Notification History returned 4232 notifications and our records contain all of them, with per-type counts matching exactly (including DID_FAIL_TO_RENEW). For contrast, another subscription in the same billing-retry state (originalTransactionId 220002005208565) DID receive a DID_FAIL_TO_RENEW — so the absence is not universal, and it correlates with subscriptions extended via the API. The three affected subscriptions span three storefronts (USA / CHN / TUR), so it is not storefront-specific. Affected originalTransactionIds: 150002285191456 (extended to 2026-05-07) 320002313172683 (extended to 2026-06-05) 470002485799388 (extended to 2026-06-12) Questions: Should a subscription extended via Extend Subscription Renewal Date emit DID_FAIL_TO_RENEW when it later enters billing retry? If so, why is it absent from Get Notification History for these three while present for 220002005208565? Does extending via the API affect generation/visibility of subsequent renewal/billing notifications? How should we reconcile entitlement for subscriptions that entered billing retry without any notification?