Payment State Replay

Overview

How it works

Its boundary with Payment Notification Event must remain explicit so related records do not collapse into one status. Operationally, the replay selects a bounded event stream and version, applies events in defined order to an isolated or prepared target, checkpoints progress, and validates the resulting state. The record should retain replay ID, source stream and range, event versions, target, mode, checkpoints, skipped or failed events, resulting state, approvals, and validation. Testing should cover success, rejection, timeout, duplicate delivery, partial completion, recovery, and the resulting accurate accounting records.

It should not automatically repeat external financial side effects; replaying history differs from retrying a payment submission.

What matters in practice

Replay reprocesses historical payment events through a state machine, often to recover from an outage or validate new code. The replay engine must not re-execute side effects such as sending money, emailing fulfillment codes or issuing refunds. Separate state calculation from outbound actions and enforce idempotency keys or an outbox pattern. Process each event with its original timestamp, policy version and stable identifier. Out-of-order delivery can otherwise cause old 'pending' events to overwrite legitimate paid states.

Safeguards become crucial when replaying events into production. Run the rebuilt projection alongside the current one, compare state counts and monetary totals, and require an explicit cutover. Side-effect consumers should reject events flagged as historical replay unless an operator intentionally authorizes new work. Refund and payout processors should continue to consult persistent operation IDs even if the event bus is replayed from its beginning.

Related glossary concepts

Payment State Persistence; Payment Notification Event