PCI Compliance for Restaurants and Takeaways: A UK Guide

Few businesses juggle as many ways of taking card payments as a restaurant or takeaway. A busy Friday night might involve the counter terminal, a pay-at-table device, three phone orders with card numbers read out over the noise of the kitchen, and a steady stream of online orders. Every one of those channels is covered by PCI DSS — the card industry's security standard — and each one affects what you have to do to comply. This guide walks through the typical hospitality payment mix, channel by channel, and shows what compliance actually looks like in practice.

Does PCI DSS really apply to a small restaurant or takeaway?

Yes. PCI DSS applies to any business that accepts, processes or transmits cardholder data, whatever its size or sector. It is not a law but a contractual obligation to your acquirer — the bank or payment company that settles your card takings — and it applies just as much to a two-person takeaway as to a national chain. For the background on how the standard works end to end, see our complete PCI DSS compliance guide.

The good news is that small hospitality businesses validate compliance with a Self-Assessment Questionnaire (SAQ) rather than an external audit, and the right payment setup keeps that questionnaire short. The bad news is what happens if you ignore it: most acquirers add a non-compliance fee of roughly £5 to £25 a month to your statement until you validate — money that buys you nothing at all.

What does a typical hospitality payment mix look like?

Most restaurants and takeaways take payments through some combination of the following:

• A counter terminal for walk-in and collection customers.
• Pay-at-table devices or handheld terminals brought to the table.
• Phone orders, where the customer reads out their card number for a delivery or collection.
• Online ordering through your own website or app.
• Marketplace platforms such as Deliveroo, Just Eat or Uber Eats.

PCI DSS cares about exactly where card details travel and what could go wrong on the way, so each channel is treated differently. The more channels you add, the more questions you answer at validation time — unless a channel keeps card data away from your business entirely, in which case it may not touch your compliance at all.

What does each payment channel mean for your SAQ?

Counter and pay-at-table terminals

Modern PCI-approved terminals encrypt card data the moment it is captured, so the card number never sits readable on your premises. If your terminals are standalone devices — connecting over a phone line or the internet — and you never store card data electronically, you will usually qualify for SAQ B or SAQ B-IP, two of the shortest questionnaires. We cover this setup in detail in do I need PCI compliance if I only use a card machine? If your terminals are integrated into an EPOS till system, scope can widen towards SAQ C, because the till network becomes part of the payment flow. If you are choosing or replacing hardware, our payments partner NexPay (www.nexpay.uk) supplies PCI-approved card machines and EPOS for hospitality, which keeps this part of the assessment simple.

Phone orders

The moment a member of staff hears, writes down or types a customer's card number, your people and your premises are inside PCI scope. Keying the number straight into a terminal or a virtual terminal typically points towards SAQ C-VT — and if card details are ever stored, on paper or electronically, you are heading for SAQ D, the longest questionnaire of all. More on why this channel deserves special care below.

Online ordering on your own website

If your website or app hands customers over to a hosted payment page — the checkout is provided and secured by your payment company, and card details never touch your site — you are usually in SAQ A territory, the simplest validation there is. If your developer has built a more integrated checkout where your own code influences the payment page, expect SAQ A-EP, which is considerably longer. When commissioning an ordering site, 'hosted payment page, please' is one of the cheapest compliance decisions you will ever make.

Why are phone orders the biggest risk in a takeaway?

It is Friday night, the phone will not stop, and a customer wants to pay by card. The classic failure is the notepad by the till: card numbers jotted down to key in later, or kept 'on file' for regular customers. Under PCI DSS, keeping card details on paper, in the till notes, in a spreadsheet or in your order system is stored cardholder data — precisely what the standard exists to prevent. One tatty notebook can drag a takeaway from a short questionnaire into SAQ D, and it is a genuine breach risk: anyone in the shop can photograph a page in seconds.

The safe habits are simple: key the number directly into the terminal while the customer is on the line, never repeat the full number back aloud, and never write it down — if a note is unavoidable mid-rush, destroy it the moment the payment is made. Better still, use pay-by-link, where you text or email the customer a secure payment link and no card number is ever spoken. Our guide to taking card payments over the phone covers the do's, don'ts and alternatives in full.

Are Deliveroo, Just Eat and Uber Eats orders in my PCI scope?

Broadly, no — and this surprises many owners. When a customer orders through a marketplace app, they pay the platform, not you. The platform processes the card payment on its own systems, sends you an order ticket, and settles your money later. The customer's card details never reach your business, so those transactions sit outside your PCI validation.

The picture changes when you sell through your own website or app: there, you are the merchant, and the checkout is in your scope as described above. Neither route is 'wrong' — plenty of takeaways happily run the apps alongside a hosted checkout of their own and stay on SAQ A. Just remember the platforms do nothing for your other channels: your counter terminal and your phone orders still need validating even if most of your volume arrives through the apps.

What about tips and bar tabs?

Two hospitality habits deserve a mention. Tips added at the terminal or pay-at-table device are no problem — the amount is adjusted inside the device's encrypted flow, so nothing changes for compliance. Bar tabs are the edge case. The old habit of keeping a customer's card behind the bar, or writing its number down 'in case they walk', is storage of cardholder data — and holding the physical card brings its own risks if it is lost or misused. Use your terminal's pre-authorisation feature instead: it reserves an amount against the card when the tab opens and completes the real payment when it closes, with nothing kept in a drawer.

What does getting compliant actually cost?

Here is a worked example. A takeaway has never validated its compliance, so its acquirer adds a £20-a-month non-compliance penalty to the statement — £240 a year, often unnoticed among the other charges (see the PCI fee on your statement, explained for how to spot it). Compare that with getting sorted: our fully managed PCI compliance service costs £100 + VAT a year, covers the assessment, the paperwork and the filing with your acquirer, and makes the penalty disappear. The takeaway ends the year roughly £120 better off — and, more importantly, it has actually closed its security gaps rather than paying monthly to ignore them.

The same logic holds for a full-service restaurant with pay-at-table devices, a hosted online checkout and phone bookings. The questionnaire is a little longer and the data flows need mapping properly, but the price of the managed service is the same flat fee — and the alternative is still a recurring penalty plus the risk of carrying it indefinitely.

Key takeaways

• PCI DSS applies to every restaurant, café and takeaway that takes cards — the delivery apps do not do it for you.
• Standalone terminals are the easy part: usually SAQ B or B-IP.
• Phone orders are the biggest risk — never store card numbers on paper or in your order system.
• Deliveroo and Just Eat-style orders are normally outside your scope; your own website checkout is not.
• A £20 monthly non-compliance penalty costs more than a whole year of managed compliance at £100 + VAT.