PCI compliance for retail stores, boutiques and market stalls
PCI DSS (the Payment Card Industry Data Security Standard) is the card industry's security rulebook. A small shop shows it follows the rules by completing a Self-Assessment Questionnaire, or SAQ, usually once a year, for its acquirer: the bank or processor that pays your card sales into your account.
Which SAQ you need depends on how a card gets from your customer to your processor, not on what you sell. A boutique, a convenience store and a hardware store with the same counter terminal file the same SAQ for it. What makes retail tricky is that most shops take cards more than one way: at the counter, on a reader at the weekend market, through an online shop, and on the odd phone order.
PCI SSC, the council that writes the standard, says a merchant with several payment channels may complete a separate SAQ for each one, as long as each channel meets that SAQ's conditions and the channels are kept apart from each other (PCI SSC FAQ 1082). So the rule is one payment method, one SAQ. For most shops that means two or three short SAQs, not one long one.
How retail stores 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 card terminal The card machine by the till that your processor supplied, where you key in the amount and the customer taps, inserts or swipes. It plugs into your internet router, uses Wi-Fi or a SIM card, or on older models a phone line. |
SAQ B-IP / SAQ B / SAQ P2PE SAQ B-IP if it connects over the internet, SAQ B if it dials out over a phone line, or SAQ P2PE if it is part of a PCI-listed P2PE solution |
The terminal reads the card and talks straight to your processor, and nothing else in the shop touches the card number, so only the terminal and how it is connected need checking. Watch out: If the terminal is wired to your register or till software, it is part of a POS system (next row). SAQ B-IP also expects the terminal to be kept apart from the network your staff and customers use for browsing. |
| Register or tablet POS system Point-of-sale software on a computer, tablet or touchscreen register, with a card reader that feeds each sale into it. Common in boutiques, gift shops and hardware stores that track stock at the till. |
SAQ C / SAQ P2PE Usually SAQ C, or SAQ P2PE if the card readers are part of a PCI-listed P2PE solution |
The register or tablet is connected to the internet and sits in the payment flow, so SAQ C covers that device, your shop network and how the two are kept apart. With a validated P2PE (point-to-point encryption) solution, the card is encrypted inside the reader and your register never sees it, which is why SAQ P2PE is much shorter. Watch out: SAQ C is for a single location. Several shops on one shared network, or any system that saves card numbers, usually means SAQ D. A brochure that says the reader is encrypted is not the same as a PCI-listed P2PE solution. |
| Card reader on a phone or tablet A small reader paired to your phone or tablet for market stalls, craft fairs, pop-up shops and sidewalk sales, or a phone app that takes contactless cards with no reader at all (often sold as Tap to Pay). |
SAQ SPoC SAQ SPoC if your provider's solution is PCI-listed as a SPoC solution; otherwise ask your provider which SAQ their solution supports |
A phone is an everyday device that runs other apps, so PCI treats this setup as low-risk only when the whole solution, reader and app together, has been validated and listed by PCI SSC. SAQ SPoC is written for listed SPoC solutions: a secure card reader paired with a phone or tablet. Watch out: SAQ B-IP does not cover readers that depend on a phone or tablet to connect. Phone-only contactless apps fall under other PCI standards (CPoC or the newer MPoC) that have no SAQ named after them, so ask your provider which SAQ they support and confirm it with your acquirer. |
| Online store A web shop on a store builder or your own website where customers pay at checkout, including buy-online, pick-up-in-store orders. |
SAQ A / SAQ A-EP / SAQ D Usually SAQ A when your payment provider supplies the checkout page or its secure card fields |
If every part of the card form comes from your payment provider, on its own checkout page or as its secure fields embedded in your page, your website never handles card numbers. With embedded fields you also confirm your checkout is protected against malicious scripts, usually with your provider's written confirmation (PCI SSC FAQ 1588). Watch out: If your own website builds the card form, even one that sends the card straight to the provider, it is SAQ A-EP. If card numbers ever reach your own server, it is SAQ D. |
| Phone and mail orders A regular customer or a contractor calls to order and reads out their card, and you type it into your processor's virtual terminal (a payment web page) on the shop computer. Or you send them a payment link instead. |
SAQ C-VT / SAQ A SAQ C-VT if staff type cards into a virtual terminal, or SAQ A if the customer pays through your provider's payment link |
With a virtual terminal, the computer your staff type on handles the card number, so it needs protecting. With a payment link, the customer types their own card into the provider's page and your systems never see it. Watch out: Never take card numbers by email, text or chat: receiving them electronically rules out SAQ C-VT. If you key phone orders into your standalone counter terminal instead, ask your processor whether that is covered by the terminal's SAQ. |
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.
Start by counting your payment methods
Before you open any form, write down every way a customer can pay you by card. Each one is a separate payment method with its own SAQ. Two short SAQs (say SAQ B-IP for the counter and SAQ A for the web shop) are far less work than one SAQ D, and having several payment methods is not by itself a reason to file SAQ D.
Your acquirer decides which SAQs it accepts. Some will want everything on one form; most small-merchant programs accept one per channel. Ask them, and use this list to explain how you take cards.
- The card machine at the till: how does it connect, and is it wired to your register?
- A register or tablet POS system with a card reader.
- A reader on your phone or tablet for markets, fairs and pop-ups.
- Your online store, and any payment links or invoices you send.
- Phone, mail or email orders.
- Self-checkout kiosks, vending machines or fuel pumps: unattended machines have their own rules, so ask your acquirer which SAQ covers them.
Counter terminals: SAQ B, SAQ B-IP or SAQ P2PE
If your card machine works on its own and talks only to your processor, it is a standalone terminal. On a phone line it is usually SAQ B. Over the internet, through your router, Wi-Fi or a SIM card, it is usually SAQ B-IP, which also expects the terminal to be a PCI-approved device (your provider can confirm the model is on the PCI SSC list of approved PTS devices) and to be kept apart from your other computers.
Some processors supply terminals that are part of a validated P2PE solution. P2PE means point-to-point encryption: the card is encrypted the moment it is read, inside a terminal PCI SSC has approved, and only the solution provider can unlock it. If your terminals are part of a PCI-listed P2PE solution, you can usually use SAQ P2PE, one of the shortest SAQs.
Encryption alone does not qualify you. To check:
- Ask your processor for the exact name of the P2PE solution and its PCI SSC listing.
- Look it up on the list of validated P2PE solutions on the PCI SSC website (you accept the terms of use, then search by the solution or provider name). Check it is listed and not expired.
- Ask for the P2PE Instruction Manual (PIM). SAQ P2PE expects you to follow it, for example by checking terminals for tampering.
- Make sure every terminal you use belongs to that solution. A terminal that is not part of it is a different payment method with a different SAQ.
Market stalls, pop-ups and card readers on your phone
A reader paired to your phone or tablet only qualifies for a short SAQ when the whole solution, reader plus app, has been validated and listed by PCI SSC. SAQ SPoC is written for one kind of listed solution: a secure card reader paired with an off-the-shelf phone or tablet (SPoC stands for Software-based PIN entry on COTS, meaning commercial off-the-shelf devices).
Phone-only contactless apps, often sold as Tap to Pay, are not SPoC solutions. PCI SSC covers them under its CPoC (Contactless Payments on COTS) and newer MPoC (Mobile Payments on COTS) standards, and there is no SAQ named after either. In May 2026 PCI SSC announced that it will stop accepting new SPoC and CPoC submissions after 31 October 2026, pointing solution makers to MPoC; existing listings stay valid until their own expiry dates.
So don't guess from the hardware. Ask your provider which PCI SSC listing their solution has and which SAQ they support for merchants using it, then confirm with your acquirer. Your market-stall reader is still its own payment method, separate from your counter terminal and your web shop.
Protect the terminals and the network they use
Whatever your SAQ, PCI SSC's guide for small merchants comes back to a few habits that stop the most common thefts: skimmers fitted to terminals, and payment devices sharing a network with everything else.
- Keep a list of every terminal and reader, with photos of the front, back and cables, so you can spot a swap or an add-on.
- Check them regularly for broken seals, odd cables or parts you do not recognise. If anything looks wrong, stop using it and call your processor.
- Only let expected, authorised technicians repair or replace terminals, and tell staff the same.
- Keep terminals on a separate network from customer Wi-Fi, and do not browse the web or read email on the computer or tablet you take payments on.
- Change default passwords on your router, POS and any payment software.
Special orders, layaway and contractor accounts
Retail has a habit of writing card numbers down: on a special-order slip, a layaway card, or a list of contractors you charge each month. Avoid it. If you need to charge later, use your processor's card-on-file or invoicing feature, where the provider stores the card and you only see the last four digits, or send a payment link when the order is ready.
If paper with card numbers already exists, black it out or shred it, and keep anything you must hold in a locked drawer few people can open. Never keep the three- or four-digit security code. And never type card numbers into a spreadsheet, email or notes app: storing card numbers electronically takes you out of every short SAQ and into SAQ D.
Your checklist
- List every way you take cards: counter terminal, POS system, market reader, online store, phone orders and payment links.
- Ask your processor how each counter terminal connects (phone line, internet or cellular) and whether it is wired to your register.
- Ask whether your terminals are part of a PCI-listed P2PE solution; if so, check the PCI SSC listing and get the P2PE Instruction Manual.
- For your phone or tablet reader, ask the provider which PCI SSC listing it has and which SAQ they support.
- Confirm your online checkout card form comes from your payment provider; if its fields are embedded in your page, get the provider's written confirmation about script protection.
- Move card terminals onto a network separate from customer Wi-Fi and staff browsing.
- Photograph and list every terminal, and check them for tampering on a regular schedule.
- Stop writing down or emailing card numbers; shred any you already hold and switch to card-on-file or payment links.
- Complete one SAQ per payment method and send them to your acquirer in the way it asks.
Common questions
Does a small shop really need to be PCI compliant?
If you accept cards, yes. The card brands' compliance programs apply to merchants of every size, and your agreement with your acquirer usually requires it. For a small shop that normally means completing an SAQ each year, not hiring an auditor.
I take cards at the counter and online. Do I need SAQ D?
Not just because you have two payment methods. PCI SSC FAQ 1082 says a merchant may complete a separate SAQ for each channel, as long as each channel meets that SAQ's conditions and the channels are kept apart. A standalone counter terminal and a provider-hosted online checkout are typically SAQ B-IP and SAQ A. Check with your acquirer, which decides what it accepts.
Is a register with a card reader attached SAQ B-IP?
Usually not. SAQ B-IP is for standalone terminals that talk only to the processor. When the reader feeds a register, computer or tablet running POS software, that device is part of the payment flow, which is usually SAQ C, or SAQ P2PE if the readers are part of a PCI-listed P2PE solution.
Which SAQ covers a card reader on my phone at a craft fair?
SAQ SPoC, if your provider's solution is listed by PCI SSC as a SPoC solution (a secure card reader paired with a phone or tablet). Phone-only Tap to Pay style apps fall under other PCI standards with no SAQ of their own. In either case, ask your provider which SAQ their solution supports and confirm with your acquirer.
How do I know if my terminal is P2PE?
Ask your processor for the name of its P2PE solution, then find it on the PCI SSC list of validated P2PE solutions and check the listing is current. If it is not listed, you don't qualify for SAQ P2PE, however strong the encryption sounds.
My processor supplied the terminal. Isn't PCI their problem?
Partly. A compliant processor and approved terminal shrink your part a lot, but you still answer for how you use them: where the terminal sits, what network it is on, who can repair it, and what happens to receipts and paper. That is what your SAQ asks about.
Can I write down a customer's card number for a special order or layaway?
It is best not to. Use your processor's card-on-file or invoicing feature, or send a payment link when the order is ready. If you ever keep paper with a card number, lock it away, never record the security code, and shred it as soon as you've charged the card.
Who decides which SAQ I file?
Your acquirer: the bank or processor that handles your card payments. PCI SSC tells merchants to check with their acquirer or the card brands. Use this guide to work out what to ask for, then confirm with them.
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: Which Self-Assessment Questionnaire (SAQ) should I complete?
- PCI SSC Document Library (PCI DSS v4.0.1 SAQs and SAQ Instructions and Guidelines)
- PCI SSC Data Security Essentials for Small Merchants: Guide to Safe Payments
- PCI SSC Data Security Essentials for Small Merchants: Common Payment Systems
- PCI SSC list of validated P2PE solutions
- PCI SSC list of approved PIN Transaction Security (PTS) devices
- PCI SSC list of validated SPoC solutions
- PCI SSC Mobile Payments on COTS (MPoC) standard
- PCI SSC bulletin: Sunset periods for the PCI SPoC and PCI CPoC Standards (1 May 2026)
- PCI SSC FAQ 1588: How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts?
- PCI SSC blog: Important updates announced for merchants validating to SAQ A (January 2025)
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.