Section 10: Keep the Card Out, Keep the Books Honest - Security, Compliance & PCI Considerations

Executive Summary: A database that holds $3.7B of pending seller money attracts attackers and auditors, and this section designs for both. PSP-hosted fields keep card numbers off our servers, which holds our PCI DSS footprint at SAQ A-level. Only the Ledger service can write postings, and every manual adjustment needs two people. A per-shard hash chain, anchored daily to WORM storage, makes any after-the-fact edit to the books detectable. The section ends on Maya's erasure request, where GDPR meets a 10-year retention obligation.

The interviewer leans back. "This system moves $600 million a day. Who can steal from it, and how would you know?" The weak answer is a list: "TLS, encryption, RBAC." The strong answer names what is worth stealing and puts each asset behind a control that someone would have to defeat on purpose. There are three such assets here: card data, the power to move money, and the integrity of the record.

Card Data: The Best Vault Is the One You Don't Run

Under D15, Maya types the card number into PSP-hosted fields, which are iframes served from the PSP's domain inside our checkout page. The PAN goes from the browser to the PSP, and our Payments API receives only a single-use token.

The flow below shows the one boundary that matters: the PAN never enters our infrastructure.

Interviewer: "So tokenization takes you out of PCI entirely?"

You: "No, it shrinks the scope. A merchant that fully outsources card capture to PSP-hosted pages or fields typically qualifies for SAQ A, the lightest questionnaire. Some JavaScript integrations land in SAQ A-EP instead, and our acquirer or assessor confirms which one applies. Volume adds a wrinkle: 10M orders a day × 365 ≈ 3.65B transactions a year makes us a Level 1 merchant. So we'll get an annual assessment by a Qualified Security Assessor rather than self-assess, but what it assesses is an SAQ A-level footprint: the checkout page, its scripts, and how we handle tokens. That page still matters. A script injected around the iframe can phish the card number, so we run a strict Content Security Policy, keep an inventory of approved scripts, and alert when the page changes."

The rejected alternative is running our own card vault, which would pull every service that touches a PAN into full PCI DSS scope with no business need behind it. The flip trigger is multi-PSP routing (D15). Routing one card across two PSPs needs a PSP-neutral credential, either network tokens or a third-party vault, not a raw-PAN vault of our own.

Quick check before moving on: