Copper Lane Payments
One shared picture of a fictional payment
Parts
2 parts on this layer, as on the map.
Payment records Data store. Keeps requests, outcomes and evidence identities.
Payment service Process. Owns logical operations and recorded state.
How they work together
- Data from Payment service to Payment records: Read and record payment state.
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.