मुख्य सामग्री पर जाएं
सभी लेख
POSApr 15, 2026

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.

SAQTypical venue setupWhat it involves
SAQ AOnline deposits, prepayments or vouchers taken on a payment page fully hosted by a PCI DSS compliant provider, by redirect or embedded iframeThe 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-EPYour website builds the payment form, or loads scripts that create it, and card data goes from the browser straight to the processorYour website and web server are in scope, so many more requirements apply than for SAQ A
SAQ B-IPStandalone PTS-approved card terminals connected to the processor over IP, with no electronic card data storageThe terminals must not connect through other systems, such as a till PC
SAQ C-VTStaff enter card details one at a time into a provider's web-based virtual terminal, for example for phone bookingsThe computer used must have no connections to other locations or systems, and nothing is stored electronically
SAQ CA payment system connected to the internet, such as an integrated POS, with no electronic card data storageCovers the payment system and the network it sits on
SAQ P2PEHardware terminals that are part of a point-to-point encryption solution listed by the PCI Security Standards CouncilFewer requirements apply, because card data is encrypted from the moment the card is read
SAQ DAnything else, including storing card numbers electronicallyEvery 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.

हम कुकीज़ का उपयोग करते हैं

एनालिटिक्स और विज्ञापन के लिए कुकीज़ की अनुमति देना चाहते हैं या नहीं, यह चुनें। आप इन्हें स्वीकार या अस्वीकार कर सकते हैं। यह सूचना बंद करने पर भी इन्हें अस्वीकार कर दिया जाएगा।

और जानें