Platform
The infrastructure behind the storefront.
One backend powers Backoffice, POS and Guests — the same OAuth2, REST and SignalR services underneath every screen. Real-time by default, multi-tenant by sub-merchant, and open at the edges through a Partner API and outbound webhooks. Serious enough to run more than one site.
The problem
A stack of apps that don't talk, integrations you babysit, and data that quietly drifts
Most hospitality stacks are three vendors stapled together — a POS here, a QR ordering tool there, a payments box that syncs on a schedule. The seams are where you lose money and trust.
Menus out of sync
The price you changed on the till never reaches the QR menu the guest is looking at.
Integrations you maintain
Every connector is one more thing that breaks on a Friday night and lands on you.
One site is the ceiling
Adding a second location means a second stack, second logins, and reconciliation by hand.
Live sync
Change it once — it's everywhere before you look up
When an entity changes, SignalR pushes a cache invalidation and every connected app re-fetches on its own. No export, no refresh, no waiting.
Make a change
The spine
The spine underneath every screen.
Four ideas do the heavy lifting: one core, real-time push, tenant isolation, and open edges. Everything else is built on top of them.
- 01 Core
One core behind every screen
Backoffice, POS and Guests share the same services — OAuth2, REST and real-time SignalR, with background jobs and an event bus underneath — so there's a single source of truth, not three that argue.
- 02 Sync
Push, don't poll
SignalR pushes cache invalidations the instant an entity changes, and each app re-fetches automatically. If a device drops off, a ~30-second poll catches it back up.
- 03 Isolation
Multi-tenant by sub-merchant
Every API call is scoped to the active sub-merchant, so one site never bleeds into another. Add a location as configuration — no new stack to stand up alongside the last one.
- 04 Connect
Open at the edges
POS integrations, acquirer and delivery configs, a dedicated Partner API and outbound webhooks — the platform plugs into what you already run instead of walling you in.
What you're actually buying
Infrastructure you can build a business on.
A proper multi-tenant platform you can connect to, pair devices against, and run across more than one site.
One backend, three apps
Backoffice for config, POS with a built-in KDS mode, and the QR Guests app — one set of shared services underneath, from auth to real-time to ESC/POS printing.
Real-time via SignalR
Cache invalidations are pushed on every entity change and apps re-fetch instantly — a guest's QR order lands on the POS and kitchen live, with a ~30s polling fallback.
Multi-tenant by sub-merchant
Every request is scoped to the active sub-merchant, so one site never leaks into another — run a single location or a whole group on the same backend.
OAuth2, JWT & device pairing
A custom Quivi.OAuth2 server on ASP.NET Identity issues OAuth2 + JWT with automatic refresh. POS devices pair with a device-authorization code from Backoffice, then run on a JWT with no re-login.
Integrations, Partner API & webhooks
Quivi-native POS integrations, acquirer configs (Cash, Paybyrd, Revolut Pay, Apple Pay) and delivery — plus a separate Partner API and outbound webhooks for BI and aggregators.
Sales-tax-ready invoicing
Locale- and tax-aware across every location you operate, with EIN validation, ZIP codes and currency, Quivi-native invoicing, and full refund traceability.
Run one site or a whole group — no cross-tenant bleed.
Every API call is scoped to its sub-merchant, and the POS reloads whenever the active tenant changes to keep every cache consistent. Adding a location is configuration in Backoffice, not a second stack to stand up and reconcile.
One backend · many sites · scoped per request
The connective tissue
One backend, every Quivi surface.
Point of Sale, Payments and the AI Assistant aren't bolted-on products — they're surfaces on this same backend, reading the same real-time truth. Configure it once in Backoffice and that's what the floor sells, what the terminal charges, and what the assistant acts on.
See the platform, end to end
Bring your architecture questions — multi-site, auth, webhooks, fiscal. We'll walk the architecture and show how your stack connects.