De reis- en toerismesector heeft een bijzonder complexe verhouding tot PCI DSS: boekingen worden via meerdere kanalen ontvangen (online, telefoon, reisbureaus), betalingen vinden vaak plaatsvinden met enige vertraging ten opzichte van de aankoop, kaartgegevens worden tussen meerdere partijen doorgegeven (OTA, hotel, luchtvaartmaatschappij, GDS) en veel transacties omvatten opgeslagen kaartgegevens voor latere afschrijvingen (zoals aanbetalingen en annuleringskosten). Deze complexiteit maakt PCI DSS in de reissector tot een van de meest veeleisende nalevingsuitdagingen.
Waarom reis- en toerismebedrijven bijzondere PCI DSS-uitdagingen hebben
In tegenstelling tot een eenvoudige e-commercehandelaar die kaartgegevens alleen op het moment van aankoop verwerkt, worden reisbedrijven geconfronteerd met scenario's waarbij kaartgegevens moeten worden opgeslagen tussen het moment van boeking en de daadwerkelijke dienstverlening:
- Gegarandeerde reserveringen: hotels slaan kaartgegevens op om bij no-show kosten in rekening te kunnen brengen.
- Aanbetalingen en restbetalingen: reispakketten worden vaak geboekt met een aanbetaling en de rest wordt later afgeschreven.
- OTA-naar-hotel-overdrachten: wanneer een OTA een boeking naar een hotel doorstuurt, kunnen kaartgegevens via meerdere systemen stromen.
- B2B-reisbureau-boekingen: zakelijke boekingen waarbij de reiziger een bedrijfskaart achterlaat.
Hotels en accommodatieaanbieders
Hotels bevinden zich in een bijzonder complexe PCI DSS-situatie: zij ontvangen boekingen via OTA's (die kaartgegevens kunnen overdragen), directe online-boekingen, telefonische reserveringen en fysieke check-ins. De PMS (Property Management Systemen) zijn vaak oudere softwaresystemen die kaartgegevens opslaan in eigen formaten.
De oplossing voor hotels is een gecombineerde strategie: tokenisatie voor alle nieuwe boekingskanalen (online, OTA-verbindingen) en geleidelijke migratie van de PMS naar getokeniseerde kaartgegevens. Wanneer het PMS geen echte PAN's meer opslaat, verlaat het de CDE en verkleint het PCI DSS-bereik aanzienlijk.
OTA's en online reisbureaus
Grote OTA's (Booking.com, Expedia enz.) hebben eigen PCI DSS-nalevingsteams en Level-1-certificeringen. Kleinere OTA's en online reisbureaus worstelen echter vaak met de complexiteit van hun betalingsmodel: zij ontvangen kaartgegevens van klanten, moeten deze doorsturen naar leveranciers (hotels, luchtvaartmaatschappijen, transfers) en tegelijkertijd terugbetalingsrechten en latere afschrijvingen beheren.
Tokenisatie lost dit probleem op via het concept van de doorgegeven token: wanneer de klant een kaart achterlaat, wordt een token gegenereerd. De OTA kan deze token naar de leveranciers doorsturen, die hem naar de kluis kan sturen om de afschrijving uit te voeren, zonder dat het PAN-nummer via het OTA-systeem stroomt. Beide partijen verlaten de CDE: de kaartgegevens blijven in de kluis van de PCI-aanbieder.
Telefonische boekingen en callcenters in de reissector
Het telefoonkanaal is in de reissector bijzonder aanwezig: veel klanten boeken complexe reizen telefonisch omdat zij persoonlijk advies wensen. Het callcenter is daardoor vaak het grootste PCI DSS-risicopunt: medewerkers die kaartnummers handmatig invoeren in boekingssystemen maken deze systemen CDE-plichtig.
Oplossingen voor callcenters in de reissector:
- MOTO-tokenisatielink: de medewerker maakt een boeking zonder kaartgegevens en stuurt de klant een beveiligde betalingslink. De klant voert de kaart zelf in.
- Pause-and-resume-opnamesystemen: gespreksopnamesystemen die de opname automatisch onderbreken wanneer de klant kaartgegevens invoert (DTMF-geluidsonderdrukking).
- IVR-betalingsverwerking: de klant wordt voor de kaartinvoer doorgestuurd naar een IVR-systeem, zonder dat de medewerker de betaling ziet.
Veelgestelde vragen
Als wij alleen aanbetalingen via Stripe verwerken en geen PAN opslaan, zijn wij dan conform?
Wanneer alle kaartgegevens uitsluitend via Stripes Hosted Payment Page of beveiligde API verlopen, zonder dat uw server ooit de PAN ziet, komt u doorgaans in aanmerking voor SAQ A. Dit geldt echter alleen wanneer alle kanalen (online, telefoon, eventueel fysiek) via dezelfde getokeniseerde architectuur worden afgehandeld. Wanneer ook maar één kanaal directe PAN-gegevens ontvangt, dient u een ander SAQ-type in te vullen.
Zijn wij verantwoordelijk wanneer onze OTA-boekingen kaartgegevens doorgeven?
De PCI DSS-aansprakelijkheid ligt bij de partij die de kaartgegevens verwerkt. Wanneer een OTA kaartgegevens naar uw systeem stuurt en u deze opslaat in uw PMS, bent u verantwoordelijk voor de beveiliging van die gegevens. De OTA en u zijn beiden betrokken in de gegevensketen en delen mogelijk de aansprakelijkheid bij een incident. De veiligste oplossing is een API-integratie die tokens in plaats van PAN's overdraagt: beide partijen verlaten de CDE.
De reis- en toerismesector heeft PCI DSS-oplossingen nodig die complexe betalingsmodellen ondersteunen: PCI Proxy EU biedt tokenisatie voor OTA's, hotels en reisbureaus.Ontdek PCI Proxy EU.
Hulp nodig bij PCI-naleving?
Ons team helpt u uw CDE in kaart te brengen, het juiste SAQ te kiezen en tokenisatie te implementeren met gegevensresidentie in de EU.
Neem contact op