Why architecture matters here
Architecture matters here because scope is transitive and unforgiving. A single system that touches a PAN pulls in every system it connects to without adequate segmentation, and 'connected to' is interpreted broadly. One debug endpoint that echoes a request body, one queue that briefly carries an unredacted payload, and your entire asynchronous processing tier is in the CDE. You do not get to argue that the exposure was momentary. The auditor asks what the system is capable of touching, and momentary is a yes.
The cost asymmetry drives every decision. Being out of scope costs an integration effort measured in weeks. Being in scope costs a permanent tax: quarterly ASV scans, annual penetration tests with segmentation validation, key management procedures, access reviews, log retention, and an auditor's time — every year, forever, growing with your system. No team regrets the weeks. Many regret the tax, and by then the flows are entrenched and getting out means re-architecting checkout.
There is a security argument that stands independently of compliance, which matters because compliance-driven work tends to rot. Card data you never possess cannot be stolen from you. The largest card breaches were not failures of encryption; they were breaches of environments that held data they had no business holding. Tokenisation makes the breach class structurally impossible rather than merely unlikely, and that is a different quality of guarantee than a well-configured HSM.
Finally, v4.0 moved the threat model in a way that punishes teams who thought an iframe finished the job. Magecart-style attacks do not need your PAN storage — they need one compromised script on the page that hosts the payment field, which can overlay a fake form or exfiltrate keystrokes. Requirements 6.4.3 and 11.6.1 exist because the boundary is only as good as the page around it, and defending that page is now an explicit, evidenced obligation rather than a nice-to-have.
The architecture: every piece explained
The hosted field is the mechanism, and its power is entirely the browser's same-origin policy. The PSP serves an iframe from its own origin containing the card input. Your page embeds it, styles it through a sanctioned API, and cannot read it — not because the PSP asked nicely but because the browser forbids cross-origin DOM access. The customer types into a document your JavaScript cannot reach. This is what makes 'the PAN never touches our systems' a structural claim rather than a policy claim, and it is why full-page redirects and hosted fields qualify for SAQ A while a self-hosted form posting to a PSP API does not.
The PSP vault receives the PAN directly from the iframe and returns a token — an opaque reference with no mathematical relationship to the card number, meaningless outside the PSP's system. Your backend receives that token and stores it exactly as it would a customer id. It is not sensitive in the PCI sense: stolen, it authorises nothing outside your PSP account. This is the property that lets a tokenised database sit outside the CDE while containing a row for every card your customers ever used.
Beneath that sits network tokenisation, worth distinguishing because teams conflate the two. A PSP token is a reference in the PSP's vault. A network token is issued by the card network itself, is domain-restricted, and updates automatically when a card is reissued. The practical consequence is lifecycle: network tokens survive card expiry and replacement, which is why subscription businesses see involuntary churn drop when their PSP enables them. Both keep you out of scope; only one keeps recurring billing working after a reissue.
The surviving CDE is what remains, and being honest about it is the point. The PSP is in scope and provides an Attestation of Compliance — obtain it, keep it current, and record it in your evidence file. The iframe is the PSP's. What is yours is the page that hosts it, and under v4.0 that page carries real requirements: an inventory of every script on the payment page with a written justification, integrity assurance for each (SRI, CSP with a strict allowlist), and change detection that alerts when the page's script set or HTTP headers move.
The leakage watch is the operational half, and it is where scope is usually lost. Session replay tools record DOM interactions; analytics tags capture form fields; error trackers serialise request bodies; a support tool lets an agent paste a card number into a ticket. Each of these can pull a PAN into a system you never intended to be in scope, and each is installed by someone who has never heard of your CDE diagram. Redaction rules, a payment-page allowlist that excludes third-party tags by default, and a support workflow that makes card entry impossible are the controls that keep the boundary real between audits.
End-to-end flow
Trace a payment. The customer reaches checkout. Your server renders a page containing an empty div and the PSP's script tag; the script is pinned by SRI hash and permitted by a CSP allowlist naming the PSP's origin and nothing else. The PSP script inserts an iframe from its origin. Your page has now delegated card collection without ever having the capability to collect it — a property the browser enforces on your behalf.
The customer types their card. Every keystroke lands in the PSP's document. Your analytics tag, your session replay tool, and your own event handlers observe nothing, because the same-origin policy is not a convention. When they submit, the iframe posts the PAN directly to the PSP over TLS. That request never transits your infrastructure: not your CDN, not your load balancer, not your API gateway. This is precisely why those systems are out of scope, and it is worth noticing that a self-hosted form proxying to the PSP would have put all three in.
The PSP vaults the PAN and returns a token to the iframe, which passes it to your page through the sanctioned postMessage channel. Your JavaScript now holds tok_1a2b3c and posts it to your backend with the order. Your backend stores the token against the customer, calls the PSP's charge API with it, and gets an authorisation. Your database now contains a payment method reference and no card data — the state you wanted, reached without your code ever handling a PAN.
A month later the subscription renews. A job reads the stored token and calls charge again; the PSP detokenises internally, and if network tokens are enabled the card network has already updated the underlying credential after the customer's reissue, so the charge succeeds against a card number nobody in your company has seen. The customer requests a refund; your support tool sends the PSP a payment-intent id, not a card. Notice what did not happen: no flow needed the PAN back, which is the test of whether the design actually holds.
Meanwhile the v4.0 controls run continuously. A weekly job diffs the payment page's script inventory against the approved list and pages if anything appears. A marketer adds a tag manager snippet to the site template; the CSP blocks it on the payment page and the change detector fires. Somebody is briefly annoyed, and that annoyance is the control working — the same snippet, unblocked, is the Magecart vector, and the difference between a near-miss and a breach was a policy that failed closed.
The most instructive thing about this flow is a negative: trace every system that a card number touched, and the list has exactly two entries, both belonging to the PSP — the iframe and the vault. Your CDN, load balancer, API gateway, application servers, message queue, and database each handled the transaction and none of them handled a PAN. That is not a happy accident of careful configuration that a future refactor might undo; it is a structural consequence of where the iframe boundary sits, enforced by the browser rather than by your discipline. This is the distinction that separates real scope reduction from the appearance of it. A team that self-hosts the card form and immediately forwards it to the PSP can truthfully say they store nothing, and they are still fully in scope, because for the width of one function call their server held the PAN and therefore could have logged it, cached it, or leaked it in a stack trace. Capability, not storage, is the test. The hosted field wins not because it stores less but because it removes the capability entirely, and the audit evidence for 'we cannot' is categorically stronger and cheaper than the evidence for 'we choose not to'.