Are Virtual Cards in PCI DSS Scope?

Picture a travel agency that starts paying hotels with virtual cards instead of wiring money or handing over a corporate Amex. No plastic changes hands. A sixteen-digit number appears in a booking confirmation email, gets typed into the hotel's terminal once, and then quietly dies. Somewhere in a compliance meeting, someone asks the obvious question: does this thing count as a card for PCI DSS purposes, or doesn't it?

It's a fair question, and the instinct behind it is usually one of two shortcuts. Either "it's not a real card, so it's not really our problem," or the opposite: "it's a card number, so of course it's in scope, end of discussion." Neither shortcut survives contact with how the standard, and the brands that sit behind it, actually treat these credentials.

The honest answer is that it depends, and it depends on more than most people expect. It depends on whether the card can be used once or many times, on whether its verification code is fixed or changes with every use, on which payment brand issued it, and on what else is sitting in the systems that happen to handle it alongside everything else.

This article works through that "it depends" properly, piece by piece: what a virtual card is actually made of, the two distinctions that end up mattering most, what Visa and Mastercard have each said on the record, why the card and the system around it are two separate questions with two separate answers, and what's left over for every other brand that hasn't said anything at all. By the end, the goal isn't to hand you a single rule to memorize. It's to leave you able to look at any virtual card program your organization runs and work out, with evidence rather than assumptions, where it actually stands.

What a virtual card actually is

A virtual card is a payment credential issued without a physical card, delivered electronically, and built from the same basic ingredients as any other card: a PAN, an expiry date, and a static or dynamic verification value. On top of that, many virtual cards carry usage restrictions, limiting how many times they can be used, which merchant can charge them, the amount, the currency, the time window, or the merchant category.

These restrictions genuinely lower fraud risk. But lower risk doesn't automatically translate into lower PCI DSS scope. It only does that if the relevant brand has said so.

Single-use versus multi-use

The first distinction worth making is how many times the number can be authorized.

A single-use virtual card is meant to go dead after one use, but the label alone proves nothing. Before treating a card as single-use, it's worth confirming that the number actually becomes inactive after one authorization, that a second attempt can't succeed, that the deactivation is enforced by a technical control rather than a policy or a UI label, and that this control can't be bypassed, reset, or extended. It's also worth checking how refunds and other exception processing are handled, since these can quietly create a second clearing record, and whether the restriction is applied by the issuer itself or only by the front-end application showing the card. A provider calling something "temporary" or "one-time" in its marketing doesn't make it technically single-use.

A multi-use virtual card can support more than one authorization, and it may still carry restrictions of its own, like being tied to one supplier or only staying active for a limited window. But if the number can authorize more than once, it behaves much more like a conventional card credential, and unless a brand has published a specific position covering it, it should be treated as in scope.

Static versus dynamic CVV2

The second distinction is the type of verification code. A static CVV2 stays the same for as long as the card is active, so anyone who gets hold of the PAN, expiry date, and CVV2 while the card is live could potentially reuse those details, depending on whatever other controls apply. A dynamic CVV2 changes on some cadence defined by the issuer, which means a compromised value can go stale before it's useful. Visa treats dynamic CVV2 as relevant to how it handles certain multi-use virtual accounts, but that doesn't turn dynamic CVV2 into a universal PCI DSS exemption across every brand. It's a characteristic of the credential, not an exemption in itself, and the applicable brand position still has to be checked.

Who actually decides the exception

PCI SSC maintains the standard, but it doesn't set a blanket rule that every single-use card is out and every multi-use card is in. Its own guidance points the other way: whether a one-time PAN is in scope depends on restrictions defined by the relevant payment brand, and entities are told to confirm with that brand or their acquirer.

That means a Visa position covers Visa account data and nothing else. It doesn't extend to Mastercard, American Express, Discover, JCB, or UnionPay. Each brand can, and does, manage its own account data differently.

What Visa says

Visa treats single-use virtual Visa account numbers, and multi-use virtual Visa account numbers that use dynamic CVV2, as sitting outside its PCI DSS protection requirements, based on the low fraud risk of those account types. Everything else stays subject to the normal rules. That includes a multi-use virtual Visa account running a static CVV2, which is treated like any other in-scope PAN unless some other Visa position says otherwise.

Visa is also clear about the limits of its own guidance: it reflects Visa's requirements for Visa account data specifically, it isn't a PCI SSC position, it isn't an assessor's independent judgment, and it can change as fraud trends shift. The takeaway is that Visa's treatment hinges on the precise account type, not on the card simply being virtual.

What Mastercard says

