Answer: C

A payment flow crosses multiple failure domains and cannot generally be treated as one atomic transaction. Network failures, processor timeouts, retries, duplicate messages, asynchronous events, and partial completion all create states that must be explicitly modeled. The architecture should define how those states are recovered and reconciled rather than assuming the entire operation succeeds or fails atomically.

Concurrency means two requests can observe the same state before either commits. A business-level uniqueness or idempotency mechanism must be enforced at a durable system boundary so concurrent requests cannot create duplicate financial effects.

Payment systems require explicit reconciliation between internal records and external financial systems. A difference may represent missing transactions, duplicates, fees, timing differences, refunds, reversals, or other exceptions. It should not be silently overwritten.

The payment and downstream business action may cross system boundaries. Durable event publication combined with idempotent consumption allows the system to recover from temporary messaging failures without duplicating the financial operation.

Distributed event delivery does not guarantee ordering. A robust payment system must understand the valid state machine and prevent delayed or duplicated events from causing an invalid regression.

A current status is useful derived state, but it is not necessarily a sufficient audit history. Important payment transitions and external events should be durably represented so the system can explain, reconcile, and recover payment state.

A local crash can create uncertainty between the external system and the local database. The system should resolve that uncertainty using a durable business identifier and the processor’s authoritative state rather than guessing.

Distributed systems commonly provide at-least-once delivery, meaning consumers may receive the same event multiple times. The payment system should therefore make webhook processing idempotent, typically using a durable event or provider-event identifier.

Authorization and capture are distinct stages in many payment flows. A transient capture failure should not erase the fact that authorization succeeded. The payment state machine must represent the actual lifecycle and support safe recovery.

A network timeout does not tell the client whether the operation committed. A payment system must distinguish a retry of the same business operation from a genuinely new payment. A durable idempotency key allows the system to safely return the original result without creating a duplicate financial operation.