Card data at a hotel in plain words: PAN, authorization, tokens and why a note field is the wrong place

A card number (the PAN, the primary account number printed on the card) should live only inside the payment terminal or the payment provider's system. A hotel that writes it into a note field, an email or a screenshot has taken on card-data duties that apply to anyone who stores, processes or transmits it. Hotel card data security under PCI rules is about where the number lives, not how big the hotel is.

A guest cannot open the payment link, so they type the card number into the booking notes. It works: the room is guaranteed and the shift ends. The number now sits in a field that is copied into reports, exports and backups. This article gives you the vocabulary (PAN, security code, authorization, token), the places numbers actually leak, what the standard's scope sentence means for a hotel that outsources payments, the questions to ask your provider and software supplier, and a desk rule your team can follow the next time a card arrives by email.

Why does a hotel handle card data at all?#

Because a reservation is a promise to pay later, and the card is the guarantee behind that promise. Every step that touches the guarantee touches card data.

The guarantee appears in several forms. A no-show or late-cancellation guarantee holds the card so a charge can be made if the guest never arrives. Deposits and prepayments for groups, packages and peak dates move the money before the stay. Walk-ins at the desk read the card at the terminal, and the terminal, not the front desk, should be the only place the number exists.

The desk is not the only point. The restaurant, bar, spa and shop take cards too, so the same rule has to reach those outlets or it does not hold. Bookings sometimes arrive with a virtual card, a one-use number issued by the channel for that booking; it behaves like a card and carries the same duties. At the end of the day, night audit closes the day by matching terminal totals to the hotel system. That is a reconciliation of amounts and references, not of card numbers.

Keep one distinction in mind: the hotel needs the payment, the authorization reference and the receipt. It does not need the number afterwards.

What do PAN, security code, authorization and token mean?#

Four terms cover almost every card conversation a hotelier has. Only one of them is the number itself, and that is the one that must not be kept.

The PAN is the long number on the front of the card. With the expiry date and the name, it is enough for card-not-present fraud, which is why it is the term the standard is built around. The security code is the three or four digits that prove the physical card was in someone's hand; no legitimate party needs it after the authorization, so any request to send it is a warning sign.

An authorization is the provider's answer that funds are available and held for a period. It is a status and a reference, not a number, and the hotel can keep the reference and the amount safely. A token is a stand-in reference the provider issues instead of the number; it works only inside that provider's system and for the purpose it was issued for, which is what lets a hotel charge a no-show later without holding the number. The masked number, usually the last four digits, is safe to display and is what staff should use to match a payment to a reservation.

Reference versus number: the difference that decides where data lives#

The rule that follows from the table: reference and amount can be stored, the number and the security code cannot. An authorization reference identifies a hold; a token identifies a stored number inside the provider. Neither is the number itself, and neither is usable outside the provider's system, which is why they are safe to keep. For more on virtual POS, 3D Secure, tokens and chargebacks, see our payment technology glossary.

Where do card numbers leak at a hotel?#

Most leaks are not attacks. They are helpful people typing a number into a field that was never built for it.

Reservation notes and comments are a common place to find one: the guest writes the number in the booking form, or staff paste it in so the next shift has it. Notes are copied into reports, exports and backups, so one paste becomes many copies. Email and messaging put the number in two inboxes, on two phones and in a spam filter, where it stays after the booking is closed. Screenshots and phone photos of a card, or of a terminal screen, travel through staff group chats.

Paper still leaks too: the mail order form, the fax, the printed arrival list with a number written by hand in the margin. Spreadsheets leak when a guaranteed-bookings file is emailed to a manager every month. Channel and chat messaging leaks when guests send card details through a booking-channel message window that was not built to hold them. If you still take details on paper, read our guide to hotel mail order forms and taking card details without storing them.

What does the standard's scope sentence actually say?#

It says the standard reaches the hotel even when someone else does the processing. Outsourcing changes which duties are yours, not whether you have any.

Read the three verbs separately. Storing is keeping a number. Processing is running a transaction. Transmitting is moving a number from one place to another, which is exactly what forwarding an email does. So a hotel that forwards a guest's email to the provider has transmitted card data, even if it stored nothing.

Scope follows where the data flows, not the size of the property. A small hotel with a note field full of numbers has a wider footprint than a large one that never lets a number leave the terminal. This article will not list requirement numbers or tell a specific hotel what to implement; that depends on the setup, the acquirer and the provider contracts, and it is a question for a qualified assessor.

What should you ask your payment provider and your software supplier?#

Ask both, in writing, and ask the same question twice, because each side will assume the other handles it.

To the payment provider, ask which of these they support: a token, a hosted payment page the guest completes, and virtual cards from channels. Ask what they store, for how long, what you can see in their panel, and what evidence they give you when a chargeback arrives. Ask what the approved procedure is when a card is given over the phone, and whether it differs from a card at the terminal.

To the software supplier, ask whether the system has a free-text field that can hold a card number, and whether that field can be masked, limited or switched off. Ask whether notes flow into reports, emails or backups, and who inside the hotel can read them. Ask whether the system stores card data at all, where, and what happens to it when the hotel changes systems.

Keep the answers. A written answer dated today is worth more than a verbal assurance when a guest disputes a charge or an acquirer asks a question. When a dispute does arrive, what matters is the evidence you hold; see our guide to answering a card chargeback with the right evidence.

What is the desk rule when a guest sends a card by email?#

Use the number once, in the approved path, and do not repeat it into any other system. Then remove the message.

Do not forward the email, do not reply quoting the number, and do not paste it into the reservation note. Prefer a payment link the guest completes themselves: the number then goes from the guest to the provider and never passes through hotel staff. If the guest cannot use a link and is not present, take the booking as unguaranteed or ask for another method. A guaranteed booking is not worth a number in the notes.

Delete the message from the inbox and from sent items, and record in the reservation only that a link was sent and what came back. If the number was already written somewhere, treat it as an incident: remove it, write down what happened and when, and tell whoever is responsible for data protection at the property. Tell the guest plainly why the number is not being kept; in practice most guests accept a one-line explanation and a working link.

Where does the card standard stop and local law begin?#

The card standard governs card data. Personal data law governs the person. A hotel answers to both, and they are not the same question.

PCI DSS is an industry standard enforced through the payment chain, by acquirers and providers in their contracts. It is not a law and it does not replace one. KVKK, the personal data protection law, covers the guest as a person: a card number is also personal data, and so are the name, the stay and the note written around it.

A single incident can therefore trigger two conversations: one with the provider about the card data, one about personal data under KVKK. The duties and time limits in each depend on the case. Contracts settle more than people expect: what the acquirer requires of the hotel, what the provider promises, and who answers a chargeback.

What to do next#

Pick one system this week and search it for a 16-digit string. If you find a hit outside the terminal and the provider's panel, delete it and close the field that accepted it. That single action joins the whole article together: the terms tell you what you are looking at, the leak list tells you where to look, the scope sentence tells you why it is your problem even when someone else processes the payment, and the desk rule keeps it from coming back.