Payment security conversations often collapse into a single acronym: PCI DSS. That shorthand is understandable — merchants, gateways, and cloud backends live under DSS scope — but it is incomplete. The PCI Security Standards Council (PCI SSC) maintains a family of standards, each scoped to a different layer of the payment stack: cardholder data in transit and at rest, PIN blocks from keypad to issuer, device hardware at the point of interaction, software on commercial phones, and end-to-end encryption from capture to decryption.

This post maps that family. The goal is architectural clarity: knowing which standard applies at each boundary, so you do not audit a backend against DSS when the gap is device trust, or certify a terminal path against DSS when the real question is PCI PTS or PCI MPoC.

The PCI standards family at a glance

At the highest level, three standards cover most card-present and backend work:

Around and beneath DSS sit program-specific standards for software assurance, COTS mobile acceptance, and encrypted terminal pipes:

These are not interchangeable checkboxes. Each standard answers a different threat model.

PCI DSS — cardholder data environments

PCI DSS is the standard almost everyone has heard of. Its purpose is direct: protect cardholder data everywhere it is stored, processed, or transmitted.

Typical entities in scope include merchants, acquirers, payment gateways, payment service providers, data centers, e-commerce sites, and the cloud infrastructure behind them. DSS covers network security, encryption, key management, logging, monitoring, access control, vulnerability management, secure SDLC, and incident response.

What DSS does not do is certify payment terminals. A merchant can be DSS-compliant while the terminal path is governed separately by PCI PTS, PCI PIN, or PCI MPoC depending on form factor. Backend architects still need DSS — authorization APIs, token vaults, and reconciliation stores all handle cardholder data — but terminal security is a different standard set.

For e-commerce, DSS concerns concentrate on the browser-to-gateway path: TLS, hosted payment pages, iframe isolation, tokenization, PAN storage boundaries, JavaScript skimming (Magecart-class attacks), content security policy, 3-D Secure, API authentication, secrets management, and cloud configuration. I cover tokenization mechanics separately in payment tokenization.

For card-present backends, DSS still applies to any system that stores, processes, or routes cardholder data — but the terminal layer adds PTS, PIN, and EMV concerns on top. Point-of-Sale Systems Architecture, Ch. 15 (Backend Architecture for POS) and Ch. 18 (Deployment and Ongoing Compliance) treat DSS storage boundaries and operational controls in production POS estates.

PCI PIN — the PIN path

PCI PIN is a separate standard with a separate audit path. Its scope is PIN protection from the instant the cardholder enters a PIN until the encrypted PIN block reaches the issuer.

The typical flow:

Cardholder → PIN entry → encrypted PIN block → acquirer → HSM → issuer

Everything in that chain — PIN block formats (ISO 9564), DUKPT or zone-key encryption, TR-31 and TR-34 key blocks, HSM requirements, key ceremonies — falls under PCI PIN Security Requirements, not DSS.

PCI PIN mandates that PIN processing occur inside PCI-approved secure cryptographic devices (SCDs): POI devices evaluated under PCI PTS (PED, EPP, SCRP, UPT families) and HSMs meeting PCI PTS HSM or FIPS 140-2/3 Level 3 or higher. EMV defines when Online PIN is required; PCI PIN defines how the PIN block is formed, transported, and translated between key domains. The mechanics of PIN translation and HSM custody are covered in PIN translation and Point-of-Sale Systems Architecture, Ch. 11 (HSMs and PIN Blocks).

PCI PTS — device trust at the point of interaction

PCI PTS — PIN Transaction Security — certifies devices, not merchant environments. Traditional SmartPOS terminals from vendors such as Ingenico, Verifone, PAX, Sunmi, and Castles are evaluated under PCI PTS POI requirements.

PTS covers tamper detection, secure boot, secure firmware, secure PIN entry hardware, side-channel resistance, and the physical security model that SmartPOS relies on. If you manufacture or integrate dedicated payment hardware, PTS is the device standard.

External card readers used with COTS devices — Secure Card Readers (SCR) and Secure Card Reader-PIN (SCRP) units — may also carry PTS evaluation. A phone running Tap to Pay, however, is not a PTS device. It is governed by MPoC software and service requirements instead. That distinction matters whenever someone lists “SoftPOS” under PTS without separating hardware readers from COTS phone acceptance.

