A till is only useful if it can talk to the terminal, the printer, the scanner and the accountant. These are the connections that exist today — and we list the ones we have built, not a roadmap.
Each one is set up once and then belongs to the shift — no middleware, no second dashboard to keep open.
The amount goes from the till to the terminal; the result comes back to the order. The guest pays on the terminal, not on the till screen.
Receipts print from the till, and a label printer can be set up for the shelf or the bar. The printer is chosen in the settings, not rebuilt for every device.
A scanner that enters the barcode like a keyboard works with the product search. The code finds the product; nobody types thirteen digits at the counter.
A second screen at the counter shows the guest what is on the receipt as it is being built — the items, the quantity and the total, before the card is tapped.
A QR code opens the menu on the guest’s phone. The prices come from the same products the till sells, so a price change does not leave an old menu on the table.
At month end the figures leave as a file rather than as a screenshot. The cash book and the reports are already built; the export is the last step, not the first.
API Access gives you your own keys for the integrations you build. If another system needs to ask the till for something, it can ask directly instead of someone exporting a file and emailing it.
Tell us what the other system needs before the demo. We will say what the API exposes today — including “not that” if that is the answer.
There is no plugin marketplace and no connector of the week. The connections that exist are the ones on this page. If your other system is not among them, ask — we will answer with what exists, not with a roadmap we cannot keep.
The fiscal signature is written through the TSE required by KassenSichV; it is part of every sale, not an integration you buy separately.
The model numbers matter more than the brand on the box. Send them before the demo and we will tell you what fits.
The system is built around Adyen terminals. The amount is sent from the till and the payment result comes back to the order. If you already own a terminal from another provider, say so before the demo — we will tell you plainly whether it can be used.
Possibly. Epson ePOS-Print printers are supported directly, and the browser’s print dialogue can reach other printers. Send the model before the demo; guessing from a photo tends to end with a printer that almost works.
A scanner that behaves like a keyboard needs no driver: it enters the code into the product search exactly as a person would. A scanner that needs its own software is a different conversation — send the model.
DATEV, CSV, Excel and PDF. The cash book and reports are built in the system, so the export is a file at month end rather than a figure copied from a screen.
No. It opens in a browser on a second screen and shows the live cart and total. It is part of the system, not a second product with its own licence.
Start with the API and tell us what the other system is. We will say whether it can be done with what exists, whether it needs work, or whether it is outside what we do. We will not promise a connector before it exists.
Show us the terminal, the printer and the scanner you have — or the ones you are about to buy — and we will tell you before the demo what will work.
