As soon as bank cards appear in a system, the abbreviation PCI DSS appears too — usually in an anxious context: "are we in PCI scope?", "the audit is next quarter". Let's look at the standard through a developer's eyes: when it applies to you, what it actually demands, and why the main architectural decision is to make it apply as little as possible.

What it is and when it concerns you

PCI DSS (Payment Card Industry Data Security Standard) is a security standard created by the card networks (Visa, Mastercard and others). It is mandatory for everyone who stores, processes or transmits payment card data. It is not state law but a contractual requirement: violate it and you face fines through your acquiring bank, up to losing the right to accept cards.

Key terms:

  • PAN (Primary Account Number) — the card number; the main protected object;
  • SAD (Sensitive Authentication Data) — CVV, magnetic stripe contents, PIN: must never be stored, not even encrypted, not even "for a minute";
  • CDE (Cardholder Data Environment) — every system that stores, processes or transmits card data, plus everything directly connected to them on the network.

The main strategy: shrink the CDE

PCI DSS requirements cover the entire CDE — including the people and processes around it. So the central architectural move is keeping card data out of your systems altogether:

  • A payment provider + tokenization. The payment form is rendered by the provider (a redirect or their iframe on your page); the PAN travels straight to the provider, and you get back a token — a surrogate worthless to a thief. Your charges run against the token. Most e-commerce services live exactly like this — their audit scope is minimal (the SAQ A self-assessment instead of a full audit).
  • Segmentation. If cards are genuinely processed on your side (a payment gateway, processing), the CDE is isolated into its own network segment: dedicated services, its own access perimeter, minimal links outward. Every service added to the CDE enlarges the audit surface; design so that "ordinary" services (catalog, orders, profiles) stay out of the CDE.

The rule in code terms: the order service must know "paid with token tok_abc" — and never the card number.

The requirements: what they mean in code

Formally the standard is 12 requirements; for a developer they boil down to a few habits:

  • Store nothing extra. PAN — only with proven necessity, masked when displayed (first 6 / last 4), encrypted at rest; SAD — never. Check the most treacherous place — logs: a PAN in a request log or a stack trace is a ready-made violation. It's the same principle as PII in logs.
  • Encryption in transit: TLS on every path card data takes, internal ones included.
  • Least privilege: roles on a need-to-work basis, unique accounts (no shared admin logins), MFA for CDE access.
  • Logging: who accessed which cardholder data and when — an audit trail protected from tampering.
  • Secure development: code review, vulnerability and dependency management, test environments without production card data.

Levels and assessments

The depth of the assessment depends on transaction volume: from an annual self-assessment questionnaire (SAQ) for small merchants to an on-site audit by a certified assessor (QSA) for large ones. The practical takeaway for a team: which SAQ applies is determined by your payment-acceptance architecture — a redirect to the provider, their iframe, or your own form each yield a different list of requirements. Decide "how we accept cards" together with whoever owns compliance — before implementation, not after.

In short

  • PCI DSS is mandatory for anyone storing, processing or transmitting card data; it is a contractual requirement of the card networks with fines through the bank.
  • CVV and other SAD are never stored; PAN — only when necessary, masked and encrypted; the most common violation is a card number in the logs.
  • The main move is shrinking the CDE: provider tokenization takes your services out of scope; with in-house processing — strict segmentation.
  • In code it means: minimal data, TLS everywhere, least privilege, access auditing, clean logs and test environments without production cards.
  • The way you accept payments (redirect / iframe / own form) determines audit depth — choose it deliberately and early.
  • PII and secrets — keeping sensitive data out of logs and configs.
  • Auditing admin actions — the logging PCI DSS also demands.
  • Which check goes where — authorization layers around payment operations.