I develop the SmartPOS trust model in depth in what makes a payment terminal secure and Point-of-Sale Systems Architecture, Ch. 5 (Trusted POS Architectures in the COTS Era).

PCI P2PE — encrypt at capture

PCI P2PE (Point-to-Point Encryption) encrypts account data immediately after capture and keeps it encrypted until it reaches a secure decryption environment. The merchant environment never sees clear PAN.

Card → encrypted at POI → merchant network → gateway/processor → decrypt in SCD

P2PE is common in retail environments where scope reduction matters. A validated P2PE solution can reduce merchant PCI DSS scope, but only when approved devices, controlled key management, and no clear cardholder data in the merchant environment are all demonstrably true. PTS POI with SRED (Secure Reading and Exchange of Data) is often a component in P2PE-validated terminal solutions, especially for unattended deployments — a topic I cover in Point-of-Sale Systems Architecture, Ch. 17 (Testing and Certification).

P2PE protects account data in transit from the POI. It does not certify a COTS phone as an acceptance device. That is MPoC’s job.

PCI Secure Software and PCI Secure SLC

PCI Secure Software replaced PA-DSS as the program for validating payment applications themselves. Instead of certifying a named payment application product, it certifies that the software meets secure coding, code review, dependency management, threat modeling, penetration testing, and secure update requirements.

PCI Secure SLC (Secure Software Lifecycle) steps up one level: it validates the vendor’s engineering process — CI/CD governance, security reviews, testing discipline, developer training, and security governance across the organization. Think of Secure Software as “this build is sound” and Secure SLC as “this company builds sound software reliably.”

MPoC’s Secure SLC appendix (Domain 4A) ties these concepts directly to SoftPOS release management. Point-of-Sale Systems Architecture, Ch. 18 (Deployment and Ongoing Compliance) maps CI/CD gates, change management, and evidence retention to MPoC ongoing compliance.

CPoC, SPoC, and MPoC — the COTS acceptance line

SoftPOS introduced a branch of PCI standards aimed at commercial off-the-shelf phones and tablets:

PCI CPoC (Contactless Payments on COTS) was the first SoftPOS certification path: NFC card acceptance on a phone, contactless only, no PIN on the device.

PCI SPoC (Software PIN on COTS) added software-based PIN entry on a COTS screen, typically with an external card reader handling the card interaction while the phone captures the PIN.

PCI MPoC (Mobile Payments on COTS) is the current framework. It consolidates CPoC and SPoC use cases and supports NFC acceptance, PIN on glass, remote monitoring, runtime attestation, white-box cryptography, and optional TEE or secure element backing on the same COTS device.

You will still see CPoC or SPoC on older certification sheets. PCI SSC has published sunset direction for those programs toward MPoC during 2026 — confirm exact dates against the current PCI SSC announcement before planning migrations. For new Tap-to-Pay work, MPoC is the practical target unless an acquirer explicitly requires a legacy listing during transition.

MPoC defines three deployable elements: MPoC Software (merchant app plus isolating SDK), MPoC Service (attestation and monitoring backend), and MPoC Solution (the approved combination listed on the PCI SSC site). Certification focuses on proving that sensitive operations stay inside the SDK boundary and that the host application does not circumvent it. I cover L3 integration and MPoC Domain 2A controls in L3 certification paths and Point-of-Sale Systems Architecture, Ch. 17.

P2PE vs MPoC — a common confusion

These two standards are often conflated because both involve encryption on a terminal path. They solve different problems:

P2PE answers: “Can the merchant environment stay out of PAN scope?” MPoC answers: “Can this ordinary phone safely accept a card-present payment right now?”

PCI DSS at the POS boundary

Card-present architectures add concerns beyond backend DSS:

Card → terminal → acquirer → network → issuer

At this layer, architects need PTS or MPoC for device trust, PCI PIN for Online PIN paths, EMV correctness for cryptograms and CVM, DUKPT for transaction keys, device certificates, attestation, remote key injection, and settlement/reconciliation discipline. Terminal tampering, offline approval policy, and store-and-forward behavior sit alongside cryptography — not instead of it.

DUKPT key derivation and the terminal-side key lifecycle are covered in DUKPT key derivation. Why PIN still matters in card-present flows — even as contactless grows — is in PIN still matters in card-present payments.

Which standard applies where?

