PCI DSS and B2B Payment Automation: What Compliance Requires

PCI DSS is the Payment Card Industry Data Security Standard, a set of 12 requirements governing any organization that stores, processes, or transmits cardholder data. It applies regardless of company size or transaction volume, and it applies to B2B card programs exactly as it applies to retail checkout.

That last point catches finance teams off guard. PCI DSS reads like a retail standard, written for merchants swiping cards at a point of sale, and most of the explainers online are aimed at e-commerce operators. Meanwhile the AP department has been running a virtual card program for three years, storing supplier card numbers in a spreadsheet for recurring payments, and emailing card details to a vendor who couldn't accept the payment file.

Whether any of that puts you in scope depends on a narrower question than most people assume. The question is whether card data touches systems you control, rather than whether you use cards at all. Once you understand that distinction, the practical goal shifts from becoming compliant to shrinking what you have to be compliant about.

Key Takeaways

• PCI DSS applies to any entity that stores, processes, or transmits cardholder data, with no minimum size or transaction threshold.

• The standard organizes 12 core requirements under six control objectives, and v4.0.1 is now the only active version.

• Your cardholder data environment is the set of systems that touch card data plus anything connected to them. Everything in it falls under the standard.

• Routing card payments through a provider that holds the data can move most of your program outside your own environment, which is scope reduction rather than a compliance shortcut.

• PCI DSS and SOC 2 answer different questions. One is a mandated card-data standard with prescriptive requirements; the other is an attestation on a service organization's controls.

What does PCI DSS require, and who enforces it?

PCI DSS is a security standard maintained by the PCI Security Standards Council, a body founded by the major card networks, that specifies technical and operational requirements for protecting account data. It's a contractual obligation flowing through your card agreements rather than a law, which surprises people who expect a regulator behind it.

The enforcement path runs through the networks and acquirers instead of a government agency. That distinction matters practically because the consequences of non-compliance arrive as fines passed down through your acquiring bank, increased transaction costs, or in serious cases the loss of card acceptance privileges, along with liability exposure after a breach that a compliance failure makes considerably worse.

The standard itself is prescriptive in a way most security frameworks aren't. Rather than asking whether you have a documented approach to encryption, it specifies what must be encrypted, where, and under which conditions. That specificity is genuinely useful once you're inside scope, and it's precisely why staying outside scope is worth real effort.

What are the six control objectives and 12 requirements?

PCI DSS sets 12 core requirements organized under six control objectives, and it applies to any entity that stores, processes, or transmits cardholder data regardless of size or transaction volume, according to the PCI Security Standards Council. All v4.x requirements became mandatory as of March 31, 2025.

Source: PCI Security Standards Council, PCI DSS v4.0.1 (2024–2025).

Read down the right-hand column and one thing stands out for finance teams. Roughly half of these are things your IT organization already does for other reasons, and the genuinely painful ones are storage, encryption, access restriction, and logging, which are exactly the requirements that disappear if the data never lands in your systems.

Which version applies now?

PCI DSS v4.0.1 is the only active version of the standard. It was published June 11, 2024, and v4.0 retired on December 31, 2024, per the PCI Security Standards Council's "Just Published: PCI DSS v4.0.1" announcement.

The version question comes up more than it should because the v4.x transition ran on a long runway, with a large batch of future-dated requirements that organizations could treat as best practice until the March 2025 deadline. That grace period is over. If a vendor or an internal team is still working from a v3.2.1 checklist, the gap is real and worth surfacing before your next assessment rather than during it.

Does PCI DSS apply to your B2B payments?

It applies if cardholder data touches any system you own, operate, or configure. Volume doesn't exempt you, being B2B doesn't exempt you, and paying suppliers rather than accepting consumer payments doesn't exempt you. The question is entirely about data flow.

Most finance teams discover they're closer to scope than they assumed. The trigger is rarely the payment platform itself. It's the workarounds that grow around it, like the supplier who can't process a virtual card through the portal, so somebody reads the number over the phone and saves it in a shared document for next month.

Worth keeping in proportion, though. Cards are a minority of B2B payment volume by count, and the bulk of it moves over rails that carry no cardholder data at all. The ACH Network alone processed 7.3 billion B2B payments in 2024, up 11.6% year over year, within 33.6 billion total payments worth $86.2 trillion, according to Nacha's 2024 network statistics. Your PCI obligation attaches to the card slice, not the whole program, which is why a payment mix that spans cards alongside EDI and ACH formats in B2B needs its scope drawn per rail rather than per department.

To whom does PCI DSS apply?

PCI DSS applies to any entity that stores, processes, or transmits cardholder data, plus any entity whose systems could affect the security of that data. In a B2B payments program, that ordinarily includes:

• Companies running a virtual card program where card numbers pass through systems they control

