A developer who swaps raw card numbers for tokens has done something useful, but has not made PCI DSS go away. What tokenization changes is PCI DSS scope: which of your servers, scripts and staff the standard reaches, and which self-assessment questionnaire your business can file each year. The difference between “fewer systems in scope” and “no obligations” is where most integration mistakes start.

This explainer walks through what the PCI Security Standards Council says about tokens, how hosted payment fields shift a merchant between questionnaires, and what still lands on your plate after the card number leaves your servers.

What PCI DSS scope means

PCI DSS applies to the cardholder data environment, or CDE: the systems that store, process or transmit card data, plus anything connected to them. Stripe’s integration security guide puts the cost of handling raw card numbers directly at “more than 300 security controls,” along with dedicated security tooling and external auditors for the annual assessment.

Scope reduction is the practice of keeping card data off as many systems as possible so that fewer of those controls apply. The Council’s Tokenization Guidelines information supplement states the principle plainly: “The key for merchants wishing to reduce their PCI DSS scope is to not store, process, or transmit cardholder data.”

The supplement dates from August 2011 and says it supplements, rather than replaces, the standard.

What tokenization takes off your plate

A token stands in for the primary account number (PAN). When a processor tokenizes a card, your database holds a value such as a payment method ID instead of the 16-digit number. The supplement says systems that hold only tokens may be considered outside the CDE, and possibly out of scope, if they meet a set of conditions:

  • recovering the PAN from the token, or from many tokens, must not be computationally feasible;
  • the PAN cannot be retrieved even if the token and the system holding it are compromised;
  • the systems are segmented from anything that can submit a de-tokenization request, reach the token vault or its keys, or derive the PAN;
  • they are not located in or connected to the CDE and hold no credentials for it;
  • they do not handle card data through any other channel;
  • systems that held card data before tokenization have been checked to confirm every trace was securely deleted.

That last point is easy to skip during a migration. Old logs, analytics exports and database backups that captured full card numbers keep those systems in scope until they are cleaned.

What you may keep is narrower than many teams assume, but useful. Stripe says the card brand, last four digits and expiration date it returns are not subject to PCI compliance and can be stored, along with anything else its API returns.

What stays in scope

The same supplement is clear about the other side. The tokenization system itself, including the card data vault and any component that can turn a PAN into a token or a token back into a PAN, is part of the CDE and “always in scope.” When a processor runs the vault, that burden sits with the processor, which is why Stripe notes that it is assessed annually as a PCI Level 1 Service Provider.

Two conditions bring tokens back into scope on the merchant side:

The merchant can get the PAN back. The supplement says that if the PAN is retrievable by the merchant, the merchant’s environment is in scope. A token is only a scope reducer if your systems cannot exchange it for the card number.

The token can pay. Tokens that can be used to initiate a transaction, which the Council calls high-value tokens, may have the same value to an attacker as the card data they replace. The supplement says such tokens “might be in scope for PCI DSS” even when they cannot reveal the PAN, and tells merchants to check with their acquirer or the card brands. In practice, a stored payment method that your API key can charge deserves the same protection as the key itself.

How the payment page decides your questionnaire

Tokenization handles card data after capture. The bigger scope decision is how the card is captured in the first place, and the Council’s self-assessment questionnaires (SAQs) spell this out for card-not-present merchants.

SAQ A is the shortest. It is for merchants that have outsourced all account data functions to PCI DSS compliant third parties and do not electronically store, process or transmit account data on their own systems. For e-commerce, every element of the payment page or form delivered to the customer’s browser must “originate only and directly” from a PCI DSS compliant service provider or processor. A hosted checkout page or card fields served in a processor’s iframe are the usual ways to meet that.

SAQ A-EP covers e-commerce merchants whose website does not receive account data itself but does affect the security of the payment transaction or the integrity of the page that collects it. Here, elements of the payment page can come from either the merchant’s site or a compliant provider. The questionnaire is far longer, because the merchant’s own web servers now matter.

A merchant that receives the card number on its own servers is outside both and generally faces the full standard.

The 2025 change to SAQ A

In January 2025, the Council announced changes to SAQ A in response to stakeholder feedback on the complexity of two new payment page security requirements in PCI DSS v4.0.1, Requirements 6.4.3 and 11.6.1. The revised SAQ A dropped those two requirements and Requirement 12.3.1’s related risk analysis. In their place it added an eligibility criterion: the merchant must “confirm their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).” The revision took effect on March 31, 2025, and the Council stressed that the requirements remain in the standard itself.

A follow-up FAQ, published in February 2025, says a merchant can meet the criterion in one of two ways: by using techniques such as those in Requirements 6.4.3 and 11.6.1, deployed by the merchant or a third party, or by obtaining confirmation from its compliant processor that the embedded payment form, implemented as instructed, includes protections against script attacks. The criterion applies only to pages that embed a provider’s form, such as an iframe. It does not apply to merchants that redirect shoppers to the provider’s page or send customers a payment link.

For developers, that makes the integration choice concrete. An embedded card form keeps the shopper on your page but brings your page’s scripts into the conversation. A full redirect to a hosted page avoids the criterion entirely.

What still lands on the merchant

Even with a hosted form and tokens everywhere, some work remains:

  • An annual attestation. Stripe says merchants must attest to compliance each year, and Braintree’s PCI compliance page says integrating with it “does not automatically fulfill” a merchant’s requirements.
  • Script hygiene on embedded checkouts. Stripe’s guide warns that including JavaScript from other sites makes your security dependent on theirs, recommends minimizing it, and lists Content Security Policy directives for its products.
  • TLS on payment pages. Stripe calls for TLS 1.2 or above.
  • Webhook integrity. Stripe says webhook events never include sensitive information, but it still tells merchants to verify webhook signatures. We compared how providers sign them in our guide to verifying payment webhook signatures.
  • Confirming the right questionnaire. The Council does not decide which SAQ a business must file. Its January 2025 notice says that is set by card brands, acquirers and payment facilitators, which it calls compliance enforcing entities.

Sources