Payment Request Trace

Overview

Payment Request Trace is an end-to-end trace that follows one payment request and its related operations across services, queues, providers, rails, and state transitions. The trace begins at an intake boundary and propagates a trace context so child spans can represent validation, routing, external calls, persistence, event delivery, and other work. The relationship with Payment Span ID matters because one payment can appear as multiple requests, events, provider references, and ledger entries.

Its boundary with Payment Span must remain explicit so related records do not collapse into one status. Operationally, the trace begins at an intake boundary and propagates a trace context so child spans can represent validation, routing, external calls, persistence, event delivery, and other work. It is technical execution evidence and must be correlated with authoritative payment records rather than treated as the financial ledger. Controls should propagate standard trace context, link asynchronous work, separate trace and payment IDs, record safe attributes, retain error traces, align clocks, and verify coverage.

Payment Request Trace should remain distinct from Payment Span, Payment Span ID, and Payment Observability, because each can represent a different stage, record, control, or financial outcome. Useful measures include trace coverage, broken-link rate, end-to-end latency, sampled error retention, services per trace, and time to locate the failing boundary.

Important risks include broken context propagation, reused payment identifiers, sensitive data in attributes, sampling that removes failures, clock skew, and traces ending before asynchronous completion. Testing should cover success, rejection, timeout, duplicate delivery, partial completion, recovery, and the resulting accurate accounting records.

The record should retain trace ID, payment and request IDs, span hierarchy, services, operations, timestamps, route and provider attributes, errors, state versions, and sampling decision. Changes to Payment Request Trace need controlled deployment and explicit ownership.