Payment service
Owns logical operations and recorded state
- Confirmation handler Apply a compatible outcome
- Checkout Read the recorded answer
- Checkout Request one logical payment
- Merchant support Request refund-1001
- Merchant support Read an order’s payment evidence
Incoming
- Confirmation handler Apply a compatible outcome
The confirmation component invokes payment operations in-process. Check event identity and logical operation before recording an accepted transition.
- Checkout Read the recorded answer
Checkout reads the current logical payment. Confirming payment means its processor outcome is still unknown; it is not a failed charge.
- Checkout Request one logical payment
Checkout supplies ord-1042 and EUR 10000. The payment service retains logical payment pay-1001 and operation key pay-op-1001.
- Merchant support Request refund-1001
Support requests EUR 10000 against pay-1001. refund-1001 uses its own operation key refund-op-1001 and initially remains requested.
- Merchant support Read an order’s payment evidence
Support reads pay-1001 and its recorded source before deciding whether to request the refund. No bank balance or settlement observation is shown.
Outgoing
- Fictional processor Check the existing operation
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.
- Payment records Read and record payment state
Persist the logical payment, operation key, accepted outcome and processed confirmation identity. Repeating a delivery must not create another payment.
- Fictional processor Submit the same payment operation
The payment service calls the fictional processor with pay-op-1001 and identical parameters inside the authored 24-hour retry window.
- Fictional processor Submit the same refund operation
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.