Mastercard allows certain single-use virtual card numbers to receive different treatment, but only when specific conditions are demonstrably met.

The first condition is that the single-use behavior has to be technically enforced: the number must become inactive after one authorization that creates a single clearing record, and that has to happen through a technical control that can't be circumvented. A product name, a UI label, marketing copy, or an assumption that the issuer will simply decline a second attempt isn't evidence. You need proof of the actual mechanism.

The second condition is that the systems handling the single-use number can't also be handling multi-use PANs. This is the one that trips people up, because virtual cards often arrive through systems that also carry regular card data, whether that's a shared inbox, a booking platform, an accounts-payable tool, or a shared database. If the same system touches ordinary in-scope PANs, the presence of a single-use virtual card doesn't pull that system out of scope.

For multi-use Mastercard cards running dynamic CVV2, the fraud risk may well be lower than a conventional static-CVV2 card, but that alone isn't enough to establish a general PCI DSS exception. The defensible default is to treat a multi-use Mastercard virtual PAN as in scope, dynamic CVV2 or not, unless a current Mastercard position specific to that card programme confirms otherwise. The same default applies to multi-use Mastercard cards using a static CVV2.

The picture at a glance

The card and the system are two different questions

It's easy to stop at the credential and forget the environment. A full assessment has to separate credential-level treatment, meaning whether the brand requires this specific virtual card type to be protected, from system-level scope, meaning whether the system handling it also stores, processes, or transmits other account data, connects into an existing cardholder data environment, or otherwise affects the security of account data.

A credential can qualify for special treatment while the system around it stays fully in scope. An out-of-scope credential doesn't create an out-of-scope system.

Take a shared inbox that receives supplier virtual cards. If it receives only a qualifying virtual card type, the brand's position might genuinely narrow the scoping assessment. But if that same inbox also receives regular customer PANs, multi-use virtual cards, cards from a brand with no confirmed exception, or sensitive authentication data, ordinary PCI DSS scoping rules still apply to it. The same pattern shows up in booking systems, CRM tools, call-centre applications, reporting platforms, data warehouses, backups, and monitoring systems. The full inventory of account data flowing through a system matters, not just whichever credential prompted the review.

Segmentation can genuinely narrow scope, but only if it's effective. Putting virtual card data in a separate table, folder, queue, or user group doesn't remove a system from scope by itself. What counts is technical connectivity, administrative access, and whether a compromise elsewhere could reach the protected environment. Where segmentation is being used to justify reduced scope, its design and effectiveness should be part of the formal scoping and validation work.

Out of scope still isn't unprotected

A brand's special treatment of a virtual credential doesn't mean that data has no value or can be handled loosely. Visa, for instance, still recommends protecting virtual account information against fraud and breach loss even where its PCI DSS requirements don't apply. Other obligations tend to survive regardless: payment-brand operating rules, issuer and acquirer requirements, contractual security terms, fraud controls, privacy law, and incident-reporting duties. "Outside PCI DSS protection requirements" is not the same thing as "safe to leave unprotected."

The brands without a published position

No comparable, publicly available exception could be found for American Express, Discover, JCB, or UnionPay. That doesn't prove no private, regional, or acquirer-level guidance exists somewhere, only that nothing should be assumed. The practical default is to treat a virtual PAN from these brands as in scope until the brand or acquirer confirms a different current position, and to keep that confirmation on file alongside the rest of the scoping evidence.

CVV2/CVC2 storage still follows the normal rules

If a virtual card stays in scope, ordinary account data rules apply. Stored PAN needs to be rendered unreadable through one of the accepted methods, and CVV2, being sensitive authentication data, generally can't be stored after authorization, encrypted or not. PCI DSS has specific applicability provisions for issuers and companies supporting issuing services, but those depend on the organization's actual role and shouldn't be treated as a blanket exception for anyone who happens to generate or distribute virtual cards. An organization involved in issuing should be able to document its role, whether any sensitive authentication data is retained, the legitimate basis for that retention, and the controls protecting it.

To learn more about CVV2/CVC2 storage requirements, have a look at our blog about Elements of Account Data and Storage Requirements.

The key lesson

Virtual cards can genuinely reduce fraud risk, but "virtual" isn't itself a PCI DSS scope category. The answer depends on the credential type, the brand behind it, the technical controls actually in place, what else the surrounding systems handle, and whether segmentation is real rather than cosmetic. Start by assuming a virtual PAN is in scope. Then check whether the relevant brand has published specific treatment for it, and whether every condition that treatment requires can actually be proven. Assess the credential and its environment separately: a card can qualify for special treatment while the system handling it stays fully in scope.