• Companies storing supplier or corporate card numbers for recurring payments, in any format including spreadsheets and CRM notes

• Companies operating a payment portal or accepting card payments from their own customers

• Service providers processing card transactions on behalf of others, which is a separate and more demanding category

• Any connected system that isn't segmented from the above, including a shared file server or an unsegmented office network

What generally doesn't put you in scope is receiving a payment as a supplier through your acquirer's terminal, or issuing card payments through a provider where the number is generated, held, and delivered entirely on their infrastructure. In that second arrangement the data genuinely never enters your environment, and scope follows data rather than intent.

Protect cash flow with modern AP

Modernize AP to cut costs, speed approvals, and mitigate payment risk — gaining the real-time visibility to protect cash flow and scale with confidence.

Download the whitepaper

What is the cardholder data environment (CDE) in a payments program?

The cardholder data environment is every person, process, and system that handles cardholder data. It also takes in any component connected to that set or able to affect its security. Defining your CDE accurately is the first real task in any PCI effort, and it's where most assessments go sideways.

Connectivity is the part that expands scope unexpectedly. A single workstation that can reach the system holding card data pulls itself into the CDE, and so does the network segment it sits on, unless segmentation controls prove otherwise. A finance team that thought its CDE was one application often discovers it's one application plus a VLAN plus a jump host plus the laptops of four AP specialists.

In B2B payments specifically, card data hides in five places most inventories miss:

• The AP inbox, where suppliers send remittance questions with card numbers attached

• Recorded customer service calls, which are rarely searched and rarely purged

• The ERP's vendor notes field, where somebody parked a number for convenience

• Backup files and archived email, which inherit whatever was in scope when they were written

• Whatever spreadsheet the team built when the portal couldn't handle a particular supplier

Bringing the same discipline you'd apply to governing data across payment systems is the practical starting point, because a CDE you haven't mapped is a CDE you can't shrink. The security measures that protect a business generally are the same ones an assessor will test here, just applied to a narrower target.

How does payment automation affect your PCI DSS scope?

Payment automation can substantially reduce your scope by moving card data out of systems you control and into a provider's environment. It can also expand your scope, if the implementation leaves numbers sitting in your ERP or your team building manual workarounds around an incomplete supplier enrollment.

The direction depends almost entirely on how supplier payments actually get delivered rather than on what the platform brochure claims. That's the question to ask during evaluation, and it's a more useful question than asking whether the vendor is compliant. Any serious look at electronic payments for business should include a data-flow diagram, because that diagram is what your assessor will eventually ask for.

How can a compliant platform reduce your scope?

A compliant platform reduces scope by holding the card data itself, so your systems handle references rather than numbers. Four mechanisms do most of the work:

1. Tokenization. Your ERP and AP system store a token that maps to a card number held on the provider's side. The token is useless if exfiltrated, and systems holding only tokens generally fall outside the CDE.

2. Provider-hosted issuance and delivery. Virtual card numbers are generated on the provider's infrastructure and delivered directly to the supplier, so your team never sees or handles a full number. Understanding how virtual card payments work in B2B makes this mechanism much easier to evaluate.

3. Hosted payment pages and redirects. When you accept card payments from customers, an iframe or redirect to the provider's page keeps your web servers out of the transaction path.

4. Supplier enrollment done properly. This is the unglamorous one and the one that determines whether the other three hold. Every supplier who can't accept the automated payment method becomes a manual exception, and manual exceptions are where card numbers end up in email.

That fourth point deserves emphasis because it's where I've seen scope reduction quietly fail. A program that automates most supplier payments and handles the stragglers by phone hasn't reduced its CDE at all. It's added a platform on top of the same manual process, and the assessor will find the spreadsheet. Getting suppliers onto a method they'll actually accept virtual card payments through is a compliance activity, not just an adoption metric.

Scope reduction is not the same as compliance transfer. You remain responsible for your own environment, your contracts, and validating that the provider's scope covers what you think it covers. What changes is how much of your estate has to meet 12 prescriptive requirements. On the issuing side, the security controls built into a virtual card program determine how much of that estate stays outside the CDE to begin with.

How does this connect to fraud and breach exposure?

It connects because card data concentrated in your environment is both a compliance obligation and a target, and removing it addresses both at once. The loss figures give the exposure some shape. Global card fraud losses totaled $33.41 billion in 2024 on $51.920 trillion in card volume, according to the Nilson Report. The United States accounted for 41.87% of worldwide card fraud losses that year while representing 26.31% of global card volume.

That gap between 41.87% and 26.31% is the interesting number, and it's a reasonable proxy for how much fraud concentrates where card acceptance is broadest and authentication requirements have historically been lightest. Take it as directional. Fraud-loss allocation methodologies vary and the underlying reporting isn't uniform across markets.

