Use cases
2 use cases, each told as its steps in order.
Pay for the €100 lamp
Who: Mira · customer. Goal: Pay once and understand whether the shop can fulfil the order. Starts when: Mira chooses Pay for the €100 lamp.
First, Mira chooses Pay for the €100 lamp. Then, the service records, submits and resolves one logical payment. Finally, Checkout reads what is known; a missing answer remains visibly unknown.
Ends with: Processor-confirmed payment lets the shop fulfil the order. Unknown and confirmed-decline outcomes remain visibly different. If it fails: No checkout response within 10 seconds: keep pay-1001 confirming and seek the existing operation’s outcome.; A confirmed decline is an explicit failure; a separate new attempt can then be requested.
Refund the unavailable lamp
Who: Merchant support. Goal: Request one refund and explain whether its processor outcome is known. Starts when: The shop cannot supply Mira’s lamp.
First, Support checks the confirmed payment and its existing refund history. Finally, Support requests a separate refund; the service records its request and compatible processor confirmation.
Ends with: A separate authored processor record confirms refund-1001; bank posting and settlement remain outside this story. If it fails: An unanswered or rejected request is not a confirmed refund. Keep uncertainty visible and do not create another refund to conceal it.