Fiscal Receipts & Thermal Printing — Appy POS Bridge

Every ticket lands on the right paper: kitchen ticket to the kitchen, bar ticket to the bar, label to the label printer, and the fiscal receipt to the cash register through the FiscalNet integration.

Appy POS Bridge, the print server that runs on one PC inside the restaurant, connects the cloud POS to the paper on site. Every ticket — the customer receipt, the kitchen and bar production tickets, product labels, the payment note — reaches it over the live connection to the server, is written into a local queue, and is then sent to whichever thermal printer you mapped to that ticket type. We do not do fiscalisation ourselves: the fiscal receipt is issued through FiscalNet, the middleware that actually talks to the cash register, while the bridge carries the fiscal command lines there and hands the returned receipt number back to the POS. If the internet drops or a printer is offline, the job is not lost — it stays in the on-disk queue and is retried, and it survives a service restart or a power cut.

Book a Site Check

Transparent pricing: Starter 0 € · Appy POS from 49 €/mo · See pricing

Fiscal Receipts & Thermal Printing — Appy POS Bridge

300+ restaurants already use APPY POS

Poco LocoLondon BrothersPizza GiuliaCasa DacilorPizzeria di MariaLa Strada

What is a restaurant print server?

A print server is the program that connects a cloud POS to the physical printers on site. A browser cannot talk to a thermal printer directly, so the server does it instead: it receives the ticket, sends it to the right printer, and keeps it queued if that printer is offline.

  • Customer receipts, kitchen tickets, bar tickets and labels
  • Routing by section: each station receives only its own ticket
  • Thermal printers over the network, USB, or the Windows spooler
  • An on-disk queue that survives a power cut
  • Fiscal receipts through the FiscalNet integration
  • Deduplication: a re-sent ticket does not print twice

Appy POS Bridge does not fiscalise on its own and is not a cash register. The fiscal receipt is issued through FiscalNet, which talks to the certified device. It runs on Windows only and does not support Bluetooth printers.

Challenges

  • A browser cannot talk to a thermal printer — not over TCP, not over a COM port, not through the Windows spooler.
  • If the connection or the printer drops mid-service, the kitchen ticket disappears and nobody finds out until a guest complains.
  • When the POS times out and re-sends the request, the same order can print twice — on a cash register that means a second real fiscal receipt.
  • Every ticket type has a different destination, so somebody ends up picking the printer by hand on every print.

With APPY

  • Appy POS Bridge, a Windows service on one PC on site, does the talking for the browser: network TCP, USB or serial, the Windows spooler, or an office printer.
  • Jobs sit in a local on-disk queue and are retried automatically; anything interrupted mid-send is re-queued after a restart.
  • A duplicate delivery of the same job does not produce a second receipt — three independent layers guard it, and the duplicate reports the first attempt's real outcome.
  • Each ticket type gets its own printer, mapped once in the local dashboard — after that the routing happens on its own, order after order.

Results

5
Printer transports actually implemented
3
Independent layers against a duplicated receipt
0
Jobs lost when the internet drops — the queue is on disk
3×
Default attempts per job, with a pause that doubles: 2s, then 4s

Features

Five ways to connect a printer

Network TCP with ESC/POS, USB or serial COM port, raw Windows spooler passthrough for thermal printers that only ship a Windows driver, page rendering for a laser or office printer, plus export to a file in a watched folder. The same receipt content goes out over any of them.

Fiscal receipts through the FiscalNet integration

We do not build the fiscal receipt. The POS composes the fiscal command lines, Appy POS Bridge posts them over HTTP to FiscalNet — the middleware that drives the cash register — and returns the receipt number to the POS. The request times out after 15 seconds, and when FiscalNet refuses a receipt you get its own error code and message, not one we invented.

A local queue that survives the outage

Jobs are written to a SQLite database on the PC on site. A service restart or a power cut does not wipe them, and anything left stuck mid-send is automatically re-queued. The default is three attempts, with a pause that doubles in between — 2 seconds, then 4; raise the attempt count and it keeps doubling, capped at 16 seconds.

No second receipt on a re-send

The same request arriving twice does not print twice: an idempotency key replays the first response for 5 minutes, a request that arrives both directly and over the relay waits for the first print and inherits its outcome, and a job the server retransmits is ignored on insert because it carries the same id. The duplicate reports the first attempt's actual result — an open cover or an empty paper roll is never masked as a successful print.

Ticket layout comes from the template, not from code

Ticket content is marker-based text controlled from the platform: centring, bold, reverse video, font A or B, 1× to 8× character magnification, separator lines, two-column rows, a line width configurable between 16 and 64 characters, cut, beep and cash-drawer pulse. QR codes are generated by the printer firmware itself, and the logo is downloaded from a URL and printed as a raster image — PNG, JPEG or WebP.

Local dashboard, discovery and test print

The PC on site serves a web dashboard in Romanian, English and Bulgarian: sweep the network for printers on port 9100, list COM ports and installed Windows printers, map one printer per ticket type, fire a test print, and watch recent jobs, connection status and queue health.

How it works

1

It goes on one PC on site

A single installer puts the Windows service on a machine that stays powered on in the restaurant, opens the firewall port and creates the shortcut to the local dashboard. Requirements: 64-bit Windows, Windows 7 SP1 or newer, with .NET Framework 4.8. Configuration and credentials are encrypted on disk with the machine key, so the file cannot be read on a different computer.

2

Map one printer per ticket type

