Transactions and the event stream

Events are immutable evidence; transactions and subscription lineages are projections of verified store state. One transaction can be associated with several observations, while one Google purchase observation can contain multiple line items. Counts from these views are therefore not interchangeable.

Use Transactions for purchase state

Open Transactions, choose the app/environment/platform and supported filters, and locate the purchase. Open its detail to inspect store identifiers, original transaction/lineage, product, status, purchase/expiry/revocation times, monetary facts where available, line items, related customer, and source evidence.

A transaction's state can be refined by later authoritative observations. Google order enrichment can add accounting facts without making a separate access decision. Missing prices or currency are not filled with a guessed value.

Refunded transaction values and timeline attribution depend on the chosen metric. In the standard revenue cohorts, known refunds are assigned to the original purchase period. The date on which a refund was observed can therefore differ from the chart bucket carrying its financial effect.

Use Event stream for evidence and change history

The stream contains normalized ledger events, including store/client observations and derived access changes. Filter the relevant categories, platform, environment, status, and time range, then trace the related transaction or customer.

The ledger is append-only. A later correction is represented by later evidence and a changed projection, not by silently rewriting the original event. Store verification occurs before trusted claims are used for app attribution and projection.

Event numbers are monotonic but can have gaps. They are not a guarantee of database commit order. Client-facing receipt/subscriber event IDs are decimal strings to preserve the full 64-bit range in JavaScript/Dart. Do not build an external durable polling cursor solely from the largest event ID and assume no lower-ID transaction can commit later.

Understand environment attribution

Apple signs production or sandbox. Google RTDN is a doorbell without a definitive purchase environment, so the notification can be recorded as unknown; the subsequent authenticated purchase read establishes the actual purchase state. Unknown is not silently included as production.

A sandbox filter can show the transaction while an associated earlier RTDN appears under unknown. Inspect the complete lineage rather than concluding that one of the records belongs to another app.

Duplicate and late delivery

Stores and clients can resend evidence. Idempotency distinguishes duplicate delivery from a new authoritative observation, and stale-state reduction prevents an old observation from overwriting newer truth. A successful duplicate receipt response does not create another sale.

If you see an unexpected change, compare store timestamps, received times, purchase ownership, product mappings, and the resulting current projection. They answer different temporal questions.

Investigation examples

• Purchase exists, access absent: check customer ownership and the versioned product access mapping, then expiry/revocation.
• Many events, one transaction: several notifications/receipts can refer to the same purchase.
• Refund seen today changes an older revenue bucket: the selected chart may attribute known refunds to original purchase cohorts.
• Google price arrives later: order enrichment is separate from purchase-state verification.
• No expected outbound webhook: outbound delivery fans out supported derived events such as access.changed, not every raw store observation.

Follow metrics, webhooks, and troubleshooting for the relevant contract. For a complete normalized event/transaction history, queue an export.