Resolve one payment without inventing its outcome
Runs in Payment service
Subject type: flow Subject ID: flow-pay-order Project ID: showroom-payments Draft ID: retry-alternative · version 1 Project settings version: 1 Project settings hash: sha256:11eb9324f48ccccdfbf345321fa5ffff2df6e34be7357a383b848db997e22834 # Flow: Resolve one payment without inventing its outcome (`flow-pay-order`) 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. - 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) - Start another payment with a new key (Payment service) - Another payment may exist; the first is still 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)