Architecture·March 2025·9 min read

Protecting Customer Payment Data: What Every E-Commerce Business Needs to Know

Protecting payment data is mostly a scoping exercise, not a feature list. The less of your own infrastructure that ever handles a raw card number, the less of PCI DSS applies to you, and tokenization at the processor and card-network level is the single change that shrinks that scope the most.

PCI DSS is a scope problem before it's a controls problem

PCI DSS applies to any organization that stores, processes, or transmits cardholder data, and it defines a common set of technical and operational requirements for protecting it (PCI Security Standards Council — Standards overview). The current version, PCI DSS v4.0.1, is a limited revision published to clarify stakeholder questions on v4.0 (PCI Security Standards Council — Document Library).

What most engineering teams miss is that the requirements only apply to systems that are actually in scope, and scope is a design decision. A checkout that never lets a raw card number touch the merchant's own servers has fundamentally less to secure, audit, and prove compliant than one that does.

Self-Assessment Questionnaires: the practical entry point

Most e-commerce merchants validate PCI DSS compliance through a Self-Assessment Questionnaire rather than a full on-site audit, and eligibility depends on transaction volume and how card data flows through the business (PCI Security Standards Council — Completing a self-assessment). There are nine SAQ types; the two that matter most for a typical online store are SAQ A, for merchants who fully outsource payment processing with no card data touching their own servers, and SAQ D, the longest and most demanding, for merchants who handle card data directly.

SAQ A has roughly 30 questions. SAQ D for merchants runs past 250. The difference between them is entirely a function of how much of the checkout flow ever sees a raw card number.

Tokenization is two different things people conflate

"Tokenization" gets used for two distinct mechanisms that solve related but different problems, and mixing them up leads to incomplete security designs.

Processor-level tokenization: the card number never reaches your servers

A payment processor's vault accepts the raw card number directly from the customer's browser or a hosted field, stores it in the processor's own PCI-compliant environment, and returns an opaque token to the merchant (Stripe Documentation — Forward card details to your own token vault, Stripe API Reference — Tokens). The merchant's server only ever sees and stores the token, which is useless outside that processor relationship.

This is what actually shrinks SAQ scope from SAQ D to SAQ A: the merchant's own infrastructure is architecturally incapable of exposing a card number it never received.

Network tokenization: a token that survives the card's whole lifecycle

Visa Token Service and Mastercard's Digital Enablement Service (MDES) operate one level up, replacing the primary account number itself with a network-issued token that both implement under the shared EMVCo tokenization framework (Visa — Visa Token Service, Mastercard Developers — Mastercard Digital Enablement Service (MDES)). Unlike a processor token, a network token is portable across a card's reissuance: if a customer's physical card expires or gets replaced, the network updates the token behind the scenes and a stored recurring-billing relationship keeps working with no customer action.

A processor vault removes the card number from the merchant's servers; a network token removes the dependency on that specific physical card ever changing.

Tokenization is becoming a regulatory requirement, not just best practice

India's central bank has made this mandatory rather than optional. The Reserve Bank of India's card-on-file tokenization framework requires explicit customer consent with an additional factor of authentication for tokenization, and prohibits merchants and payment aggregators from storing actual card numbers, only issuers and card networks may retain them (Reserve Bank of India — Notification on tokenisation of card transactions).

That single regulatory move converts "should we tokenize" into "we are not permitted to store card numbers at all" for any merchant serving that market. Other regulators are moving in the same direction with strong customer authentication requirements under PSD2 in the EU and UK (European Commission — Strong customer authentication requirement of PSD2).

Card-on-file tokenization went from an optional security upgrade to a regulatory mandate in at least one major market. Treating tokenization as a nice-to-have engineering project is already behind where the regulatory floor sits.

SAQ A versus SAQ D in practice

Dimension	SAQ A (fully outsourced)	SAQ D (merchant handles card data)
Card number touches merchant servers	Never	Yes, at some point in the flow
Approximate question count	About 30	250+ for merchants, more for service providers
Typical implementation	Hosted payment fields or redirect to processor	Custom-built checkout handling raw PAN
Audit and maintenance burden	Low, concentrated on integration correctness	High, ongoing formal controls across infrastructure

Encryption in transit still matters, independent of tokenization

Tokenization protects data at rest and reduces what the merchant stores; it does not replace transport security for the request that carries the card number to the processor in the first place. TLS 1.3, defined in RFC 8446, removed several legacy cipher modes that earlier TLS versions still permitted, closing off entire classes of downgrade attack (IETF — RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3).