One row worth stressing: EMV L1/L2/L3 certification is not a PCI standard. EMVCo testing proves specification conformance for devices, kernels, and integrations. PCI standards prove security controls for data, PINs, and devices. A solution needs both where applicable, but they answer different questions. EMV approval is not a substitute for PCI PTS or MPoC listing.

A practical learning order

If you are building depth in payment architecture — especially coming from EMV, SoftPOS, or acquirer integration work — this sequence connects standards to systems:

1. PCI DSS v4.x — foundation for any environment that touches cardholder data.
2. PCI PIN Security — natural follow-on if you already work with DUKPT, PIN blocks, and HSM translation.
3. PCI PTS — device security, tamper resistance, and hardware trust for SmartPOS.
4. PCI MPoC — attestation, runtime monitoring, SDK boundaries, and PIN on glass for Tap-to-Pay.
5. PCI Secure Software and Secure SLC — software assurance and organizational governance.
6. PCI P2PE — end-to-end encryption architecture and scope reduction.
7. PCI CPoC and SPoC — historical context for legacy listings and migration planning.

The payoff is architectural, not checklist-driven. Being able to explain why an e-commerce backend falls under DSS, why a SmartPOS terminal requires PTS, why Online PIN paths require PCI PIN, and why modern Tap to Pay on Android relies on MPoC is what separates layer-aware design from isolated implementation knowledge.

Confirmed facts vs interpretation

Confirmed (per PCI SSC and EMVCo documentation):

• PCI DSS protects cardholder data in storage, processing, and transmission; it does not certify payment terminals.
• PCI PIN governs PIN block formation, transport, and HSM requirements from POI to issuer.
• PCI PTS evaluates payment devices and HSMs at the POI layer.
• PCI MPoC is the current PCI SSC framework for mobile payments on COTS, consolidating CPoC and SPoC use cases.
• PCI SSC has published sunset direction for SPoC and CPoC toward MPoC during 2026. Verify exact dates against the current PCI SSC announcement.
• PCI P2PE validates encryption from capture to secure decryption and can reduce merchant DSS scope when implemented as a listed solution.
• PA-DSS has been succeeded by the PCI Secure Software Standard.
• EMV L1/L2/L3 testing assesses EMV specification conformance; it is separate from PCI device and software listings.

Interpretation (mine):

• Treating “PCI” as synonymous with DSS is the most common source of scope errors in architecture reviews.
• For new SoftPOS programs, MPoC is the practical compliance target unless a specific acquirer requires otherwise during transition.
• P2PE and MPoC are complementary in some estates (encrypted backend pipes plus COTS acceptance) but not substitutes for each other.
• Knowing which standard applies at each layer is a prerequisite for Staff-level payment architecture work — not because interviews demand it, but because wrong-scope designs fail in certification and production.

References

Primary reference (this post is built on it):

• Bevia, V. Point-of-Sale Systems Architecture: A Practical Guide to Secure, Certifiable POS Systems. Book page. Chapters most relevant here:
  • Ch. 3 — EMV Principles (PIN processing, TR-31, PCI PIN layering on EMV)
  • Ch. 5 — Trusted POS Architectures in the COTS Era (SmartPOS vs SoftPOS, MPoC elements)
  • Ch. 11 — HSMs and PIN Blocks
  • Ch. 15 — Backend Architecture for POS (DSS storage boundaries)
  • Ch. 17 — Testing and Certification (PTS, MPoC, P2PE/SRED, EMV L3)
  • Ch. 18 — Deployment and Ongoing Compliance (MPoC lifecycle, Secure SLC)

Related Corebaseit posts:

• What Makes a Payment Terminal Secure: SmartPOS vs SoftPOS
• L3 Certification Paths: CTAP, SmartPOS, and SoftPOS
• PIN Translation
• DUKPT Key Derivation
• PIN Still Matters in Card-Present Payments
• Payment Tokenization

External standards:

• PCI SSC, PCI DSS
• PCI SSC, PCI PIN Security Requirements
• PCI SSC, PCI PTS
• PCI SSC, Mobile Payments on COTS (MPoC)
• PCI SSC, Contactless Payments on COTS (CPoC) — legacy program
• PCI SSC, Software PIN on COTS (SPoC) — legacy program
• PCI SSC, PCI Point-to-Point Encryption (P2PE)
• PCI SSC, PCI Secure Software Standard and PCI Secure SLC
• EMVCo, EMV Level 1 and Level 2 Testing