A store selling 30 orders a week carries the same PCI baseline as one selling 30,000. That single fact drives nearly every mistake small merchants make with card compliance.
Quick answer: Every business that takes cards must meet PCI DSS, whatever its size. If your store never touches a raw card number, PCI compliance for ecommerce is 1 short questionnaire a year plus a signed attestation. Which questionnaire depends entirely on how your checkout is built, a decision made in code, not in a compliance meeting.
Key Takeaways
- PCI DSS is a contract, not a law. Your bank decides which form you file and charges you when you skip it.
- Scope follows card data, not revenue. A $3,000-a-month store faces the same baseline as a national retailer.
- Most small stores qualify for SAQ A: roughly 20 to 30 questions. The catch-all SAQ D has around 329.
- Hundreds of questions means a scoping mistake, not a real need for 300 controls.
- Platform compliance is not checkout-page compliance. Shopify being compliant does nothing for your payment-page scripts.
- Since 31 March 2025, script rules 6.4.3 and 11.6.1 are mandatory, including for SAQ A iframe merchants.
- British Airways paid a £20 million fine over 22 lines of injected JavaScript on its checkout.
The Question That Sets Your Entire PCI Scope
Ask whether a raw card number ever reaches your servers, database, or logs. If it never does, you stay on SAQ A. If it does, even for a second, your workload multiplies by roughly 10.
| Checkout model | Where the card is entered | Your questionnaire | Approx. questions |
|---|---|---|---|
| Full redirect | On the processor’s own page | SAQ A | 20 to 31 |
| Embedded iframe | In a processor form on your page | SAQ A, plus script rules | 20 to 31 |
| Custom form / direct post | On your page, read by your code | SAQ A-EP | around 139 |
| Card saved in your database | Any of the above, plus storage | SAQ D | around 329 |
1. A Full Redirect Keeps Your Scope Smallest
The shopper clicks pay and lands on the processor’s domain. The card never enters your systems.
This is the safest route for a store with no security staff, and the 2025 rule changes reward it.
2. An Embedded Iframe Stays SAQ A but Adds a Script Rule
The card fields belong to the processor, but they sit on your page. You still file SAQ A.
The catch is everything around the iframe. You now need script-protection controls, or written proof from your provider that the embedded form is protected.
3. Custom Card-Field Code Moves You to SAQ A-EP
A hand-built form or JavaScript that reads the card input puts your website inside the payment flow. That is SAQ A-EP, around 139 questions.
Stores built by an AI tool or a departed developer often have card fields wired this way without anyone realising the compliance jump.
Why “We’re Too Small for PCI” Is the Costliest Assumption
PCI compliance for ecommerce covers any business that stores, processes, or transmits cardholder data. Size changes how you prove compliance, never whether you owe it.
Skimmers Target Reachable Stores, Not Big Ones
Attack groups do not pick you for your revenue. They pick you because a scanner found an opening.
Bots sweep millions of domains for these weak points:
- Outdated WordPress or plugin versions
- Exposed admin panels and default logins
- Checkout pages with scripts nobody monitors
An abandoned plugin is a softer target than a bank, which is why web-application attacks stay a top breach pattern for small firms in Verizon’s Data Breach Investigations Report.
Your Processor’s Compliance Never Becomes Yours
Stripe, PayPal, and Square carry most of the technical load. They do not carry your accountability.
You are the merchant of record. If a breach starts on your site, your bank pursues you for the costs.
The blunt version assessors repeat: the processor’s certificate covers the processor, not your store.
How a 22-Question Form Turns Into 300
The full standard runs about 360 pages, written for companies that hold raw card numbers. Small merchants read it, panic, and file the wrong questionnaire.
1. You Answered About Customer Data, Not Card Data
The scoping questions ask about cardholder data. Owners say “yes, we store it” because addresses and order history sit in their database, and the tool sends them to SAQ D.
Those are not cardholder data. Only the card details count:
- In scope: primary account number, cardholder name, expiry date, service code
- Never store after payment: card verification code, full stripe or chip data
- Not cardholder data: billing address, email, phone, order history
2. Your Bank Picks Your SAQ, Not You
You do not choose your questionnaire from a blog or a checklist. Your acquirer or payment provider tells you which one they expect.
Many banks send a generic request for scan reports to merchants who do not need them. Confirm your SAQ type in writing first, or you will document controls you were never required to meet.
3. You Read All 360 Pages Instead of Your Own SAQ
The PCI SSC document library publishes each SAQ on its own, with its own instructions. Download the one that matches your setup and ignore the rest.
If your model truly needs staff to see card numbers, phone orders for example, SAQ A is gone. Fix the flow with a pay-by-link or DTMF masking instead of widening your scope.
Platform Compliance Is Not Checkout-Page Compliance
Shopify, WooCommerce, and Magento being PCI compliant refers to their servers. It says nothing about the scripts running in your shopper’s browser.
1. How Payment-Page Skimming Actually Works
Attackers rarely break the processor’s iframe. They change the page around it.
The sequence is short:
- A weak plugin or a stolen login gives them write access
- They add a few lines of JavaScript to the checkout
- That script copies each keystroke, or overlays a fake form
- Nothing looks broken to the shopper or the owner
This is the British Airways breach: 22 lines of script, 15 days undetected, roughly 400,000 cards taken. Ticketmaster fell the same way through a chat widget.
2. What Requirements 6.4.3 and 11.6.1 Now Demand
Both apply to SAQ A iframe merchants and have been enforced since March 2025.
| Requirement | What it asks for |
|---|---|
| 6.4.3 | A list of every payment-page script, a written reason for each, and an alert when one changes |
| 11.6.1 | Weekly checks on the page’s headers and script content for unapproved change |
An iframe served from the processor’s own domain keeps the risk lower. An iframe rendered from your domain puts the whole surrounding page in scope.
The updated SAQ A FAQ lets iframe merchants meet the rule with written confirmation from their provider.
3. Why CSP and SRI Rarely Fix It Cleanly
The textbook answers are a Content Security Policy and subresource integrity hashes. Both fight you in production.
A strict CSP blocks third-party forms the moment they update their own code, so checkout breaks and the policy gets rolled back. SRI only covers static files on a CDN, not tag managers that load new scripts live.
Teams that pass an assessment usually run a change-monitoring agent on the checkout instead. It is also far easier to show in a security review.
The Small Habits That Quietly Widen Your Scope
Scope creep is rarely a decision. It is a stack of small conveniences.
| Habit | Why it widens scope | The fix |
|---|---|---|
| Card read over the phone into a form | The call, the note, and the room enter scope | Pay-by-link or DTMF masking |
| Customer emails their card number | Your mail server now stores card data | Delete it, ask them not to |
| Card written on paper for later | Physical media rules apply until the shredder | Key it in directly, shred at once |
| Chat widget or social login on checkout | Loads outside scripts into the payment page | Gate behind consent or move it |
| Full card number saved for renewals | Storage moves you to SAQ D | Use the processor’s token vault |
Phone, Email, and Paper All Break SAQ A Eligibility
The rule assessors repeat: never capture a card number where you or your staff can see it. The moment you do, the phone system and the workstation join your assessment.
A pay-by-link keeps a phone order card-not-present. So does DTMF masking, where the caller keys the digits and the operator hears nothing.
Marketing Scripts on Checkout Are the Silent Risk
Every new hire wants 1 more tag on the checkout: a heatmap, a pixel, a chat bubble. A tag manager then loads more, none of them version-controlled.
A store can go from 2 scripts to 15 in a quarter. That drift is exactly what a third-party integration review is meant to catch before an auditor does.
What Ignoring PCI Actually Costs
Nothing happens for a while. Then something specific does.
The Monthly Fee Some Merchants Choose to Pay
Skip the SAQ and most processors add a non-compliance fee, usually $20 to $50 a month.
Some small merchants pay it on purpose. PCI is contractual, so that is a business call, not an offence. The exposure is in what comes next.
The Bill After a Breach
A breach while non-compliant stops being a fee.
| Exposure | Typical range |
|---|---|
| Forensic investigation | $10,000 to $100,000+ |
| Card-brand fines, passed from your bank | $5,000 to $100,000 a month until fixed |
| Card reissuance and fraud | Billed back to you |
| Loss of card processing | In bad cases, across every bank |
The global average breach hit $4.44 million in IBM’s 2025 report. Small merchants land far below that, but the forensic bill alone closes most of them.
An inaccurate attestation can also void your cyber-insurance claim, which is why PCI compliance for ecommerce is worth getting right the first time.
Keeping PCI Compliance for Ecommerce Cheap: Scope by Design
The cheapest compliance is the smallest scope. Scope is set before launch, not after the processor’s email.
Map the Card-Data Path Before Writing Checkout Code
Decide early: redirect, iframe, or custom form. Confirm nothing stores the primary account number.
Another move drops scope further: keep the payment step on a separate system from the app customers log into. The main server then never enters the cardholder data environment.
That belongs in the Shopify or custom-build decision, not a later scramble.
The Pre-Launch Checklist GVM Runs
Our engineers work through this before an e-commerce store goes live, alongside the wider pre-launch security checklist:
- Confirm the SAQ type in writing with the bank
- List every checkout script with a written reason
- Add change monitoring on the payment page
- Get the iframe-protection confirmation from the provider
- Collect an Attestation of Compliance from every processor and integration
- Remove any “save card” logic, CSV export, or support field that stores a number
- Enforce unique logins and MFA on the CMS and hosting
The same pass clears the load-order faults behind GDPR cookie consent, so we run both together.
FAQs
1. Do small businesses really need PCI compliance?
Yes. PCI compliance for ecommerce has no size exemption. Small stores validate with a short self-assessment questionnaire instead of a paid audit.
2. Is PCI compliance a law?
No. It is a term in your merchant agreement, enforced by your bank through fees. A few US states cite it in statute, but there is no PCI regulator.
3. Which SAQ does my e-commerce store need?
It depends on how the card is captured:
- Full redirect, no storage: SAQ A
- Embedded iframe: SAQ A plus the script rules
- Your code reads the card fields: SAQ A-EP
Your bank confirms the final choice.
4. Does using Stripe or PayPal make me PCI compliant?
No. They give you their attestation. You still file your own SAQ and secure the page the form sits on.
5. What are PCI DSS Requirements 6.4.3 and 11.6.1?
Client-side controls, enforced since March 2025. Requirement 6.4.3 wants a justified inventory of every payment-page script. Requirement 11.6.1 wants weekly monitoring for unapproved change.
6. Can I just pay the non-compliance fee instead?
Some merchants do, and it is legal. The risk is that a breach while non-compliant brings forensic costs, fines, and a likely insurance denial.
7. Why did my SAQ have hundreds of questions?
You selected the wrong SAQ. Saying you store or process card data, when you actually redirect, routes you to SAQ D. Re-check your card-data path.
The Takeaway
Small stores get PCI compliance for ecommerce wrong the same few ways: assuming size is an exemption, mis-scoping the form, trusting the platform to cover the browser, and letting checkout scripts pile up.
Every one of them is avoidable while the checkout is still a diagram. Start with the question that sets the rest: does a raw card number ever touch your systems?
Get Your Checkout Scoped Before Your Processor Does
A payment page that survives a real assessment needs a load-order and script-level review most agencies skip. GVM Technologies has built and audited production e-commerce stores since 2012, from Miami and Surat, under ISO 27001:2022, 20000-1:2018, and 9001:2015 certified processes.
We scope PCI on every build, so your checkout stays on the shortest questionnaire and your quality assurance process stays routine, not urgent.
Talk to GVM about a PCI and checkout-security review and find out which SAQ you actually need before it becomes a problem.
