PCI compliance for restaurants, bars, cafes and food trucks
PCI DSS is the card industry's security standard. If you accept cards, your agreement with your payment processor requires you to follow it, and most restaurants, bars and cafes prove it once a year by filling in a Self-Assessment Questionnaire (SAQ), a checklist your processor or bank asks for.
Which SAQ you need depends on how you take cards, not on what you serve. Most places take them two or three ways: at the counter or the table, online, and over the phone. Each of those is its own payment method, with its own SAQ, and most of them are short.
How restaurants, bars and cafes usually take cards, and the SAQ for each
Each way you take cards is its own payment method, and each one gets its own SAQ. Most businesses have two or three.
| Payment method | Usually | Why |
|---|---|---|
| Countertop or pay-at-table terminal on its own A card machine by the register, or a handheld the server brings to the table so guests tap or insert, add a tip and pay without the card leaving their sight. It connects to the processor by itself over Wi-Fi, Ethernet or cellular. |
SAQ B-IP / SAQ P2PE / SAQ B SAQ B-IP; SAQ P2PE if it is part of a PCI-listed P2PE solution; SAQ B for a phone-line terminal |
The terminal sends the card straight to your processor, and nothing else in the restaurant touches the card number. P2PE (point-to-point encryption) means the card is encrypted inside the terminal under a solution PCI SSC has listed, which makes the SAQ shorter still. Watch out: If the handheld is linked to your POS so checks and tips sync, it is part of the POS system below, not a standalone terminal. |
| POS system with card readers A point-of-sale (POS) system on tablets or touchscreens at the counter, bar and floor, often cloud-based, with card readers built in or attached, used to open checks, split bills and close tabs. |
SAQ C / SAQ P2PE / SAQ D Often SAQ C; SAQ P2PE if the provider's solution is PCI-listed P2PE; SAQ D if card numbers are stored or several locations share one network |
The card reader feeds a POS running on internet-connected devices, so those devices and your network are part of the payment. A PCI-listed P2PE solution encrypts the card inside the reader so the POS never sees it, which is why its SAQ is so much shorter. Watch out: "Encrypted" is not the same as PCI-listed P2PE. Ask your POS provider for the solution's listing on the PCI SSC website before you assume SAQ P2PE. |
| Online ordering Pickup, delivery and catering orders on your own website or app, through your POS provider's online ordering or an ordering service. |
SAQ A / SAQ A-EP / SAQ D SAQ A if the ordering provider supplies the whole checkout or its embedded card fields; SAQ A-EP if your own site builds the card form |
When every part of the card form comes from a PCI DSS compliant provider, on its own page or as its secure fields embedded in yours, card numbers never touch your website. Watch out: If the provider's card fields are embedded in your own page, SAQ A also asks you to confirm the page is protected against malicious scripts, usually with your provider's written confirmation. Orders paid inside a delivery marketplace app are usually the app's payment, not yours. |
| Phone orders Takeout or catering orders by phone, where staff take the card number and type it into a payment web page, the POS or a terminal keypad. |
SAQ C-VT / SAQ C SAQ C-VT if staff type cards into your provider's web-based virtual terminal on one dedicated computer; if typed into the POS or a terminal, that system's SAQ covers it |
A virtual terminal is a payment web page your provider hosts. Typing card numbers into it one at a time, on one computer kept apart from the rest of your network, is what SAQ C-VT covers. Watch out: Taking card numbers by text, email or chat means you receive card data electronically, which rules out the short SAQs. A payment link from your provider, where the customer types the card in, is usually SAQ A. |
| Phones and tablets as card readers A food truck, market stand or patio server taking cards on a phone or tablet, either with a small card reader paired to it or with Tap to Pay, where the card is tapped on the phone itself. |
SAQ SPoC SAQ SPoC if it is a PCI-listed SPoC solution with its secure card reader; for tap-on-phone with no reader, ask your provider which SAQ it supports |
SAQ SPoC is for a phone or tablet paired with a secure card reader that is part of a solution PCI SSC has validated and listed. Tap-on-phone apps without a separate reader are built to other PCI standards (CPoC and MPoC), and there is no SAQ written specifically for them. Watch out: Not every phone reader is a listed SPoC solution. Ask your provider for its PCI SSC listing and which SAQ your processor expects for it. |
Find out which SAQ fits each way you take payments, free
Describe how you take payments in your own words. We'll tell you which SAQ fits each one, free, before you pay anything.
One restaurant, several payment methods
PCI SSC, the council that writes the card security standards, says a business with several payment channels may complete a separate SAQ for each channel, as long as each channel meets the conditions of its SAQ and the channels are kept separate from one another. That is the rule we apply: one SAQ per payment method.
So a cafe with a standalone terminal, online ordering and a virtual terminal for catering calls usually completes three short SAQs (for example SAQ B-IP, SAQ A and SAQ C-VT) rather than one long one. Having several channels is not, on its own, a reason to file SAQ D. Your acquirer, the bank behind your processor, decides which forms it wants.
Your POS provider holds most of the answers
For most restaurants the POS is the biggest payment method, and whether it is SAQ C, SAQ P2PE or something else depends on the provider's solution, not on anything you can see on the screen. Questions to put to your POS provider:
- Are your card readers part of a PCI-listed P2PE solution? What is its listing on the PCI SSC website?
- Which SAQ do you tell merchants with my setup to complete?
- Do full card numbers ever reach the POS tablets, our network or your reports, or only tokens (stand-in codes in place of the card number)?
- If we key in a phone order, does that go through the same protected reader or a different path?
- Can you send us your PCI DSS Attestation of Compliance (AoC), the signed summary of your own PCI assessment?
- Who can connect remotely to our POS for support, and how is that access controlled?
Tips, bar tabs and pay-at-table
Tips do not change your SAQ. They are added to the card's authorization in the POS or terminal, so there is never a reason for a server to write down a card number to add a tip later.
Pay-at-table handhelds keep the card in the guest's hand, which avoids walking it away to a back-room terminal. For bar tabs, many POS systems let you open the tab by authorizing the card and handing it straight back, rather than keeping guests' cards behind the bar.
Never keep the three- or four-digit security code. PCI SSC says card verification codes may not be kept once the transaction they were collected for is authorized, including for future charges, even if the customer agrees.
Delivery apps and your own online ordering
When a customer orders and pays inside a delivery marketplace app, the app takes the payment and pays you later, so you never handle that card. Those orders are usually not a card payment method you validate. Confirm with your processor if you are unsure.
Online ordering on your own website or app is yours. If the checkout comes entirely from your POS provider or ordering service, on its own page or as its embedded card fields, it is usually SAQ A. If a developer built the card form on your site, it is usually SAQ A-EP, and if card numbers ever reach your own server, SAQ D.
Protecting terminals, receipts and the network
Card terminals in a busy dining room or at a bar are a target for tampering and swapping. PCI DSS asks businesses to keep a list of their terminals, inspect them regularly for signs of tampering, and train staff to spot it, for example by checking for unfamiliar attachments and verifying anyone who says they have come to repair a terminal.
Keep guest Wi-Fi on a separate network from card terminals and the POS. Receipts and reports should show only the last few digits of a card; if yours show full card numbers, ask your provider to fix it. Anything on paper with a card number on it should be locked up and cross-cut shredded when you no longer need it.
Your checklist
- List every way you take cards: counter, tables, bar, online ordering, phone orders, catering and events.
- For each one, note where the card number goes: a standalone terminal, the POS, a virtual terminal, an online checkout or a phone app.
- Ask your POS provider whether its readers are a PCI-listed P2PE solution, and check the listing on the PCI SSC website.
- Ask your online ordering provider to confirm its checkout supplies the whole card form, and get its written confirmation about script protection if the card fields are embedded in your site.
- Stop taking card numbers by text, email or chat; send a payment link from your provider instead.
- Make sure no one writes down card numbers for tips or tabs, and that security codes are never kept.
- Put card terminals and the POS on a network separate from guest Wi-Fi.
- Inspect terminals and handhelds for tampering on a regular schedule and show staff what to look for.
- Complete one SAQ for each payment method and submit them the way your processor asks.
Common questions
Do I need PCI compliance if my POS company handles everything?
Yes. If you accept cards, your merchant agreement requires you to follow PCI DSS and usually to complete an SAQ each year. A good POS provider makes your SAQ short because it does most of the work, but you still confirm how you use it, and your processor still expects the form.
Is my cloud POS SAQ C or SAQ P2PE?
It depends on the provider's solution. If the card readers are part of a solution listed on the PCI SSC website as validated P2PE, and you follow its instruction manual, it is usually SAQ P2PE. If not, a POS connected to the internet is usually SAQ C. Ask your provider for the listing and for the SAQ it tells merchants to use.
Are pay-at-table handhelds a separate SAQ?
Only if they work on their own. A handheld that connects straight to the processor is its own payment method, usually SAQ B-IP or SAQ P2PE. A handheld that is part of your POS, so checks and tips sync to it, is covered by the POS system's SAQ.
Do orders through delivery apps count toward my PCI compliance?
Usually not, when the customer pays inside the app: the app takes the card and pays you out, so you never handle it. Your own online ordering, your phone orders and your in-person payments are still yours, each with its own SAQ.
Can I take cards with Tap to Pay on my phone?
Many providers offer it, but check which SAQ applies before you rely on it. SAQ SPoC covers a phone or tablet paired with a secure card reader in a PCI-listed SPoC solution. Tap-on-phone with no reader is built to different PCI standards and has no SAQ of its own, so ask your provider and processor which form they expect.
Can servers write down card numbers to add tips later?
No need, and best not to. Tips are added to the existing authorization in your POS or terminal. Any card number on paper must be locked up and shredded, and the security code must never be kept after the payment is authorized.
Why is there a PCI non-compliance fee on my statement?
Your processor has not received proof that you completed your yearly PCI validation, meaning the SAQs and the signed Attestation of Compliance. The fee usually repeats every month until you send them the way your processor asks. Our guide at complianceassessmenttool.com/pci-non-compliance-fee explains how to stop it.
Ready to see your SAQs?
Describe how you take payments in your own words. We'll tell you which SAQ fits each one, free, before you pay anything.
Other businesses
Sources
- PCI SSC FAQ 1082: Should a merchant with multiple processing environments complete multiple SAQs?
- PCI SSC FAQ 1280: Can card verification codes be stored for card-on-file or recurring transactions?
- PCI SSC FAQ 1588: How an e-commerce merchant meets the SAQ A criterion for scripts
- PCI SSC Document Library (PCI DSS v4.0.1 and the SAQs, with their eligibility criteria)
- PCI SSC list of validated Point-to-Point Encryption (P2PE) solutions
- PCI SSC list of validated Software-based PIN Entry on COTS (SPoC) solutions
- PCI SSC Mobile Payments on COTS (MPoC) standard
- PCI SSC Data Security Essentials for Small Merchants: Guide to Safe Payments
General guidance, not legal advice. Your acquirer or payment processor decides which SAQ you must file. PCI DSS v4.0.1; content checked 2026-10-23.