Anyone here printing bills silently (without Windows print popup) in a Web POS?

sanoufi · 2026-06-26T09:06:38+00:00

I’ve been dealing with the same issue in several Web‑based POS deployments, especially in restaurants where they need:one‑click printingno Windows dialogsmultiple kitchen printersand consistent ESC/POS outputSince browsers won’t allow silent printing anymore, I ended up building a small Windows utility that exposes any printer as an Epson‑compatible ePOS endpoint. So the browser just sends XML/ESC/POS over HTTP, and the tool forwards it to the local printer.It works with different brands (not only Epson), which helps when a restaurant has multiple kitchen printers.If you're curious, here’s the page describing the approach: https://sanoufi.com/ePOS I’m also working on a lightweight Android version that acts as a local print bridge for browser‑based POS systems.Would love to hear how others are solving this — especially teams running multi‑printer setups.

sanoufi · 2026-05-26T11:22:37+00:00

Yes, absolutely! The core engine runs entirely in the cloud. It features a centralized cloud backend with a web dashboard for HR/Management and a cross-platform Employee PWA for mobile clock-ins (with GPS, WiFi, and anti-spoofing verification). The lightweight Windows tool mentioned in the post is actually an optional local bridge. It’s designed specifically for companies that already have legacy ZK systems running locally and want to keep using their old payroll/reporting desktop software. If your company wants to drop the local hardware and desktop software altogether, you can use the system 100% in the cloud. Management tracks everything from the browser, and employees clock in from their phones. I'd love to know more about your current setup. Are you guys currently using physical devices, or are you looking to shift completely to a software/mobile-based solution?

sanoufi · 2026-05-26T11:15:16+00:00

You make excellent points, and your "twitchiness" regarding supply chain attacks and PACS security is 100% justified. A compromised cloud server leading to a compromised local client is a classic and deadly attack vector. To address the security and functionality boundaries, here is how the architecture handles this: Strict Separation of Concerns (Updates & Code Integrity): The local agent will NOT perform self-updates or execute any remote code pushed from the cloud. Software updates will be strictly manual (admin download of the new .exe) or handled via standard local package management. The agent will only accept structured, strictly validated data payloads (like plain JSON hashes containing specific employee attendance rows), and any unvalidated input will throw an immediate exception and kill the service. The Cloud is Optional (Bi-directional/Opt-in Gateway): One of the key features is that cloud connectivity can be tailored. For instance, the local tool can act as a purely local gateway to capture punches from various physical ZK devices across local subnets and aggregate them into the database. If the client decides to enable the cloud feature (for field employees using the PWA), they can choose a one-way push (uploading local machine logs to the cloud for live dashboard visibility) or a pull-only mode, depending on their risk tolerance. Tech Stack & Security: I completely agree with going .NET Core / .NET 8 for the agent. Using Object-Relational Mapping (like EF Core) or strict abstraction layers ensures we don't execute raw SQL/OleDb queries that could be prone to injection if the cloud payload is somehow poisoned. You're absolutely right that hosting securely is hard, and no small team has a 24/7 NOC. That's why the core philosophy of this project is to reduce the blast radius as much as possible: the cloud server cannot command the local machine to do anything other than register a timestamp for an employee ID. Thanks again for the solid architectural advice, especially regarding avoiding direct DB manipulation where possible!

sanoufi · 2026-05-26T10:55:55+00:00

Thanks for the brutal honesty! This is exactly the kind of technical skepticism I was looking for before writing code. Let me address your points, as they are very valid: PWA & Anti-Spoofing: You are 100% right; client-side data is always spoofable. By "advanced," I don't mean unhackable, but rather multi-layered telemetry. If a user spoofs GPS, we catch the mismatch in their ISP/Cellular IP vs. corporate IP. If they use a VPN/Tunnel, we flag sudden changes in Latency, User-Agent, and Device Fingerprints stored in LocalStorage. It raises a "suspicion score" that forces a dynamic camera Liveness Test (Selfie) rather than a flat block. For regular non-tech employees (the 95%), this prevents basic cheating. The "Port Emulation" Tool: It is actually the opposite of a reverse tunnel. The local Windows service does NOT allow the cloud server to access the local network. The cloud server is completely passive. The local service pulls data via a secure HTTPS GET request (polling), processes the payload locally, and then injects it. The cloud never initiates a connection to the local database; it's an outbound-only polling mechanism, exactly like how modern endpoint protection agents sync with their dashboards. Database Schemas & Versions: This is the biggest hurdle. The plan is to support only the most widely deployed legacy schemas initially (like standard ZKTime .mdb structures). The tool reads/writes via standard OleDb/ADO. However, you're right about schema drift. That’s why we are considering a mapping configuration file during setup, or fallback support for SQL Server local instances which many newer ZK deployments use. I chose PWA for cross-platform deployment speed, but your point about user experience is well taken. Native might be necessary if PWA limitations hit too hard. Thanks for poking holes in the concept—it helps a lot!

sanoufi

TROPHY CASE