Hotel Contactless Payment at Check-In: What the PCI Compliance Team Needs to Know

When a hotel adds contactless payment capture at check-in — a guest tapping their phone on the Puck to authorize payment alongside identity verification and key delivery — the PCI compliance team has questions. Rightly so.

The good news: NFC payment at the Puck doesn’t expand PCI scope the way a new card terminal or a custom payment integration would. The payment interaction follows the same contactless payment flow that PCI already governs at millions of point-of-sale terminals worldwide. But there are nuances worth understanding.

How payment capture works at the Puck

The Puck captures a payment credential via NFC — the same contactless payment mechanism used at retail terminals, transit gates, and vending machines. The guest holds their phone near the Puck, and the payment credential (a tokenized card number) is captured.

The critical architecture: the Puck does not store, process, or transmit raw card data. The payment credential that the NFC interaction captures is a token — a one-time-use or limited-use reference that represents the card without exposing the actual card number. The token is passed to the Guest Experience Platform (GEP), which routes it to the hotel’s payment processor through the existing payment integration.

This is point-to-point encryption from the NFC tap to the payment processor. The Puck is a credential capture point, not a card data storage point.

PCI scope implications

What doesn’t change: The hotel’s existing PCI compliance scope (SAQ type, network segmentation, PCI-validated payment processor relationship) remains the same. The Puck is an additional payment acceptance point — not a fundamentally different architecture.

What to verify: The payment processor must support tokenized NFC transactions. Most modern hospitality payment processors do (FreedomPay, Shift4, Worldline, Adyen). If your current processor doesn’t support NFC tokenization, the payment capture can be handled separately — identity verification and key delivery still work via the Puck; payment is captured through the existing card terminal.

What’s different: The payment capture happens during the same NFC session as identity verification and key delivery. From the guest’s perspective, it’s one tap. From the compliance perspective, the payment credential is captured, tokenized, and routed independently of the identity data. Payment tokens never enter the identity verification pathway. Identity data never enters the payment pathway. The data flows are architecturally separated.

The incremental authorization question

Hotels use incremental authorizations — an initial hold at check-in, followed by additional charges (minibar, room service, late checkout) during the stay. Contactless payment at the Puck captures the initial authorization. Incremental authorizations follow the same PMS-to-processor flow they use today.

For properties evaluating the payment integration, the question is: “Does our payment processor support incremental authorization from a contactless initial capture?” Most do — but confirm with your processor before deployment.

For the PCI assessor

When your PCI assessor reviews the Puck deployment, the key points:

• The Puck is a PCI-validated payment acceptance device with a Common Criteria EAL5+ secure element.
• Payment credentials are tokenized at the point of capture — no raw PAN traverses the hotel network.
• The GEP passes tokens to the payment processor — it does not store, process, or log cardholder data.
• Network segmentation requirements for the Puck follow the same rules as any other payment terminal on the property network.
• The Puck’s secure element (Common Criteria EAL5+) provides hardware-level protection for cryptographic operations.

For the broader wallet key provisioning architecture, see what IT directors need to know about wallet room keys.

Learn about the full check-in platform and payment integration →