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.

Payment records

Use cases write to this store, but none reads from it.

Use cases that touch it

Ask your agent

In Alexandria, “Payment records” (id part-payment-store) is a gap: Written, never read. Find the use case it belongs to and add it to that use case's steps with settings_apply, or say why it is not needed. Read the model with drafts_get and settings_get.