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:
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
purchaseDateto be recorded this way (storefronts/regions, purchase channels, offer types, original-receipt formats)? - When
purchaseDateandsignedDatedisagree, 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.