Resolve one payment without inventing its outcome
Runs in Payment service
Description
flow-pay-order details pay-process in uc-pay-order. Two start points distinguish the original request from a later processor event. Authored records reveal knowledge, not live telemetry.
At a glance
- Blocks
- 13
- Use cases
- 1
- ID
flow-pay-order
Blocks
- Payment request arrives Payment service
- Record pay-1001 before calling the processor Payment service
- Submit pay-op-1001 with the same parameters Payment service
- What does the available evidence establish? Payment service
- Payment confirmed; the shop may fulfil Checkout
- Record the confirmed payment outcome Payment service
- Confirmed decline; an explicit new attempt is possible Checkout
- Keep pay-1001 confirming; do not invent failure Payment service
- Show Confirming payment; outcome remains unknown Checkout
- A processor confirmation arrives separately Confirmation handler
- Was this confirmation identity already processed? Confirmation handler
- Duplicate evt-9001; recorded outcome unchanged Confirmation handler
- Record the compatible confirmation and payment outcome Payment service