PCI Compliance for Hotels and B&Bs: Phone, Online and Front-Desk Payments

Accommodation businesses handle card details in more ways — and riskier ways — than almost any other small business. A single ten-room B&B might take a card by phone for a deposit, retrieve a virtual card from Booking.com, tap a guest's card at the front desk and hold details against a no-show, all in the same afternoon. Every one of those moments is inside PCI DSS scope, and a couple of them are where hotels most often go wrong. This guide walks through the payment flows in a typical hotel or B&B and what each means for your compliance.

Why are hotels and B&Bs higher-risk than other businesses?

Most shops see a card for three seconds while it taps a terminal. Accommodation is different: bookings are made days or months ahead, guests are not present when they pay, and card details are used to guarantee rooms as well as to pay for them. That combination creates risks a café never faces:

• Card details arrive by phone — and sometimes by email — handled by people rather than machines.
• No-show and cancellation policies tempt owners to keep card numbers 'on file'.
• Virtual terminals let anyone with the login key in a payment from any computer.
• Online travel agents (OTAs) such as Booking.com and Expedia send virtual cards that staff must retrieve and charge manually.
• Chargebacks on no-shows push owners towards keeping raw card details as 'evidence' — which does not help and creates real risk.
• Seasonal and part-time staff may never have had a minute of payment-security training.

How does card data actually flow through a hotel?

The front desk

A guest checking out taps or inserts their card at a PCI-approved terminal. This is your lowest-risk channel: the device encrypts the card data immediately and nothing readable stays on site. If this were your only way of taking payments you would likely qualify for SAQ B or B-IP — the same short questionnaires used by shops, as explained in our card machine compliance guide. If your terminal is ageing or lacks pre-authorisation, our payments partner NexPay (www.nexpay.uk) supplies PCI-approved terminals and pay-by-link tools built for hospitality — both remove reasons to ever write a card number down.

Your booking engine and website

Direct online bookings usually run through a booking engine with a hosted payment page: the guest types their card details into a page provided and secured by the payment company, and the data never touches your website. That keeps this channel in SAQ A territory. Many booking engines can also store a card as a secure token for no-show protection — the system keeps a reference, not the number, which is exactly what you want.

OTAs, channel managers and virtual cards

Booking.com, Expedia and similar OTAs often collect payment from the guest themselves and issue you a single-use virtual card to charge instead. The card appears in your extranet or channel manager, and a member of staff keys it into your terminal or virtual terminal on or after its activation date. Here is the point hotels miss: a virtual card is still a card number. The moment staff view it and key it in, you are handling cardholder data, and the same rules apply — retrieve it only when you are ready to charge it, key it straight in, and never copy it into a diary, spreadsheet or booking note.

Phone bookings and deposits

Deposits and balances taken over the phone are keyed into a virtual terminal or the card machine while the guest is on the line. This is the channel that drags most accommodation businesses up the compliance scale, because it puts card numbers in human hands. Our guide to taking card payments over the phone covers safe handling in detail, including pay-by-link — texting the guest a secure payment link — which takes the card number out of the conversation entirely.

What should you never do with a guest's card details?

• Never ask guests to email card details — and if one does anyway, take payment another way (a pay-by-link is ideal), then delete the email from every folder, including sent and deleted items.
• Never write card numbers in the bookings diary, on registration forms or on notes at the desk.
• Never store card details in the free-text 'notes' field of your property management system or channel manager — those fields are not designed or protected for card data.
• Never keep card numbers 'in case of a no-show' — use your terminal's pre-authorisation feature or your booking engine's tokenised card storage instead.
• Never read a card number back aloud across a busy front desk.

On the chargeback point: keeping a guest's raw card number does not help you win a no-show dispute. What wins disputes is evidence — a clearly communicated cancellation policy, the booking confirmation showing the guest accepted it, and a properly authorised transaction. Pre-authorisation and tokenised storage give you all of that without a single card number written down.

Which SAQ applies to a hotel or B&B?

It depends on your mix of channels — and hotels usually have several. Terminal-only businesses point at SAQ B or B-IP; a hosted booking engine alone points at SAQ A. Add a virtual terminal for phone bookings and OTA virtual cards, and you are looking at SAQ C-VT — which requires the virtual terminal to run on a dedicated, isolated computer, not the same machine used for email and browsing. Store card data anywhere, or mix payment channels into your general IT, and you are heading for SAQ D and its roughly 250 questions. Getting the scoping decisions right therefore makes an enormous practical difference — see SAQ A vs SAQ D explained for just how far apart the questionnaires are, and the complete PCI DSS compliance guide for how validation works end to end.

How do you keep seasonal staff from breaking your compliance?

Hospitality runs on seasonal and part-time staff, and your compliance is only as good as the newest person answering the phone. The fix is a fifteen-minute induction and a one-page procedure kept by the desk: never write card numbers down, how to take a phone payment or send a pay-by-link, how to retrieve and charge an OTA virtual card, how to take a pre-authorisation, and what to do if a guest emails card details. Repeat it at the start of every season. PCI DSS expects staff who handle card data to be trained — and in a small hotel that training is genuinely the cheapest security control you have.

What does this look like for a 10-room Devon B&B?

A worked example. A ten-room B&B on the Devon coast takes roughly half its bookings through Booking.com, a quarter through its own website's hosted booking engine, and a quarter by phone. Phone deposits are keyed into a virtual terminal in the back office, and Booking.com virtual cards are charged the same way. Nobody has ever completed an SAQ, and the merchant statement quietly shows a £15-a-month non-compliance fee — £180 a year for nothing.

Getting sorted looks like this: confirm the virtual terminal runs on a dedicated machine (pointing at SAQ C-VT rather than SAQ D), retire the paper diary habit, switch no-show protection to pre-authorisation, and complete the questionnaire properly. Done through our fully managed PCI compliance service at £100 + VAT a year, the B&B saves £60 a year against the penalty alone — before counting the hours not spent wrestling a 250-question form it never needed, and the far smaller chance of a breach. We work with accommodation businesses across the South West; see PCI DSS compliance in Devon and Plymouth for the local picture.