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

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.View full definition → 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.View full definition → 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.View full definition →, 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.View full definition →-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.View full definition →) 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:

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.View full definition → 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.View full definition → 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.

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.View full definition → 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.View full definition → 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.View full definition → 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.View full definition → 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.