Breach cost lands on top of fraud loss rather than instead of it. The global average cost of a data breach reached a record $4.88 million in 2024, up 10% year over year, per IBM's Cost of a Data Breach Report 2024, and third-party exposure is a growing share of the problem. 15% of breaches involved a third party in Verizon's latest Data Breach Investigations Report, a 68% year-over-year increase.

Payment fraud arrives through a separate door and hits AP hardest. 79% of organizations were victims of attempted or actual payments fraud in 2024, according to the Association for Financial Professionals' 2025 Payments Fraud and Control Survey Report. PCI DSS won't stop business email compromise, which is worth saying plainly, since a supplier impersonation attack redirecting an ACH payment involves no card data at all. Card-data controls and the practices that defend a company against payment fraud more broadly are complementary programs, not one program.

How does PCI DSS relate to SOC 2 and your audit trail?

They answer different questions and neither substitutes for the other. PCI DSS is a prescriptive, mandatory standard for a specific data type. SOC 2 is a flexible attestation on a service organization's controls against criteria it partly selects. A vendor can hold one, both, or neither, and knowing which tells you different things. How to verify an AP automation vendor's SOC 2 report covers the attestation half of that question in detail.

Your own audit trail sits underneath both. Requirement 10 of PCI DSS is about logging and monitoring access to cardholder data, and any SOC 2 examination will test whether privileged actions generate reviewable records. Both frameworks assume you can reconstruct who did what and when, which is the same capability your auditors and your fraud controls depend on.

PCI DSS vs SOC 2: what's the difference for a payments buyer?

The difference is mandate versus attestation, and prescription versus judgment. Here's how the two compare on the dimensions that matter during vendor evaluation:

Source: PCI Security Standards Council and AICPA framework documentation.

Ask for both where both apply, and read the scope on each. A provider's Attestation of Compliance names which services were assessed, and it's common for that list to be narrower than the provider's full catalog. The same scoping discipline that governs reducing compliance and regulatory friction applies here, and it's a habit worth building before your assessor builds it for you.

Run compliant B2B payments with Corpay

The failure mode this article keeps returning to is the manual exception, the supplier who couldn't take the automated payment, and the card number that ended up somewhere it shouldn't. That's the specific problem our model is built around.

Corpay Payments Automation delivers supplier payments by virtual card, ACH, and check. Our managed service enrolls suppliers and handles the follow-up rather than leaving your team to chase the holdouts. Enrollment coverage is a security control in this context, because every supplier we get onto an automated method is one fewer place a card number gets read aloud. Card credentials are generated and delivered on our side, so your ERP works with references rather than raw account data.

On the card side, Corpay Commercial Cards supports virtual card programs with single-use numbers, amount and merchant controls, and per-transaction data that flows back for reconciliation. Two compliance facts, scoped precisely as they should be. Corpay is SOC 2 Type II compliant. Comdata, a Corpay company, is a PCI DSS Level 1 service provider, which is the highest service-provider tier the card networks define.

For your own assessment, the practical ask is straightforward. Request our current attestation documentation during evaluation, confirm which services it covers, and have your assessor validate that the resulting data flows land where you think they do. That's the same standard we'd expect you to hold any provider to.

Frequently Asked Questions

What is PCI DSS?

PCI DSS is the Payment Card Industry Data Security Standard, maintained by the PCI Security Standards Council, which specifies 12 requirements for protecting cardholder data. It's enforced contractually through card networks and acquiring banks rather than by a government regulator, and it covers any organization handling card data.

What is PCI DSS compliance?

PCI DSS compliance means your organization meets the standard's requirements for every system that stores, processes, or transmits cardholder data, and has validated that through a self-assessment questionnaire or a formal assessment depending on your transaction volume and role. Validation is periodic; compliance is expected continuously.

To whom does PCI DSS apply?

PCI DSS applies to any entity that stores, processes, or transmits cardholder data, along with any connected system that could affect that data's security. There's no minimum transaction volume or company size exemption, and it applies to B2B card programs the same way it applies to retail merchants.

What is the CDE in PCI DSS?

The CDE, or cardholder data environment, is the set of people, processes, and technology that handle cardholder data, plus every system component connected to them or capable of affecting their security. Accurately defining the CDE is the first step in any assessment, since everything inside it must meet the standard.

How do you become PCI DSS compliant?

Start by mapping where cardholder data actually lives, then eliminate every instance you don't genuinely need. Determine your merchant or service-provider level, complete the matching self-assessment questionnaire or engage a qualified security assessor, remediate the gaps found, and validate annually. Reducing scope first makes every subsequent step cheaper.

David Luther

Product Marketing Program Manager

David Luther, MBA is a product marketing program manager with years of experience in commercial banking, finance, and technology sectors, with research and writing appearing in financial publications.

Payments Automation

Risk management