PCI DSS by industry
PCI DSS for e-commerce and retail: checkout, payment page scripts and store terminals
What changes when the merchant is an online shop or a retail chain: why acquirers ask, how redirect, iframe and direct post checkouts shape scope, where assessors sample in stores and on payment pages, and how omnichannel merchants validate.
Key points
- For an online shop or a retail chain, PCI DSS usually arrives as a letter from the acquirer asking for a current Attestation of Compliance (AOC) by a set date.
- How your checkout collects the card number (redirect, embedded iframe or direct post) decides how much of your website falls into scope and which questionnaire, if any, you qualify for.
- Outsourcing the payment page does not outsource the scripts on your own pages: payment page script controls have been mandatory since 31 March 2025.
- In stores, the scope follows the terminal. Validated point-to-point encryption keeps tills and store networks out; anything less brings them in.
Why e-commerce and retail businesses are asked for PCI DSS
The demand reaches you from the acquirer, the bank or payment company that settles your card sales, usually as a yearly request for an AOC backed by a self-assessment questionnaire (SAQ) or, for the largest merchants, a Report on Compliance (ROC) from a Qualified Security Assessor (QSA). The card brands set your merchant level from your annual transaction volume; the acquirer confirms it and tells you what to submit.
Marketplaces and franchise partners may also ask for your AOC. What makes this sector distinctive is the number of channels: web shop, mobile app, stores, pop-ups, phone orders and returns desks can each touch card data in a different way. The general validation steps are in PCI DSS validation step by step: ROC, SAQ and AOC.
What sits inside the scope for an online shop or retail chain
Online checkout
With a full redirect or an iframe served by a PCI DSS compliant payment service provider, your web server never receives the card number. Your site still decides where the customer is sent and what code runs around the form, so the storefront, its admin login and its scripts remain yours. Direct post, where your page sends card data straight to the provider, or a payment form your own code builds, leaves your web server able to affect the transaction and generally means a longer questionnaire than SAQ A. Which one applies is set by the SAQ's eligibility criteria and confirmed with your acquirer; see Which SAQ applies to you: eligibility explained.
Stores and point of sale
Terminals in a PCI SSC-listed point-to-point encryption (P2PE) solution encrypt card data at the tap or insert, keeping the till, store Wi-Fi and back office out of readable card data. Integrated POS systems that receive card data bring the store network, the head-office systems managing it and the links between them into scope unless segmentation is designed and tested.
Three scope mistakes recur in retail: forgetting phone orders and the customer-service inbox where card numbers arrive by e-mail; treating a new pop-up or franchise store as outside the programme; and leaving out the agency or developer with admin access to the web shop. Shrinking the environment is covered in PCI DSS scoping and segmentation: shrinking the CDE.
Where the requirements bite in e-commerce and retail
| Requirement area | What it means in e-commerce and retail | Evidence the assessor or acquirer samples |
|---|---|---|
| 6 Develop and Maintain Secure Systems and Software | Managing every script on payment pages, and patching the e-commerce platform, its plug-ins and themes | A payment page script inventory with the reason for each script, integrity checks, platform and plug-in patch records, change records for checkout releases |
| 11 Test Security of Systems and Networks Regularly | Scanning the storefront every quarter and detecting unauthorised changes to payment pages | Passing quarterly Approved Scanning Vendor (ASV) scans, tamper detection alerts on checkout pages, penetration test reports where the SAQ or ROC calls for them |
| 9 Restrict Physical Access to Cardholder Data | Protecting card terminals in stores from swapping and tampering | A terminal inventory by store and serial number, inspection records, cashier training on spotting tampered devices |
| 8 Identify Users and Authenticate Access to System Components | Strong authentication for the web shop admin, POS back office and remote support by vendors | Multi-factor authentication settings on admin and remote access, unique accounts per person, leaver removal records |
| 12 Security policies and third-party service providers | Managing the payment service provider, platform host, POS vendor and web agency | A provider register with each provider's current AOC, a responsibility matrix, a yearly scope confirmation, an incident plan covering a skimmed checkout |
All twelve requirements are explained in PCI DSS requirements explained, requirement by requirement.
Omnichannel retail, acquirer requests and your other obligations
An omnichannel merchant often completes more than one questionnaire. The PCI Security Standards Council's SAQ set includes types for standalone PCI-approved terminals (SAQ B-IP), validated P2PE solutions (SAQ P2PE), card readers used with a mobile device in a validated SPoC solution (SAQ SPoC), virtual terminals on standalone computers (SAQ C-VT) and SAQ D for merchants that do not fit any other. Ask your acquirer early whether it wants one AOC per channel or one covering the business, in writing.
Your payment service provider's AOC covers its own controls, not yours. Customer personal data travels with every order, so one control set and evidence calendar can serve PCI DSS, ISO/IEC 27001 and privacy work. See PCI DSS vs ISO/IEC 27001 and SOC 2.
What an e-commerce and retail engagement looks like
Duration depends on how many payment channels and store formats you run, whether terminals are already P2PE, how the checkout is built and how quickly the acquirer confirms its expectations. The e-commerce or digital lead, store operations, IT and whoever owns payment contracts must be involved. With Design™, Sterling guides your team to own the controls; with Drive™, Sterling carries more of the documentation and evidence.
How Sterling works with e-commerce and retail businesses
A smaller scope, and an AOC your acquirer accepts.
Our expert and experienced consultants trace every channel where card data enters, redesign the checkout and store set-up to keep scope small, close the gaps that remain and keep the evidence in Effivity, included with the engagement. Sterling does not validate compliance; the QSA assesses and attests, or your acquirer accepts your SAQ. We ensure successful validation for our clients.
Book a free discovery callPCI DSS for e-commerce and retail: questions merchants ask
Does a hosted payment page or iframe take our website out of PCI DSS scope?
Not completely. The card number goes to the provider, but your site still controls where customers are sent and what scripts run, so the storefront keeps reduced obligations.
Do e-commerce merchants on SAQ A need quarterly ASV scans?
Yes, under PCI DSS v4.x a merchant whose page redirects to, or embeds a form from, a compliant provider needs external ASV scans at least once every three months.
Our payment provider is PCI DSS compliant. Does that make us compliant?
No. Its AOC covers its own environment. You still validate your own channels, and you keep its current AOC as part of managing the provider.
How often should store card terminals be checked for tampering?
Periodically, on a documented schedule your staff can sustain. Keep a terminal inventory by store, inspect against it and train cashiers to report anything unusual at once.
PCI DSS by industry
Every guide in the PCI DSS series is written for one question and links back to the hub for the whole picture.
- PCI DSS for banking and financial services
- PCI DSS for BPO and contact centres
- PCI DSS compliance cost
- Do you need PCI DSS
- PCI DSS documentation
- PCI DSS for e-commerce and retail
- Effivity for PCI DSS
- PCI DSS for fintech and payment facilitators
- PCI DSS gap analysis
- PCI DSS for healthcare providers and insurers
- PCI DSS for hospitality and travel
- PCI DSS for software and hosting providers
Keep exploring
Explore more about PCI DSS
Watch a video on how to implement PCI DSS here.
Watch a video on PCI DSS requirements here.
PCI DSS resources
Services for PCI DSS
Talk to a consultant
Plan a PCI DSS programme that covers every channel you sell through.
Tell us your goals, locations and target date. We’ll help you define the scope, timeline and next steps.
hello@sterling-grc.com+1 201 263 4443 (global headquarters) · your nearest office and its number are at the top of this page
What would you like to achieve?
Choose a starting point. The enquiry form takes about a minute.
Book my free discovery callContinue to the enquiry form to share your details. Please do not include passwords, sensitive personal information or confidential files. A Sterling consultant replies within one working day. Privacy notice