PCI DSS Compliance for San Francisco Payment Companies: Why Sub-Merchant Scope Is an Asset Management Problem
Payment Card Industry Data Security Standard (PCI DSS) compliance is usually framed around one question: does a business’s cardholder data environment (CDE) have a definable edge, and can that edge be secured and audited? For most enterprises that accept card payments, the answer starts with their own point-of-sale (POS) terminals, payment gateway, and the systems that touch a transaction on its way to an acquirer. San Francisco’s largest payment companies don’t fit that framing at all, because they are not enterprises that happen to accept card payments, they are the infrastructure other companies’ card payments run through. Stripe, Square, Brex, and Marqeta are not managing PCI DSS as a cost of doing business, payment processing is the business, and that changes what CDE scope actually means for them.
A traditional merchant has a CDE with a describable edge. A payment facilitator does not have that kind of edge, it has thousands of them, layered on top of each other, and most are owned by companies that never signed up to think about PCI DSS at all.
What a Payment Facilitator Actually Is, and Why That Changes the Scope Question
A payment facilitator, or PayFac, is a company that lets other businesses accept card payments under its own master merchant account rather than requiring each business to register directly with an acquiring bank. Stripe’s own guide to the model describes a payment facilitator as the entity that manages sub-merchant onboarding, card network relationships, and payouts on behalf of every business connected through it. The sub-merchant gets a fast, simple way to start accepting payments. The PayFac gets the master account, the card network relationship, and the liability.
That liability is specific and heavy. As one payment security executive put it, the PCI compliance obligation ultimately concentrates at the payment facilitator, regardless of how many sub-merchants sit downstream of it. A PayFac is required to conduct due diligence on every sub-merchant before onboarding, screen each one against card network risk lists, and maintain PCI DSS Level 1 certification (the highest compliance tier that exists) because its sub-merchant volume alone typically qualifies it for that tier by default. None of that changes because the sub-merchant is a five-person startup that has never thought about a cardholder data environment in its life.
The scope problem this creates is structural, not incidental. Every sub-merchant onboarded is a new potential extension of the PayFac’s own CDE, and every sub-merchant offboarded, integrated differently, or changed at the technical level is a potential change to that scope. A PayFac processing for tens of thousands of sub-merchants is not managing one CDE boundary. It is managing a boundary that moves every time a sub-merchant relationship changes, and most of those changes originate outside the PayFac’s own infrastructure entirely.
Why 2026 Removes the Room to Manage This Loosely
The pressure on this scoping problem is not abstract, and it is not new to this year alone, but 2026 is the year it stops being optional to solve. PCI DSS v4.0.1’s transition period has ended, and every assessment conducted this year is measured against the complete standard, with no future-dated exceptions left to fall back on. For a payment facilitator, that means the full weight of the standard’s requirements now applies not just to the PayFac’s own infrastructure, but to how it can demonstrate oversight of every sub-merchant sitting inside its scope.
The compliance industry has been direct about what this means in practice. One PCI Qualified Security Assessor firm advised payment facilitators to hold discussions with sub-merchants well ahead of the newer requirements taking full effect, specifically because a PayFac cannot demonstrate compliance for payment pages and integrations it does not have visibility into. A payment facilitator can have flawless security on its own core systems and still fail an assessment because it cannot produce an accurate account of what its sub-merchants are running, and how those systems connect back to the PayFac’s own environment.
See how Virima delivers trusted runtime truth for payment infrastructure compliance
Where Relationship Tracking Becomes the Actual Asset Management Problem
This is the point where the compliance challenge stops being about individual systems and becomes about the relationships between them. A configuration management database (CMDB) that only lists configuration items (CIs), a server here, a gateway there, is answering the wrong question for a PayFac. The question that matters is which sub-merchant integrations connect to which parts of the platform’s own infrastructure, when those connections were established, and whether anything about them has changed since the last time someone checked.
Sub-merchant onboarding and offboarding at PayFac scale happens continuously, not in scheduled batches. New businesses connect through APIs on their own timeline. Existing sub-merchants change their own systems, integrate new services, or shut down entirely, and none of those changes are visible to the PayFac unless something is actively tracking the relationship rather than waiting to be told about it. A sub-merchant’s own infrastructure decision (swapping a shopping cart platform, adding a new payment page, changing how it hosts checkout) can quietly extend or alter the PayFac’s own PCI DSS scope without the PayFac’s security team ever making a decision about it.
This is precisely the gap a relationship-aware CMDB is built to close. Tracking CIs alone tells a PayFac what exists in its own environment. Tracking the relationships between CIs (this integration point connects to this sub-merchant, this API credential was issued on this date, this connection was last verified on this date) is what allows a PayFac to answer the question a QSA will actually ask: not “what do you have,” but “what is connected to what, and how do you know.”
How Virima Supports San Francisco’s Payment Infrastructure Companies
Virima’s approach to this problem starts from the same premise as the rest of the discovery-first CMDB: an asset record is only useful if it reflects what exists today, not what existed at the last assessment. For a payment facilitator, that discovery has to extend past the PayFac’s own servers and into the relationships that define its actual scope.
Service mapping is the layer that does this work directly, connecting individual configuration items to the business services and, in a PayFac’s case, the sub-merchant relationships that depend on them. Rather than a flat inventory, this produces a live map of which integrations touch which parts of the CDE, so a change on a sub-merchant’s side shows up as a scope question on the PayFac’s side, rather than surfacing for the first time during an audit. IT asset management (ITAM) maintains the underlying record of what exists, and IT service management (ITSM) integration ensures that onboarding a new sub-merchant, or modifying an existing integration, generates a ticketed, auditable record rather than an undocumented change.
For a company whose entire business model depends on onboarding sub-merchants faster than a traditional acquirer ever could, this is not a constraint on speed. It is what allows that speed to continue without the scope of the CDE becoming a question nobody can answer.
Book a demo to see how Virima maps sub-merchant scope for PCI DSS readiness
