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 Liste: Rechtsbezug, 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
Datenaustausch per Datei statt per Schnittstelle. Nächtliche CSV-Exporte liefern Preise und Kontingente, die längst verkauft sind, im Callcenter entstehen Doppelbuchungen. Gegenmaßnahme: Echtzeitabfragen über OpenTravel-XML oder REST/JSON mit klarer Fehlerbehandlung. Anbieterbeispiel: Peakwork und Amadeus liefern API-Zugänge für Veranstalter- und Flugdaten. Anforderung: dokumentierte Endpunkte mit Sandbox und zugesagter Antwortzeit im Lastenheft.
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.