Guide · Payments & compliance
PCI DSS for online stores: what a small merchant actually needs to do
PCI DSS — the Payment Card Industry Data Security Standard — sets security requirements for any business that accepts, processes, stores or transmits card data. For large processors it is a heavy programme of controls and audits. For a typical online store, the most important decision is architectural: if card data never enters your systems, most of the burden stays with your payment provider. This guide explains how that works and what remains your responsibility.
[ 01 ]
In short
In short
- 01
PCI DSS is maintained by the PCI Security Standards Council, founded by the major card brands; version 4.0 and its update 4.0.1 are the current generation.
- 02
Your obligations depend on how you accept cards; banks and providers tell merchants which self-assessment applies.
- 03
Redirecting to a provider's hosted payment page, or using its hosted fields, keeps card data out of your systems and your scope small.
- 04
Even then, the security of your website matters: a compromised site can redirect customers to a fake payment page or inject malicious scripts.
- 05
Never store card numbers or security codes in your database, logs, emails or CRM.
[ 02 ]
Guide
What PCI DSS covers
The standard includes requirements for network security, protecting stored card data, encrypting transmission, vulnerability management, access control, monitoring, testing and security policies. Its full text and supporting documents are published by the PCI Security Standards Council.
Source: PCI Security Standards Council.
How your integration decides your scope
- Hosted payment page (redirect): the customer is sent to the provider's page, enters card details there and returns. Card data never touches your servers. This gives the smallest scope.
- Embedded hosted fields or iframe: the payment form appears on your page, but the card fields are served by the provider. Card data still goes directly to the provider; your page must be protected from tampering.
- Direct integration (card data sent via your server): your systems handle card data directly. Your scope is large, requiring substantial controls and assessments. Few small merchants should choose this.
Banks and payment providers classify merchants and tell them which self-assessment questionnaire applies. Ask your provider which one fits your integration.
Your responsibilities with a hosted page
Even when card data stays with the provider, attackers target the path to it. Your responsibilities include:
- Protecting the website from compromise: updates, secure admin access, strong passwords with two-factor authentication, minimal plugins.
- Protecting payment pages from script injection: control which scripts load on checkout pages; recent versions of PCI DSS added requirements around scripts on payment pages for relevant integrations.
- Securing notifications: verify the provider's server notifications so that forged "paid" messages cannot mark orders as paid.
- Not collecting card data elsewhere: no card numbers by phone into spreadsheets, by email or in chat. If customers send card details in messages, delete them and explain the proper method.
- Access control: limit access to the merchant dashboard and use two-factor authentication.
See security checklist before launch and security audit.
Saved cards and subscriptions
If customers want to save cards or pay by subscription, use the provider's tokenisation: the provider stores the card and gives you a token. Your system stores only the token, which is useless outside the provider's system.
Mobile apps
Apps should use the provider's SDK or hosted page for card entry, with the same principle: card data goes to the provider, not to your backend.
Phone and manual payments
Taking card details over the phone and typing them into a terminal or a virtual terminal brings its own requirements. If staff handle card details, they must follow procedures that prevent recording or storing them. Where possible, send customers a secure payment link instead.
[ 03 ]
FAQ
Frequently asked questions
Does a small online store need a PCI DSS audit?
Small merchants usually complete a self-assessment rather than a full external audit, as determined by their bank or provider. The integration choice largely determines how demanding it is.
Are we compliant if we use a hosted payment page?
It greatly reduces your scope but does not remove all obligations: your website's security and your processes still matter. Confirm the applicable requirements with your provider.
Can we store the last four digits of a card?
Truncated card numbers and tokens provided by the payment provider can generally be stored for reference. Full card numbers and security codes must not be stored by your systems.