The six jobs hiding inside ‘secure payments’

“Secure payments” is not one claim. It is six: replace valuable account data with a constrained substitute; encrypt sensitive bytes while they move; authenticate the customer or payment credential; authorize this transaction now; isolate the vault that can recover the original data; and control the operators who can cross those boundaries.

These jobs fail independently. A checkout can use sound TLS while a malicious script reads a card number before encryption.35 A customer can pass authentication while the issuer declines the purchase.12 A token can keep a PAN out of an application while a broadly reachable token vault quietly restores the original blast radius.114 Security begins when each claim names its asset, adversary and trust boundary.

1. Tokenization: make stolen data less useful

Tokenization changes what the rest of the system handles. Instead of passing a primary account number (PAN) through order services, logs and support tools, a token service returns a substitute. EMV payment tokens go further than simple substitution: they can be restricted to a merchant, device or payment scenario, reducing where a compromised value can be used.1

The boundary sits at capture. On one side, a tightly scoped component sees the PAN. On the other, ordinary commerce systems see only a token. PCI SSC says an EMV payment token outside the token service provider’s token-data environment is not account data, provided the defined controls apply; systems that also handle account data, or connect to those that do, remain in scope.2

That caveat matters. A reversible database alias with an unrestricted detokenization API is not equivalent to a domain-constrained payment token.12 Tokenization limits exposure only when redemption is narrow, authenticated and observable. It does not encrypt a network connection, prove who is paying or decide whether money should move.

2. Encryption: protect the hand-off

Encryption protects data while it crosses an untrusted channel. TLS 1.3 is designed to give application data confidentiality and integrity between its endpoints.3 In card-present environments, PCI point-to-point encryption protects account data from capture in the merchant’s payment device until decryption in the provider’s secure environment.4 The useful question is therefore not “is it encrypted?” but “from which point, to which point, and who holds the keys?”

Encryption ends at an endpoint. If hostile JavaScript reads a PAN in the browser before TLS sends it, the network channel can be flawless and the payment still compromised. PCI SSC’s e-skimming guidance addresses payment-page scripts and pages that can affect payment security, including pages using embedded iframes.5

Key access is the second trap. PCI SSC notes that encryption systems, decryption systems and key-management functions remain in PCI DSS scope.6 Encryption reduces what a network observer or database thief can read. It does not make a compromised endpoint trustworthy, and it does not erase the need to protect the machinery that decrypts.

3. Authentication: establish who—or what—is present

Authentication asks whether the presented customer, device or payment credential deserves belief. EMV 3-D Secure carries transaction, payment-method and device data between merchant and issuer; the issuer can complete a lower-risk flow without customer interaction or request a challenge for higher-risk activity.7

Different mechanisms establish different subjects. FIDO passkeys use public-key cryptography, bind credentials to an online service’s domain and keep any biometric processing on the user’s device.8 EMV chip, by contrast, generates a transaction-unique cryptogram that lets the terminal and issuer authenticate the card; EMVCo says that code cannot be reused.9 “Authenticated” is incomplete unless the system says whether it means the person, device, card, bank or message.

It is also possible to authenticate the right person for the wrong transaction. W3C’s candidate Secure Payment Confirmation specification addresses that gap by having the browser present the payee, amount, currency and instrument, then produce signed evidence of confirmation.10 Authentication can strengthen confidence. It still does not answer whether the account is open, funds are available or policy permits the purchase.

4. Authorization: decide whether this payment may proceed

Authorization is a decision about a specific request at a specific moment. Visa defines it as the issuing bank—or VisaNet acting on its behalf—returning an approval or decline.11 Public Visa documentation separates the stages explicitly: authentication confirms the cardholder’s identity; authorization determines whether the transaction can proceed based on factors such as available funds and account status.12

The trust boundary runs from the merchant and acquirer’s request, through the network, to the issuer’s decision. Cryptographic validation results can travel with that request, but the issuer still applies its risk strategy and returns approve or decline.13 A successful 3DS result is evidence for authorization, not authorization itself.

