Diese Seite fasst alle Netzwerk- und Firewall-Anforderungen für eine bessa-Installation an einem Kundenstandort zusammen. Sie richtet sich an IT-Verantwortliche, die in einem gemanagten Netzwerk (Firewall, getrennte VLANs, Whitelist) entscheiden müssen, welche Hosts und Ports freigegeben werden müssen, damit Kassa, Bestellsystem, Drucker, Bezahl- und Schankanlagen einwandfrei funktionieren.
Die Inhalte sind nach Produktbereich gegliedert. Zu jedem Bereich finden Sie zwei Abschnitte: Kommunikation nach außen (Internet) und Kommunikation intern (lokales Netzwerk).
Diese Seite ist die Quelle für den IT-Onboarding-Prozess. Bei Anfragen aus IT-Abteilungen können Sie diese Seite oder einzelne Abschnitte direkt verlinken.
Allgemeine Hinweise
-
Cloud-Verbindungen: Alle ausgehenden Verbindungen zu bessa-Diensten erfolgen über HTTPS / TCP 443. Es sind keine zusätzlichen Outbound-Ports erforderlich.
-
DNS: Die Standard-System-DNS-Auflösung reicht aus. Eine bessa-spezifische DNS-Konfiguration ist nicht erforderlich.
-
NTP: Aktuell besteht keine zwingende NTP-Anforderung an Geräte oder Netzwerk.
-
IP-Whitelist: Geben Sie ausschließlich Hostnames frei. Konkrete IP-Bereiche (CIDR) sind nicht stabil — Cloud-Dienste werden über CDN- und Load-Balancer-Pools ausgeliefert, die sich ändern können.
-
Lokale Geräte: Drucker, Bezahlterminals und Schankanlagen benötigen eine statische IP oder eine reservierte DHCP-Lease. Sie müssen für die Kassa im selben Subnetz erreichbar sein bzw. zwischen Subnetzen geroutet werden.
-
ICMP/PING: Manche Geräte (z. B. Brau Union Z1U Schank) beantworten kein ICMP. Verwenden Sie zur Diagnose den jeweiligen TCP-/UDP-Port, nicht
ping.
1. Kassa
Die Kassa kommuniziert mit der bessa-Cloud (Manager / API) und — je nach Land — mit einer zertifizierten Signaturkomponente (RKSV / TSE / länderspezifisch).
Kommunikation nach außen
|
Zweck |
Hostname |
Port / Protokoll |
|---|---|---|
|
bessa Manager (Hauptbackend Kassa) |
|
TCP 443 / HTTPS |
|
bessa API (Hauptbackend Kassa) |
|
TCP 443 / HTTPS |
|
bessa Manager (Zusatzprodukte) |
|
TCP 443 / HTTPS |
|
bessa API (Zusatzprodukte) |
|
TCP 443 / HTTPS |
|
RKSV-Signaturkomponente (Österreich) |
|
TCP 443 / HTTPS |
|
RKSV-Signaturkomponente (Österreich, alternativ) |
|
TCP 443 / HTTPS |
|
TSE-Middleware (Deutschland) |
|
TCP 443 / HTTPS |
|
Länderspezifische Fiskal-Cloud (z. B. Kroatien) |
|
TCP 443 / HTTPS |
|
App-Updates Standard-Android |
Google Play Store |
TCP 443 / HTTPS |
|
App-Updates Sunmi-Geräte |
Vendor-eigener App-Store |
TCP 443 / HTTPS |
|
App-Updates iMin-Geräte |
Vendor-eigener App-Store |
TCP 443 / HTTPS |
|
App-Updates Orderman |
System Center Next |
TCP 443 / HTTPS |
Welche Signaturkomponente angesprochen wird, hängt vom Standort des Kunden ab — Österreich (RKSV), Deutschland (TSE) oder weitere Länder. Geben Sie nur jene Hostnames frei, die für Ihren Standort relevant sind.
Kommunikation intern
|
Zweck |
Port |
Bemerkung |
|---|---|---|
|
Hauptkassa-Discovery |
UDP 48858 |
Nebenterminals und Bestellmonitore finden über diesen Port die zuständige Hauptkassa im LAN |
|
Nebenterminals ↔ Hauptkassa |
TCP 48880 |
Buchungen und Synchronisation zwischen Sub-Terminal und Hauptkassa |
|
Bestellmonitor ↔ Kassa |
TCP 48888 |
Bestellweitergabe an Bestellmonitore (Küche, Bar) |
|
mDNS/Bonjour-Discovery |
UDP 5353 |
Erkennung von Netzwerkdruckern (siehe Abschnitt 6) |
|
Echtzeit-Kommunikation (SSE / wss) |
TCP 443 |
Server-Sent Events und WebSocket Secure ( |
Drucker, Bezahlterminals und Schankanlagen sind in den jeweiligen Abschnitten weiter unten dokumentiert — die Kassa öffnet ausgehende TCP-Verbindungen zu diesen Geräten im LAN.
2. Bestellen (Connector)
Der bessa Connector ist die zentrale Bestellschnittstelle zwischen externen Order-Channels (Self-Order-Tablets, Bestell-Apps, Webshop) und der Kassa. Er kann als Windows-Dienst, auf Android oder als Sunmi-Standalone betrieben werden — die Port-Anforderungen unterscheiden sich nicht nach Plattform, sondern nach angebundenem Kassensystem.
Kommunikation nach außen
|
Zweck |
Hostname |
Port / Protokoll |
|---|---|---|
|
bessa Manager |
|
TCP 443 / HTTPS |
|
bessa API (HTTPS + WebSocket Secure) |
|
TCP 443 / HTTPS und |
|
Treuepass POS-Endpoint |
|
TCP 443 / HTTPS |
Der Connector hält zur bessa API eine permanente WebSocket-Secure-Verbindung (wss://) auf TCP 443 — über diese werden Bestellungen und Status-Updates in Echtzeit ausgetauscht. Die Firewall muss langlebige TCP-443-Outbound-Verbindungen ohne Idle-Timeout zulassen.
Kommunikation intern
Connector ↔ Kassa:
|
Kassensystem |
Port |
|---|---|
|
dieKassa (integrierter Connector) |
TCP 20030 auf 127.0.0.1 |
|
dieKassa (alleinstehender Connector im LAN) |
TCP 20030 auf der fixen IP der Kassa |
|
Andere Kassensysteme |
TCP 20031 oder 1090 — mit dem Vendor abzustimmen |
Order-Channels (Self-Order-Tablets, externe Bestell-Apps, Webshop): Die Kommunikation erfolgt aktuell ausschließlich über die Cloud (HTTPS). Es ist keine Port-Freigabe direkt am Connector im LAN erforderlich.
3. Kundenbindung
Die Kundenbindung (Bonus- und Treuesystem) läuft über die bessa-Cloud. Es gibt keine LAN-Komponente.
Kommunikation nach außen
|
Zweck |
Hostname |
Port / Protokoll |
|---|---|---|
|
bessa API |
|
TCP 443 / HTTPS |
|
bessa Manager |
|
TCP 443 / HTTPS |
Die früher genutzte Domain treuepass.app ist deprecated. Neue Installationen kommunizieren ausschließlich über bessa.app-Endpoints.
Kommunikation intern
Keine. Es ist keine LAN-Hardware-Komponente erforderlich (kein dedizierter Treuepass-Reader / NFC-Terminal).
4. Gutscheine
Die Gutscheinverwaltung läuft vollständig über die bessa-Cloud.
Kommunikation nach außen
|
Zweck |
Hostname |
Port / Protokoll |
|---|---|---|
|
bessa API (Gutschein-Validierung & -Ausstellung) |
|
TCP 443 / HTTPS |
Externe Gutschein-Provider (Hausgutschein-Plattformen Dritter etc.) werden derzeit nicht unterstützt — es sind keine zusätzlichen Hosts freizuschalten.
Kommunikation intern
Keine.
5. Kennzahlen
Die Kennzahlen-App liefert Echtzeit-Reporting für eine Kassa. Sie kommuniziert lokal mit der Kassa und zur bessa-Cloud für Sync und Reporting.
Kommunikation nach außen
|
Zweck |
Hostname |
Port / Protokoll |
|---|---|---|
|
bessa API (Reporting / Sync) |
|
TCP 443 / HTTPS |
Kommunikation intern
-
Kennzahlen-App ↔ Kassa: TCP 1090
In Multi-Standort-Setups erfolgt keine zentrale Aggregation auf Netzwerkebene. Jede Kassa wird einzeln angesprochen — der Kennzahlen-App reicht eine LAN-Erreichbarkeit pro Standort, nicht standortübergreifend.
6. Drucker
Drucker sind ausschließlich lokale Geräte. Es ist keine ausgehende Internet-Verbindung erforderlich.
Kommunikation nach außen
Keine.
Kommunikation intern
|
Druckertyp |
Discovery |
Port (TCP) |
Hinweise |
|---|---|---|---|
|
Star (Bondrucker, Netzwerk) |
mDNS/Bonjour (UDP 5353) |
9100 (Raw / ESC/POS) |
Discovery oder feste IP |
|
Epson (Bondrucker, Netzwerk) |
mDNS/Bonjour (UDP 5353) |
9100 |
Discovery oder feste IP |
|
Bixolon (Bondrucker, Netzwerk) |
mDNS/Bonjour (UDP 5353) |
9100 |
Discovery oder feste IP |
|
Metapace, Pulse |
keine Discovery |
9100 |
Feste IP-Konfiguration |
|
Aures (Etikettendrucker) |
keine Discovery |
9100 |
Statische IP zwingend nötig |
|
Sunmi / iMin (eingebauter Bondrucker) |
— |
— |
USB-lokal, keine LAN-Konfiguration |
Reservieren Sie für jeden Netzwerkdrucker eine DHCP-Lease oder vergeben Sie eine statische IP. Bei vielen Drucker-Brands ist Discovery nur einmalig zur Erstkonfiguration nötig — danach läuft die Kommunikation gegen die feste IP.
AirPrint / IPP (TCP 631) wird nicht verwendet.
7. Bezahlterminals
Bezahlterminals decken zwei Klassen ab: Kartenzahlungsterminals (Karten, NFC, SoftPOS) und Barzahlungsterminals (Cashmatic). Cloud-only-Terminals (Vivawallet, SumUp, GPTom-Cloud-Mode) benötigen keine LAN-Port-Freigabe; klassische Netzwerkterminals nutzen ZVT, TIM oder TECS.
Kommunikation nach außen
-
Pro Vendor: HTTPS / TCP 443 zur jeweiligen Vendor-Cloud (für Backend-Anmeldung, Transaktions-Routing, Software-Updates des Terminals).
-
Die exakten Vendor-Cloud-Hostnames sind beim jeweiligen Vendor zu erfragen — sie unterliegen Vendor-Änderungen und werden hier bewusst nicht hartkodiert.
Kommunikation intern
|
Vendor |
Protokoll |
Port (TCP) |
Bemerkung |
|---|---|---|---|
|
Nexi |
ZVT |
5577 |
Netzwerkterminal, fixe IP |
|
Hobex |
ZVT |
20007 |
Netzwerkterminal, fixe IP |
|
Hobex |
TECS |
9990 |
Netzwerkterminal, fixe IP |
|
Worldline / PayOne |
TIM (WPI) |
20007 (Standard) |
Netzwerkterminal, fixe IP |
|
Worldline / PayOne |
ZVT |
7784 |
Netzwerkterminal, fixe IP — alternative ZVT-Konfiguration |
|
CCV / cardcomplete |
ZVT |
20007 (Standard) |
Netzwerkterminal, fixe IP |
|
Cashmatic (Barzahlung) |
proprietär |
7409 (Standard, frei konfigurierbar) |
Fixe IP |
|
Vivawallet |
— |
— |
Cloud-only (HTTPS) — keine LAN-Port-Freigabe nötig |
|
SumUp |
— |
— |
Cloud + Bluetooth — keine LAN-Port-Freigabe nötig |
|
Global Payments / GPTom |
— |
— |
Cloud-Variante: HTTPS; Geräte-interne Variante: Kommunikation direkt zwischen Terminal und Kassa |
Tap-on-Mobile / SoftPOS (Worldline-WPI, GPTom-App, Viva Tap-to-Pay) erfordern keine eigene LAN-Port-Freigabe — die Kommunikation läuft entweder über die Vendor-Cloud (HTTPS) oder lokal über das Android-Gerät selbst.
8. Schankanlagen
Schankanlagen sind häufig vom Vendor zertifizierte und teilweise gehärtete Geräte, die an die Kassa angebunden werden — entweder direkt seriell/USB oder über das LAN.
Kommunikation nach außen
-
Pro Schank-Vendor wird typischerweise eine Vendor-Cloud für Telemetrie und Updates angesprochen (z. B. Heineken / Brau Union). Die exakten Hostnames sind beim jeweiligen Vendor zu erfragen.
Kommunikation intern
|
Vendor / Protokoll |
Verbindung |
Port |
Bemerkung |
|---|---|---|---|
|
Brau Union Z1U |
LAN, statische IP |
TCP 443 (HTTPS) |
Antwortet nicht auf ICMP/PING — Diagnose direkt über TCP 443 (siehe Brau Union Z1U Schank ) |
|
E-Protokoll |
USB / Seriell |
— |
Keine LAN-Komponente |
|
VMPS |
USB / Seriell oder LAN |
UDP 28001 (Standard, im LAN-Modus) |
Bei LAN-Modus statische IP empfohlen |
Häufige Fragen (FAQ)
Reicht ausgehender HTTPS-Verkehr für die Cloud-Kommunikation? Ja. Alle bessa-Cloud-Endpoints sind ausschließlich über TCP 443 / HTTPS erreichbar. Es sind keine zusätzlichen Outbound-Ports erforderlich.
Müssen wir konkrete IP-Bereiche (CIDR) freigeben? Nein. Geben Sie ausschließlich die in den Tabellen aufgeführten Hostnames frei. Cloud-IPs werden über CDN- und Load-Balancer-Pools ausgeliefert und können sich ändern.
Reicht ein Outbound-only-Profil für die Kassa? Für die Kommunikation zur bessa-Cloud reicht Outbound-HTTPS. Für die Kommunikation zu lokalen Geräten (Drucker, Bezahlterminals, Schankanlagen) muss die Kassa diese Geräte über das LAN aktiv erreichen — siehe die jeweiligen Tabellen pro Bereich.
Müssen Geräte auf ICMP/PING antworten? Nein, ICMP ist nicht zwingend erforderlich. Manche Geräte (z. B. Brau Union Z1U Schank) beantworten gezielt kein ICMP. Verwenden Sie zur Diagnose stattdessen den jeweiligen TCP-/UDP-Port.
Wir betreiben mehrere Standorte hinter einem SD-WAN — was ändert sich? Pro Standort gelten dieselben Anforderungen. Es gibt keine standortübergreifende Aggregation auf Netzwerkebene; jeder Standort kommuniziert eigenständig mit der bessa-Cloud und mit seinen lokalen Geräten.
Welche Hostnames muss ich für die TSE-/RKSV-Signatur freigeben? Das hängt vom Standort des Kunden ab: Österreich (RKSV) erfordert rksv.a-trust.at und/oder rksv.fiskaly.com, Deutschland (TSE) kassensichv-middleware.fiskaly.com, weitere Länder gegebenenfalls cloud-efr.efsta.net. Geben Sie nur die für Ihren Standort relevanten Hostnames frei.
Was, wenn ein Vendor-Cloud-Hostname für Bezahlterminal oder Schankanlage fehlt? Diese Hostnames sind beim jeweiligen Vendor zu erfragen — sie unterliegen Vendor-eigenen Änderungen und sind in dieser Dokumentation bewusst nicht hartkodiert.