Leaders Insights
Leaders Insights

Rester au meilleur niveau, un peu chaque jour.

DomainesMarketingDataFinanceIA
RessourcesApprendreTestOutilsBlogGlossaire
© 2026 Leaders Insights — Tous droits réservés.
Formations/Data in travel and hospitality/Governance, privacy and checks/PCI DSS and the payment data trail through PMS, POS and OTAs
2/4+150 XP

Governance, privacy and checks

10Cross-border data flows: why a booking in Bali touches five jurisdictions+15011PCI DSS and the payment data trail through PMS, POS and OTAs+15012Building a data retention schedule for guest records that actually gets enforced+15013Running a data governance audit: the checklist for a multi-property portfolio+150

PCI DSS and the payment data trail through PMS, POS and OTAs

# PCI DSS and the payment data trail through PMS, POS and OTAs

A guest books a room on an OTA, pays a deposit through the hotel's booking engine, charges dinner to the room at the restaurant POS, and settles the final folio at checkout with a different card. That single stay just created four separate payment data trails across four different systems, often run by four different vendors. If any one of them stores an unencrypted card number, the hotel is holding a liability it may not even know exists.

This lesson traces where card data actually lives in a hotel's tech stack, what PCI DSS requires at each stop, and how to audit for the tokenization gaps that turn a routine compliance check into a breach disclosure.

What PCI DSS actually is

PCI DSS (Payment Card Industry Data Security Standard) is a private industry standard, not a government law. It's maintained by the PCI Security Standards Council, founded by Visa, Mastercard, American Express, Discover and JCB. Compliance is enforced contractually: your merchant bank (acquirer) requires it, and your card brand agreements require it. There's no regulator issuing fines directly, but non-compliance triggers acquirer penalties, higher processing fees, and in a breach scenario, forensic costs and potential card brand fines that flow through your acquirer.

The current version, PCI DSS 4.0.1 (2024 update, per the PCI Security Standards Council), is the baseline hotels should be working against in 2026, with older 3.2.1 provisions fully retired.

Core requirement categories relevant to hospitality:

