PCI compliance for merchants — what actually matters (and what's theater)

PCI-DSS is the security standard every merchant who accepts card payments must comply with. In practice, 90% of merchants drastically overcomplicate it because they don't understand scope — and scope is the single variable that determines whether PCI is a $300 annual effort or a six-figure quarterly program.

What PCI-DSS actually requires

The Payment Card Industry Data Security Standard mandates 12 controls covering: firewall configuration, cardholder data storage, encryption, access management, physical security, monitoring, testing, and policy. The current version (PCI-DSS 4.0.1) took effect April 2024 with mandatory compliance March 2025. Key new-in-4.0 requirements: MFA on all access (not just admin), targeted risk analyses, customized approach option.

The four merchant levels

• Level 1: 6M+ Visa/MC transactions per year, or any merchant processing any Amex, Discover, JCB, or UnionPay annually. Requires annual on-site audit by a QSA (~$40k-$100k).
• Level 2: 1M-6M transactions. Annual self-assessment + quarterly scanning.
• Level 3: 20k-1M transactions. Annual self-assessment.
• Level 4: Under 20k transactions. Annual self-assessment (discretion of acquirer).

Most multi-brand operators at $500k-$2M/mo fall into Level 3 or Level 4. An on-site QSA audit is usually not required. What is required: correctly completing a Self-Assessment Questionnaire (SAQ).

Pick the right SAQ — this is where 90% of effort is wasted

There are 9 SAQ types. Picking the wrong one means answering hundreds of irrelevant questions. The key variable: where does cardholder data (CHD) actually touch in your system?

SAQ A (the easy one — aim for this)

22 questions. You qualify if: all card payments are fully outsourced (hosted by your processor via iFrame or redirect). Your website never sees card data. Examples: you use Stripe Checkout redirect, Square hosted checkout, or a fully-iFrame'd payment form. PCI scope = minimal.

SAQ A-EP

191 questions. Your website partially controls the payment page but card data still goes directly to the processor via iFrame or JavaScript tokenization (Stripe Elements, Square Web SDK). Your server never handles the PAN. Much harder than SAQ A but still manageable.

SAQ D (the painful one — avoid if at all possible)

329 questions. You store, process, or transmit card data on your own infrastructure. Custom checkout that POSTs PAN to your server. Legacy gateway integrations that tokenize server-side. Full CHD environment on your infrastructure.

Going from SAQ D to SAQ A typically saves 10-40 hours of compliance work per year. Architectural changes pay for themselves in the first cycle.

The three scope-reduction moves

1. Tokenization (biggest lever)

Replace card numbers in your system with tokens. Your processor handles the actual PAN; your database stores meaningless tokens. Subscription management, refunds, representment — all work with tokens. Your database falls out of scope.

Almost every modern processor supports this. Stripe, Square, Authorize.net, NMI, Adyen — all have tokenization products. If you're doing custom checkout, you're leaving scope on the table unless you're tokenizing.

2. iFrame / hosted checkout

Card entry happens in an iFrame or hosted page served by your processor. Your website's DOM never contains the card number field. Most processors offer this — Stripe Checkout, Square hosted, Authorize.net SIM, etc.

Tradeoff: less control over checkout styling + flow. But on standard e-commerce, the UX impact is minimal and the PCI savings are enormous.

3. Network segmentation

If you must handle CHD directly, segment it. Systems that touch card data live on a separate VLAN, separate firewalls, separate logging — isolated from the rest of your infrastructure. This scopes PCI requirements to that segment only; the rest of your systems fall out.

Segmentation requires penetration testing annually (PCI 11.3.4) to prove it's effective. Not trivial, but much cheaper than treating your whole infrastructure as in-scope.

Common scope-creep traps that quietly expand PCI liability

• Logging cardholder data in application logs. Accidentally logging a POST body that contains a card field. Scan your logs; if PAN ever appears, you're in-scope.
• Session replay tools on checkout. FullStory, Hotjar, LogRocket — if enabled on the checkout page, they may capture the card input. Now in-scope. Exclude them from checkout pages explicitly.
• Support agents viewing full PANs. Old-school admin tools that display "last 12 digits" for verification. Those workstations + that tool = in-scope.
• Email receipts containing card data. "Last 4 of card used: 1234" is fine (masked). Full PAN is scope expansion.
• Backup systems holding old card data. If your backups from 2019 contain unencrypted PANs, all backup infrastructure is in-scope today.

PCI-DSS 4.0.1 changes that matter for merchants

• MFA on all access to systems handling CHD. Not just admins. Including developers, support, ops.
• Quarterly penetration testing for Level 1 merchants (was annual).
• Targeted risk analyses for any control you customize or address differently. Documentation required.
• Customized approach option — if a control doesn't fit your environment, you can propose an equivalent. Requires extensive documentation but adds flexibility.

How multi-brand operators specifically handle PCI

Running 4 brands on 4 processors = 4 separate PCI programs in the worst case. Each brand has its own SAQ, its own annual attestation, its own compliance cycle.

Under a consolidated parent merchant account via multiflow: one PCI program covering the parent entity. All sub-brands inherit the parent's compliance posture. Typical operator saves 20-40 hours per year in compliance overhead alone.

multiflow operates the orchestration layer as a PCI-DSS Level 1 Service Provider with SAQ D-SP attestation. We do the heavy compliance lifting; your operator-side SAQ is typically SAQ A (iFrame checkout) or SAQ A-EP (JS-tokenized). Attestation + memo available on request under NDA.

The operator checklist

1. Map your card data flow: where does PAN enter your system, where does it leave?
2. Identify the SAQ you qualify for today. Most merchants qualify for SAQ A-EP at minimum.
3. If you're on SAQ D, architect toward SAQ A within 6 months. The path: iFrame checkout + token-only storage.
4. Audit logs quarterly for PAN exposure. Set up alerts.
5. Enforce MFA on everything that touches CHD systems.
6. Document sub-processors + data flow for DPA/privacy compliance.
7. Penetration test before annual attestation.

Beyond PCI — what your operator-facing compliance story should include

Customers and enterprise buyers increasingly ask for: SOC 2 Type II reports, DPA (Data Processing Addendum), sub-processor list, incident response plan, business continuity documentation. PCI alone isn't sufficient for enterprise sales anymore. multiflow's security page details our posture across these dimensions — it's the compliance pitch deck most multi-brand operators need.