CenterPoint POS · In build · Heading into its first restaurants
The internet goes down. Service does not.
An iPad point of sale for Hong Kong restaurants. Ordering, the kitchen screen, table state, cash and the end-of-day close all run over the restaurant's own Wi-Fi, directly between the iPads.
Status
Venues live
0 — we are choosing the first now
Card payments
Built, awaiting hardware validation
What it needs
Roughly three or more iPads per venue, and your own Wi-Fi
Launch date
Not set. We would rather be late than wrong in service.
The kitchen display: live tickets with aging timers, station tabs and a banner on anything modified mid-service. A real capture from the iPad app.
| Stage | What happens | The rule behind it |
|---|---|---|
| 01 OPEN | Open the day | A counted float goes in before a single order can be taken. |
| 02 SEAT | Seat and order | Seat a party from the floor, take the order with modifiers, combos and courses, fire it to the kitchen. |
| 03 COOK | Cook the board | Tickets land on a kitchen screen with aging timers, station tabs and a banner on anything modified. |
| 04 SETTLE | Settle the bill | Service charge per check, cash rounding, split by item, merge two checks, refunds with a reason. |
| 05 CLOSE | Close it out | Count the drawer by denomination, over and short as you type, End of Day with a blocker checklist. |
3+
iPads per venue
Come and break it before your guests do.
We are choosing our first restaurants now. Tell us how your service runs and we will tell you honestly what is ready and what is not.
Why it holds
No cloud in the critical path.
Every iPad holds the whole day
Each device carries a complete ordered record of the venue's service and replays it identically. Any server can act on any table from any iPad, and no single device is the only copy of anything.
It tells staff the truth about itself
Synced, catching up, or offline with a count of orders waiting. A mis-routed kitchen item raises a visible warning instead of disappearing, and a device that cannot keep up says so on every screen.
Recalculated, not reported
The server recomputes all money from the underlying record of what happened rather than trusting a total sent by an iPad, and compares the two.
Nobody moves money anonymously
Discounts, voids, refunds and moving an order all take a manager PIN and a recorded reason, scoped to that one action. The day panel shows voids broken out by reason.
Where it stands today
What is built, and what is not.
Built and running today
- Floor plan, seating, moving and linking tables, takeaway alongside dine-in
- Modifiers, combos, courses, custom and open-price items, time-of-day menus
- Kitchen display with stations, aging timers, mirror rows and recall
- Split and merge checks, service charge, cash rounding, itemised refunds
- PIN lock, time clock, deny-by-default permissions, full attribution
- A browser back office to provision iPads, publish prices, roll back a change and export CSV
Not yet, and we will say so
- Card payments are built against the terminal's network protocol and are awaiting hardware validation
- FPS and Octopus are recorded as tenders; the merchant's own reader takes the money
- Guests are read a receipt number today; there is no printer and no digital receipt
- Built to run several restaurants at once, but never yet run with more than one
- Venue setup, floor plan and menu structure are still done for you, not self-serve
Also from CenterPoint
CenterPoint Marketplace
Order from your suppliers in one app and settle one invoice per supplier per month. A separate product, launching in Hong Kong.
See the Marketplace
Tell us what you order, and from whom.
We will tell you honestly whether your suppliers are on the platform yet, and what it takes to get them there. No sales script, no obligation.
Email us directly
CENTERPOINT
Support
Privacy Policy
Terms of Service
CenterPoint is a trading name. Hong Kong. [email protected]