PCI DSS compliance for restaurants and hotels
PCI DSS compliance applies to every restaurant, bar and hotel that accepts card payments, whatever its size. The Payment Card Industry Data Security Standard is maintained by the PCI Security Standards Council, while the card schemes and your acquirer (the provider that settles your card payments) decide how you prove you meet it. For most independent venues and small groups, that proof is a self-assessment questionnaire (SAQ) completed each year.
How much work the SAQ involves depends on where card data travels in your business. A venue that takes payments only on approved terminals and through a payment page hosted by its provider has a short questionnaire. One that types card numbers into a back-office PC, or keeps guarantee details in a bookings diary, brings far more of its systems into scope.
What is PCI DSS, and which version applies?
PCI DSS is an industry standard for any organisation that stores, processes or transmits cardholder data. Your obligation to follow it comes through the card scheme rules and your agreement with your acquirer, which is also who you report compliance to.
The current version is PCI DSS v4.0.1, published in June 2024 as a limited revision of v4.0 with no requirements added or removed. Version 4.0 was retired on 31 December 2024. Requirements that v4.0 introduced as best practice, known as future-dated requirements, became mandatory on 31 March 2025. They include two controls aimed at the scripts that run on e-commerce payment pages.
Who is responsible for PCI DSS compliance if a provider handles payments?
Your business stays responsible. Payment providers are assessed against PCI DSS as service providers, and a good integration keeps most card data away from your systems. Stripe, for example, describes PCI compliance as a shared responsibility: Stripe is certified each year as a Level 1 service provider, and every business accepting payments must do so in a compliant way and attest to that annually.
The way you connect to a provider can reduce the number of requirements that apply to you, but the attestation is still made by your business. The card schemes group merchants into levels, mainly by annual transaction volume, and your level affects how you validate. The Council's advice is to ask the organisation you report compliance to, usually your acquirer, whether you need to submit an SAQ and, if so, which one.
Which SAQ applies to a restaurant or hotel?
Each SAQ has eligibility criteria, and you can use one only if you meet all of them. These are the questionnaires hospitality businesses most often come across.
| SAQ | Typical venue setup | What it involves |
|---|---|---|
| SAQ A | Online deposits, prepayments or vouchers taken on a payment page fully hosted by a PCI DSS compliant provider, by redirect or embedded iframe | The shortest questionnaire. Under the current SAQ A you also confirm your website is not susceptible to script attacks that could affect your e-commerce systems, and the provider of an embedded payment form can give you that confirmation for its own solution |
| SAQ A-EP | Your website builds the payment form, or loads scripts that create it, and card data goes from the browser straight to the processor | Your website and web server are in scope, so many more requirements apply than for SAQ A |
| SAQ B-IP | Standalone PTS-approved card terminals connected to the processor over IP, with no electronic card data storage | The terminals must not connect through other systems, such as a till PC |
| SAQ C-VT | Staff enter card details one at a time into a provider's web-based virtual terminal, for example for phone bookings | The computer used must have no connections to other locations or systems, and nothing is stored electronically |
| SAQ C | A payment system connected to the internet, such as an integrated POS, with no electronic card data storage | Covers the payment system and the network it sits on |
| SAQ P2PE | Hardware terminals that are part of a point-to-point encryption solution listed by the PCI Security Standards Council | Fewer requirements apply, because card data is encrypted from the moment the card is read |
| SAQ D | Anything else, including storing card numbers electronically | Every applicable PCI DSS requirement |
Plenty of venues take payments in more than one way: terminals at the bar, a hosted page for deposits and the occasional phone booking. Each channel has to fit the SAQ you use, so ask your acquirer how it wants a mixed setup reported before you start.
How do hosted payment pages and tokenised terminals reduce PCI scope?
Your PCI scope is every system that stores, processes or transmits card data, plus the systems connected to them or able to affect their security. The fewer of your own systems that ever see a card number, the fewer requirements apply. Providers publish which SAQ their products support. Stripe's guide maps its hosted Checkout and embedded Elements fields to SAQ A, and card collection only through its Terminal readers to SAQ C.
Tokenisation helps with anything you need to charge later. The provider keeps the card details and gives you a token, a substitute value that is useless to a thief, which you can use for refunds, follow-up charges or a balance at checkout. That is how a restaurant can hold a card guarantee for a booking without storing a card number.
Point-to-point encryption (P2PE) protects card data from the moment a card is read until it reaches the provider's secure decryption environment. Merchants using a solution on the Council's P2PE list have fewer applicable requirements. A terminal that encrypts data is not automatically part of a listed solution, so check the P2PE listing, or ask your provider, before assuming SAQ P2PE applies.
Where do restaurants and hotels create PCI risk?
Watch for these workarounds, each of which widens your scope or breaks the rules outright:
- Card numbers taken over the phone and written on paper, in a diary or in an email. Any record like that is in scope, and paper card data you no longer need should be securely destroyed.
- Keeping the three- or four-digit security code after a payment has been authorised. PCI DSS does not allow it, and a guest asking you to keep it does not change that.
- A virtual terminal used on the same PC staff use for email, bookings and browsing. SAQ C-VT expects that computer to have no connections to other locations or systems.
- Card terminals that connect through a till or another system, which takes them outside SAQ B-IP.
- Chat widgets, tracking tags and other third-party scripts on pages that host an embedded payment form. Merchants using SAQ A now have to confirm their site is not susceptible to script attacks that could affect their e-commerce systems.
What does annual PCI validation involve?
Validation is the yearly evidence that you meet the standard. In practice it means confirming with your acquirer which SAQ applies, completing it against how you take payments today, and signing the attestation of compliance that comes with it. Depending on the SAQ, you may also need quarterly external vulnerability scans from an Approved Scanning Vendor.
Treat the SAQ as a description of your current setup. If you add a phone booking line, swap terminals or rebuild the website, check whether you still meet its eligibility criteria. A simple diagram of every way a card payment enters the business, with the provider and device used for each, makes that check quick, and it is worth reviewing before you sign each year's attestation.
Tiquo processes card payments through Stripe, which is certified as a PCI DSS Level 1 service provider. Card data is tokenised within Stripe's systems, and Tiquo does not store cardholder data. Your business still has its own PCI responsibilities, including validating compliance in the way your payment provider asks. The payments page, the security page and our article on how Tiquo works with Stripe explain how card data is handled.
This is general information, not compliance advice. Check the current SAQ documents published by the PCI Security Standards Council and confirm your validation requirements with your acquirer.
Nieuwste artikelen
WebMCP explained: how AI agents can book through hospitality websites
What WebMCP is, how websites register tools that AI agents in the browser can call, where the standard and Chrome support stand in October 2026, and what it means for booking pages.
How to sell spa treatments and dining to hotel guests before they arrive
Pre-arrival upselling for hotels: when to send spa and dining offers, what to offer which guests, how to make offers bookable, and the UK consent rules for promotional messages.
How to split bills and move tabs between tables
How to split bills by item, seat, equal share or amount, and how to move a tab or selected items to another table without sending food to the kitchen twice or charging twice.