Home › PCI compliance by business › Small online stores

PCI compliance for small online stores

Short answer. Each way your store takes cards is a separate payment method with its own PCI Self-Assessment Questionnaire (SAQ), so your website checkout, the payment links or invoices you send, and any phone orders are each assessed on their own. For a website checkout, who supplies the card form decides: if it comes entirely from your payment provider, on its own page or as its secure fields embedded in your checkout, it is usually SAQ A; if your own site builds the card form, it is SAQ A-EP; and if card numbers reach your server, it is SAQ D. Sales paid through a marketplace's own checkout are usually the marketplace's to protect, not yours.

PCI DSS (the Payment Card Industry Data Security Standard) is the set of security rules the card brands require of every business that accepts card payments, including a one-person online shop. Most small stores prove compliance once a year with a Self-Assessment Questionnaire (SAQ), a form your payment processor asks you to complete and sign.

Online, the SAQ depends on how your checkout collects the card, and since January 2025 the test is who supplies the card form, not which web address the customer is on. And if you sell more than one way, each way is its own payment method with its own SAQ.

How small online 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
Hosted store builder with its own checkout Your store runs on a hosted store builder and customers pay on the builder's checkout, or you send them to your payment provider's hosted payment page, such as Stripe Checkout.	SAQ A SAQ A	Every part of the card form comes from a PCI DSS compliant provider, so card numbers never touch anything you run. Stripe states Checkout is SAQ A. Some platforms that are the merchant of record for your sales say you do not need to validate separately; follow what your platform or processor tells you. Watch out: Custom code or apps that change the checkout page itself, or taking card details any other way (email, chat, phone), are separate questions; check them before assuming SAQ A covers you.
Provider's card fields embedded in your own checkout A WordPress or custom site whose checkout shows the provider's secure card boxes inside your page, for example Stripe Elements, Braintree Hosted Fields, or the WooCommerce Stripe or Square extensions.	SAQ A / SAQ A-EP SAQ A, plus the script-attack criterion; SAQ A-EP if you cannot meet that criterion	The card boxes are the provider's, loaded in an iframe (a small window from the provider's site inside your page), so the January 2025 SAQ A applies. Because they sit inside your page, you must also confirm your site is not susceptible to malicious scripts (PCI SSC FAQ 1588). Watch out: If you have neither your provider's written confirmation nor your own payment-page script controls, the same setup falls to SAQ A-EP.
Your own website's card form A checkout where your site or plugin draws the card boxes and posts them straight to the gateway (a direct post), or a developer-built form using Authorize.Net Accept.js with your own card fields.	SAQ A-EP / SAQ D SAQ A-EP; SAQ D if card numbers reach your server	Your website builds or submits the card form, so it is part of keeping the payment page safe, even if the card number goes straight to the provider. PCI SSC created SAQ A-EP for this case; Authorize.Net lists Accept.js with your own form as SAQ A-EP. Watch out: If your form posts card numbers to your own server, which then sends them to the provider, it is SAQ D, the full questionnaire. Moving to the provider's hosted page or embedded fields usually brings you back to SAQ A.
Payment links and emailed invoices You email or text a customer a link or an invoice from your processor, and they pay on the processor's own payment page. Common for custom orders, deposits and wholesale buyers.	SAQ A SAQ A	The customer types the card on the provider's hosted page, so you never see it. PCI SSC FAQ 1588 says the script criterion does not apply when you fully outsource payment, for example by emailing customers a payment link. Watch out: If the customer reads you their card number instead and you type it in, that is a different payment method, usually SAQ C-VT.
Selling on an online marketplace You list products on a marketplace site, buyers pay at the marketplace's own checkout, and the marketplace pays you out.	Often no SAQ from you for this channel; confirm with the marketplace and your processor	Visa defines a marketplace as an entity that brings cardholders and retailers together online and processes transactions and receives settlement on behalf of those retailers. In that model the marketplace takes the card, and you never receive card data. Watch out: Not every platform that calls itself a marketplace works that way. If the platform has you connect your own payment account and the charge appears under your business name, you may be the merchant for those sales, and the checkout rules above apply.

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 SAQ per way you take payments

List every way a customer pays you by card: your website checkout, links or invoices you send, phone orders, a card reader at markets and pop-ups, and any marketplaces. Each one is a separate payment method, and each gets the SAQ that fits it.

A candle maker with an embedded-fields checkout on her own site, emailed payment links for custom orders and a validated phone card reader at weekend markets would usually look at SAQ A for the site, SAQ A for the links and SAQ SPoC for the markets. Having several channels is not, by itself, a reason to file SAQ D. SAQ D applies to a channel only when card numbers reach your own systems or that channel fits no shorter SAQ.

Your processor or acquiring bank has the final say on which SAQs you file. Use this guide to know what to ask for.

Who supplies the card form decides

PCI SSC revised SAQ A in January 2025. The question is no longer whether the customer leaves your website. It is whether every part of the card form, the boxes where the customer types the number, comes directly from your PCI DSS compliant payment provider.

Provider's hosted page or provider's embedded fields: usually SAQ A. Your own site builds or submits the form: SAQ A-EP. Card numbers reach your server, database or logs: SAQ D. Our integration-by-integration table, with each provider's own source, is at https://complianceassessmenttool.com/saq-a-vs-saq-a-ep.

WordPress and WooCommerce: the plugin decides

