The parts

Mira · customer (Actor). Buys one €100 lamp Mira wants one payment and a clear answer. This is an authored fictional purchase; no real money or card details are involved.

Merchant support (Actor). Explains outcomes and requests refunds Support reads the recorded evidence for an order and requests a refund when the lamp is unavailable. A request and a confirmed result are distinct.

Fictional processor (External system). An external system with an authored contract Outside the merchant payment system. Its sample contract permits identical same-key requests for 24 hours and repeated, unordered confirmations. These assumptions are not guarantees about real providers.

Copper Lane Payments (Boundary). One shared picture of a fictional payment Illustrative system · authored sample records. A merchant payment service connected to a fictional processor. No bank, wallet, settlement product or real processor integration is represented.

Checkout (Process). Makes the payment outcome understandable Owns the fictional checkout interface. Its 10-second wait may end before the payment outcome is known. A timeout shows Confirming payment rather than inventing failure.

Payment records (Data store). Keeps requests, outcomes and evidence identities The fictional payment service owns this authoritative store. Tables describe a proposed design. Example values are authored notes, not live transaction rows or bank observations.

Payment service (Process). Owns logical operations and recorded state Owns payment and refund operations, their stable keys and state transitions. Processor calls cross the network. Its confirmation component calls payment operations in-process.

Confirmation handler (Component). Checks event identity and compatible outcomes A component inside the payment-service process. Receives fictional processor callbacks, recognizes repeated events and applies compatible state changes. Delivery order alone never establishes truth.