Copper Lane Payments

Illustrative payment system · authored sample knowledge

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.

In: Buy the €100 lamp, from Mira · customer to Checkout. Mira submits order ord-1042 through the fictional checkout. src-purchase-requirement records the desired business outcome.

In: Read an order’s payment evidence, from Merchant support to Payment service. Support reads pay-1001 and its recorded source before deciding whether to request the refund. No bank balance or settlement observation is shown.

In: Request refund-1001, from Merchant support to Payment service. Support requests EUR 10000 against pay-1001. refund-1001 uses its own operation key refund-op-1001 and initially remains requested.

In: Receive payment confirmation, from Fictional processor to Confirmation handler. The fictional processor sends authored event evt-9001 for pay-1001, processor reference processor-pay-7001, EUR 10000 captured. src-processor-confirmation records this prepared evidence.

In: Receive refund confirmation, from Fictional processor to Confirmation handler. Authored event evt-9002 confirms refund-1001 for EUR 10000 against pay-1001. src-refund-confirmation does not establish bank posting.

Out: Submit another payment after timeout, from Payment service to Fictional processor. Unsafe proposed change: a timeout creates a new logical payment and new operation key immediately, although pay-1001 may already have succeeded. Authored scenario; not an executed test.

Out: Check the existing operation, from Payment service to Fictional processor. A bounded, on-demand read asks the fictional processor about the existing operation. An unanswered lookup leaves the outcome unknown; it does not start another payment.

Out: Submit the same refund operation, from Payment service to Fictional processor. The payment service submits refund-op-1001 with identical refund parameters. A retry of that logical refund retains the key inside the fictional contract window.

Checkout. 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. 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. 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.

Mira · customer. 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. 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. 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.