On WordPress, the payment plugin you choose sets your SAQ. Two common setups are documented as SAQ A by WooCommerce itself: its Stripe extension, which collects cards with Stripe Elements (WooCommerce says most merchants using it can validate with SAQ A), and its Square extension.

Other plugins vary. Some send customers to the provider's page or show the provider's fields (SAQ A), some draw their own card boxes and post them to the gateway (SAQ A-EP), and some pass card numbers through your WordPress server (SAQ D). Read the plugin's documentation for the SAQ it states, and if it states none, ask the payment provider which integration the plugin uses.

Prefer a plugin that uses the provider's hosted page or the provider's embedded card fields.
Avoid plugins that ask you to store cards, or that save card details in orders, notes or logs.
Keep WordPress, your theme and plugins updated, remove plugins you do not use, and limit who has admin access; your site still serves the checkout page.

The script-attack criterion, and what 'confirm with your provider' means

When the provider's card fields are embedded in your checkout, SAQ A adds one condition: you confirm your site is not susceptible to attacks from scripts that could affect your e-commerce system. A malicious script on your page could, for example, show a fake card form over the real one.

PCI SSC FAQ 1588 gives two ways to meet it. Either protect your payment page yourself, or through a third party, with techniques such as those in PCI DSS Requirements 6.4.3 and 11.6.1, or get confirmation from your PCI DSS compliant payment provider that its embedded solution, implemented according to its instructions, protects your payment page from script attacks.

In practice, 'confirm with your provider' means getting that statement in writing, from the provider's documentation or a letter or email, following its setup instructions exactly, and keeping a copy with your SAQ. The criterion does not apply when you redirect customers to the provider's page or send payment links.

Things that quietly change your SAQ

Most small stores start on SAQ A and drift off it through habits rather than technology.

A customer emails, texts or chats their card number and you process it: card data is now arriving electronically.
Phone orders typed into a virtual terminal: a separate channel, usually SAQ C-VT.
Writing card numbers in order notes, spreadsheets or a notebook for repeat orders: use the provider's saved-card feature instead.
A developer replaces the provider's card fields with a custom-built form: that is SAQ A-EP, or SAQ D if the numbers reach your server.

Your checklist

List every way customers pay you by card, including marketplaces, links, invoices, phone orders and markets.
For your website, find out who supplies the card form: the provider's hosted page, the provider's embedded fields, or your own site.
Check your payment plugin's documentation for the SAQ it states, and ask the provider if it states none.
If the provider's fields are embedded in your page, get your provider's written confirmation for the script-attack criterion, or put your own payment-page script controls in place.
Send payment links or invoices from your processor instead of taking card numbers by email, chat or phone.
Make sure no card numbers are saved in orders, notes, logs, spreadsheets or email; delete any you find.
Check each marketplace's seller terms to confirm the marketplace, not you, processes the card payments.
Ask your processor which SAQ to file for each payment method, and whether it expects quarterly scans of your site.
Complete and sign one SAQ for each payment method your processor confirms, and diary the renewal for next year.

Common questions

Do I need PCI compliance if my store runs on a hosted store builder?

Usually yes, but it is usually the shortest form. If the builder's own checkout supplies the whole card form, your website checkout is normally SAQ A, and your processor still expects it to be completed each year unless your platform or processor tells you otherwise. Anything else you do, such as phone orders, is a separate payment method.

Is an embedded payment form SAQ A or SAQ A-EP?

If the card fields are served entirely by your PCI DSS compliant provider, it is SAQ A under the January 2025 revision, as long as you can also confirm your site is not susceptible to malicious scripts. If you cannot, or if your own site builds the card boxes, it is SAQ A-EP.

I use WooCommerce. Which SAQ do I need?

It depends on the payment plugin. WooCommerce says most merchants using its Stripe extension can validate with SAQ A, and calls its Square extension SAQ-A compliant; with both, the provider's fields are embedded, so the script criterion applies. Other plugins may be SAQ A, SAQ A-EP or SAQ D depending on whether the provider or your site supplies the card form.

I only sell on a marketplace. Do I need an SAQ?

Often not for those sales, when buyers pay at the marketplace's checkout and the marketplace processes the payment and pays you out, because you never accept the card. Check the marketplace's seller terms to confirm, and if you also sell on your own site or by link, those channels need their own SAQs.

Which SAQ covers payment links and invoices?

Usually SAQ A, when the customer pays on your processor's own hosted page. PCI SSC FAQ 1588 treats emailing customers a payment link as fully outsourcing the payment, so the script criterion does not apply to it.

Do SAQ A stores still need quarterly vulnerability scans?

PCI SSC FAQ 1604 says the SAQ A external scans by an Approved Scanning Vendor apply to merchant webpages that redirect to a payment provider and to webpages that include a provider's embedded iframe. If your whole store is hosted by a platform, ask your processor what it expects from you.

A customer emailed me their card number. What should I do?

Do not reply with the number in the message and do not save it. Delete it securely, then send the customer a payment link so they enter the card on the provider's page. Card numbers arriving by email put your inbox in scope, which does not fit SAQ A.

Who decides which SAQ I file?

Your payment processor or acquiring bank. PCI SSC says the entities that accept your compliance validation, typically acquirers and the card brands, decide how merchants validate. Use the who-supplies-the-card-form rule to know 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

Hotels and lodgingRestaurants, bars and cafesRetail storesSalons, spas and barbershopsMedical, dental and veterinary officesContractors and home service prosNonprofits and charities

Sources

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.