Don't store card data you don't need
  • Encrypt cardholder data in transit and at rest
  • Restrict access on a need-to-know basis
  • Log and monitor all access to payment systems
  • Test systems and networks regularly
  • The four places card data hides in a hotel stack

    1. The OTA and booking engine.

    When a guest books through Booking.com, Expedia, or the hotel's own IBE (internet booking engine), card data is captured to guarantee or prepay the reservation. Some OTAs process payment themselves (merchant model) and only pass the hotel a virtual card number for settlement. Others pass raw guest card data directly into the PMS via an APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Voir la définition complète → feed. That second scenario is where hotels often unknowingly inherit PCI scope they didn't budget for.

    2. The PMS (property management system).

    Systems like Oracle Opera, Mews, or Cloudbeds hold the guest folio: charges, room rate, incidentals, and often a card tokentokenA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.Voir la définition complète → for "charge to room" privileges. The PMS should never store the raw PAN (primary account number, the 16-digit card number) in cleartext. It should hold a tokentokenA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.Voir la définition complète →, a substitute value that has no exploitable meaning outside the tokenization system that created it.

    3. The POS (point of sale) at restaurants, spas, minibars.

    Every outlet that lets guests charge to the room, or pay directly by card, is a card data touchpoint. Legacy POS terminals that aren't EMVEMVUnpaid media exposure such as press coverage, word-of-mouth, social shares and customer reviews generated organically rather than bought or self-published.Voir la définition complète →-compliant or point-to-point encrypted are a classic audit failure point, especially in independent hotels running older hardware.

    4. The payment gateway and processor.

    The gateway (Stripe, Adyen, Shift4, etc.) is where tokenization should actually happen, ideally the moment the card is captured, before it ever reaches the PMS or POS database.

    Tokenization: the concept that decides your audit outcome

    Tokenization replaces the real card number with a randomly generated surrogate value (a tokentokenA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.Voir la définition complète →) that is useless if stolen, because it can't be reverse-engineered into the real PAN without the tokenization vault, which sits with the payment processor, not the hotel.

    Contrast this with encryption, where data is mathematically reversible with the right key. Encryption protects data in transit; tokenization removes the sensitive data from your environment altogether.

    A simplified view of a compliant flow:

    Guest card swipe/entry
         │
         ▼
    Point-of-interaction device (encrypts on capture)
         │
         ▼
    Payment gateway (decrypts briefly, tokenizes, sends to processor)
         │
         ▼
    PMS/POS receives TOKEN only ──► stored in folio for "charge to room"
         │
         ▼
    Raw PAN never touches hotel-owned database

    The gap most audits find: a hotel's booking engine or PMS integration was configured years ago, before tokenization was standard, and still writes the raw PAN into a database field "just in case a chargeback dispute needs it." That field is exactly what a breach investigator finds first.

    The practical audit: what to actually check

    A data governancedata governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.Voir la définition complète → lead or GMGMGross margin is the share of revenue left after subtracting the direct cost of producing goods or services, expressed as a percentage of revenue.Voir la définition complète → doing a pre-audit sweep should check:

    • Data flow mapping. Document every system that touches card data: OTA feed, IBE, PMS, POS, gateway, PDF folio exports, email confirmations. Most hotels are surprised email confirmations sometimes include full or partial card numbers, a common and avoidable PCI violation.
    • Storage scan. Run a PAN-detection scan (many gateways and QSAs, Qualified Security Assessors, offer free scanning tools) across shared drives, PMS databases, and even staff email inboxes. Full card numbers pasted into a spreadsheet for a "VIP list" is a recurring real-world finding.
    • Third-party scope. Confirm which OTAs use the merchant model (they hold PCI liability) versus pass-through (you inherit it). This should be spelled out in the OTA's data processing terms.
    • Access logs. Who can view unmasked card data in the PMS? Front desk staff often have broader access than their role requires, a violation of the "least privilege" principle central to PCI DSS Requirement 7.
    • Retention policy. Card data (even tokenized references) should have a defined deletion schedule tied to legal retention needs, not kept indefinitely "for reporting."

    For a free starting reference, the PCI Security Standards Council's Quick Reference Guide walks through merchant-level requirements in plain language.

    Vérification des acquis

    1. A hotel manager says, 'We don't need to worry about PCI DSS since no government agency enforces it.' What is the flaw in this reasoning?

    2. Why does a single guest stay involving an OTA booking, a booking engine deposit, a restaurant POS charge, and a front desk checkout create a distinct compliance concern compared to a single point-of-sale transaction?

    3. A hotel is deciding how to handle card numbers captured through its booking engine. Which approach best reflects the core PCI DSS principle of minimizing risk?

    CHOIX MULTIPLES

    4. Select ALL correct answers about what PCI DSS 4.0.1 core requirements involve for a hotel's payment systems.

    Sélectionnez toutes les réponses correctes.

    CHOIX MULTIPLES

    5. Select ALL correct answers about why a hotel's payment data risk is distributed rather than centralized.

    Sélectionnez toutes les réponses correctes.

    Where this intersects GDPR and US state law

    PCI DSS governs card data specifically, but the same guest record often includes passport numbers, loyalty IDs, and stay history, which fall under broader privacy law. In the EU/UK, GDPR (General Data Protection Regulation) treats card data as personal data subject to breach notification within 72 hours to the relevant supervisory authority. In the US, there's no single federal law, but state breach notification statutes (e.g., California's data breach law) apply, and processors must still follow PCI DSS contractually regardless of geography.

    This matters practically: a card data breach at a hotel is almost never *only* a PCI event. It's usually a GDPR or state-law notifiable breach too, because the same compromised database typically holds names, addresses, and passport details alongside the card tokentokenA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.Voir la définition complète → or PAN.

    A worked example: scoping cost of a tokenization gap

    Say a mid-size hotel (150 rooms) discovers its PMS integration with a legacy IBE stores raw PANs for the past three years of reservations, an estimated 45,000 records (illustrative, not a real incident figure).

    Immediate governance actions and rough cost drivers:

    • Forensic investigation (required by acquirer): typically tens of thousands of dollars for a property this size, cost estimate, varies significantly by scope
    • Re-issuance/monitoring costs if card brands mandate it, often passed through the acquirer
    • Remediation: re-architecting the IBE-PMS integration to pass tokenstokensA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.Voir la définition complète → only
    • Potential GDPR fine exposure if EU guests are affected: up to €20 million or 4% of global annual turnover, whichever is higher, per GDPR Article 83, this is a statutory ceiling, not a typical outcome

    The lesson isn't the dollar figure, it's that the cost of finding this gap in an internal audit is a remediation project. The cost of a card network or regulator finding it first is a breach disclosure, with all the reputational and legal weight that carries.

    🎬 [VIDEO: "How Credit Card Tokenization Works" - youtube.com/results?search_query=how+credit+card+tokenization+works - search and choose a reputable payments-industry explainer (e.g. from a processor like Stripe or a security vendor) showing the tokentokenA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.Voir la définition complète → vault flow end to end]

    Key Takeaways

    • Card data in hospitality moves through at least four systems (OTA, PMS, POS, gateway), each a separate point of PCI DSS exposure, and audits must mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Voir la définition complète → all of them, not just the front desk terminal.
    • Tokenization removes the raw PAN from hotel-owned systems entirely; encryption alone still leaves reversible data in scope, know which one your vendors actually use.
    • Legacy integrations (especially older IBE-to-PMS feeds) are the most common source of undiscovered raw card storage, run a PAN-detection scan as a standing quarterly check, not a one-time audit item.
    • A card data breach is rarely isolated: it typically triggers GDPR or state breach notification obligations simultaneously, because guest PII sits in the same compromised record.
    • PCI DSS is contractual, not statutory, but the reputational and regulatory fallout of a breach behaves like a legal event, treat governance accordingly.

    Précédent

    Cross-border data flows: why a booking in Bali touches five jurisdictions

    Suivant

    Building a data retention schedule for guest records that actually gets enforced