PCI DSS for Online Stores in Plain English

PCI DSS, the Payment Card Industry Data Security Standard, sets the security rules for any business that accepts, processes, stores or transmits card payments. For an online store, it applies whether you take ten orders a month or ten thousand. The good news is that the effort depends mainly on one choice: how your checkout collects card details. If a compliant payment provider collects them on its own secure page or fields, so card numbers never touch your systems, your obligations are much lighter. If card data passes through your servers, they grow considerably.

What PCI DSS is and who sets it

The standard is maintained by the PCI Security Standards Council, founded by the major card brands. It sets out requirements for protecting cardholder data: building secure networks, protecting stored data, managing vulnerabilities, controlling access, monitoring systems and maintaining security policies. The current version and supporting documents are published in the council's document library.

The standard is updated from time to time, and newer versions add requirements with dates by which they must be in place. Check which version applies when you complete your yearly review, because the questions may have changed since last year.

The card brands and your payment provider, also called the acquirer, enforce compliance. Your provider will usually tell you which validation you need and how to submit it. Non-compliance can lead to fines from the provider, higher fees, liability for fraud losses after a breach, and in serious cases the loss of the ability to accept cards.

Why your checkout design matters most

The single biggest factor in your PCI workload is how card details travel during checkout.

The difference between these approaches can be invisible to shoppers. A well-designed embedded form looks like part of your checkout, even though the card fields are actually served by the provider. That is why it is worth asking your developer precisely how your checkout works, rather than judging from how it looks.

For almost every online store, a hosted page or provider-served embedded fields is the sensible choice. It keeps card numbers out of your systems, which reduces both your risk and your paperwork. Our guide to choosing a payment gateway covers how to compare providers on this point.

Self-assessment questionnaires

Most small and mid-sized merchants confirm compliance by completing a self-assessment questionnaire (SAQ) each year. There are different SAQs for different set-ups. The one you need depends on how your checkout works:

• Fully outsourced card handling, such as a hosted payment page or provider-served fields, usually qualifies for the shortest questionnaire.
• Partly outsourced e-commerce, where your website controls the payment form even though the provider processes the payment, needs a longer questionnaire covering your web servers.
• Card data on your systems needs the most comprehensive questionnaire, or a formal assessment.

Answer each question honestly and keep notes on how you reached each answer, such as screenshots of settings or confirmation from your host. If a requirement is not yet met, plan the fix rather than ticking the box. The questionnaire is only useful if it reflects reality.

Large merchants, based on their annual card transaction volume, may need an on-site assessment by a qualified security assessor instead. Your payment provider will tell you which level and validation apply to you. Many providers offer online tools that guide you through the questionnaire.

Protecting your payment pages

One of the most common attacks on online stores is card skimming: malicious code inserted into the checkout that copies card details as customers type them. Even when a provider collects the card data, attackers may try to alter the page that loads the provider's form.

The latest version of PCI DSS added requirements aimed directly at this risk. In plain terms, merchants are expected to:

• Keep an inventory of every script that runs on payment pages, with a reason for each one.
• Authorise scripts and confirm their integrity, so unexpected code cannot run.
• Detect changes to payment pages and their security headers, and alert someone when they happen.

These rules recognise that modern checkouts load many pieces of code from different places: the platform, the theme, analytics, chat widgets, fraud tools and the payment provider itself. Each one is a possible way in for an attacker if it is changed without anyone noticing.

Practical steps include removing marketing and analytics scripts from checkout pages where they are not needed, using a Content Security Policy that limits where scripts can load from, and monitoring checkout pages for changes. Your provider and developer can advise which requirements apply to your set-up.

The ongoing basics

Compliance is not a one-off form. The everyday security practices behind it protect your store whether or not anyone audits you.

• Patch promptly: keep your platform, extensions, server and plugins up to date. Our guide to Magento security patches explains a safe process.
• Control access: unique accounts for every person, strong passwords and two-factor authentication for admin and hosting access.
• Never store card data you do not need. Never store security codes at all.
• Use secure connections on every page.
• Monitor and log access and changes, and review alerts.
• Have an incident plan for suspected breaches.
• Review yearly when completing your questionnaire, and whenever your checkout changes.

Our ecommerce security checklist turns these into a regular review.

Common misunderstandings

• "My provider is compliant, so I am too." Your provider's compliance covers its systems. You still have responsibilities for your website and processes, even if they are small.
• "We are too small to matter." The standard applies to all merchants, and small stores are frequent targets of automated attacks.
• "We passed last year." Compliance must be maintained continuously, not just on the day you submit a form.
• "Card data in emails or spreadsheets is fine." It is not. Never ask customers to send card details by email or chat, and never record them in spreadsheets.

PCI DSS for your online store: a step-by-step plan

1. Map how cards are taken. List every way you accept card payments: website checkout, phone orders, invoices with payment links, marketplace sales and shop terminals.
2. Confirm your checkout type. Ask your developer and payment provider exactly how card details are collected and where they travel.
3. Reduce your scope. If card data passes through your systems, plan a move to hosted pages or provider-served fields.
4. Find out your validation requirements. Ask your provider which questionnaire or assessment applies and when it is due.
5. Review payment page scripts. List every script on checkout pages, remove what is not needed and set up change monitoring.
6. Tighten access. Review admin, hosting and payment dashboard users, remove old accounts and turn on two-factor authentication.
7. Check patching and backups. Make sure updates are applied promptly and backups are secure.
8. Complete and submit the questionnaire, keeping evidence of each answer.
9. Diary the next review, and repeat whenever your checkout changes.

Phone orders, links and other channels

Online stores often take payments in more ways than they realise, and each one counts.

Phone orders

Staff typing card details into the admin or a virtual terminal bring those systems into scope. Safer options include sending the customer a secure payment link, or using a provider service that lets customers enter details on their phone keypad without staff hearing them.

Payment links and invoices

Payment links from your provider keep card details on the provider's page, which is a good way to take payment for quotes, deposits and custom orders.

Marketplaces

When a marketplace takes the payment, card handling sits with the marketplace, not you. Keep any order data you receive secure, but card security is their responsibility.

Shops and events

Card terminals in a physical shop or at events have their own requirements. Use terminals supplied or approved by your provider, keep them physically secure and include them in your annual review.

Working with your developer and host

Many PCI responsibilities sit with the people who build and run your store. Make them explicit.

• Ask your developer to confirm in writing how the checkout handles card data and which scripts run on payment pages.
• Agree who monitors payment pages for changes and who receives the alerts.
• Ask your host what security controls they provide, such as firewalls, patching and logging, and whether they can supply evidence for your questionnaire.
• Make sure any agency with admin access uses individual accounts with two-factor authentication.

Clear responsibilities make the yearly questionnaire faster, and, more importantly, make the protections real.

Frequently asked questions

Unsure how your checkout affects PCI compliance? Talk to our team about payment integrations that keep card data off your systems and checkout pages protected.