Kiosk Ordering System: How a Self-Order Kiosk Connects to Your POS

A kiosk ordering system is a new ordering channel into your restaurant’s point-of-sale (POS): it reads the menu, modifiers, prices and stock-outs from the POS and posts each paid order back, so the kitchen display (KDS) sees it exactly like a counter order. Five things decide whether it works: automatic menu sync, modifier rules the POS will accept, reliable order injection, payments that reconcile against orders, and a defined rule for when the network or POS is down. The kiosk connects either directly through the POS vendor’s ordering API or through middleware. POS vendors’ API access policies vary, so confirm in writing that a third-party kiosk may read the menu and post orders and payments before you buy hardware. KioskForce builds this as a project-scoped REST API integration, not a certified off-the-shelf connector.

Updated 27 October 2026.

What a kiosk ordering system actually connects to

A restaurant kiosk system has three parts: the kiosk (screen, enclosure, payment terminal, printer), the ordering software running on it, and the integration that ties both to your point-of-sale (POS) and kitchen display system (KDS). Buyers spend most of their time choosing the first part. Projects succeed or fail on the third.

The kiosk does not replace the POS. It is a new ordering channel into the POS, like a cashier who never gets tired. Everything the kitchen, the accountant and the stock system rely on still lives in the POS. If you are still deciding whether a kiosk suits your restaurant at all, start with the self-order kiosk guide. This page covers the integration in detail.

The data moves in two directions:

Direction What moves How often
POS → kiosk Menu items, categories, modifier groups, prices, tax rules, item availability (86’d items), store hours On every menu change, plus a scheduled full refresh
Kiosk → POS Order lines and modifiers, order type (dine-in or takeaway), customer name or table number, payment reference On every paid order
POS → kiosk Order number, order accepted or rejected, optionally order status for a pickup screen Within seconds of each order
POS → KDS The order, flagged as a kiosk order, routed to the right station As for any counter order

If staff must update a price in the POS and again in the kiosk, the two will drift, and a customer will eventually pay one price on the screen and see another on the receipt. The kiosk should read its menu from the POS, not keep its own copy.

What to check:

  • Kiosk-only content. Photos, longer descriptions, allergen and calorie text and upsell rules usually don’t live in the POS. Decide where they are stored and who maintains them. A common pattern is that the POS owns items, prices and availability, and the kiosk’s content manager adds photos and copy against each POS item ID.
  • Stock-outs. When the kitchen marks an item unavailable at the POS, it should grey out or disappear on the kiosk within seconds, not at the next nightly sync.
  • Day-parts and store hours. Breakfast menus, happy-hour prices and closing times need to come from the POS too.
  • Multiple sites. Chains need to know whether each site’s menu and prices sync separately.

Modifiers: where most integrations get difficult

Modifiers are sizes, sides, extra toppings, “no onion” and combo upgrades. The POS defines them as groups with rules: choose exactly one size, up to three toppings, a free first sauce and a charge for the second. The kiosk must build an order that obeys every rule, or the POS rejects it.

Test these cases before launch: nested modifiers (a combo containing a burger containing toppings), required groups, price changes inside a combo, half-and-half items, and free-text notes. Free text is best avoided at a kiosk. Where it is offered, check that it reaches the kitchen ticket.

Order injection: getting the order into the POS

“Order injection” means the kiosk posts a paid order into the POS through its API. The POS then routes it to the KDS or kitchen printer, records sales and tax, and returns an order number.

  • The POS must accept the order before the customer leaves. The kiosk should wait for the POS to confirm the order and only then print the receipt with the order number.
  • Flag the channel. Kitchen staff and reports should show that the order came from the kiosk, and whether it is dine-in or takeaway, because packaging and sometimes tax depend on it.
  • Don’t bypass the POS. A kiosk that prints straight to the kitchen printer without posting to the POS leaves sales, stock and tax unrecorded. It is a second till, not an integration.

Payment reconciliation

Every kiosk order is paid before it is sent, so every order needs a matching payment. There are two common designs:

Design How it works Trade-off
POS-integrated terminal The kiosk asks the POS’s payment service to take the card payment; payment and order are recorded together Simplest reconciliation; only possible if the POS vendor supports payments from a third-party kiosk
Separate kiosk terminal The kiosk’s own terminal and acquirer take the payment; the kiosk posts the order to the POS as paid with an external payment reference Works with more POS platforms; you reconcile acquirer settlements against POS orders, and refunds happen at the acquirer, not the POS

Either way the terminal must be approved for unattended use. The PCI Security Standards Council’s PTS POI standard (accessed 27 October 2026) lists unattended payment terminals as a device category. A terminal that encrypts card data itself keeps card numbers out of the kiosk software and reduces your PCI DSS scope. On KioskForce kiosks the payment device is specified per project; see payments for the options.

Offline behaviour: decide the rule before launch

Networks drop and POS servers restart. Decide in advance what the kiosk does:

  • Stop and show an out-of-service screen. Most operators choose this, because it never takes money for an order the kitchen cannot see.
  • Queue orders locally and send them when the connection returns. This keeps the kiosk selling, but you need a printed kitchen ticket as a backup, a way to stop selling items that have run out, and a process for payments that were approved but never reached the POS.

Wired Ethernet to each kiosk position is the most reliable link. KioskForce kiosks have Ethernet with optional Wi-Fi or 4G/5G, which can serve as a fallback.

Direct API or middleware?

  Direct POS API integration Middleware or ordering hub
Best for One POS brand with an open ordering API Several POS brands across sites, or a POS that only approved partners may access
Moving parts Kiosk and POS Kiosk, middleware and POS
Running cost No extra subscription Usually a monthly fee per site
Who fixes it The kiosk integrator Split between the middleware provider and the kiosk integrator
Risk Rework if you change POS Another system that can fail or change its pricing

What to ask your POS vendor

Send these questions in writing before you choose kiosk hardware. POS vendors’ API access policies vary: some open their ordering API to any developer, some restrict it to approved partners, some charge for access, and some older systems have no ordering API at all.

  1. Is there a documented API to read the menu, modifiers, prices and availability?
  2. Can a third-party kiosk post orders, and can it mark them paid with an external payment?
  3. Is API access open, partner-only or paid? What does approval involve, and how long does it take?
  4. Are there webhooks for menu changes and stock-outs, or must the kiosk poll?
  5. Can orders carry an order type, a channel name and a customer name or table number through to the KDS?
  6. What are the rate limits, and is there a sandbox for testing?
  7. What happens to API access if we change our plan or the POS vendor changes its terms?

If the answers are “no ordering API” or “partners only, and you are not one”, fix the POS question first. A kiosk can’t solve it.

Where a custom kiosk integration is the wrong answer

  • Your POS sells its own kiosk app. Many platforms offer one on a standard tablet, integrated out of the box. For a single site that is usually cheaper and faster than any custom kiosk.
  • You need a POS-certified integration on day one. If a franchise agreement or your IT team requires a pre-certified kiosk for a specific POS, buy from a supplier that holds that certification.
  • Your POS has no ordering API, or won’t grant you access. No kiosk can post orders to the kitchen without one.
  • You change POS every year or two. Each change means rebuilding the integration.

How KioskForce handles POS integration

Question KioskForce answer
Integration approach Project-scoped REST API integration against your POS’s API, or through middleware you already use
Certified POS integrations None claimed with named POS vendors
Software Android ordering software designed in-house; integration scope and timeline agreed before the order
Hardware Custom kiosk built to specification; standard K180-6C is a 21.5-inch kiosk, about 1830 × 750 × 400 mm, indicative USD 1,800 before freight, duties and installation
Lead time 4–6 weeks for a modified standard model, 8–12 weeks for a fully custom enclosure; software scoped separately
Support By email; installation is optional and done by your contractor or, in some regions, a local distributor

Before you integrate, check the site side as well: see what a restaurant needs for a self-service kiosk. Food courts with several kitchens add split tickets and settlement; see self-order kiosks for food courts, stadiums and food trucks.

Frequently asked questions

What is a kiosk ordering system?

A kiosk ordering system is the software and hardware that let a customer build and pay for an order on a touchscreen and send it to the kitchen. In a restaurant it is a channel into the point-of-sale (POS): it reads the menu, modifiers, prices and availability from the POS and posts each paid order back, so the order reaches the kitchen display or printer like a counter order.

How does a self-order kiosk send orders to the kitchen?

The kiosk posts the paid order to the POS through the POS vendor’s ordering API, either directly or through middleware. The POS then routes it to the kitchen display or printer, records the sale and tax, and returns an order number for the pickup screen. The kiosk should not print straight to the kitchen while bypassing the POS, because sales and stock would then go unrecorded.

Can any self-order kiosk work with any POS?

No. It depends on the POS vendor’s API. Some POS platforms open their ordering API to any developer; others restrict it to approved partners or charge for access, and some older systems have no ordering API at all. Ask your POS vendor in writing whether a third-party kiosk may read the menu and post orders and payments before you choose kiosk hardware.

Should a kiosk integrate with the POS directly or through middleware?

Direct integration has fewer moving parts and no extra subscription, and suits a single POS with an open ordering API. Middleware suits restaurants running several POS brands, sites with POS systems that only partners can access, or operators who want kiosk, web and delivery orders through one connector. Middleware adds a monthly fee and another system that can fail.

What happens to kiosk orders if the POS or internet goes down?

You choose the rule before launch. Most operators stop taking kiosk orders and show an out-of-service screen, so they never take payment for an order the kitchen cannot see. The alternative is to queue orders on the kiosk and send them when the connection returns, which needs a printed kitchen ticket as backup and careful handling of payments that were approved but never reached the POS.

Does KioskForce have certified integrations with POS vendors?

No. KioskForce does not hold certified integrations with named POS vendors. We scope the integration against your POS’s API and build it as a REST API integration for your project. If your franchise agreement requires a kiosk pre-certified for a specific POS, buy from a supplier that holds that certification.

Get started

Send us your POS name and version, the answers your POS vendor gave to the questions above, and your menu’s most complicated item. We’ll come back with an integration scope, a form factor and a payment option. More on the hardware is in the self-order kiosk guide and on the kiosks page.

Project brief · 60 seconds

What are we building together?

Three quick steps. Your brief goes straight to the engineers who design, build and support KioskForce systems.

1What are you building?
2Roughly how many units? (optional)
3Where should we send your proposal?

Prefer email? sales@kioskforce.com