Engineering notes / 01 — Deployed platform
Cafesserie Ordering
From checkout to the restaurant queue.
A multi-branch ordering platform connecting customer checkout, payment verification, and live restaurant operations.
- TypeScript
- Next.js
- React
- Convex
- Clerk
- Cloudflare
- PesaPal
The engineering problem
An order crosses several trust boundaries: the customer, the payment provider, and the restaurant team. The backend needs to own pricing, prevent duplicate orders, and give each branch access to the right operational data.
Follow the request.
- 01
Customer checkout
Account or token-protected guest session
- 02
Server validation
Branch, prices, checkout intent, authorization
- 03
Payment verification
Verify provider facts; reconcile duplicate callbacks
- 04
Restaurant operations
Branch-scoped queues and reactive order tracking
02 / Design decisions
Where the architecture earns its keep.
Pricing belongs on the server
The backend freezes checkout pricing and creates orders idempotently. Server-issued order numbers and checkout fingerprints prevent the browser from becoming the source of truth.
A callback is a signal, not proof
Provider amount, currency, reference, tracking ID, and status are verified before payment is accepted. The verified payment fact is persisted before order materialization, with reconciliation for interrupted work.
Authorization follows the branch
Viewer, operator, manager, and administrator roles govern restaurant actions. Customer details are retrieved when an authorized operator opens an order, rather than broadcast across the workspace.
03 / Verification & scope
Failure is part of the specification.
The implementation accounts for duplicate callbacks, repeated checkout submissions, and late or conflicting payments. Conflicting payment facts are held for review; bounded retries and reconciliation handle recoverable failures.