Security for e-commerce: PCI DSS in plain terms and what reduces your scope
What the card industry security standard requires of a small shop, how using a hosted checkout reduces the burden, and what still remains yours.
The short answer
The Payment Card Industry Data Security Standard is not a law. It is a standard set by the card brands and enforced through the contracts you sign with your acquirer or payment provider, with consequences that are commercial: fees, liability for fraud losses, and ultimately losing the ability to accept cards. The current version is 4.x, published as v4.0.1. What it requires of you depends on how card data flows through your systems. A shop where customers enter card details on the payment provider’s page, or in an element the provider serves and controls, never receives card data, which keeps that data out of scope and reduces validation to a short self-assessment questionnaire, though under version 4 that short form carries requirements of its own for payment pages. A shop that collects card details on its own form and passes them on is in a different category with a far longer questionnaire and substantially more obligations. That is the single biggest decision, and it argues strongly for using the provider’s checkout as designed. What remains yours either way is the shop around the payment: account security, the scripts loaded on payment-adjacent pages, updates, access control and the protection of order data after the sale.
How scope changes with the setup
| Setup | Card data touches your systems? | Typical validation | Practical burden |
|---|---|---|---|
| Hosted payment page at the provider | No | Shortest questionnaire | Low, plus an approved external scan |
| Provider-served embedded element or iframe | No | Short questionnaire | Low, plus script controls and a scan |
| Platform checkout, such as a major store platform’s own | No | Short questionnaire | Low, plus whichever of the two applies |
| Your own form posting to the provider’s API | Yes | Much longer questionnaire | High |
| Storing card details anywhere | Yes, heavily | Full standard | Very high; avoid entirely |
| Taking card numbers by phone or email | Yes | Additional controls required | Avoid; use a payment link |
Two of those low entries changed on 31 March 2025. Under version 4 of the standard the shortest questionnaire also asks for two things that did not used to be in it. The first: the scripts on payment pages authorised, their integrity assured, and an inventory kept with a written reason for each, which is Requirements 6.4.3 and 11.6.1 and applies where the payment page or form is embedded from the provider, an iframe being the usual case. The second: an external vulnerability scan by an approved scanning vendor, which is Requirement 11 and applies both where the site embeds the provider’s form and where it redirects to the provider. These were future-dated requirements; that date has passed, so they apply now.
What still needs doing
- Ask your payment provider which self-assessment questionnaire applies to your setup, and complete it honestly.
- Never store card numbers, including in emails, order notes, support tickets, spreadsheets or call recordings.
- Never take card details by email; use a payment link instead.
- Control the scripts on pages leading to or containing payment, with a content security policy and integrity checks; script injection on checkout pages is the current attack of choice. Since 31 March 2025 this is Requirements 6.4.3 and 11.6.1 of the standard rather than only good practice.
- Secure the store accounts: second factors for every staff member, least privilege, prompt removal on departure.
- Keep the platform, theme and apps updated, and remove apps you do not use.
- Protect order and customer data after the payment: access control, retention, backups.
- Monitor for unexpected changes to checkout pages and for unusual order patterns.
- Review annually, and whenever the checkout or the platform changes.
Why we do not replace the platform checkout
On a major store platform, the checkout is the most tested, most attacked and most carefully maintained part of the system, and it keeps card data out of your scope. Replacing it with a custom flow to gain design control moves card handling towards your systems, expands your validation obligations, and takes on a maintenance burden for a component where mistakes are expensive. The design benefits are almost never worth it for a small shop, and the compliance consequences are rarely considered in the decision.
What this means for you
PCI DSS reaches you through your payment contracts, and your burden depends on whether card data enters your systems. Use the provider’s or the platform’s checkout so it does not, complete the applicable self-assessment questionnaire, never store or email card details, control the scripts on payment pages, secure staff accounts, keep everything updated and protect order data afterwards. This is general information rather than legal or compliance advice; your provider defines your specific obligations.
Frequently asked questions
Do we have to be PCI compliant?
If you accept card payments, your agreement with your acquirer or payment provider requires compliance with the standard, and your validation obligation depends on your transaction volume and how card data flows through your systems. Smaller merchants typically validate with a self-assessment questionnaire, and which questionnaire depends on your setup. Your payment provider tells you which one applies; that is the question to ask them.
How does a hosted checkout help?
By keeping card data out of your environment entirely. If the card details are entered on the provider's page or in an element served and controlled by the provider, your systems never receive them, and the questionnaire that applies is much shorter. Since 31 March 2025 that short questionnaire is not an empty one: it carries the payment page script requirements and an external scan by an approved scanning vendor. Replacing the provider's checkout with your own form is what expands scope dramatically, which is one reason we advise against it on small shops.
What are we still responsible for?
Everything around the payment: the security of your store accounts and staff access, the scripts loaded on pages that lead to or contain payment elements, which version 4 of the standard now names as requirements rather than good practice, keeping the platform and apps updated, protecting order and customer data after the payment, and not storing card details anywhere, including in emails, notes and support tickets. Skimming attacks that inject a script into a checkout page are exactly a failure of that surrounding responsibility.
Sources
- PCI Security Standards Council: PCI Data Security Standard (PCI DSS) (accessed 2026-09-14)
- PCI DSS v4: What’s New with Self-Assessment Questionnaires (accessed 2026-09-14)
- New Information Supplement: Payment Page Security and Preventing E-Skimming (accessed 2026-09-14)