Timeline and Correlation

Timeline and Correlation

Correlation: which events belong together

Events are grouped into one transaction only when they share an explicit identifier that the provider documents as linking them, for example:

• a payment id that appears in several webhooks,
• a parent or original transaction id on a refund or capture,
• a subscription id on rebills and cancellations,
• a dispute that names the payment it disputes.

PandaPayLens never links events by:

• merchant order references that can be reused across attempts,
• equal amounts or close timestamps,
• customer data.

Adapters often keep separate key spaces for different id families (for example a charge id and a pingback reference) when the documentation does not say they are the same thing. Two records that look related but share no documented identifier stay in separate groups, and the MISSING_REFERENCE rule may point this out.

Timeline views

View	Order
Event time	by the time the provider says the event happened
Receipt order	by the order the records arrived (timestamps of delivery if present, else input order)

When the two orders differ, the OUT_OF_ORDER_ARRIVAL rule explains it. A single record that contains several events (for example a status response listing past operations) is treated as one snapshot: its older entries are history, not late arrivals.

Event times are used only when the provider sends a timestamp with a known time zone. A date without a time zone is shown as an attribute but not placed on the time axis, because guessing the zone could reorder events.

A few providers (CCBill, Trust Payments) document times without a time zone. Those times are read as UTC so events can be ordered and are marked UTC assumed in the timeline and the Markdown report. When they are analyzed together with another provider's events, a TIME_ZONE_ASSUMED warning says that ordering across providers may be off by hours. Any time value without a zone that reaches the engine is dropped and counted in a TIMESTAMP_IGNORED warning, so ordering never depends on the computer running the analysis.

Filters

The timeline can be filtered by provider, outcome, operation (payment or deposit, recurring charge, authorization, capture, refund, dispute, payout, subscription change, cancellation, void, reversal, settlement, error) and reference.

What the timeline never does

• It never inserts events that are not in the data. A missing capture or refund is reported as missing, not invented.
• It never marks a payment as settled unless a settlement record says so.