Understanding how online payments are kept secure
Merchant Secure is an independent, plain-language reference on the core technologies and standards that protect cardholder data when customers pay online. No products, no sign-ups — just the fundamentals every merchant should understand.
PCI DSS
The Payment Card Industry Data Security Standard sets the baseline requirements any business handling card data is expected to meet.
Encryption in transit
TLS encrypts the connection between the shopper's browser and the payment page so card details cannot be read while travelling across the network.
Tokenization
Real card numbers are replaced with a meaningless token, so the actual data is never stored on the merchant's own systems.
3-D Secure
An additional verification step (such as Visa Secure or Mastercard Identity Check) that confirms the shopper is the legitimate cardholder.
The standard behind secure card payments
PCI DSS is a security standard maintained by the PCI Security Standards Council, an organisation founded by the major card networks — Visa, Mastercard, American Express, Discover, and JCB. It applies to any business that stores, processes, or transmits cardholder data, regardless of size. The standard is organised around six control objectives that are broken down into twelve core requirements.
The six goals in plain terms
- Build and maintain a secure network — use firewalls and avoid vendor-supplied default passwords and settings.
- Protect cardholder data — protect stored data and encrypt it whenever it travels across open, public networks.
- Maintain a vulnerability-management programme — use and update anti-malware protection and develop secure systems and applications.
- Implement strong access control — restrict access to data on a need-to-know basis, give every user a unique ID, and control physical access.
- Regularly monitor and test networks — track and log all access to data, and test security systems and processes on a routine basis.
- Maintain an information-security policy — keep a written policy that addresses information security for everyone involved.
Compliance is not a one-time event. It is an ongoing process of controls, testing, and documentation that scales with how much card data a business handles. The current major version of the standard is PCI DSS v4.0, which introduced a stronger focus on continuous security rather than a once-a-year snapshot.
PCI compliance levels
Not every merchant faces the same validation effort. Card networks group merchants into levels based on the annual volume of card transactions they handle. A larger volume means more scrutiny and a more formal validation process. The exact thresholds are set by each card brand, but they broadly follow the pattern below.
| Level | Typical annual card transactions | Usual validation approach |
|---|---|---|
| Level 1 | Over 6 million | Annual on-site assessment by a Qualified Security Assessor (QSA) and quarterly network scans. |
| Level 2 | 1 million to 6 million | Annual Self-Assessment Questionnaire (SAQ) and quarterly network scans. |
| Level 3 | 20,000 to 1 million (e-commerce) | Annual SAQ and quarterly network scans. |
| Level 4 | Fewer than 20,000 (e-commerce) or up to 1 million total | Annual SAQ and, where required, quarterly network scans. |
How an online card payment flows
Understanding where card data travels makes it clearer why each protection matters. A typical card-not-present transaction moves through several parties in a few seconds:
- Checkout — the shopper enters card details on a payment page served over HTTPS, or on a hosted field provided by the payment processor so raw data never touches the merchant's server.
- Encryption & capture — the details are encrypted in transit and, ideally, immediately tokenized so the merchant only ever holds a substitute value.
- Authentication — where 3-D Secure applies, the shopper may confirm their identity with the card issuer before the payment continues.
- Authorisation — the payment processor forwards the request through the card network to the issuing bank, which approves or declines it.
- Settlement — approved transactions are later batched and settled, moving funds from the issuer to the merchant's acquiring bank.
The safest architectures keep sensitive card data out of the merchant's environment as early as possible — often before it ever reaches the merchant's own servers — which is why hosted fields and tokenization are so widely recommended.
Protection works in layers
No single mechanism makes a payment secure on its own. Strong payment security combines several independent layers so that a weakness in one does not expose cardholder data:
- Transport security (TLS/HTTPS) — protects data while it moves between the browser and the server.
- Tokenization & vaulting — removes raw card numbers from the merchant environment entirely.
- Strong customer authentication — confirms the shopper's identity through 3-D Secure or similar checks.
- Access control & monitoring — limits who can reach systems and records what happens on them.
- Regular testing — vulnerability scanning and reviews to catch gaps before they are exploited.
Tokenization vs. encryption
These two terms are often confused. Encryption scrambles data using a key, so anyone who holds the key can turn it back into the original card number. Tokenization instead swaps the card number for an unrelated placeholder that has no mathematical relationship to the original; the real value lives only inside a secured vault held by the processor. In practice the two are complementary — encryption protects data in transit, while tokenization keeps the raw number out of storage altogether.
Common threats to card data
Attackers target payment flows in predictable ways. Knowing the common patterns helps a merchant judge which controls matter most for their setup.
- Digital skimming (Magecart) — malicious JavaScript injected into a checkout page quietly copies card details as they are typed. Content-security policies and script integrity checks reduce this risk.
- Phishing & social engineering — staff or customers are tricked into revealing credentials or card data. Awareness training and multi-factor authentication help.
- Unpatched software — known vulnerabilities in a plugin, CMS, or server are exploited to reach stored data. Timely patching is one of the most effective defences.
- Weak or reused credentials — stolen admin logins give direct access to payment systems. Unique passwords and least-privilege access limit the damage.
- Man-in-the-middle interception — traffic captured on an insecure connection. Enforcing HTTPS everywhere prevents card data being read in transit.
A general checklist for merchants
These are widely recognised, vendor-neutral practices. They are educational starting points and do not replace formal compliance guidance from a qualified provider or assessor.
- Serve every payment page over HTTPS with a valid certificate.
- Use a reputable payment processor and avoid storing raw card numbers yourself.
- Enable tokenization so sensitive data stays out of your systems.
- Turn on 3-D Secure / strong customer authentication where supported.
- Keep software, plugins, and servers patched and up to date.
- Restrict and log administrative access to payment systems.
- Complete the correct Self-Assessment Questionnaire for your setup.
- Review your PCI DSS obligations for your specific transaction volume.
Frequently asked questions
Who has to comply with PCI DSS?
Any business that stores, processes, or transmits cardholder data is expected to comply, no matter how small. Even a merchant that outsources its entire checkout to a third party still has obligations, such as confirming that its providers are themselves compliant.
Does HTTPS alone make my checkout PCI compliant?
No. HTTPS protects data while it travels between the browser and the server, which is essential, but PCI DSS covers far more — how data is stored, who can access systems, how they are monitored and tested, and the policies around them. HTTPS is one necessary layer, not the whole picture.
What is the difference between an acquirer and an issuer?
The issuing bank (issuer) is the bank that gave the shopper their card. The acquiring bank (acquirer) is the merchant's bank that receives the funds. During a payment, the processor routes the request from the acquirer side, through the card network, to the issuer for approval.
Is tokenization the same as encryption?
They are related but not identical. Encryption transforms data with a key that can reverse it, while tokenization replaces a card number with an unrelated placeholder whose real value is kept in a separate secure vault. Many payment systems use both together.
How often do I need to validate compliance?
Validation is typically an annual activity — an on-site assessment for the largest merchants or a Self-Assessment Questionnaire for smaller ones — often combined with quarterly network scans. The exact cadence depends on your compliance level, which your acquirer or processor can confirm.
About this site
Merchant Secure is an independent informational resource focused on the fundamentals of online payment security. It does not sell products or services and does not collect personal information from visitors. The goal is simply to explain, in plain language, how the standards and technologies that protect card payments fit together, so that anyone running an online business can understand the terms they encounter and ask better questions of their providers.
Where this site references specific standards such as PCI DSS or 3-D Secure, those are the responsibility of their respective governing bodies and card networks. Nothing here should be treated as a substitute for the official documentation published by the PCI Security Standards Council or the individual card brands.