Aller au contenu principal
Tous les articles
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.

© 2026 Tiquo. « Tiquo » et le logo Tiquo sont des marques déposées de Tiquo Ltd.

GDPR · CCPA · PCI DSS · ICO · Cyber Essentials Certified · EU–US DPF · SOC 2 Type II (in progress) · ISO 27001 (in progress)

Security & Operational

  • 99.99% SLA Uptime
  • AES-256 encryption at rest
  • TLS 1.3 in transit
  • AES-256 / TLS 1.3
  • Perfect Forward Secrecy (PFS)
  • HTTP Strict Transport Security (HSTS)
  • 99.999999999% (11 nines) data durability
  • Automated backups
  • DDoS protection
  • Web Application Firewall (WAF)
  • Zero Trust posture
  • Role-Based Access Control (RBAC)
  • Principle of Least Privilege
  • Secret scanning in CI
  • SBOM generation
  • Dependency supply-chain controls
  • 24/7 infrastructure monitoring
  • GDPR Article 22 safeguards
  • Data Protection Impact Assessments (DPIAs)
  • Records of Processing Activities (ROPA)
  • SAML 2.0 SSO
  • EASIE SSO
  • OAuth 2.0 / OpenID Connect (OIDC)
  • SCIM 2.0 provisioning
  • MFA / 2FA enforcement
  • Responsible disclosure / bug bounty programme

Privacy, Data Protection & Statutory Obligations

  • ICO Registered
  • UK Modern Slavery Act 2015 compliant
  • UK Public Interest Disclosure Act 1998 compliant
  • EU Article 27 Representative appointed (Paris, France)
  • Swiss FADP Article 14 Representative appointed
  • UK GDPR compliant
  • EU GDPR/DSGVO compliant
  • UK Data Protection Act 2018 compliant
  • Swiss revFADP compliant
  • CCPA / CPRA compliant (California)
  • VCDPA compliant (Virginia)
  • CPA compliant (Colorado)
  • CTDPA compliant (Connecticut)
  • TDPSA compliant (Texas)
  • OCPA compliant (Oregon)
  • MCDPA compliant (Montana)
  • FDBR compliant (Florida)
  • ICDPA compliant (Iowa)
  • ICDPA compliant (Indiana)
  • TIPA compliant (Tennessee)
  • DPDPA compliant (Delaware)
  • NJDPA compliant (New Jersey)
  • NHDPA compliant (New Hampshire)
  • NDPA compliant (Nebraska)
  • MCDPA compliant (Minnesota)
  • MODPA compliant (Maryland)
  • KCDPA compliant (Kentucky)
  • RIDTPPA compliant (Rhode Island)
  • Canada PIPEDA compliant
  • Quebec Law 25 compliant
  • Alberta PIPA compliant
  • British Columbia PIPA compliant
  • Singapore PDPA compliant
  • Hong Kong PDPO compliant
  • Brazil LGPD compliant
  • Japan APPI compliant
  • Australia Privacy Act / APPs compliant
  • India DPDPA 2023 compliant
  • Thailand PDPA compliant
  • Malaysia PDPA 2010 (as amended 2024) compliant
  • New Zealand Privacy Act 2020 compliant
  • South Africa POPIA compliant
  • UAE PDPL compliant
  • Mexico LFPDPPP compliant
  • Kenya Data Protection Act 2019 compliant
  • Ghana Data Protection Act 2012 compliant
  • Nigeria NDPA 2023 compliant
  • Indonesia PDP Law 2022 compliant
  • Philippines Data Privacy Act 2012 compliant

