rl-docs-hub

Home · Apps · rl-bank-mvp

---

Fake shop / merchant ecosystem workflows

Status: Draft.

Workflow 1 — Merchant setup

1. merchant signs into merchant/admin surface
2. merchant creates or edits shop profile
3. merchant adds products with price and image
4. system makes those products available in POS

Workflow 2 — Cashier checkout happy path

sequenceDiagram
  participant C as Cashier / POS
  participant S as Shop backend
  participant T as Terminal
  participant B as Fake-bank backend
  participant U as Customer

  C->>S: create checkout session with basket
  S-->>C: checkout session + amount + reference
  C->>T: send payment request/context
  T-->>U: show amount + merchant label + tap prompt
  U->>T: present fake-bank token/card
  T->>B: authorize payment
  B-->>T: approved + reference
  T-->>S: payment approved
  S-->>C: order paid / completed

Expected outcomes:

• order is marked paid
• merchant sees completed sale
• customer sees corresponding bank-side activity

Workflow 3 — Declined payment

1. cashier initiates checkout
2. terminal prompts customer
3. authorization returns decline
4. terminal shows decline state
5. POS shows unpaid/declined state
6. cashier can retry or cancel the sale

Expected outcomes:

• order is not marked paid
• payment attempt remains visible in history
• decline reason shown to merchant should stay simple and demo-safe

Workflow 4 — Cancelled or timed-out payment

1. checkout session starts
2. terminal waits for customer action
3. customer cancels or no tap occurs before timeout
4. terminal returns cancelled/timeout state
5. POS keeps basket/order recoverable

Expected outcomes:

• merchant can retry without rebuilding the entire basket if we choose to support that in UX
• no false successful payment should appear on bank side

Workflow 5 — Merchant history lookup

1. merchant opens recent orders/payments
2. merchant selects an order/payment row
3. system shows:
   • items
   • total
   • timestamps
   • payment state
   • references/correlation ids where appropriate

Expected outcomes:

• merchant can understand what happened without checking backend logs

Workflow 6 — Customer-side visibility

1. approved payment is recorded by bank backend
2. customer opens fake-bank activity/history
3. system shows a merchant payment entry with readable label/reference

Expected outcomes:

• the merchant ecosystem improves bank-side realism, not just merchant-side realism

State model sketch

Checkout/order states

• draft basket
• checkout started
• awaiting payment
• paid
• payment declined
• cancelled
• timed out
• errored

Terminal session states

• idle
• checkout loaded
• awaiting tap
• authorizing
• approved
• declined
• cancelled
• timed out
• error

Design note

I would keep the first implementation state model intentionally small and explicit. Hidden pseudo-states or clever workflow abstractions will make this harder to reason about during review.