POS operations guide
Restaurant QR ordering: test every scan, order and handoff
A QR code and two API routes do not prove a dependable ordering service. Freeze the exact public web, API, branch, menu, table, kitchen and payment configuration, then retain evidence from scan through close before serving customers.
Evidence and review scope
Evidence reviewed 2026-08-20. Pinned QR catalogue and order route, controller, service, repository and test review; eight accessQr-named tests passed; two selected QR-order guard cases passed while the selected successful-order case failed; five supporting API suites passed 486 tests; two exact Search Console query rows produced eight impressions and zero clicks; and official W3C, OWASP, PCI SSC, NIST and GNU sources.
Stable release: v1.3.0, source commit b531ef4. No complete public customer UI, hosted menu, accepted authorization and abuse-control configuration, scan-to-order transaction, kitchen output, online payment, accessibility result, service period, outage recovery, clean restore, customer deployment or local support operation was found or executed.
What the current evidence establishes
Catalogue and order source paths exist
The pinned release contains a public-facing catalogue access path and a QR-order repository path. The catalogue path can return branch-scoped products and table-order configuration; the order path loads item records and calculates price and tax from stored data.
Eight accessQr tests passed
Three selected suites passed eight tests whose names match accessQr. They cover controller, service and repository success or failure boundaries, not a browser, hosted menu, real database, table scan or service period.
The selected order-success test did not pass
Two qrOrderModel guard cases passed, while the selected successful-order case returned false. The broader six-suite selection passed 540 tests and retained six failures. No complete QR order is accepted from this result.
Public API exposure remains a deployment decision
The reviewed routes are intentionally registered before normal session protection. Exact branch pairing, authorization, rate limits, input validation, object scope, logging and abuse behavior were not accepted on a deployed public API.
No public customer interface was found
Targeted source search found API, documentation and tests but no complete customer QR menu frontend in the pinned release. A custom or separately hosted screen must be versioned and tested as its own product surface.
Search evidence is small and query-only
The supplied Search Console export contains two exact QR-order rows: qr order and qr ordering system malaysia. Together they produced eight impressions and zero clicks, with no landing-page, country, device, position, date-range or conversion dimension.
Match every QR-ordering promise to an observable record
Treat the printed code, browser, public web application, API, POS, kitchen device and payment provider as separate systems until the exact handoffs are accepted.
| Control | Minimum record | Current Posnic evidence | Acceptance decision |
|---|---|---|---|
| Code and location identity | Versioned QR value, branch, table or pickup point, issue date, status and replacement history. | Branch and table inputs exist in source; no printed-code inventory or scan result was accepted. | Scan valid, copied, stale, moved, damaged and duplicate codes and reject every wrong mapping. |
| Public access and scope | Authentication or pairing rule, branch scope, object authorization, rate limit, input limits and audit owner. | Public-facing routes exist; their deployed security and abuse behavior was not accepted. | Complete threat review and adversarial tests before exposing the API to customer devices. |
| Menu authority | Menu version, item ID, display name, description, price, tax, availability and responsible publisher. | The catalogue repository reads stored item data; no hosted menu freshness result was accepted. | Compare the customer view with the authoritative POS records and retain the exact version. |
| Order identity and retry | Client action ID, server order ID, received time, attempt count, result and duplicate-control record. | An order repository path exists; no accepted idempotency or retry result was established. | Replay duplicate, delayed and out-of-order requests and require one durable business outcome. |
| Staff and kitchen handoff | Approval, route, KOT or display reference, output state, reprint, change and cancellation trail. | The order source seeds a KOT-style change record; no physical output or staff workflow was exercised. | Trace every accepted line to one visible kitchen outcome and reconcile corrections. |
| Payment and settlement | Provider payment ID, authorization, pending result, capture, refund, fee, payout and accounting reference. | Payment-related fields exist; no approved customer payment or settlement was executed. | Keep payment data in the approved provider flow and reconcile every order, refund, fee and payout. |
| Personal data | Purpose, fields, notice, access, retention, correction, deletion and incident owner. | Customer phone and notes can enter the order record; no deployed privacy result was accepted. | Collect only approved fields and verify every lifecycle control under applicable rules. |
| Accessibility and assistance | WCAG test results, browser and assistive-technology matrix, language, timeout and staff-assisted alternative. | No customer interface or accessibility assessment was found. | Test the complete interaction on representative devices and keep an equivalent assisted path. |
| Outage and recovery | Dependency map, stopped state, queued or rejected work, retry owner, recovery time and duplicate check. | No hosted dependency failure or QR backlog recovery was exercised. | Remove each dependency separately and recover without unexplained orders or charges. |
| Close and restore | Known orders, POS and kitchen records, payment settlement, exceptions, backup, clean restore and approvals. | No complete service period, reconciliation or clean restore was accepted. | Approve only after independent totals agree and the required records survive a clean restore. |
Practical workflow
Give every printed code a lifecycle
A code is a credential-like pointer into an ordering context. Record who issued it, which branch and table it resolves to, when it became active, when it was replaced and how staff identify a copied, moved or stale code.
Keep one menu authority
The customer view, POS item record, tax rule, availability decision and kitchen name must share stable item identities. Do not rely on display-name matching or assume a successful page load proves freshness.
Make retries produce one business result
Mobile networks repeat requests. Assign a client action ID and server order ID, then test duplicates, delays, timeouts and responses lost after commit so one basket never becomes two orders or charges.
Separate order acceptance from kitchen output
Received, validated, approved, sent, printed, displayed, acknowledged, changed, cancelled and failed are different states. Keep the order visible until staff resolve every failed handoff.
Keep payment inside its approved boundary
A payment label is not authorization or settlement. Use the provider's approved customer flow, preserve provider references and reconcile pending, declined, captured, refunded, disputed and paid-out states.
Design the fallback before service
Customers need a visible staff-assisted path when a phone, browser, network, API, payment service or kitchen output fails. Recovery must not silently replay an order that staff already entered manually.
An eight-step QR ordering acceptance path
Use synthetic customers, items and payments in a disposable environment. Keep the result unverified until another person can reproduce every retained outcome.
Freeze the implementation
Record the QR value, public web build, API deployment, source commit, branch, table map, menu version, devices, providers and owners.
Prove code identity
Scan valid, copied, stale, moved, damaged and duplicate codes and verify the resolved branch, table or pickup point.
Reconcile the menu
Compare customer-visible items, descriptions, prices, taxes, availability, modifiers and food-information references with the approved source.
Attack the public boundary
Test authorization, branch and object scope, malformed input, quantity limits, rate limits, enumeration and logged rejection behavior.
Exercise order states
Run normal, changed, invalid, duplicate, delayed, timed-out and cancelled baskets with stable client and server identities.
Trace the kitchen outcome
Follow each accepted line through staff review, POS record, route, output, reprint, correction and cancellation.
Reconcile payment and close
Match provider authorization, pending, capture, refund, fee and payout records to orders, POS totals and exceptions.
Break, restore and approve
Remove dependencies, recover without duplication, restore an off-machine backup cleanly and obtain named approval for all 24 controls.
What the QR-ordering pilot must include
Hardware
- Printed or displayed QR codes with a controlled inventory and replacement history.
- Representative customer phones, browsers, screen sizes and assistive technologies.
- Exact POS computer, kitchen printer or display, receipt printer and staff device.
- Approved payment device or provider test environment when customer payment is in scope.
- Network and power interruption methods that do not endanger production records.
- Separate clean environment and off-machine backup destination for recovery testing.
Software and data
- Versioned public menu build, API deployment, Posnic release and pinned source commit.
- Branch, table or pickup identity map plus issued, replaced and revoked QR records.
- Authoritative item, price, tax, availability, modifier and food-information data.
- Authentication or pairing, authorization, rate-limit, validation, idempotency and audit controls.
- Order, staff approval, POS, KOT or display, status, change and cancellation states.
- Payment-provider references and reconciliation exports without unnecessary card data.
- Privacy, accessibility, monitoring, support, backup, restore and incident procedures.
Setup sequence
- Name the restaurant, branch, service modes, tables or pickup points, target users, objective, stop rule and accountable owners.
- Record the exact release, source commit, public web build, API deployment, database, browser matrix and kitchen devices.
- Create a synthetic menu with available, sold-out, modified, taxable, discounted and deliberately invalid items.
- Inventory every QR code and verify issue, replacement, revocation and physical placement controls.
- Approve the public API authentication, branch scope, object authorization, input limits, rate limits, logging and alerts.
- Define client action IDs, server order IDs and duplicate behavior before testing unstable connections.
- Run staff approval, direct-routing, failed-output, reprint, changed-item and cancellation scenarios.
- Test pending, declined, successful, cancelled and refunded payments and reconcile provider evidence.
- Approve personal-data purpose, fields, notice, access, retention, correction, deletion and incident handling.
- Test WCAG 2.2 criteria, representative mobile browsers, slow connections and the staff-assisted alternative.
- Remove the public web, API, database, network, payment and kitchen dependencies separately and recover safely.
- Reconcile a known service set, restore off-machine backup data on a clean environment and record named sign-off or open gaps.
What each person sees
Customer
Needs the right table and menu, clear totals, accessible errors, one order result, trustworthy payment state and an obvious way to ask staff for help.
Service and kitchen staff
Need visible new, changed, cancelled and failed orders with stable table and order identities, no silent duplicates and a controlled reprint path.
Technical and security owner
Needs scoped access, validation, rate limits, idempotency, logs, alerts, dependency health, recovery and evidence for rejected requests.
Business, payment and privacy owners
Need current menu authority, approved data purpose, order and settlement reconciliation, exceptions, retention, support and signed rollout decisions.
Mistakes to avoid
Avoid these during rollout
- Calling API routes a complete customer QR-ordering product.
- Printing codes without an issue, replacement and revocation inventory.
- Trusting a table or branch value supplied by the browser without accepted scope controls.
- Publishing a second menu that drifts from POS price, tax and availability records.
- Letting a retry create a duplicate order, KOT, charge or manual re-entry.
- Marking payment paid from a client label instead of provider evidence.
- Sending every received request directly to the kitchen without a defined abuse and correction policy.
- Collecting phone numbers or notes without purpose, access and retention decisions.
- Treating an automated HTML scan as a complete mobile accessibility result.
- Launching without dependency failures, independent reconciliation, clean restore and named exception owners.
Run the 24-control QR-ordering acceptance record
Keep configuration, observed result, evidence, owner review and decision fields blank until the exact public web, API, POS, kitchen and payment implementation is exercised.
Primary sources used
Posnic v1.3.0 release
Stable public release used for the package and product boundary.
Pinned Posnic source tree
Exact source commit used for every implementation and test statement on this page.
Pinned catalogue route
Route source exposing the reviewed public-facing accessQr boundary.
Pinned catalogue repository
Source for branch lookup, product projection, configured table data and the reviewed catalogue boundary.
Pinned QR-order route
Route source exposing the reviewed qrOrder boundary before normal protected sales routes.
Pinned QR-order repository
Source for branch and item lookup, stored price and tax calculation, order record construction and KOT-style changes.
Pinned catalogue tests
Repository tests containing the selected accessQr cases cited by the review.
Pinned QR-order tests
Repository tests containing the two passing guard cases and the retained failed success case.
GNU AGPL-3.0 license
Primary license text for the open-source release; it does not certify a hosted service or implementation.
W3C WCAG 2.2
Current W3C Recommendation used to structure accessible names, roles, focus, errors, target size and status-message tests.
OWASP API Security Top 10 2023
Primary awareness source for object authorization, authentication, property authorization, resource consumption and sensitive business-flow risks.
PCI Data Security Standard
Primary payment-security baseline for entities that store, process, transmit or can affect payment account data.
NIST Privacy Framework
Voluntary risk-management framework used to structure data purpose, processing, access and privacy review.
NIST contingency planning
Primary recovery-planning guidance used to structure dependency, fallback, recovery and restore tests.
Questions
What QR-ordering evidence exists in Posnic v1.3.0?
The pinned source contains catalogue-access and QR-order paths. Eight accessQr-named tests passed. Two selected QR-order guard cases passed while the selected successful-order case failed.
Does Posnic v1.3.0 include an accepted public QR menu?
No complete public customer UI, hosted deployment or scan-to-close service period was found or accepted in this review.
Does source code prove a QR order reaches the kitchen?
No. Trace staff approval, durable POS identity, route, printer or display output, reprint, change, cancellation and failed-output recovery on the exact implementation.
How should duplicate scans and retries be handled?
Use a stable client action ID and server order ID or equivalent control, then prove repeated and delayed requests create one business result or one clear rejection.
Can the customer pay from the QR page?
Only after the exact provider, merchant account, hosted flow, authorization states, refund, settlement, security and outage behavior are accepted.
What personal data should a QR order collect?
Only fields with an approved purpose and documented notice, access, retention, correction, deletion and incident process. A table order may not need a customer phone number.
Which accessibility standard applies to the web menu?
WCAG 2.2 provides testable web-content criteria. Test the complete interaction on representative devices and assistive technologies and retain a visible staff-assisted alternative.
Does this guide certify a restaurant or country?
No. It supplies a reusable evaluation method. Current food, tax, payment, privacy, accessibility, consumer and record rules require accountable local review.
When is the implementation ready for rollout?
Only after all 24 controls have observed evidence, failures have owners, independent records reconcile, recovery and clean restore pass, and named business, technical, security, payment, privacy and local reviewers approve it.
Where Posnic fits
Posnic v1.3.0 exposes bounded catalogue and QR-order source paths. Eight accessQr-named tests passed; two selected QR-order guard cases passed while the selected successful-order case failed. This review does not establish a public customer UI, hosted menu, accepted security controls, complete order, kitchen output, payment, accessibility result, service period, outage recovery, clean restore, customer deployment or local support operation. Use the 24-control record on the exact implementation before production.