Virtual Card Security: PCI DSS and Controls Explained
Virtual card security rests on a simple substitution. The number you give a merchant isn't your real account number, and it's usually capped by amount, scoped to a merchant, dated to expire, and tokenized by the card network before it ever reaches a payment terminal.
That substitution changes what a breach is worth. When a merchant's systems are compromised and the attacker walks off with stored card data, what they have is a credential that may already be dead, may only work at one merchant, and may have a ceiling of a few hundred dollars.
Most published writing about virtual card safety is aimed at consumers worried about entering a card number on an unfamiliar website. The question a controller is asking is different. You want to know what the security model is, where its edges are, and how much of it you can verify before you standardize a payment method across your vendor base.
Key Takeaways
A virtual card number is a substitute credential issued against your account, not the account number itself, so exposing it exposes far less than exposing a real card or bank account.
Network tokenization adds a second substitution beneath the number, replacing it with a merchant- and device-specific token that has no value elsewhere.
The controls that matter most are set at issuance, not after: an amount cap, a merchant or category scope, an expiry date, and in the strongest case a single-use setting.
PCI DSS v4.0.1 is the current standard, and the practical question for a buyer is which entity holds the attestation and what scope it covers.
Virtual cards reduce exposure that checks and ACH structurally can't, because paying by card never requires you to hand a vendor your bank account and routing numbers.
No control eliminates fraud. Virtual cards shrink the value of a successful attack rather than preventing every attempt.
Are virtual cards safe?
Yes, and generally safer than the alternatives a finance team is already using, because a virtual card is designed to be disposable in a way a bank account or a physical card is not. The security comes from four properties working together: substitution of the number, a spending ceiling, a scope that limits where the number works, and an expiry that closes the window.
None of those properties exist on a check, and only weak versions exist on a shared corporate card. That's the honest comparison. A virtual card isn't safe in some absolute sense, and anyone selling it that way is overselling. It's safe in the specific sense that a compromised credential has a small blast radius.
Cards carry an enormous share of what businesses and consumers spend, which is part of why they attract so much attack effort. U.S. noncash payments reached 236.6 billion transactions worth $140.01 trillion in 2024, with cards making up roughly four-fifths of noncash transactions by number, according to the Federal Reserve's 2025 Federal Reserve Payments Study. Volume that large will always draw fraud. The design question is how much a single stolen credential is worth once it's stolen.
How is a virtual card number different from your real account number?
A virtual card number is a separate 16-digit credential mapped back to your underlying account inside the issuer's systems, so the merchant never receives the account number itself. Think of it as an alias with rules attached. The issuer knows which account it belongs to; the merchant only knows the alias.
That mapping is what allows a card to be killed without disrupting anything else. Cancel a compromised virtual number and the underlying account, the other cards issued against it, and every recurring payment on those cards keep running. Cancel a physical corporate card and you've just broken every subscription, travel booking, and vendor autopay attached to it, which is why so many teams delay doing it.
The same logic underpins the older workarounds finance teams built before virtual cards existed. A lodged account number assigned to one travel agency, for example, is a primitive version of the same idea, and what a ghost card is explains where that model still earns its place and where it falls short.
What can someone do with a stolen virtual card number?
Usually much less than they expect, and often nothing at all. What a thief holds depends entirely on how the card was configured:
A single-use number that has already been charged is dead on arrival.
One scoped to a single merchant fails everywhere else.
A card with a $4,000 ceiling stops at $4,000 even in the worst case.
A number past its expiry date is a string of digits with no account behind it.
The exposure that remains is a number that's still live, still funded, and scoped loosely enough to be useful. That's a real risk, and it's the one your issuance discipline controls. Cards created with generous limits and no merchant scoping because someone was in a hurry are the ones that show up in fraud reports.
Card fraud at scale is not a hypothetical problem. Global card fraud losses reached $33.41 billion in 2024, with the U.S. accounting for 41.87% of worldwide losses on just 26.31% of card volume, per the Nilson Report's January 2026 study of card fraud losses worldwide. The U.S. share is disproportionate largely because of how much card-not-present volume runs here, which is exactly the transaction type virtual cards are built for.
How does PCI DSS apply to virtual card payments?
PCI DSS applies to virtual cards the same way it applies to any card payment, because the standard governs how cardholder data is stored, processed, and transmitted regardless of whether a piece of plastic exists. Your issuer, your payment platform, and any merchant that stores your card credentials all sit somewhere in scope.
The current version is PCI DSS v4.0.1, which has been the only supported version of the standard since January 1, 2025, with 51 of its 64 new requirements becoming mandatory on March 31, 2025, according to the PCI Security Standards Council. The 2025 deadlines pushed a set of previously optional practices into required territory, including tighter authentication and more explicit inventory of scripts and cardholder data flows.
Here's the practitioner version of the question. Compliance claims in this market are frequently stated at the wrong scope, and a vendor saying "we're PCI compliant" is telling you almost nothing until you know which legal entity holds the attestation and what that attestation covers. Ask for the Attestation of Compliance, check the entity name and the assessment date, and confirm the scope matches the service you're actually buying. Comdata, a Corpay company, is a PCI DSS Level 1 service provider, which is the kind of specific, entity-scoped statement you should expect to be able to verify from any provider.
What does PCI DSS require of a card program?
At a high level, it requires that anyone touching cardholder data protect it in transit and at rest, restrict who can reach it, monitor access, and test the controls on a schedule. The standard organizes this into a set of requirement groups covering network security, data protection, vulnerability management, access control, monitoring, and a written security policy.
For a finance buyer, three of those matter most in vendor conversations:
Scope. Which systems and which entity are covered, and whether your specific service sits inside that boundary.
Assessment level. Service providers handling large transaction volumes face the most rigorous validation, including an annual on-site assessment by a qualified assessor rather than a self-questionnaire.
Currency. An Attestation of Compliance is a point-in-time document. A three-year-old attestation tells you about a system that no longer exists.
Your own PCI scope shrinks when you stop handling card data yourself. A program where the platform generates and stores the numbers, and your team never keys a PAN into a spreadsheet, keeps far more of your environment out of scope than one where AP clerks email card details to vendors. Getting there is partly a process question and partly a matter of how virtual card payments work for B2B transactions in the first place.
Best practices for a virtual card program
Learn the internal strategies that make a virtual card program succeed — from program design to driving the vendor acceptance that determines how much of your AP spend earns rebates.
Download the guide
How does tokenization reduce what's exposed?
Tokenization replaces the card number with a surrogate value that's useless outside the specific context it was issued for, so a merchant breach yields tokens rather than usable credentials. The token is bound to a merchant, a device, or both, and the mapping back to the real number lives only inside the network's vault.
The scale here is worth knowing. Visa reported issuing its 10 billionth payment token in June 2024, with 29% of its transactions using tokens as of April that year, and estimates that tokenization can reduce fraud by up to 60%. That reduction isn't a marketing figure applied to a hypothetical. It reflects what happens when stolen data stops being spendable.
Tokenization also quietly improves the data quality of your card program, since token-based transactions carry richer merchant identifiers back into reporting. That intersects with the enhanced data fields covered in Level 2 and Level 3 card data, which matter both for reconciliation and for interchange treatment.
What built-in controls limit virtual card fraud?
The controls that limit fraud are the ones applied at card creation, because that's the only point where you can decide what the credential is allowed to do before anyone can misuse it. Everything applied afterward is detection, and detection means the money has already moved.
Fraud attempts are close to universal, so this isn't a defense you can skip on the theory that you're too small to target. AFP's 2025 Payments Fraud and Control Survey Report found that 79% of organizations faced attempted or actual payments fraud in 2024, with 63% naming business email compromise as the leading avenue.
How do single-use numbers and spend limits help?
A single-use number expires after one authorization, so the window during which a stolen credential is worth anything is measured in hours rather than years. A spend limit does the complementary job by capping what any successful misuse can extract.
Together they turn an open-ended liability into a bounded one. A reusable number stored in a vendor's billing system is exposed to every breach that vendor suffers for as long as the number stays active, which could be years. A number that dies at settlement is exposed only to a breach that happens in the narrow gap before it does.
Exact-amount matching is the underrated part of this. When the card is issued for $12,340 and the merchant tries to run $13,400, the transaction declines. That catches transposition errors and quiet overbilling as reliably as it catches fraud, and it's a large part of why single-use virtual cards show up in duplicate-payment discussions as often as in fraud discussions.
How do merchant and expiry controls narrow the attack surface?
They shrink the set of places and the span of time where a credential works, which is the two-dimensional version of the same idea. Merchant category restrictions let a card authorize at hotels and airlines and decline at everything else. Named-merchant locking narrows that to one vendor.
Expiry dates handle the time dimension. A card issued for a project that ends in September should stop working in September, and the discipline of setting real end dates is one of the easiest wins in a card program. Most teams over-provision here and set expiries a year out because it saves a conversation, which quietly rebuilds the standing-liability problem they bought virtual cards to solve.
Merchant category codes are imprecise, and it's worth saying so plainly. Codes are assigned by acquirers and don't always describe what a business sells, so legitimate purchases will get declined and someone has to be able to widen a card's scope quickly. Building that response path into your process is as much a part of the control as the restriction itself, and card controls and spend policies covers how the policy layer and the platform layer fit together.
How do virtual cards compare to ACH and checks on fraud risk?
Virtual cards carry structurally less exposure than either, because paying by card never requires you to disclose a durable financial identifier. ACH requires giving a vendor your account and routing numbers, which are permanent and cannot be scoped or expired. Checks require mailing a document that displays those same numbers, plus a signature, to an address you don't control.
That's the asymmetry that gets lost when people compare fraud rates by method. Card fraud is more visible in the data partly because card networks detect and report it, while a compromised bank account often surfaces weeks later as a reconciliation discrepancy. The FTC's 2025 Consumer Sentinel Network Data Book for 2024 found credit card fraud was still the most prevalent form of identity theft that year, with more than 458,000 reports filed against $12.5 billion in total reported fraud losses, up 25% year over year.
What separates these methods in practice is how much each one forces you to disclose, and what recourse is left afterward:
Check: discloses your account number, routing number, signature, and address on a document you can't track after it leaves.
ACH: discloses account and routing numbers that stay valid indefinitely and can't be scoped or dated.
Shared physical card: one static number, valid for years, usually known to several people.
Virtual card: a substitute number with a ceiling, a merchant scope, an expiry date, and network chargeback rights.
Why are checks still the most-targeted payment method?
Because a check discloses everything an attacker needs and offers almost no built-in verification. The account number, the routing number, the authorized signature, and the payer's address all travel on a single piece of paper through a delivery chain nobody monitors.
Check volume has fallen for decades and check fraud has not fallen with it, which tells you attackers are concentrating on a shrinking target. Business email compromise plays directly into this, since redirecting a payment is easiest when the payment instruction is a document rather than a controlled transaction. The FBI Internet Crime Complaint Center's 2024 Internet Crime Report recorded $2.77 billion in reported business email compromise losses across 21,442 complaints in 2024. Teams working through this problem generally start with the process side, and how to defend your company from payment fraud walks the operational controls that sit alongside the payment instrument.
Where do virtual cards reduce exposure buyers can't control elsewhere?
In the space between your controls and your vendor's, which is where most payment fraud lives. You can harden your own systems, train your AP team, and require callback verification, and none of it protects you from a vendor whose email is compromised or whose billing database is breached.
A virtual card is one of the few instruments that limits damage originating outside your perimeter. If a vendor's systems leak your stored credential, the credential is scoped and possibly dead. If a fraudster impersonates that vendor and requests payment, a card issued against the real vendor's merchant identity won't authorize for an impostor's merchant account.
That containment is why virtual cards keep appearing in AP fraud programs rather than just card programs. The mechanics of how virtual cards and automation mitigate fraud sit alongside the broader pattern of accounts payable fraud schemes, most of which target the weakest instrument in the payment mix rather than the strongest.
How Corpay secures virtual card payments
The situation that drives most of these evaluations is a specific one. A vendor's email gets compromised, banking details get changed, a payment goes out, and the discovery happens at reconciliation three weeks later with no way to recall the funds. Corpay's virtual cards are built to make that outcome smaller and rarer.
Cards can be issued single-use and amount-matched to the exact invoice, scoped to a merchant or category, and dated to expire when the work does. Network tokenization stands between the credential and the merchant's systems. Vendor banking details are validated as part of the managed program rather than trusted from an email, and every card carries its own transaction record back into your accounting system so a discrepancy surfaces at settlement rather than at close. As Mastercard's number one commercial B2B issuer, Corpay runs these programs at a volume that keeps the vendor-acceptance side workable, which is usually the practical constraint rather than the security side.
If you're evaluating providers, the useful ask is not a security overview deck. Request the entity-scoped attestation, ask which controls are configurable per card versus per program, and ask what happens operationally when a legitimate charge gets declined at 5 p.m. on a Friday.
Frequently Asked Questions
Can virtual cards be hacked?
The number can be stolen the same way any card number can, usually through a merchant breach or a compromised device rather than an attack on the card itself. What differs is the payoff. A scoped, limited, or already-spent number gives an attacker little to work with, and tokenized credentials stored by merchants don't function outside that merchant relationship.
Are virtual cards safer than physical cards?
In most respects, yes. A physical card carries a static number that stays valid for years, travels in someone's wallet, and is often shared across a team. A virtual card can be issued per purchase, per vendor, or per project, and canceling one doesn't disrupt anything else running on the account.
What happens if a virtual card number is stolen?
You cancel that single number, and nothing else in your program is affected. Because the credential is mapped to your account rather than being your account, the underlying line, the other active cards, and any recurring payments on them keep working. Fraudulent charges are disputed through the card network's chargeback process.
Who is responsible for PCI DSS compliance in a virtual card program?
Responsibility is shared, and the split depends on where card data lives. Your issuer and payment platform are responsible for the systems they operate, while your organization is responsible for how your people handle card credentials. Ask each provider for an entity-scoped Attestation of Compliance rather than accepting a general claim.
How does tokenization protect a virtual card?
It replaces the card number with a surrogate value tied to a specific merchant or device, so the data a merchant stores has no value if it's stolen. The mapping between token and real number stays inside the card network's systems, which the merchant never touches.
Can you lock or cancel a virtual card if it's compromised?
Yes, and immediately, from the platform that issued it. Most programs also let you tighten a card instead of killing it, by lowering the limit, narrowing the merchant scope, or pulling in the expiry date, which is useful when you suspect a problem but haven't confirmed one.
Are virtual cards secure enough for business payments?
For most B2B spend, they're the strongest widely accepted option available, which is a large part of why adoption keeps climbing. Virtual card transaction value is projected to rise from roughly $3 trillion in 2024 to $11 trillion by 2028, making it the fastest-growing B2B payment method, according to Juniper Research's 2024 Virtual Cards Market Research Report 2025-29. Acceptance, not security, is the usual limiting factor, and that is what programs like the one described in growing a virtual card program are built to solve.
Switch to Corpay
Discover how making the move to Corpay streamlines payments and strengthens your business.
Talk to an ExpertSmarter payments. Stronger growth. Keep business moving.
Corpay powers payments for 800,000+ businesses worldwide. Let’s build what’s next for yours.