Global Fiscal & E-Invoicing

  • EN 16931 - EU e-invoicing core standard
  • UBL 2.1 - Universal Business Language
  • Austria - RKSV
  • Belgium - Peppol BIS 3.0 (B2B)
  • Czechia - fiscalization
  • Croatia - Fiscalization 2.0
  • Denmark - Peppol BIS 3.0 (B2B)
  • France - NF525 / LNE / Infocert, Factur-X / PDP, E-Reporting
  • Germany - KassenSichV / TSE, DSFinV-K, GoBD, E-Rechnung B2B (XRechnung / ZUGFeRD)
  • Hungary - Online Szamla
  • Italy - Scontrino, FatturaPA (via SDI)
  • Lithuania - i.SAF / i.MAS
  • Norway - Peppol BIS 3.0 (B2B), SAF-T
  • Poland - KSeF
  • Portugal - ATCUD/QR, SAF-T PT
  • Slovakia - eKasa
  • Slovenia - fiscalization (davcno potrjevanje)
  • Spain - FacturaE, SII, VeriFactu, TicketBAI
  • Sweden - SKVFS (certified cash registers)
  • Argentina - ARCA (Q4 2026)
  • Australia - Peppol PINT A-NZ (Q4 2026)
  • Brazil - NFe, NFCe, NFSe (Q4 2026)
  • Chile - SII Chile (Q4 2026)
  • Colombia - DIAN (Q4 2026)
  • Finland - Finvoice, TEAPPSXML (Q4 2026)
  • Japan - JP PINT (Peppol) (Q3 2026)
  • Malaysia - Peppol Malaysia (Q4 2026)
  • Mexico - CFDI (Q4 2026)
  • New Zealand - Peppol PINT A-NZ (Q4 2026)
  • Peru - SUNAT (Q4 2026)
  • Romania - Peppol (RO e-invoice) (Q4 2026)
  • Saudi Arabia - ZATCA (Q4 2026)
  • Singapore - Peppol BIS 3.0 (Q4 2026)
  • United Arab Emirates - Peppol (5C) (Q4 2026)

Standards & Frameworks

  • Cyber Essentials Certified
  • SOC 2 Type II - audit in progress
  • ISO/IEC 27001 - audit in progress
  • NIST Cybersecurity Framework - aligned
  • NIST Privacy Framework - aligned
  • NIST SP 800-53 / 800-63 / 800-63B - aligned
  • NIST AI Risk Management Framework - aligned
  • CIS Critical Security Controls / CIS Benchmarks - aligned
  • OWASP ASVS & OWASP Top Ten - aligned
  • ISO 25010 (quality) - aligned
  • ISO 31000 (risk) - aligned
  • ITIL - aligned
  • W3C Web Standards - aligned
  • OpenAPI Standard - aligned
  • DevSecOps practices - aligned
  • ePrivacy Directive - aligned
  • EU Whistleblowing Directive (2019/1937) - aligned

Payments Compliance

  • PCI DSS Level 1
  • PSD2 / Strong Customer Authentication
  • 3D Secure (3DS)
  • EMVCo Level 1 & 2
  • AML / KYC controls
  • Sanctions screening (OFAC, UN, EU, HMT)

International Data Transfer Mechanisms

  • EU-US Data Privacy Framework
  • EU Standard Contractual Clauses (Decision 2021/914) - Modules 2 & 3
  • UK International Data Transfer Agreement (IDTA) + ICO Addendum
  • Swiss FDPIC-recognised transfer mechanisms
  • APEC Cross-Border Privacy Rules (CBPR)

Accessibility Compliance

  • ADA (Americans with Disabilities Act) - aligned
  • European Accessibility Act (EAA) 2025 - aligned
  • WCAG 2.2 - aligned
  • EN 301 549 - aligned
  • WAI-ARIA - aligned

Une plateforme unique pour hôtels, spas, cours, événements, restaurants et plus encore.

Tiquo Ltd
Londres, Royaume-Uni

LinkedInTop Performer Spring

Nous utilisons des cookies

Choisissez si vous autorisez les cookies d’analyse et de publicité. Vous pouvez les accepter ou les refuser. Fermer cet avis revient à les refuser.

En savoir plus