How the parts talk

Confirmation handler → Payment service: Apply a compatible outcome (Command, In-process). Contract: Apply confirmed outcome. The confirmation component invokes payment operations in-process. Check event identity and logical operation before recording an accepted transition.

Payment service → Fictional processor: Check the existing operation (Query, Network). Contract: Fictional processor operations. 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.

Fictional processor → Confirmation handler: Receive payment confirmation (Event, Network). Contract: Processor confirmation endpoint. 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.

Checkout → Payment service: Read the recorded answer (Query, Network). Contract: Payment service API. Checkout reads the current logical payment. Confirming payment means its processor outcome is still unknown; it is not a failed charge.

Payment service → Payment records: Read and record payment state (Data, Network). Contract: Payment state storage. Persist the logical payment, operation key, accepted outcome and processed confirmation identity. Repeating a delivery must not create another payment.

Fictional processor → Confirmation handler: Receive refund confirmation (Event, Network). Contract: Processor confirmation endpoint. Authored event evt-9002 confirms refund-1001 for EUR 10000 against pay-1001. src-refund-confirmation does not establish bank posting.

Checkout → Payment service: Request one logical payment (Command, Network). Contract: Payment service API. Checkout supplies ord-1042 and EUR 10000. The payment service retains logical payment pay-1001 and operation key pay-op-1001.

Merchant support → Payment service: Request refund-1001 (Command, Network). Contract: Payment service API. Support requests EUR 10000 against pay-1001. refund-1001 uses its own operation key refund-op-1001 and initially remains requested.

Mira · customer → Checkout: Buy the €100 lamp (Command, Network). Contract: Checkout interface. Mira submits order ord-1042 through the fictional checkout. src-purchase-requirement records the desired business outcome.

Payment service → Fictional processor: Submit the same payment operation (Command, Network). Contract: Fictional processor operations. The payment service calls the fictional processor with pay-op-1001 and identical parameters inside the authored 24-hour retry window.

Payment service → Fictional processor: Submit the same refund operation (Command, Network). Contract: Fictional processor operations. 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.

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

Apply confirmed outcome (In-process). The confirmation component invokes payment operations inside the same payment-service process. No HTTP hop exists between these two parts. Guarantees: Record event identity and a compatible outcome together. A repeated event cannot create another logical payment or refund.. contract

Checkout interface (HTTP API). Checkout owns POST /checkout/pay. It accepts the order reference and shows known, unknown or confirmed payment state. Guarantees: The authored checkout waiting deadline is 10 seconds; reaching it does not establish processor failure.. contract

Processor confirmation endpoint (HTTP API). The payment service owns POST /processor-confirmations. Its confirmation component receives processor-originated payment and refund events. Guarantees: Confirmations can be duplicated or unordered. Event identity and compatible state transitions determine whether recorded state changes; exactly-once delivery is not assumed.. contract

Payment service API (HTTP API). The payment service owns POST /payments, GET /payments/{id} and POST /refunds. Checkout and support call these fictional endpoints. Guarantees: An unanswered request retains the same logical payment. Responses distinguish confirming, paid and confirmed-decline states.. contract

Payment state storage (SQL). The payment service owns reads and writes of order references, logical payments, confirmations and refunds in the modeled PostgreSQL design. Guarantees: Event identity is recorded with the accepted state transition. The schema is illustrative, not a deployed payment backend.. contract

Fictional processor operations (HTTP API). The fictional processor owns payment submission, existing-operation lookup and refund submission. This is an authored interface, with no credentials or real provider. Guarantees: Identical parameters and operation key identify one operation for 24 hours. Beyond that window, inspect the existing outcome before another attempt; unresolved stays unresolved.. contract