A hosted payment field only isolates card data from the parent page if the connection carrying that field is itself on a current TLS version, with certificates rotated on schedule rather than left to expire and silently fall back to an insecure default (MDN — Transport Layer Security). Tokenization and transport encryption are complementary controls, not substitutes for each other.

Breach notification is a separate obligation layered on top

Reducing PCI scope lowers the chance of a card-data breach; it does not remove the notification obligations that apply once any breach involving personal data occurs. The EU's data protection framework requires notifying the relevant supervisory authority without undue delay once a controller becomes aware of a qualifying breach (European Commission — Data protection explained).

California's Consumer Privacy Act imposes its own separate disclosure and consumer-rights obligations for businesses handling the personal information of California residents, distinct from and additional to PCI DSS's technical requirements (California Department of Justice — California Consumer Privacy Act (CCPA)). PCI DSS compliance and breach notification compliance are two different obligations that both apply to the same underlying data.

What client-side tokenization actually looks like in code

Stripe recommends performing tokenization client-side through its payments integrations specifically so that a card number never reaches the merchant's own server at all, which is what keeps the integration eligible for SAQ A rather than a heavier questionnaire (Stripe API Reference — Tokens).

// Card details are collected in a Stripe Element, isolated in its own iframe.
// The merchant's own JS never sees the raw card number.
const {token, error} = await stripe.createToken(cardElement);

// Only the token is sent to the merchant's server.
await fetch("/charge", {
  method: "POST",
  body: JSON.stringify({ token: token.id }),
});

The security property here is architectural, not procedural: the merchant's server-side code has no code path that could leak a card number, because it never receives one to leak.

Who owns this in practice

Tokenization scope reduction sits at the intersection of engineering, payments operations, and compliance, and treating it as purely an engineering task tends to miss the SAQ re-filing step. The architecture change is engineering's job; confirming the new SAQ type actually reflects the new architecture, and getting the acquiring bank to sign off, is a payments-operations and compliance task that has to happen alongside it.

Where PCI scope quietly expands without anyone noticing

Logging: a card number pasted into an error log or a customer-support ticket by a well-meaning support tool puts that logging system in scope, even if the primary checkout never stores it.
Screen-sharing and support tooling: a support agent viewing a customer's screen during checkout can inadvertently capture card data in a session recording.
Misconfigured hosted fields: an iframe-based hosted field that isn't actually isolated from the parent page's JavaScript can leak keystroke-level card data to scripts that were never meant to see it.
Third-party scripts on the checkout page: any analytics or marketing script with page-wide DOM access sitting on the same page as a card field is a scope risk regardless of what it was installed for.

A rollout sequence for reducing scope

Confirm today's actual card-data flow end to end; most scope creep comes from an integration nobody mapped, not the primary checkout path.
Move to a processor's hosted fields or a redirect-based checkout so the merchant's own servers never receive a raw card number.
Re-file the correct, now-smaller SAQ type once the architecture actually supports it; SAQ eligibility follows the real data flow, not intent.
Layer network tokenization on top for stored, recurring-billing relationships, to survive card reissuance without a failed-payment support ticket.
Audit every third-party script and support tool with access to the checkout page for card-data exposure, not just the primary payment integration.

FAQ

Does tokenization eliminate PCI DSS compliance entirely?

No. It reduces scope and the applicable SAQ type, but the merchant still has PCI DSS obligations around the systems that remain in scope, including the token itself and any integration with the processor.

What's the actual difference between a processor token and a network token?

A processor token is specific to that processor relationship and replaces the card number in the merchant's own systems. A network token, issued by Visa or Mastercard, replaces the card number across the card's lifecycle and survives reissuance.

Can a small e-commerce business skip PCI DSS entirely?

No business handling card transactions is exempt, but a fully outsourced checkout using hosted fields or a redirect qualifies for the much shorter SAQ A rather than SAQ D.

Is storing a token instead of a card number completely risk-free?

A stolen token is far less useful to an attacker than a stolen card number, since it typically only works within the specific processor or network relationship it was issued for, but the token vault and its access controls still need to be secured.

Why is India's RBI tokenization mandate relevant outside India?

It's a preview of where card-network and regulatory direction is heading generally: mandatory tokenization and a prohibition on merchant-side card storage, rather than an optional security enhancement.

References

From the Destm engineering archive. For current work on this topic, start at Solutions or the blog.