Restaurant Commerce — Menu, Ordering, KDS, Kiosk and POS

Reven Ordering, KDS, Kiosk and POS use one menu, the same pricing rules and a shared order record. As a result, an item that is sold out or changed in the menu should not require a manual edit in every channel.

Menu

A user with menu:manage can manage:

• the location, menu, publication and category order;
• an item's name, SKU, description, price, compare-at price and image;
• Vege, Vegan, New and Bestseller labels and spice level;
• display of an item in additional categories;
• preparation stations;
• modifier groups and minimum and maximum selections;
• options, surcharge, default value, active status and sold-out status;
• order capacity, base lead time and delivery zones.

SKU is important for links between locations and vouchers for an exact item. It should be stable and unique within the customer's chosen model.

Ordering and order operation

The public customer or POS operator chooses dine-in, pickup or delivery available for the address or zone. In public Ordering, Kiosk and POS, this choice can be configured before the menu or at the end of the cart when the venue wants to collect items first. Items can be added in the chosen quantity immediately and then adjusted with minus/plus controls in the cart or current POS ticket. The server recalculates prices, quantities, modifiers, the delivery fee or another fulfilment fee, for example takeaway packaging, minimum, coupons, vouchers and the payment amount. Settlement must not rely on a value sent only by the browser.

On 2026-08-14 the public Ordering mobile visual change was reviewed: cart and add-item CTA buttons force text to primary-foreground so branded themes keep contrast. The change does not modify cart logic, checkout or order statuses.

On 2026-08-14 the public Ordering mobile category navigation change was also reviewed: the venue header scrolls with the page, while the category bar stays pinned at the top of the screen. The change improves access to categories while browsing the menu and does not modify cart behavior, checkout, payment or order statuses.

After a valid payment, an order can be accepted automatically or wait for staff. In manual mode, staff accept it and provide a promised time. A typical sequence is: paid → accepted → preparing → ready → completed. A refund requires orders:manage and a review of every tender and benefit used.

The order status page is private — it is entered with a token from the URL, and the token is never repeated in metadata — so it is set to noindex, nofollow. It shows the saved modifiers and charged fees from the order record so the customer can review choices after payment. When an order reaches completed, the page shows the embedded, private Guest Experience survey, but only when the guest_experience module is active and the order trigger is enabled. cancelled, refunded and all non-completed statuses show no survey. The page polls every few seconds and stops at a terminal status, so the survey appears on completion without a manual reload. A kiosk voucher purchase is technically a completed order but not a real meal, so the status page and the server-side resolver both skip it.

KDS

KDS shows active orders and items by preparation station. Staff with kds:operate update the work stage. The screen should run on a dedicated device, and the venue's procedure must cover a network outage and manual handoff of the order.

Kiosk

A guest can start a food order or — when configured — a separate voucher purchase. For food, the guest chooses or confirms the fulfilment mode, items and modifiers, can scan a Loyalty card, coupon or voucher, and then pays the remaining amount.

The Kiosks dashboard is used to enrol a device once and monitor its connection, terminal, fiscal printer, scanner, paper and latest error. The local agent communicates outbound with Reven and keeps the device secret outside frontend code.

In production, the terminal adapter must support status, idempotent start, result query, reversal and refund; the fiscal adapter must support device status, paper, fiscalisation and result verification. An ambiguous result must be checked against the provider reference. Do not start a second payment “blindly.” A paid order is released only after required fiscalisation when that flow is active.

POS

POS uses the shared menu for counter orders, phone orders and orders manually copied from a marketplace. For a user with multiple locations, POS opens a location with an available menu; a manually selected location without a menu sends staff to menu configuration. POS can have its own pos product configuration and inherits missing fields from ordering, so the fulfilment-choice step and fees can stay shared or be separated for POS. Terminal-payment availability depends on the deployed provider and device. When entering an external order, staff should preserve its reference and not create a parallel online payment.

Solution boundaries

Reven v1 is not, by itself, a certified Polish fiscal cash register. The customer retains the legally required fiscal process unless the implementation scope includes a specific approved integration. Drivers in the agent package may be simulators; production status must be confirmed for the specific terminal and printer.

Pre-launch checks

1. Place a dine-in order, pickup order and an order for every delivery zone.
2. Check the base price, modifiers, fee, minimum, voucher/coupon and remaining payment.
3. Test successful payment, declined payment, repeated webhook and refund.
4. Check automatic and manual modes, KDS and the promised time.
5. On a real kiosk, check idle/reset, scanner, terminal, fiscalisation, paper-out state, network loss and recovery.

With LoyaltyPlant, the kiosk keeps a verified customer session on the server. REGULAR can start with a card or a valid gift; a removed gift is excluded from the final receipt. A failed payment does not authorize a second charge: finish the previous attempt and scan the card again before a new order. Actual points accrual must be confirmed with the provider, not inferred from a successful worker call.