Transaction Record

Overview

A transaction record is the operational source used to reconstruct what was requested, what the system decided, what external parties reported, and what financial effects occurred. It may represent one transaction entity with an append-only event history or several linked records for attempts, transfers, fees, and adjustments.

Core fields include a stable internal identifier, transaction type, amount and currency or asset, accounts or destinations, lifecycle state, created and updated times, provider and network references, authorization evidence, fees, and relationships to orders, settlements, refunds, reversals, or replacements. Sensitive data should be minimized, protected, and retained according to policy.

Corrections should preserve history instead of silently overwriting financial facts. Access, version changes, and manual actions need audit evidence. A transaction record differs from a customer receipt: the record supports operations, reconciliation, accounting, investigation, and compliance, while the receipt is a selected external presentation of that information.

The record should use immutable event history or versioned transitions rather than replacing status without context. Links to Dispute Case , refunds, captures, fees, settlement, and ledger entries make the lifecycle navigable. Sensitive data should be minimized or tokenized, but identifiers needed for reconciliation must remain searchable. Retention rules should reflect financial, legal, privacy, and operational requirements.

Records should also distinguish event time, receipt time, processing time, booking time, and posting time. These timestamps reveal where delay occurred and support period reconciliation. Corrections should create linked adjustment or reversal records instead of deleting the original evidence.

The record provides evidence for Transaction Processing and later accounting in the General Ledger .