Skip to content
Copper Lane Payments Read-only example
Mira · customer
Actor

Mira · customer

Buys one €100 lamp

AI context

Subject type: element
Subject ID: actor-customer
Project ID: showroom-payments
Draft ID: retry-alternative · version 1
Project settings version: 1
Project settings hash: sha256:11eb9324f48ccccdfbf345321fa5ffff2df6e34be7357a383b848db997e22834

# Copper Lane Payments — Retry change · authored alternative

_Draft retry-alternative · version 1 · based on revision 1 · content sha256:6f1911244e421f287163fec53bf4e3e9f8af67e3c1c1cbb5b337e7e7a3fa0be8_

_Context for Mira · customer (element actor-customer)_

Illustrative payment system · authored sample knowledge

_Readiness 0% · 1 open decisions · 1 decided_

## Use cases that pass through it

- Pay for the €100 lamp

## Inputs and outputs

**Inputs**

- **Buy the €100 lamp** (`int-start-checkout`): Mira · customer → Checkout

## Outline

- **Mira · customer** (`actor-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.
- **Copper Lane Payments** (`system-payments`, Boundary, system in scope) — 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** (`part-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.

## Interactions

- **Buy the €100 lamp** (`int-start-checkout`): Mira · customer → Checkout · Command · Network · Contract Checkout interface

  Mira submits order ord-1042 through the fictional checkout. src-purchase-requirement records the desired business outcome.

## Contracts

### Checkout interface (`contract-checkout`) · HTTP API

Checkout owns POST /checkout/pay. It accepts the order reference and shows known, unknown or confirmed payment state.

- The authored checkout waiting deadline is 10 seconds; reaching it does not establish processor failure.

## Decisions

### Who owns a payment that remains unresolved? (`dec-unresolved-payment-escalation`, open)

The fictional contract’s key window is bounded. If the existing outcome still cannot be established, keep the uncertainty open. An owner and escalation policy have not been decided.

- Affects: Checkout

### A timeout means unknown, not failed (`dec-timeout-is-unknown`, decided)

Checkout’s authored 10-second deadline can expire before the processor outcome is known. Starting another payment would risk charging twice if the unanswered operation succeeded.

- Keep confirming: Retain the same logical payment and key while seeking its existing outcome. Identical retries inside the fictional 24-hour window refer to that operation.
- Start another payment immediately: Treat a missing answer as failure and create another payment with a new operation key. — The first payment may already have succeeded. A new operation permits a possible duplicate charge.
- **Chosen:** Keep confirming

Keep Confirming payment visible until compatible evidence establishes the outcome. Beyond the 24-hour key window, inspect the existing operation first. Confirmed decline permits a separate explicit attempt.

- Evidence: note src-purchase-requirement: Authored src-purchase-requirement: Mira buys a EUR 100.00 lamp. The fictional shop fulfils only after processor-confirmed payment.
- Evidence: note src-payment-request: Authored src-payment-request: order ord-1042, logical payment pay-1001, EUR 10000 minor units and operation key pay-op-1001.
- Evidence: note src-checkout-timeout: Authored src-checkout-timeout: no reply reached checkout within 10 seconds. This proves the wait ended, not that the processor failed.
- Evidence: note src-processor-confirmation: Authored src-processor-confirmation: evt-9001 confirms EUR 10000 captured for pay-1001 with reference processor-pay-7001. Repeated delivery uses the same event identity.
- Evidence: note src-refund-confirmation: Authored src-refund-confirmation: evt-9002 confirms refund-1001 for EUR 10000 against pay-1001. Bank posting is outside this story.
- Evidence: note src-processor-contract: Authored src-processor-contract: identical same-key requests identify one operation for 24 hours. Confirmations may repeat or arrive out of order. Beyond that window, inspect the existing outcome before another attempt.
- Affects: Checkout