In the local dashboard you pick the app, the location and the POS device, scan the network or the COM ports, add the printers and bind them to the ticket types the server defines for your device — kitchen ticket, bar ticket, label, fiscal receipt and whatever else is configured in the platform. A test print confirms every printing point before the first service. You can rehearse the whole thing without hardware on the built-in simulators — the fiscal one sends text-only lines, so testing cannot emit a real receipt.

3

After that, you only watch three numbers

Once it is configured you leave it alone: the bridge updates itself — a first check 2 minutes after start, then every 3 hours, and again whenever the connection to the server recovers. The dashboard shows three numbers that should all read zero: results that have not reached the server yet, unacknowledged jobs, and jobs stuck for more than 5 minutes. If one of them climbs, you see the problem before the guest does.

Specs you can check

9100
Default TCP port for network printers, with a 5-second connect timeout
CP852
Code page for Romanian diacritics; by default receipts print transliterated so cheap printers do not emit garbage
15s
Timeout on the FiscalNet request, surfaced as its own error rather than as a printed receipt
7 days
How long finished jobs stay in the local queue before automatic cleanup

Frequently asked questions

It only sends, and you should know that up front. Fiscalisation is done by FiscalNet — the middleware installed on site that actually talks to the cash register. The POS composes the fiscal command lines, Appy POS Bridge posts them over HTTP to FiscalNet, and hands the returned receipt number back to the POS. There is no fiscal protocol, no VAT logic, no receipt numbering, no Z report, no electronic journal and no fiscal archive anywhere in the bridge — because that is not where fiscalisation happens.
The honest answer is: the ones FiscalNet supports, not the ones we would "certify" ourselves. Appy POS Bridge implements no direct cash-register protocol — there is no Datecs, Partner, Tremol or Custom driver in it — and a list of brands we cannot back with code would be worth nothing to you. Compatibility gets checked against your actual device, with us, before installation.
Print jobs live in a SQLite database on the PC on site, not in memory: they survive a service restart and a power cut, and anything interrupted mid-send is automatically re-queued. Results work the same way — if the server is unreachable at the moment the receipt prints, the result is stored on disk and retried until the server acknowledges it. On top of that, the bridge can serve the POS front-end locally and proxy calls to the cloud with an on-disk cache, so the POS keeps working even when the web server is unreachable.
A duplicate delivery of the same job does not produce a second receipt: an idempotency key replays the first response for 5 minutes, a request that arrives both directly and over the relay waits for the first print and inherits its real outcome, and a job the server retransmits is ignored on insert because it carries the same id. What we cannot promise: a request that arrives with no idempotency key gets no deduplication on the HTTP path, and if FiscalNet returns an error after the cash register has already cut the receipt, our retry can produce a second one — FiscalNet gives us no way to ask "has receipt X already printed?". So the accurate claim is "duplicate delivery of the same job does not duplicate the receipt", not "a fiscal receipt can never be duplicated".
The short list, so there are no surprises at installation. It does not fiscalise — FiscalNet does. It has no direct cash-register driver. It runs on Windows only: there is no macOS, Linux, Android or iOS build. It does not support Bluetooth at all — the transports are network TCP, serial/COM, the Windows spooler and file export. It does not speak ZPL, TSPL or EPL, so labels print as ordinary ESC/POS content or one per page on an office printer. It prints QR codes but no 1D barcodes on receipts. It does not fail over to a backup printer when one dies: the job is retried on the same printer and, if that still fails, marked failed. There are no scale, scanner or customer-display drivers, and the cash drawer opens only as a pulse sent through the receipt printer.
On network thermal printers, yes: status is queried in real time after every print and reports online, offline, cover open or paper out. On FiscalNet, no — all we can verify is that the middleware answers over HTTP; the real state of the cash register (paper, fiscal memory, day open) is not exposed to us. And a network scan tells you that "something answered on 192.168.x.y port 9100", not what model it is; only serial ports get a friendly name, and only because Windows supplies it.
Because that is the deliberate default. Many low-end thermal printers ignore the code-page selection command and read the extended bytes as the start of a CJK sequence, so the receipt comes out full of ideographs instead of "Brânză afumată". To keep you out of that, automatic ASCII transliteration is on from the start and prints "Branza afumata". If your printer does honour the code-page command, you turn the option off for that printer and get the full CP852 set: Ă ă Â â Î î Ș ș Ț ț.
7 days by default, configurable, with cleanup running hourly. The bridge is a queue with a rolling window, not an archive: the history of orders and receipts lives in the platform, not on the PC on site. One more limit worth knowing — the queue accepts at most 1000 pending jobs per POS device, and past that threshold a job is rejected explicitly rather than dropped in silence.
The local dashboard listens on all interfaces, not just on localhost, and the installer opens its port in the firewall on the domain and private profiles. That is deliberate — POS tablets on the local network have to reach it — but it does mean a LAN-reachable service, not one sealed inside the machine. In exchange, configuration and credentials are encrypted on disk with the local machine key, so the config file cannot be decrypted if it is copied to another computer.
You export the whole Appy POS Bridge configuration from the dashboard as an archive — settings only, or settings together with the queue and cache — and import it on the new machine. Updates happen by themselves anyway, with no operator opt-out by design: a first check 2 minutes after start, then every 3 hours, and again on every reconnection to the server.

See whether Appy POS Bridge fits what you already have on site

We look at your thermal printers, your cash register and the PC in your restaurant together, and tell you plainly what works straight away, what has to change, and what stays FiscalNet's job.

Book a Site Check

Related solutions

POS & Order Management

Learn more

Kitchen Display System

Learn more

e-Invoice

Learn more

This website uses cookies to ensure you get the best experience on our website.