Reiseveranstalter
Teil von Buchungssysteme für Reiseveranstalter im Vergleich mit Anbietern und Preisen
5 Fehler bei Buchungssystemen von Reiseveranstaltern
Buchungssysteme für Reiseveranstalter: fünf typische Fehler bei Schnittstellen, Zahlungen, Insolvenzabsicherung, Zugriffen und Testbetrieb mit Gegenmaßnahmen.
Das Wichtigste auf einen Blick
- Fünf Fehler treten bei Auswahl und Betrieb von Buchungssystemen in Veranstalterhäusern immer wieder auf.
- Jeder Fehler wird mit Gegenmaßnahme, Anbieterbeispiel und einem Prüfpunkt für den Anforderungskatalog verbunden.
- Als Schnittstellenstandards gelten OpenTravel, IATA NDC, EDIFACT und REST/JSON mit OpenAPI.
- Aufnahmekriterien der ListeRechtsbezug, Wirkung auf die Buchbarkeit, Kostenfolge, Nachweisbarkeit.
- Zugriffs- und Notfallregeln richten sich nach dem IT-Grundschutz des BSI.
Aufnahmekriterien dieser Liste
Ein Fehler kommt nur in die Liste, wenn er in mehreren Veranstalterprojekten auftritt, die Buchbarkeit oder die Abrechnung unmittelbar berührt und sich mit einer überprüfbaren Maßnahme beheben lässt. Zusätzlich muss ein Anbieter oder ein offener Standard benennbar sein, der die Lösung trägt.
Reine Fragen der Oberflächengestaltung bleiben außen vor, weil sie weder Vertriebsweg noch Haftung ändern. Auch die Abgrenzung von Reiseveranstaltung und Reisevermittlung nach § 651c BGB steht nicht auf der Liste, denn sie betrifft den Vertrag und nicht die Software.
Fünf Fehler mit Gegenmaßnahme und Anbieterbeispiel
Fünf Fehler und Gegenmaßnahmen
- Datei statt SchnittstelleEchtzeit-API nutzen
- Zahlungen ohne SchichtTokenisierung einführen
- Insolvenzabsicherung manuellPflichtfeld setzen
- Rollen und Notfallpläne fehlenKonzept erstellen
- Anbieter und Standard je Fehler benennen
- Zahlungen ohne eigene Schicht im System.Zahlungsarten und Zahlungsdienstleister werden je Buchung einzeln verdrahtet, Kartendaten bleiben im System. Gegenmaßnahme: zentrale Zahlungsschicht mit Tokenisierung und 3-D Secure. Anbieterbeispiel: Adyen und Unzer stellen diese Schicht bereit. Anforderung: vollständige Protokollierung jedes Zahlungsvorgangs nach § 675c BGB.
- Insolvenzabsicherung läuft neben dem Buchungsprozess.Sicherungsschein und Kundengeldabsicherung entstehen manuell, bei Umbuchungen und Teilstornos geht die Prüfung verloren. Gegenmaßnahme: Sicherungsschein als Pflichtfeld je Buchung, Prüfung vor Zahlungsannahme. Grundlage ist die Absicherungspflicht nach § 651v BGB. Anbieterbeispiel: Bewotec und Traffics bilden solche Felder in Veranstaltersystemen ab.
- Rollen, Protokolle und Notfallpläne fehlen.Alle Mitarbeitenden arbeiten mit demselben Vollzugang, Preisänderungen und Stornos sind nicht nachvollziehbar. Gegenmaßnahme: Rollenmodell, Zwei-Faktor-Anmeldung, Protokollierung und Notfallplan. Als Grundlage dient der IT-Grundschutz des BSI. Anbieterbeispiel: Identitätsdienste wie Microsoft Entra ID oder Okta liefern Anmeldung und Rollen.
- Kein Testbetrieb und kein Monitoring.Änderungen gehen ungeprüft live, in der Buchungsspitze bricht die Verfügbarkeitsprüfung ab. Gegenmaßnahme: getrennte Testumgebung, Testbuchungen, Lasttest mit dem Saisonprofil und Monitoring mit Alarmen. Anbieterbeispiel: Amadeus stellt über Amadeus for Developers eine Testumgebung mit Beispieldaten bereit. Anforderung: Abnahmeprotokoll je Release.
Anforderungskatalog für die Ausschreibung
Nehmen Sie die fünf Punkte als Prüfraster in das Lastenheft auf. Jede Zeile braucht einen Nachweis, sonst bleibt die Anforderung eine Absichtserklärung.
Vier Formate sollte das System mindestens bedienen: OpenTravel-XML, IATA NDC, EDIFACT für Bestandsanbindungen und REST/JSON für neue Partner. Fehlt eines davon, entsteht ein manueller Pflegeaufwand, der jede Saison wiederkehrt.
| Prüffeld | Anforderung | Nachweis |
|---|---|---|
| Schnittstellen | Echtzeit-API in OpenTravel-XML oder REST/JSON | OpenAPI-Dokumentation |
| Zahlungen | Tokenisierung, 3-D Secure, Protokollierung | Testbuchung mit Zahlungsdienstleister |
| Absicherung | Sicherungsschein als Pflichtfeld je Buchung | Prozessbeschreibung |
| Zugriffe | Rollen, Zwei-Faktor-Anmeldung, Revision | Berechtigungskonzept |
| Betrieb | Testumgebung, Lasttest, Monitoring | Abnahmebericht |
Häufige Fragen
Wie viele Schnittstellen braucht ein Reiseveranstalter?
Mindestens eine Echtzeitschnittstelle je Leistungsträger, dazu je eine für Buchhaltung und Zahlungen. Dateibasierte Übergaben gehören in den Notfallplan und nicht in den Regelbetrieb.
Wer haftet, wenn das System eine Zahlung falsch verbucht?
Gegenüber dem Reisenden bleibt der Veranstalter verantwortlich, unabhängig von der Technik. Das Innenverhältnis zum Zahlungsdienstleister regelt der Vertrag, rechtlicher Rahmen ist § 675c BGB.
Reicht ein Standard wie OpenTravel für alle Partner?
Nein. Airlines verlangen häufig IATA NDC, Hotels und Ausflugsanbieter arbeiten oft mit REST/JSON. Das Buchungssystem sollte mehrere Formate über eine Übersetzungsschicht bedienen.
Wie oft sollte ein Lasttest laufen?
Vor jedem Saisonstart und nach jeder größeren Änderung an Schnittstellen, Datenbank oder Hosting. Der Bitkom veröffentlicht in seiner Mediathek Studien und Leitfäden zur Digitalisierung.
Was kostet die Umstellung auf ein neues Buchungssystem?
Die Summe hängt von der Zahl der Schnittstellen, der Datenmigration und dem Testaufwand ab. Kalkulieren Sie Lizenzen, Anbindungen, Testbetrieb und Schulung getrennt, weil sie unterschiedlich stark steigen.
