Home · Apps · rl-bank-mvp
Fake shop / merchant ecosystem vision
Status: Draft, planning-level only.
Why this exists
The fake-bank experience is getting more believable on the banking side, but it still needs a realistic merchant-side world around it. A fake shop ecosystem gives us that world by connecting:
- fake-bank customer accounts and cards
- merchant/shop operations
- a physical payment terminal
- an iPad-style POS surface
- later merchant reporting and operations workflows
This is intentionally a docs-first planning set. It is meant to help John review direction and make scope decisions before implementation hardens.
Vision statement
Build a believable but safely fake merchant ecosystem where a shop operator can:
- manage a fake shop identity
- maintain a fake product catalogue
- take orders in an iPad POS flow
- send payment requests to a dedicated payment terminal
- accept fake-bank card/token payments
- view simple order, payment, and session history
The end result should feel like a small merchant stack rather than just a bank demo.
Product principles
- Believable over overbuilt
- It should feel real enough for demos and product storytelling.
- We do not need enterprise-grade merchant ops on day one.
- Thin hardware, richer backend
- The terminal should stay focused on payment acceptance.
- Shop logic and basket logic should live primarily in app/backend layers.
- Editable planning before implementation commitment
- Keep contracts and workflows clear.
- Avoid locking in data models, transport choices, or infra details too early.
- Fake-safe by design
- UI and flows should not imply real banking or card-network behavior.
- Demo artifacts should remain under our own control where possible.
- Shared ecosystem, clear boundaries
- fake-bank owns customer accounts, payment authorization logic, and card/payment history
- fake-shop owns products, carts, orders, checkout context, and merchant-side operations
- payment terminal owns in-person payment interaction
Experience shape
Merchant-side surfaces
The ecosystem likely spans four surfaces:
- Merchant admin / backoffice — shop profile, product setup, transaction review
- iPad POS — day-to-day checkout surface for cashier/staff
- Payment terminal — customer-facing tap/approve device
- Bank/customer side — card/account/payment history reflecting merchant activity
Customer-side realism goals
The customer should see believable downstream effects of merchant activity:
- recognizable merchant labels
- order-linked card payments
- cleaner activity/history narratives
- eventually richer fake receipts or purchase references
Ecosystem boundaries
In scope for this planning set
- fake shop concept and merchant operating model
- actors and responsibilities
- MVP scope for merchant + POS + terminal collaboration
- checkout and payment workflows
- key open questions that must be decided before implementation
Out of scope for this planning set
- full API schemas
- detailed DB schema lock-in
- final repo split decision
- final hardware procurement choices
- production payment compliance or real money movement
- advanced merchant finance features such as payouts, reconciliation, refunds, disputes, or tax engines
Relationship to existing rl-bank-mvp docs
This draft extends the current bank-first planning already captured in:
Those docs already establish the terminal as a bridge toward future POS flows. This new set makes that future POS/shop layer explicit.
Recommendation
Treat fake shop as the next realism layer around fake bank, not as an unrelated product. For now, I would document it under rl-bank-mvp because the main value is the connected demo ecosystem, not repo purity.