PCI-DSS Basics for Restaurants: What Card Payments Actually Require in 2026

PCI-DSS is the Payment Card Industry Data Security Standard — the rulebook every business that accepts cards must follow to protect cardholder data.

If you take Visa, Mastercard, or Amex at your restaurant, PCI-DSS applies to you. The good news: in 2026 most small restaurants never touch raw card numbers, so compliance is mostly a short self-assessment, not a six-figure audit.

What is PCI-DSS and who has to comply?

Every merchant that stores, processes, or transmits cardholder data must comply. There are four merchant levels based on annual card volume. Almost every independent restaurant is Level 4 (under 20,000 e-commerce transactions or under 1 million total a year), which is the lightest tier.

Non-compliance is not a vague risk. After a breach, card networks can fine your acquiring bank $5,000 to $100,000 per month, and that cost flows straight down to you. A single breached terminal can also trigger forensic-audit fees of $10,000 or more.

What are SAQ types and which one do I need?

A Self-Assessment Questionnaire (SAQ) is how a Level 4 merchant proves compliance. The type depends on how card data flows through your setup:

• SAQ A — you fully outsource card handling to a PCI-compliant provider; no card data ever touches your systems. ~22 questions. This is the goal.
• SAQ A-EP — e-commerce where your site affects the payment but does not receive card data. ~190 questions.
• SAQ B / B-IP — standalone dial-out or IP terminals.
• SAQ C / C-VT — payment applications connected to the internet or virtual terminals.
• SAQ D — you store or process card data directly. ~330 questions, and far more expensive to maintain.

The difference between SAQ A and SAQ D is the difference between an afternoon and a multi-week project. Architecture decides which one you fill out.

Why you must never store card data

The cheapest card data to protect is the data you never hold. Storing the full PAN (card number), and especially the CVV after authorization, is the fastest way to fall into SAQ D and become a breach target. PCI-DSS flatly forbids storing the CVV at all once a transaction is authorized.

Worked example: a restaurant that writes card numbers on paper tickets or saves them in a spreadsheet to charge later is processing and storing cardholder data manually. That is SAQ D territory, it is a liability nightmare, and one stolen laptop becomes a reportable breach.

How hosted checkout keeps you out of scope

With Direct Dine, online card payments use hosted checkout: the customer is handed to the payment provider's own secure page (or an embedded Stripe field), enters their card there, and your servers only ever receive a token and a success/fail result. The raw card number never reaches Direct Dine, so you stay on the SAQ A path — the 22-question version.

Because Direct Dine is commission-free, you also are not handing a delivery marketplace 25–30% just to process a payment you could own outright. You keep the margin and the simplest possible compliance footprint.

When the easy path does NOT apply

• You key card numbers into a back-office system by hand → you are processing card data and lose SAQ A eligibility.
• You store cards to bill regulars later without using the provider's vault/tokenization → SAQ D.
• You run an old terminal that is not P2PE-validated → larger SAQ, more obligations.

This is general information, not legal or compliance advice — confirm your exact SAQ with your acquirer or a QSA.

For most restaurants the takeaway is simple: never hold the card number, use hosted checkout, and your yearly PCI work shrinks to a short questionnaire.