This distinction changes error handling. An approval belongs to a specific transaction request; it is not blanket permission for future attempts.11 The implementation has to correlate the response to the original order, amount and attempt, preserve the issuer’s decision, and prevent a retry from becoming an untracked second request. Calling the whole sequence “authentication” hides the state transition where financial permission is actually granted.

5. Vault isolation: contain the power to reverse protection

Tokenization creates a substitute; vault isolation protects the mapping, PANs and keys that make reversal possible. PCI SSC’s tokenization guidance places token generation, detokenization, PAN storage and any systems with access to those processes inside the cardholder-data environment. Systems that hold only tokens may be considered outside it only when adequately segmented.14

The boundary should be visible in architecture and behaviour. A payment application may request a narrowly defined operation; it should not inherit database access, export capability or a general-purpose decrypt function. Separate network paths, service identities, authorization policy and audit records make the vault a distinct security domain rather than a table named vault in the main application database.

Isolation has an operational cost: fewer components can debug production failures directly, migrations need controlled procedures, and recovery must work without handing routine administrators permanent access. That friction is the control. NIST’s key-management guidance treats key protection, access control, identity authentication and inventory as management problems in their own right.15 Strong cryptography with casually reachable keys is a strong lock with the key left beside it.

6. Operator access: govern the people who can cross boundaries

Privileged humans and automation can bypass the paths designed for normal payments. The final job is to decide who may deploy payment-page code, query sensitive stores, invoke detokenization, rotate keys, change risk rules or use emergency credentials—and to leave evidence when they do.

PCI DSS makes these separate controls: restrict access by business need to know, uniquely identify and authenticate users, and log and monitor access to systems and cardholder data.16 PCI SSC also says shared credentials should be exceptional; even “break glass” access should preserve individual identity, accountability and an audit trail.17

Least privilege is concrete here. A support role that can view a token need not reveal a PAN. A deployer need not query the vault. A key custodian need not change authorization policy. Short-lived privileged sessions, approval for sensitive actions and alerts on unusual access reduce the chance that one stolen administrator credential becomes every breach at once.

The six jobs form a chain, not a maturity ladder. Tokenization limits usefulness. Encryption protects a journey. Authentication establishes a subject. Authorization grants permission. Vault isolation contains reversal. Operator controls govern exceptional power. None is inherited from another.

A serious design review should replace “the payment flow is secure” with six smaller statements, each carrying an owner, boundary, failure mode and test. The result is less reassuring as a slogan. It is far more useful as engineering.

Sources

1. “EMV Payment Tokenisation.” (opens in a new tab) EMVCo.
2. “How does PCI DSS apply to EMVCo Payment Tokens?” (opens in a new tab) PCI Security Standards Council.
3. “RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3.” (opens in a new tab) RFC Editor.
4. “Point-to-Point Encryption (P2PE).” (opens in a new tab) PCI Security Standards Council.
5. “New Information Supplement: Payment Page Security and Preventing E-Skimming.” (opens in a new tab) PCI Security Standards Council.
6. “How does encrypted cardholder data impact PCI DSS scope?” (opens in a new tab) PCI Security Standards Council.
7. “EMV 3-D Secure.” (opens in a new tab) EMVCo.
8. “User Authentication Specifications.” (opens in a new tab) FIDO Alliance.
9. “EMV Contact Chip.” (opens in a new tab) EMVCo.
10. “Secure Payment Confirmation.” (opens in a new tab) World Wide Web Consortium.
11. “Glossary: Authorization.” (opens in a new tab) Visa Developer.
12. “3D Secure: your guide to safer transactions.” (opens in a new tab) Visa.
13. “Getting Started with VisaNet Connect – Issuing.” (opens in a new tab) Visa Developer.
14. “PCI DSS Tokenization Guidelines.” (opens in a new tab) PCI Security Standards Council.
15. “Key Management Guidelines.” (opens in a new tab) National Institute of Standards and Technology.
16. “Maintaining Payment Security.” (opens in a new tab) PCI Security Standards Council.
17. “Does PCI DSS Requirement 8.2.2 allow users to share authentication credentials?” (opens in a new tab) PCI Security Standards Council.