Queues kill throughput. At peak, a QSR or food-court counter can only take orders as fast as staff can tap them into ERPNext POS — so customers walk, average ticket drops because nobody has time to upsell, and you pay for cashiers whose job is really just data entry. ERPNext ships a capable cashier-facing POS Profile and POS Invoice flow, but it assumes a trained operator behind the screen. There is no customer-facing, hardware-locked, self-order surface: no kiosk session lifecycle, no modifier/upsell prompts a guest can drive, no unattended payment capture, and no clean handoff of a paid order to the kitchen. That is exactly the road where ERPNext native runs out.

ECOSIRE builds a proper Frappe application — a custom app installed on your bench alongside erpnext, not a pile of manual customizations — that adds a locked-down, touch-first ordering front end backed by your existing ERPNext instance. We model the kiosk domain as first-class DocTypes: a Kiosk Session (device, POS Profile, cashier-of-record, opening state), a Kiosk Order staging document that maps to items, Item variants and a modifier/attribute structure, and a Kiosk Payment Attempt that records each terminal interaction. A dedicated Kiosk Device role profile and restricted API user keep the kiosk's permissions to exactly what it needs. The guest UI is a self-contained web front end (Frappe page / bundled assets, or a Vue/React build served by the app) that talks to the backend only through @frappe.whitelist() methods and the Frappe REST API — never direct DB access — so every write is validated and auditable.

Technically, order build-up and payment run server-side. Whitelisted methods assemble the cart, price it through ERPNext's own pricing rules and taxes, and on payment success create a submitted POS Invoice against the session's POS Profile. hooks.py document events (on_submit, on_update) fire the downstream actions: push an order-number ticket, emit the kitchen-display (KDS) payload, and update session totals. Payment is integrated to your chosen provider (card terminal, wallet, or dynamic QR) via a thin adapter, with the terminal result reconciled to a Mode of Payment — we never ask the kiosk to hold card data. Client scripts and the front end handle idempotency and timeouts so a double-tap or a dropped network never double-charges or double-fires the kitchen. A scheduler_events job reaps abandoned sessions, releases held stock, and closes the day. Multilingual menus and an accessibility mode (large-tap, high-contrast, screen-reader labels, wheelchair-height layout) are built in from the DocType translations and front-end config. It is targeted and tested on Frappe/ERPNext v15 and v16.

Because this is build-to-order, nothing is a generic download. We start with a short scoping call to lock your menu structure, modifiers, hardware (kiosk shell, card terminal, printer, KDS), payment provider and languages, then build against that spec. You get the installable source for your version, a staging deployment for UAT, and a documented go-live with a rollback plan. Typical delivery is 2 to 4 weeks from confirmed scope, depending on how many payment and hardware integrations are in play.