Der Reise- und Tourismussektor hat ein besonders komplexes Verhältnis zu PCI DSS: Buchungen werden über mehrere Kanäle entgegengenommen (Online, Telefon, Reisebüros), Zahlungen erfolgen oft mit Zeitverzögerung gegenüber dem Kauf, Kartendaten werden zwischen mehreren Parteien (OTA, Hotel, Airline, GDS) weitergeleitet und viele Transaktionen beinhalten gespeicherte Kartendaten für spätere Belastungen (z.B. Anzahlungen, Stornogebühren). Diese Komplexität macht PCI DSS im Reisebereich zu einer der anspruchsvollsten Compliance-Herausforderungen.
Warum Reise- und Tourismusunternehmen besondere PCI DSS-Herausforderungen haben
Im Gegensatz zu einem einfachen E-Commerce-Händler, der Kartendaten nur im Moment des Kaufs verarbeitet, haben Reiseunternehmen oft Szenarien, in denen Kartendaten zwischen dem Buchungszeitpunkt und der tatsächlichen Leistungserbringung gespeichert werden müssen:
- Garantierte Reservierungen: Hotels speichern Kartendaten, um bei No-Show Gebühren erheben zu können.
- Anzahlungen und Restzahlungen: Reisepakete werden oft mit Anzahlung gebucht und der Rest wird später belastet.
- OTA-zu-Hotel-Übertragungen: Wenn eine OTA eine Buchung an ein Hotel weiterleitet, können Kartendaten durch mehrere Systeme fließen.
- B2B-Reisebüro-Buchungen: Unternehmensbuchungen, bei denen der Reisende eine Firmenkarte hinterlegt.
Hotels und Unterkunftsanbieter
Hotels sind in einer besonders komplexen PCI DSS-Situation: Sie erhalten Buchungen über OTAs (die Kartendaten übertragen können), direkte Online-Buchungen, Telefonreservierungen und physische Check-ins. Die PMS (Property Management Systeme) sind oft ältere Software-Systeme, die Kartendaten in proprietären Formaten speichern.
Die Lösung für Hotels ist eine kombinierte Strategie: Tokenisierung für alle neuen Buchungskanäle (Online, OTA-Verbindungen) und schrittweise Migration des PMS zu tokenisierten Kartendaten. Wenn das PMS keine echten PANs mehr speichert, verlässt es die CDE und der PCI DSS-Scope reduziert sich erheblich.
OTAs und Online-Reisebüros
Große OTAs (Booking.com, Expedia etc.) haben eigene PCI DSS-Compliance-Teams und Level-1-Zertifizierungen. Kleinere OTAs und Online-Reisebüros hingegen kämpfen oft mit der Komplexität ihres Zahlungsmodells: Sie nehmen Kartendaten vom Kunden entgegen, müssen diese an Lieferanten (Hotels, Airlines, Transfers) weiterleiten und gleichzeitig Rückerstattungsrechte und späte Belastungen verwalten.
Tokenisierung löst dieses Problem durch das Konzept der weitergeleiteten Token: Wenn der Kunde eine Karte hinterlegt, wird ein Token generiert. Die OTA kann diesen Token an den Lieferanten weiterleiten, der ihn zur Belastung an den Vault übermitteln kann, ohne dass die PAN-Nummer durch das OTA-System fließt. Beide Parteien verlassen die CDE: Die Kartendaten bleiben im Vault des PCI-Anbieters.
Telefonische Buchungen und Call Center im Reisebereich
Der Telefonkanal ist im Reisebereich besonders präsent: Viele Kunden buchen komplexe Reisen telefonisch, weil sie individuelle Beratung wünschen. Das Call Center ist damit oft der größte PCI DSS-Risikopunkt: Mitarbeiter, die Kartennummern manuell in Buchungssysteme eingeben, machen diese Systeme CDE-pflichtig.
Lösungen für Call Center im Reisebereich:
- MOTO-Tokenisierungslink: Der Mitarbeiter erstellt eine Buchung ohne Kartendaten und sendet dem Kunden einen sicheren Zahlungslink. Der Kunde gibt die Karte selbst ein.
- Pause-and-Resume-Aufzeichnungssysteme: Anrufaufzeichnungssysteme, die die Aufzeichnung automatisch unterbrechen, wenn der Kunde Kartendaten eingibt (DTMF-Ton-Maskierung).
- IVR-Zahlungsabwicklung: Der Kunde wird für die Karteneingabe an ein IVR-System weitergeleitet, ohne dass der Mitarbeiter die Zahlung sieht.
Häufig gestellte Fragen
Wenn wir nur Anzahlungen über Stripe nehmen und kein PAN speichern – sind wir compliant?
Wenn alle Kartendaten ausschließlich über Stripes Hosted Payment Page oder sichere API fließen, ohne dass Ihre Server jemals den PAN sehen, qualifizieren Sie sich in der Regel für SAQ A. Das gilt jedoch nur, wenn alle Kanäle (Online, Telefon, wenn vorhanden physisch) über dieselbe tokenisierte Architektur abgewickelt werden. Wenn auch nur ein Kanal direkte PAN-Daten empfängt, müssen Sie einen anderen SAQ-Typ ausfüllen.
Sind wir verantwortlich, wenn unsere OTA-Buchungen Kartendaten weitergeben?
Die PCI DSS-Haftung liegt bei der Partei, die die Kartendaten verarbeitet. Wenn eine OTA Kartendaten an Ihr System sendet und Sie diese in Ihrem PMS speichern, sind Sie für die Sicherheit dieser Daten verantwortlich. Die OTA und Sie sind beide an der Datenkette beteiligt und teilen potenziell die Haftung bei einer Panne. Die sicherste Lösung ist eine API-Integration, die Tokens anstelle von PANs überträgt: Beide Parteien verlassen die CDE.
Der Reise- und Tourismussektor benötigt PCI DSS-Lösungen, die komplexe Zahlungsmodelle abbilden: PCI Proxy EU bietet Tokenisierung für OTAs, Hotels und Reisebüros. PCI Proxy EU entdecken.