PCI DSS and the payment gateway: how a hosted checkout and a vault keep card data out of your scope
PCI DSS is the card schemes' standard for anyone who stores, processes or transmits card data. A hosted checkout keeps the card number out of the merchant's systems; a vault keeps it out of the PSP's own code and replaces it with a token; the platform that runs both is the part that carries the full standard. Tranzify's checkout and vault are built for that: card data enters the platform's vault, the client and its merchants work with tokens.
Who is in scope
| Party | What it handles | Scope |
|---|---|---|
| Payer | enters the card on the checkout | none |
| Merchant | receives a token and a result | minimal: the hosted page keeps card data away |
| Licensed client (PSP, acquirer) | routes tokens, sees masked data in the cabinets | reduced: no card numbers in its own systems |
| Platform (Tranzify) | hosts the checkout and the vault | the standard’s service-provider requirements: the vault, the keys |
| Acquirer | authorises and settles | its own certification |
The merchant’s questionnaire
A merchant’s assessment depends on how card data reaches the acquirer. With a hosted page served by the platform under the client’s domain, reached by a redirect, the merchant’s systems never see a card number and the shortest self-assessment applies. A merchant that embeds its own fields and sends them to the platform’s API from its page handles card data in the browser it controls and falls under a longer questionnaire. A merchant that receives card numbers on its own servers is in full scope. The acquirer or the PSP confirms which questionnaire applies to each merchant; the platform’s job is to make the shortest one possible.
How the platform keeps card data contained
- Hosted checkout: the payment page is served by the platform under the client’s domain; the card number goes from the payer’s browser to the vault and nowhere else.
- Vault and tokens: the card is stored encrypted; the token represents it in every API call, journal and report; the client sees BIN, last four digits and expiry.
- Security headers and integrity: the checkout ships with a strict content security policy, subresource integrity for its scripts and a check that its markup and headers have not changed, as the standard requires for payment pages.
- Keys: encryption keys live in the cloud’s key management service with rotation; nobody on the team sees a card number.
- Journals: every payment is journaled without card data, with a trace that support and compliance can open.
- Access: roles, two-factor authentication, step-up checks for sensitive actions, an audit log, named accounts for the people who operate the vault.
Version 4 and the payment page
The current version of the standard treats the payment page as part of the scope that must be protected against script injection and skimming: every script on the page must be inventoried with its purpose and its integrity verified, and a mechanism must detect unauthorised changes to the page’s content and the headers it is served with. The hosted checkout loads no third-party scripts, ships subresource integrity for its own, sends the headers the standard asks for, and runs a check on every release that the page’s elements and headers match the inventory, with an alert when they do not. A merchant on the hosted page inherits that; a merchant with its own page has to build it.
What this means for a client
A PSP or acquirer that runs Tranzify keeps its own PCI DSS obligations for the parts it operates, but its own code never handles card numbers: integrations, cabinets, reports and webhooks work with tokens. The platform is built to the standard’s service-provider requirements for the checkout and the vault; the compliance documents are shared at contract stage. For a client in its own AWS account the same architecture applies; the key service and the vault run in that account, under the client’s keys, and the client’s assessor reviews them there.
Updated: 2026-11-08