Payment and Transaction Processing Systems Questions
Designing systems that move money correctly: idempotent payment flows, exactly-once semantics, reconciliation, ledgers, double-entry accounting, and fraud-detection architecture. Covers handling retries and partial failures without double-charging, and the consistency guarantees payments demand. Also covers protecting cardholder data through tokenization and PCI scope reduction, reconciling processor webhooks, and merchant and partner payouts. A high-stakes specialization of distributed transactions.
Outline the main PCI DSS control areas relevant to a cloud-based payments platform, and describe the practical architecture-level approaches a team can use to reduce PCI scope for a merchant. Explain the trade-offs and the residual compliance responsibilities that remain after scope reduction.
Sample Answer
Direct answer
PCI DSS (Payment Card Industry Data Security Standard, currently v4.0.1) has 12 requirements grouped under six goals: secure networks, protect account data, manage vulnerabilities, control access, monitor and test, and maintain a security policy. The cheapest control is not needing most of them: design the payment flow so card numbers go straight from the customer's browser or device to the payment provider and never touch the merchant's systems. Scope reduction shrinks the audit, but it never removes all responsibility: the merchant still owns the page that loads the payment form, its vendors, its policies and its incident response.
Key terms
- Cardholder data: the PAN (primary account number, the long card number), plus cardholder name, expiry date and service code when stored with it.
- SAD (sensitive authentication data): the CVV security code, full track or chip data, and PINs. It must never be stored after authorization.
- CDE (cardholder data environment): every system that stores, processes or transmits cardholder data, plus systems connected to them. PCI scope is the CDE.
- PSP (payment service provider): the company that processes card payments on the merchant's behalf.
- SAQ (self-assessment questionnaire): the form smaller merchants complete to validate compliance. Different SAQs apply to different payment designs, and the shortest ones apply when the merchant never handles card data.
The main PCI DSS control areas
| Goal | Requirements (v4.0.1) | What it means in a cloud payments platform |
|---|---|---|
| Build and maintain a secure network and systems | 1. Network security controls. 2. Secure configurations | Security groups and network policies (security groups are cloud firewall rules attached to a resource, controlling exactly which network traffic may reach it) isolating the CDE; hardened images (server images with unnecessary services and default accounts stripped out before use, to shrink what an attacker could exploit); no default credentials |
| Protect account data | 3. Protect stored account data. 4. Strong cryptography over open networks | Store as little as possible; encrypt stored PANs with keys held in a KMS (key management service, a system dedicated to creating, storing and controlling access to encryption keys) or HSM (hardware security module); TLS (Transport Layer Security, the encryption protocol behind HTTPS) everywhere |
| Maintain a vulnerability management program | 5. Protect against malicious software. 6. Develop and maintain secure systems and software | Patching, secure coding, code review, managing scripts on payment pages |
| Implement strong access control | 7. Restrict access by business need to know. 8. Identify users and authenticate access. 9. Restrict physical access | Least-privilege IAM (identity and access management) roles, MFA (multi-factor authentication) for all CDE access, physical security inherited from the cloud provider |
| Regularly monitor and test networks | 10. Log and monitor all access. 11. Test security regularly | Centralised, tamper-evident logs; vulnerability scans; penetration tests (authorized, simulated attacks meant to find exploitable weaknesses before a real attacker does); change detection (alerting when a file or configuration that is supposed to stay static gets modified, which can signal a compromise) |
| Maintain an information security policy | 12. Support information security with policies and programs | Risk assessment, vendor management, training, incident response plan |
In a cloud deployment, the provider covers part of this (physical security, hypervisor (the virtualization layer that isolates one customer's virtual machines from another's on the same physical hardware), some managed services) and publishes a responsibility matrix saying which requirements it meets, which you meet, and which are shared. You still own your configuration of everything the provider hands you.
Architecture approaches that reduce scope
Ordered from least to most merchant scope:
- Redirect to a PSP-hosted payment page. The customer leaves the merchant site to pay on the PSP's page, then returns. The merchant never sees card data.
- Embedded iframe or hosted fields. (an iframe, inline frame, is a small embedded webpage inside the merchant's page that is actually served by, and under the control of, a different origin, here the PSP) The card inputs are rendered inside frames served by the PSP, so the PAN goes from the browser to the PSP even though the page looks like the merchant's. The merchant receives a token (a random substitute for the card number).
- PSP JavaScript that posts directly to the PSP from a merchant-served page, or client-side encryption of the card in the browser with the PSP's public key. The merchant's servers never receive a readable PAN, but the merchant's page itself can be tampered with to steal it, so more controls apply than in options 1 and 2.
- Tokenization for storage and recurring billing. After the first payment, the merchant stores only the PSP's token and charges it later, so no PAN is at rest in merchant systems.
- P2PE (point-to-point encryption) for card-present terminals: a validated terminal encrypts the card at swipe or tap and only the provider can decrypt it.
- Network segmentation for anything that must remain in scope: isolate the CDE into its own account and network so the rest of the estate is out of scope, and prove the isolation with testing.
Worked example
An online retailer accepts 400,000 card payments a year on its website. That number matters for what follows: under the card networks' volume-based merchant levels, a merchant processing roughly 20,000 to 1,000,000 e-commerce transactions a year falls in the tier that validates PCI compliance by completing a Self-Assessment Questionnaire (SAQ), not the highest-volume tier (Level 1, over roughly six million transactions a year), which faces a mandatory annual on-site audit by a Qualified Security Assessor (QSA). At 400,000 payments, this retailer is squarely in SAQ territory, which is exactly why the SAQ A eligibility question below is the one that decides its validation path.
- Design A: its checkout page posts the card form to its own API, which calls the PSP. Its web servers, API servers, load balancers, logs and the admins of all of them are in the CDE. It must satisfy essentially all 12 requirements across that estate.
- Design B: it switches to PSP hosted fields and stores only tokens. Its servers never see a PAN. Its validation shrinks to a short questionnaire (for fully outsourced e-commerce this is SAQ A). What remains is protecting the checkout page that embeds the PSP frames, managing the PSP as a vendor, and its policies and incident response.
The SAQ A revision published in January 2025 (effective 31 March 2025) removed three payment-page requirements from SAQ A's own checklist (6.4.3: keep an inventory of every script that runs on the payment page, justify why each one is needed, and verify none has been tampered with; 11.6.1: run a change- and tamper-detection mechanism, checked at least weekly, that alerts on unauthorized changes to the payment page's security-relevant HTTP headers and script contents as the browser actually receives them; and 12.3.1: the targeted risk analysis that had backed how often 6.4.3 and 11.6.1 needed to run, no longer needed on SAQ A once those two are gone) and replaced them with two eligibility criteria: every payment-page element must be sourced only from a PCI DSS-compliant third-party service provider, and the merchant must confirm its site is not susceptible to attacks from scripts that could affect its e-commerce systems. In practice that still means controlling which scripts run on the checkout page and vetting who those scripts come from. The underlying requirements 6.4.3, 11.6.1 and 12.3.1 still exist in PCI DSS itself and still apply to merchants on SAQ D or a full on-site assessment; only SAQ A's own paperwork changed for the merchants eligible for it.
Trade-offs
| Approach | Scope | Cost to the merchant |
|---|---|---|
| Redirect | Smallest | Less control over look and flow; the extra hop can cost conversion |
| Iframe / hosted fields | Very small | Styling limits; tied to that PSP's components |
| Direct post or client-side encryption | Moderate | Merchant owns page integrity and more controls |
| Own vault | Large | Full control and PSP portability; full audit burden |
Tokens also create PSP lock-in: a token from one provider does not work at another, which matters if you want a backup processor.
Residual responsibilities after scope reduction
- The page that hosts the payment form. A compromised checkout page can swap the PSP frame for a fake one. Script control, a content security policy (a browser header listing which script sources may run) and change monitoring on that page stay the merchant's job.
- Vendor management. Keep the PSP's attestation of compliance (a formal document, typically signed by a PCI-approved assessor, stating that the PSP's own systems were found compliant) on file, know which requirements it covers, and review it yearly.
- Policies, training, incident response. A breach plan and staff awareness are required regardless of design.
- Anything that drifts back into scope. A support agent who takes a card number over the phone and types it into a CRM (customer relationship management system, the software used to track customer interactions) pulls that CRM and its users back in. Scans for PAN patterns in logs, tickets and data warehouses catch this.
- Annual validation. Scope reduction lowers the effort; it does not remove the obligation to validate and to keep the evidence.
Explain the difference between tokenization and encryption when protecting cardholder data. Describe how tokens are generated and mapped to PANs, where the mapping and encryption keys ideally live, and how tokenization can reduce PCI footprint while supporting use cases like recurring payments.
Sample Answer
Direct answer
Encryption transforms the card number with a key; anyone with the key can mathematically reverse it, so the encrypted value is still card data and the systems holding it (and the keys) stay in audit scope. Tokenization replaces the card number with a random substitute that has no mathematical relationship to it; the only way back is a lookup in a separately secured token vault. Systems that hold only tokens, and cannot ask the vault to reverse them, can be taken out of scope for most of the card-security standard. That is why merchants store tokens for recurring billing instead of card numbers.
Key terms
- PAN (primary account number): the card number, typically 13 to 19 digits in practice (the ISO/IEC 7812 standard allows 8 to 19); most Visa, Mastercard and Discover cards use 16, American Express uses 15, and some older Visa cards use 13.
- PCI DSS (Payment Card Industry Data Security Standard): the security standard every business that stores, processes or transmits card data must meet.
- CDE (cardholder data environment): the systems that touch PANs plus anything connected to them. "Reducing PCI footprint" means shrinking the CDE.
- Detokenization: exchanging a token back for the PAN. Only a few tightly controlled systems should be able to do it.
- HSM (hardware security module): tamper-resistant hardware that stores keys and performs cryptography so the key never leaves it. A cloud KMS (key management service) offers similar key custody as a managed service.
Tokenization vs encryption
| Encryption | Tokenization | |
|---|---|---|
| Relationship to PAN | Mathematical: ciphertext plus key gives the PAN | None: a random value, reversible only through the vault |
| What an attacker needs | The ciphertext and the key | Access to the vault itself |
| Scope effect | For whoever holds or can use the key, the ciphertext is still cardholder data | Systems holding only tokens, with no detokenize access, can be out of scope |
| Typical use | Protecting PANs inside the vault, on disk, and in transit | Letting the rest of the business reference a card safely |
| Format | Ciphertext is usually longer binary data unless format-preserving encryption (encrypting into an output that still looks like a normal card number: same length, same character set) is used | Can be designed to look like a card number (same length, keep last four digits) |
They are complementary: the vault itself encrypts the PANs it stores. Tokenization moves the problem into one small place; encryption protects that place.
How tokens are generated and mapped
- Generate a token from a cryptographically secure random number generator, not from the PAN. A format-preserving token might keep the length and last four digits (useful for receipts and "card ending 4242" screens) and randomise the rest, taking care the result cannot be mistaken for a real, valid card number, for example by deliberately failing the Luhn check (the checksum built into every genuine PAN's last digit, which software uses to catch typos) that a real card number would pass.
- Store the mapping in the vault as
token -> encrypted PAN. The PAN is encrypted with a data key; the data key is itself encrypted by a master key in the HSM or KMS (this is called envelope encryption). - Support lookup by PAN (so the same card gets the same token for a customer, if you want that) with a keyed hash of the PAN, such as an HMAC (a hash combined with a secret key, so only someone holding that key can compute or check it) with a key held in the HSM. A plain unsalted (no random, per-value salt mixed in before hashing, so the same PAN always produces the same output) hash of a PAN is not safe: a 16-digit PAN's first six digits are a public BIN (bank identification number) and its last digit is a Luhn check digit computed from the rest, not random, leaving only about 9 unknown digits, at most 10^9 (one billion) possibilities. Someone who obtains the hashes can precompute all one billion candidates for a known BIN, which is well within reach of ordinary hardware in under a day, and read off which hashes match, so they can be brute-forced.
- Detokenize only for a short list of callers (the service that sends the authorization to the processor), each authenticated, authorised and logged.
Where things should live. The vault, its database and the keys belong in separate security domains: keys in an HSM or KMS whose administrators are not the vault's database administrators, and the vault in its own network segment or cloud account. Stealing the database alone yields ciphertext; stealing a key alone yields nothing to decrypt. Many merchants never run a vault at all: the payment service provider (PSP, the company that processes card payments for the merchant) runs it, and the merchant only ever sees the PSP's tokens.
How this reduces PCI footprint and supports recurring payments
- The customer types their card into a payment form hosted by the PSP (a hosted page or an embedded iframe), so the PAN goes browser to PSP and never reaches the merchant's servers.
- The PSP returns a token such as
pm_1a2b3c. The merchant's database, billing jobs, logs and analytics hold only that token. - For each monthly charge, the merchant's billing job calls the PSP API with the token. The PSP detokenizes inside its own environment and sends the authorization to the card network.
- Because the merchant never stores, processes or transmits the PAN and cannot detokenize, its CDE shrinks dramatically, and its compliance validation becomes far lighter.
Network tokens go one step further: the card networks themselves (for example Visa Token Service and Mastercard's tokenization service) issue a token tied to a merchant, and the network updates it when the physical card is reissued or expires. Recurring billing then keeps working after the customer gets a new card, which reduces involuntary churn.
Worked example
A streaming service bills 2 million subscribers monthly. With encryption only, it would store 2 million encrypted PANs and manage the keys: its database servers, billing workers, backup system and every administrator with key access would be inside the CDE. With PSP tokenization, its database stores pm_... tokens and "Visa ending 4242, expires 08/28" for display. A breach of that database leaks tokens that are useless outside that merchant's PSP account, and cannot be turned into card numbers. The billing job on the 1st of the month submits 2 million charges by token; the PSP holds the only mapping.
Trade-offs and pitfalls
- Tokens are PSP-specific. A token from one PSP does not work at another, which creates lock-in and complicates failover to a backup processor. Network tokens or a PSP-independent vault reduce this, at extra cost or scope.
- "Out of scope" requires that no system can detokenize. If a merchant service has an API credential that can reverse tokens, that service is back in scope.
- Never store sensitive authentication data (the CVV security code, full magnetic-stripe or chip data, PINs) after authorization, whether encrypted or tokenized. PCI DSS forbids it regardless of protection.
- Encryption is not a scope escape for the key holder. Encrypting PANs in your own database is required protection, but if you also hold the keys, those systems are still in scope.
- Card numbers leak sideways. Logs, error messages, support tickets and analytics pipelines are where PANs turn up unexpectedly; scan for them.
That is every published Payment and Transaction Processing Systems question for Cybersecurity Engineer so far. Browse the other topics in this category, or practice this one interactively.