Cloud QR ordering, integrated into an existing point of sale estate

Table ordering for venues that did not want to replace the system they already depend on, in an environment where connectivity cannot be assumed.

RoleArchitecture, integration, payments
Timeline11 weeks
StatusPilot
StackSambaPOS GraphQL API, Cloud middleware, Local bridge agent

The situation

Venues running an established point of sale wanted table ordering without replacing the system their staff already knew and their accountant already trusted. Orders were taken on paper, walked to a terminal and rekeyed, which cost time at the busiest hour of service and produced errors nobody could trace afterwards.

The constraint that shaped everything: internet connectivity in the venues could not be assumed. A design that stopped taking orders when the line dropped was not a design anyone would buy.

What I did

I scoped the integration with the venues and the point of sale vendor, designed the architecture, specified the payment flow against the partner agreement, and built and deployed the middleware and the local bridge agents. The commercial structure of the payment component was mine to define as well, which turned out to matter more than any of the engineering.

System diagram

Diagram
Diagram
FIG. 01 — ORDERS ARRIVE IN THE CLOUD, ARE HELD BY A LOCAL AGENT, AND ARE WRITTEN TO THE POS THROUGH ITS OWN API.

Key decisions and tradeoffs

Three decisions that shaped the build, the alternative in each case, and what the choice cost.

Decision 01RELIABILITY

A local bridge agent rather than a direct cloud to point of sale connection

ALTERNATIVEconnect the cloud service straight to each venue's point of sale over the internet.WHY NOTevery dropped connection becomes a lost order during service. The venue blames the new system, correctly.COSTsoftware now has to be deployed and maintained inside each venue, which is an operational burden a pure cloud design would not carry.
Decision 02COMMERCIAL

Fee handling designed around the payment partner agreement, not around the code

ALTERNATIVEpass transaction costs to the diner at checkout, which is the simplest thing to build.WHY NOTthe partner agreement prohibits it. This is a business analysis problem wearing a technical costume.COSTmargin has to be found in the venue's pricing instead, which made the commercial conversation harder and the compliance position sound.
Decision 03WOULD DO DIFFERENTLY

Integrating through the vendor's API rather than at the database layer

WHYwriting to the database directly is faster to build and breaks silently on the next vendor update.NEXT TIMEI would agree the menu synchronisation contract with the venue before building, rather than discovering each venue's naming conventions during rollout.

Current status

In pilot with two venues, taking live orders through service. Rollout to the wider estate is paused until menu synchronisation is automated, which is the next piece of work.

Scheduled next: automated menu sync with the point of sale, then a phased rollout to the remaining eleven venues through Q1.

Stack and timeline

Stack: SambaPOS GraphQL API, cloud middleware, local bridge agent, ABA PayWay, Cloudflare R2.

PhaseWorkDuration
DiscoveryVenue observation, vendor API review, payment agreement read2 weeks
SpecificationArchitecture, payment flow, fixed price scope1 week
BuildMiddleware, bridge agent, ordering interface, KHQR6 weeks
PilotTwo venues, staff training, live service2 weeks
SambaPOS GraphQL APICloud middlewareLocal bridge agentABA PayWayCloudflare R2

Have a system that half works and nobody wants to touch?

A systems review puts the situation, the cost and the options in writing.