What PCI DSS actually asks of your architecture

The standard isn’t a checklist, it’s a set of architectural questions

PCI DSS gets talked about as a compliance hurdle to clear, which makes people focus on the audit rather than the system. The more useful way to read it is as a set of architectural questions a system handling card data should already be able to answer well: where does raw card data exist, for how long, who and what can reach it, and what happens to it in transit and at rest. Answer those well and most of the standard’s specific requirements fall out as consequences, not separate work.

We built and took a US payments platform through PCI DSS Level 1 service provider validation — a QSA-led onsite assessment with a Report on Compliance and a signed Attestation of Compliance, not a self-assessment questionnaire — and through its PCI DSS v4.0 revalidation since, with quarterly ASV scans. What follows is the architecture that made those assessments go the way they did: tokenization, no raw PAN storage, encryption in transit and at rest, segregated access. The attestation belongs to the client’s platform, not to us as a company, and it depends on facts about that specific deployment at that specific time — but the engineering decisions behind it are the same ones any platform handling card data has to get right, and they’re what this article walks through.

Scope reduction: the highest-leverage decision

The single decision that affects everything else is how much of your system ever touches a raw primary account number (PAN). Every system, service, and person that can reach raw card data is “in scope,” and everything in scope inherits the full weight of the standard’s controls. The practical answer most platforms converge on: touch raw PAN in as few places as possible, for as short a time as possible, and push everything else out of scope entirely by never letting it see the number at all.

Browser/mobile app
  → (raw PAN, TLS) → tokenization boundary (minimal scope)
                          ↓ token
      Everything else in the platform: charges, disputes,
      payouts, reporting, the checkout library, the plugin
      ↑ never sees a raw PAN, only ever a token

Card capture happens as close to the customer as possible — a hosted field or a client-side tokenization call directly to a processor or gateway — so that a raw PAN never transits your own application servers as plaintext in the first place. What reaches your systems is a token: an opaque reference the tokenization provider can resolve back to the real card number, but your own database, logs, and application code cannot.

Tokenization is the mechanism, not the marketing word

Once a token exists, it behaves like the object every downstream service actually needs: charge it, refund it, store it against a customer for next time.

interface StoredPaymentMethod {
  token: string;         // opaque, provider-issued
  brand: string;         // "visa", "mastercard" — safe metadata
  last4: string;         // safe to display, not reconstructable
  expiryMonth: number;
  expiryYear: number;
  // no PAN, no CVV, ever
}

last4 and brand are stored because they’re useful for a customer to recognize their own card in a UI, and neither can be used to reconstruct a usable card number. Nothing in this table, or any table derived from it, can be used to make a charge outside the tokenization provider’s own systems. That property — that a database leak of this table is not a card-data breach — is the entire point of the exercise.

Encryption in transit and at rest, as defaults not exceptions

Every hop that does carry sensitive data — the initial capture call, any internal service-to-service traffic that touches a token or the metadata around it — runs over TLS, with no fallback to plaintext. Anything a token resolves to, and any sensitive metadata stored alongside it, is encrypted at rest using managed keys (AES-256 in the systems we run), with key rotation and access to the keys themselves separated from access to the encrypted data. The failure mode this defends against isn’t a sophisticated attacker breaking encryption — it’s a misconfigured backup, a leaked disk snapshot, or a database export that ends up somewhere it shouldn’t, where encryption at rest is what stands between that mistake and a card-data breach.

Segregated access as an organizational control, not just a technical one

Scope reduction and tokenization limit what’s technically reachable; segregated access limits who can reach it and requires that access be deliberate and logged. In practice that means role-based access to anything in the reduced-scope boundary, no shared credentials, and an audit trail for any access to the systems that can resolve a token — not because an auditor asks for the trail, but because “who looked at this, and why” is the question you need answered fast if something ever looks wrong.

What this buys you architecturally, regardless of the audit calendar

A system built this way is easier to reason about even before anyone schedules an assessment: fewer services touch sensitive data, which means fewer services need the heaviest controls, which means most of your codebase — checkout, reporting, disputes, the parts your engineers actually spend time in — never has to think about card data handling at all. That’s a maintainability win independent of any compliance calendar, and it’s also what made the onsite assessment on the platform we built go the way it did: the QSA was looking at a system where the answer to “where does raw card data exist” was already “almost nowhere, briefly, and almost nobody,” rather than an architecture retrofitted to explain itself under audit pressure — and it’s the same reason the quarterly ASV scans since have stayed routine rather than eventful.

What this means for you

If your architecture can answer, specifically, where raw card data exists, for how long, and who can reach it — and the honest answer is “almost nowhere, briefly, and almost nobody” — you’re building toward what a QSA assessment actually asks for. We’ve built and taken a platform through PCI DSS Level 1 service provider validation, and through the ongoing revalidation and scanning that follows it; this is the engineering that made it possible, not a substitute for the assessment itself, which remains a real, separate process with its own scope and its own assessor.