POS operations guide
Restaurant self-ordering kiosk software guide
A restaurant self-order kiosk is a complete order path, not only a touch screen. Prove the menu, required choices, payment state, POS record, kitchen route, customer proof, staff exceptions and close together before rollout.
Evidence and review scope
Evidence reviewed 2026-08-18. Pinned source review plus 67 kiosk-named API tests and 24 configuration and route tests.
Stable release: v1.3.0. No customer order, provider payment, kitchen output, accessibility audit or complete shift was accepted on physical kiosk hardware.
What the current evidence establishes
91 focused tests passed
At exact source commit b531ef4308c4dc3a25f250551a54fc5616e3b8d9, 67 kiosk-named API tests and 24 configuration and route tests passed with zero failures.
Documented POS-side scope
The pinned user guide describes a Catalog Display / Kiosk, while the source contains branch kiosk settings, item availability, kiosk order processing and kiosk report paths.
67 kiosk-named API tests passed
Nine focused controller, model, repository and service suites passed 67 kiosk-named tests with zero failures. They exercise code boundaries, not a customer-facing terminal or live provider.
24 configuration and route tests passed
Ten kiosk-column tests and fourteen public-route tests passed. They cover branch visibility, guarded routes, constant-time key comparison and closed-by-default behavior.
Security boundary
Anonymous kiosk and kitchen routes stay closed unless a kiosk key is configured and presented. Passing focused tests is not an independent security or penetration assessment.
Unproven in this review
No touchscreen, scanner, unattended payment terminal, customer printer or kitchen device was connected, and no end-to-end kiosk order or shift was executed.
Restaurant self-order kiosk versus retail self-checkout
The supplied Search Console data mixes several meanings of kiosk. Assign each workflow to one page and one acceptance owner instead of promising that one screen covers every use.
| Search intent | Customer task | Operational proof | Posnic owner |
|---|---|---|---|
| Restaurant self-order kiosk | Choose menu items and modifiers then place or pay for an order | Menu state, payment outcome, POS identity, kitchen route, token and close | This restaurant kiosk guide |
| Retail self-checkout | Scan or weigh merchandise and complete a retail basket | Barcode and price data, weighing, loss exceptions, payment, stock and supervision | Retail self-checkout guide |
| Payment or public-service kiosk | Pay a bill, buy a ticket, check in or use another public service | Provider-specific hardware, identity, payment, receipt, accessibility and regulation | Outside this guide and not a current Posnic offer |
Practical workflow
Separate the four systems
Treat the customer kiosk, POS record, payment terminal and kitchen output as separate components with an explicit contract between them. A successful tap is not yet a completed sale.
Design for first-time users
Keep categories short, show prices and required choices before payment, provide a clear back path and make staff assistance visible. Test alternatives to fine touch and the exact installed reach and viewing conditions.
Exceptions decide reliability
Test sold-out items, duplicate taps, payment decline, printer failure, network loss, cancellation, refund, reprint and abandoned orders before measuring queue speed.
Reconcile every source
Kiosk orders should be traceable by source, payment state, token, POS sale and kitchen outcome so day-close staff can find gaps without comparing notebooks.
Kiosk acceptance flow
Treat every arrow as a testable handoff. A deployment is not accepted until the business can trace one order through all seven steps.
Load the approved menu
The kiosk receives the intended branch, category, price, tax, modifier and availability data. Staff verify one item from each important rule.
Build and validate the order
Required choices, quantity limits, sold-out items and duplicate taps are handled before the order leaves the screen.
Resolve payment state
The design distinguishes paid, declined, cancelled, timed-out and pay-at-counter orders. Staff can see the same state.
Create the POS record
The accepted order has a durable POS reference, source, totals, tax, discounts and payment state. Retrying must not create a second sale.
Route preparation
The correct KOT printer or kitchen display receives the item, quantity, modifiers, token and source. A failed route becomes visible to staff.
Give the customer proof
The kiosk shows or prints a token and, when payment is captured, the required receipt. Staff can search and reprint it.
Reconcile the close
Kiosk order count, completed sales, payment settlement, cancellations, refunds, failed prints and open orders are compared before close.
Hardware and software required
Hardware
- Touchscreen and enclosure tested at the installed height, angle and lighting.
- Receipt or token printer with accessible paper replacement and a visible failure state.
- Payment terminal supplied and supported by the merchant's acquirer when payment is accepted at the kiosk.
- Kitchen printer or display tested with the exact network and routing configuration.
- Network equipment whose failure and recovery behavior has been rehearsed.
- Power protection and a staff fallback for kiosk, POS, network and kitchen devices.
Software
- Versioned menu and modifier data with a named owner for price, tax and availability changes.
- Customer front end that supports keyboard or alternative input as well as touch where required.
- Documented payment handoff and duplicate-order protection.
- Token, receipt, search and reprint controls.
- Staff controls for help, cancellation, refund, unavailable items and failed output.
- Reports that reconcile kiosk source, POS sale, payment and kitchen outcome.
Setup sequence
- Start with one supervised kiosk and one branch. Record the software, hardware, payment and network versions used for acceptance.
- Test a short representative menu, including tax, modifiers, sold-out items, a discount and an item routed to each preparation station.
- Use WCAG 2.2 and the informative WCAG2ICT guidance to test contrast, focus, input, error recovery and target size. Confirm the actual legal and accessibility requirements for the market and installation.
- Complete paid, declined, cancelled, timed-out and pay-at-counter paths without leaving an unexplained POS or payment record.
- Disconnect each dependency in turn: kiosk network, POS, payment service and kitchen output. Verify the staff fallback and recovery path.
- Test cancellation, refund, duplicate tap, reprint, paper-out, sold-out item and staff override with the people who will handle them.
- Close a mock shift by reconciling kiosk orders, POS sales, payment settlement, kitchen output and refunds.
- Run a supervised pilot before buying more terminals, then review failed orders and interventions rather than only kiosk sales.
What each person sees
Customer
Can understand choices, correct mistakes, request help, know whether payment succeeded and receive a searchable token or receipt.
Counter staff
Sees order and payment state, pauses unavailable items, handles exceptions and recovers failed prints without creating duplicate sales.
Kitchen
Receives an unambiguous item, quantity, modifier, token and source, with a visible recovery path when output fails.
Owner
Reconciles kiosk orders to POS sales and payment settlement, then measures completion, failure and staff-intervention rates.
Mistakes to avoid
Avoid these during rollout
- Buying several terminals before one complete order and close can be reconciled.
- Treating a successful payment screen as proof that the POS sale and kitchen output also succeeded.
- Using small controls, touch-only interactions or error messages that do not explain recovery.
- Allowing retry logic to create duplicate orders or charges.
- Hiding printer, network or payment failures from staff.
- Assuming a standards-based device or source-tested route is physically certified.
- Calling a restaurant order kiosk retail self-checkout, or claiming payment and public-service kiosk support from a restaurant workflow.
Run the 24-record restaurant kiosk worksheet
Record the exact branch, kiosk, menu, payment setup, kitchen route, accessibility review, dependency failures and closing evidence. Observation and pass fields remain blank until the installed system is exercised.
Primary sources used
Posnic v1.3.0 release
Stable public release used for the pinned product review.
Posnic v1.3.0 user guide
Pinned documentation for the Catalog Display / Kiosk scope.
Posnic API route inventory
Pinned route inventory for item access, kiosk orders, kiosk reports and kiosk settings.
Posnic hardware matrix
Pinned customer-display, kiosk, printer and payment-terminal support boundaries.
Focused Posnic route tests
Exact kiosk-column and public-route tests used for the 24-test result.
W3C WCAG2ICT
Current informative guidance for applying WCAG 2 concepts to non-web software and closed-functionality kiosks.
PCI PTS Point of Interaction
Primary device-standard overview that includes Unattended Payment Terminals as a supported category.
NIST contingency planning
Primary recovery-planning model used to structure dependency, fallback and recovery tests; it is not presented as a restaurant legal requirement.
Questions
Does Posnic v1.3.0 include restaurant kiosk support?
The pinned release documents a catalog display or kiosk and contains kiosk settings, item controls, guarded routes, order-processing paths and reports. Ninety-one focused tests passed, but this review did not execute a complete customer order on physical kiosk hardware.
Is a restaurant self-order kiosk the same as retail self-checkout?
No. A restaurant kiosk builds a menu order and routes it to preparation. Retail self-checkout scans or weighs merchandise and needs retail exception, stock and supervision controls. Posnic keeps those evaluation intents on separate guides.
What should be tested before a restaurant kiosk goes live?
Test menu rules, accessibility, payment outcomes, duplicate prevention, POS recording, KOT routing, receipt or token output, staff overrides, dependency failures and end-of-day reconciliation.
Does WCAG 2.2 certify an installed kiosk?
No. W3C's WCAG2ICT note explains how WCAG concepts can inform non-web software and closed-functionality kiosks, but it is informative guidance. Test the complete installed hardware and software against the applicable market requirements.
Is an unattended payment terminal included with Posnic?
No accepted integrated unattended terminal is established by this review. PCI SSC lists Unattended Payment Terminals as a PTS POI device category. Confirm the exact device, integration, acquirer requirements and card-data scope with the payment parties.
Can a kiosk continue when internet or another dependency fails?
Do not assume it can. Test the exact kiosk, POS, payment and kitchen architecture. A local POS may reduce one dependency, while online payment and connected ordering can still require network services.
Where Posnic fits
The pinned Posnic release provides documented POS-side kiosk settings, item controls, guarded order routes and kiosk reporting paths. Ninety-one focused tests establish source and unit-test boundaries only. Posnic v1.3.0 does not have an accepted bundled customer kiosk, integrated unattended payment terminal, physical kitchen output, accessibility conformance report, complete shift, regional compliance package or worldwide onsite service promise. Run the worksheet on the exact implementation before production.