Virtual Card Payment Controls

Introduction: The Payment Method Marketed as a Control

Virtual cards occupy an unusual position in the payment risk landscape. Every other payment method covered in this series — ACH, checks, wire transfers and real-time payments — is evaluated by finance and risk professionals primarily in terms of the fraud exposure it carries. Virtual cards are frequently evaluated in the opposite terms: as a control mechanism, a fraud reduction tool, a way to impose transactional discipline on disbursements that other payment methods cannot achieve.

That positioning is not wrong. Virtual cards do carry structural features that meaningfully constrain certain categories of fraud. The single-use card number, the merchant-specific authorization, the amount restriction, the automatic expiration — these are genuine controls embedded in the payment instrument itself, not layered on top of it. No other common payment method offers equivalent transaction-level specificity at the point of authorization.

But the positioning is incomplete in ways that matter. Virtual cards are not a fraud-free payment method. They carry their own distinct risk profile — including risks that arise precisely because of the organizational infrastructure required to issue and manage them at scale. They are accepted by a smaller universe of vendors than ACH or checks. They generate reconciliation complexity that creates its own error and control gaps. And they sit at the center of a vendor enrollment and incentive structure that, if not carefully managed, can itself become a control vulnerability.

A clear-eyed assessment of virtual cards requires understanding both what their structural controls prevent and what they do not — and what risks the virtual card environment introduces that a simpler payment method would not.

How Virtual Cards Work

A virtual card is a payment card — operating on the Visa, Mastercard, or American Express network — that exists only as a set of card credentials: a 16-digit card number, an expiration date, and a card verification value (CVV). There is no physical card. The credentials are generated electronically, typically through a card management platform operated by a bank or fintech provider and are transmitted to the vendor for use in a card-not-present transaction.

The defining feature of a virtual card, from a control standpoint, is the degree to which its parameters can be specified at the time of issuance. A virtual card issued for a specific vendor payment can be configured with:

A single-use restriction, meaning the card number can be charged exactly once and is automatically invalidated after that transaction. A merchant restriction, locking the card to a specific merchant category code (MCC) or, in more sophisticated implementations, a specific merchant identifier. An amount restriction, setting a maximum authorized charge — typically matched to the invoice amount — above which the transaction will be declined. An expiration window, defining a date range within which the card is valid and after which it cannot be used.

These parameters are set by the issuing organization at the time the card is generated, typically through an integration between the organization's AP system and the card management platform. The vendor receives the card credentials — usually by email or through a payment portal — and processes the payment as a standard card-not-present transaction. Settlement occurs through the card network in the normal course, and the issuing organization receives a transaction record that can be matched against the original payment instruction.

The organizational financial benefit beyond fraud control is interchange revenue. When a vendor accepts a virtual card payment, the card network charges the vendor an interchange fee — typically in the range of 1.5% to 2.5% of the transaction amount for commercial card transactions — a portion of which is rebated to the issuing organization. For large AP programs that have successfully migrated significant vendor payment volume to virtual cards, these rebates can generate meaningful revenue, which is one of the primary commercial drivers of virtual card program adoption.

The Genuine Control Advantages

Before addressing the risk profile, it is worth being precise about what virtual cards' structural controls accomplish — because the controls are real and their value is not overstated when accurately described.

Single-use card numbers eliminate post-transaction card data exposure. With a traditional purchasing card or corporate card, the card number remains valid after each transaction and can be used for subsequent unauthorized charges if compromised. A single-use virtual card number that has been charged once is worthless to anyone who subsequently obtains it. Data breaches at vendor systems — a persistent source of card fraud losses — produce no usable credentials from virtual card transactions.

Amount restrictions prevent overbilling. A virtual card issued for a specific invoice amount cannot be charged for more than that amount. The vendor cannot, intentionally or accidentally, charge the card for an amount exceeding the authorized limit. This control is not available with ACH or check payments, where the disbursed amount is defined at the point of issuance but cannot be enforced at the point of receipt.

Merchant restrictions limit misdirection. A card locked to a specific merchant category or merchant identifier cannot be used at an unauthorized merchant, even if the card credentials are obtained by a third party. This restricts the utility of compromised virtual card credentials to the specific payment context for which they were issued.

Transaction-level audit trail. Every virtual card transaction generates a detailed record — merchant name, amount, date, authorization code — that provides granular visibility into disbursement activity. This visibility is more detailed than most ACH or check payment records and supports more precise reconciliation and exception identification.

These are substantive advantages. For organizations managing high-volume, recurring vendor payments — particularly in categories like facilities services, temporary staffing or professional services — virtual card controls provide a level of transactional governance that alternative payment methods cannot replicate.

The Risk Profile: Where Virtual Cards Fall Short

The risks associated with virtual card programs are real, distinct from those of other payment methods, and insufficiently understood by organizations that have adopted virtual cards primarily based on the control narrative.

Card-Not-Present Fraud

Virtual card transactions are, by definition, card-not-present transactions — the card is never physically presented to a merchant terminal. Card-not-present fraud is the dominant and growing form of payment card fraud, accounting for the substantial majority of card fraud losses in business payment contexts.

The risk is concentrated at two points. First, if the card credentials — the 16-digit number, expiration date, and CVV — are intercepted in transit between the issuing organization and the intended vendor, they can be used by whoever intercepts them to process an unauthorized transaction before the legitimate vendor does, or before the card expires. Second, if the card credentials are delivered to a fraudulent party — because the vendor contact information in the AP system has been compromised or because a BEC attack has redirected the card delivery to an attacker-controlled email address — the fraudulent party can use the credentials for an unauthorized charge.

The single-use restriction limits the damage from intercepted credentials — a compromised single-use card number can only be charged once, and if the legitimate vendor charges it first, the fraudulent use is blocked. But single-use restrictions are not universally enforced across all virtual card programs, and a compromised card with a multi-use configuration or a longer validity window presents a more significant exposure.

The Card Delivery Problem

Virtual card credentials are almost always delivered electronically — typically by email to a vendor contact address stored in the AP system. This delivery mechanism creates a vulnerability at the intersection of the vendor master and the card program: if the vendor contact email address in the AP system is fraudulent or has been compromised, the card credentials are delivered to a fraud actor rather than the legitimate vendor.

This is a variant of the vendor master compromise attack that affects ACH payments, transposed to the virtual card context. The attacker does not need to change a bank account number — they need only to ensure that the card delivery email reaches them rather than the legitimate vendor. An attacker who has compromised a vendor's email account, or who has successfully social-engineered a change to the vendor's contact email address in the AP system, can receive virtual card credentials intended for the legitimate vendor and use them before the vendor is aware of the payment.

The controls required to prevent this attack — verification of vendor contact information, out-of-band confirmation of email address changes, secure card delivery through authenticated portals rather than unencrypted email — are the same vendor master integrity controls discussed throughout this series. Organizations that have adopted virtual cards without correspondingly robust vendor master controls have shifted the fraud vector without eliminating it.

Program-Level Account Takeover

Beyond individual card transaction fraud, virtual card programs face the risk of compromise at the program management level. The card management platform — through which virtual cards are generated, configured and issued — is accessed through user credentials. An attacker who obtains those credentials, whether through phishing, credential theft or insider access, can generate and issue virtual cards to accounts they control without going through the normal AP authorization workflow.

Program-level account takeover is a high-consequence attack because it bypasses the transaction-level controls entirely. An attacker with access to the card management platform can issue cards with any parameters they choose — large amounts, extended validity windows, multiple uses — and direct them to merchant accounts they control. The fraud may not be visible in the AP system at all, because the card issuance occurred at the platform level rather than through the AP workflow.

This risk is structurally similar to ACH origination platform credential theft — in both cases, the attacker targets the issuance infrastructure rather than the payment instruction. The controls required are correspondingly similar: strong authentication for platform access, activity monitoring and anomaly detection, and access controls that limit card issuance authority to authorized personnel.

Vendor Acceptance Limitations and Workaround Risks

Virtual card acceptance is not universal. A significant portion of the vendor population — particularly smaller vendors, international vendors and vendors in certain industry sectors — either cannot or will not accept virtual card payments. The reasons vary: card processing infrastructure costs, the interchange fees vendors bear on card acceptance, contractual restrictions or simply the operational friction of processing card-not-present payments in high volume.

When vendor acceptance is the goal of a virtual card program, organizations frequently engage third-party payment intermediaries — firms that accept virtual card payments on behalf of vendors who cannot or will not process cards directly, convert the card payment to an ACH credit or check, and remit to the vendor. These intermediaries enable broader virtual card adoption but introduce a new party into the payment chain — one whose financial stability, security controls and operational practices are outside the issuing organization's direct control.

The intermediary model deserves scrutiny that it does not always receive. An intermediary that processes virtual card payments and converts them to ACH credits must maintain accurate vendor banking records, secure card acceptance infrastructure and reliable remittance processes. Failures at any of these points — whether through operational error, security breach or insolvency — produce disbursement failures and potential losses that the issuing organization may not immediately detect.

Reconciliation Complexity as a Control Gap

Virtual card programs generate detailed transaction data — but that data must be reconciled against AP records, matched to purchase orders and invoices, and integrated into the organization's financial reporting. At scale, this reconciliation is operationally complex, and the complexity creates gaps.

Unmatched virtual card transactions — charges that appear in card program data but have no corresponding AP record, or AP records for which no corresponding card charge appears — are the exception items that require investigation. In programs with high transaction volume, exception management can become a resource-intensive process that is managed reactively rather than proactively. Charges that should have been flagged as unauthorized may persist undetected in exception queues that are not reviewed with adequate frequency or rigor.

This is not unique to virtual cards — any high-volume payment program generates reconciliation complexity. But the specific structure of virtual card data, which differs in format from ACH and check records and requires integration across the card management platform and the AP system, means that reconciliation failures are a more common operational reality than finance teams accustomed to simpler payment methods anticipate.

The Rebate Incentive and Its Distorting Effect

The interchange rebate that virtual card programs generate for issuing organizations is a genuine financial benefit — but it can also distort program management decisions in ways that compromise the control framework.

When virtual card adoption is partly driven by rebate revenue objectives, there is an institutional incentive to maximize card payment volume — to push vendors toward card acceptance, to use card payment as a default rather than a deliberate choice, and to minimize friction in the card issuance process to sustain throughput. This incentive, if it overrides control considerations, can produce a program that issues cards more quickly, with less verification, and with fewer constraints than the risk profile warrants.

The rebate incentive is also visible to vendors — and to third parties representing vendor interests in payment negotiations. In some documented cases, payment intermediaries and consultants operating in the virtual card ecosystem have structured arrangements that generate rebates and fees in ways that may not be fully transparent to the issuing organization's finance and procurement leadership. Organizations evaluating or managing virtual card programs should ensure that rebate structures and intermediary arrangements are reviewed with the same scrutiny applied to any significant financial relationship.

The Fraud Cases: Where Virtual Card Controls Have Failed

Virtual card fraud does not generate the same volume of publicly documented individual cases as wire fraud or check fraud — partly because virtual card losses are often smaller per incident and partly because card fraud losses may be absorbed at the card network or bank level rather than generating the kind of organizational crisis that produces public disclosure.

But documented failures exist. Card management platform compromises at financial institutions have resulted in unauthorized card issuance. BEC attacks targeting virtual card delivery email addresses have diverted card credentials to fraud actors. Payment intermediaries in the virtual card ecosystem have failed operationally, leaving organizations with unremitted payments and vendor relationship damage.

The pattern across documented virtual card fraud incidents is consistent with the risk profile described above: the structural controls embedded in individual card parameters are generally effective at what they are designed to do. The failures occur at the edges of those controls — in the delivery mechanism, in the platform access controls, in the vendor contact data, and in the intermediary relationships that extend the program beyond its core infrastructure.

Conclusion: Controlled, Not Immune

Virtual cards are the payment method that most closely approximates a built-in control framework. The parameters that govern each card — amount, merchant, validity window, use count — impose a transactional discipline that no other common payment method can match at the individual transaction level. For organizations that have implemented virtual card programs with rigorous vendor master controls, strong platform access management and disciplined reconciliation, the fraud exposure is meaningfully lower than equivalent ACH or check payment programs would present.

But virtual cards are not immune to fraud. They shift the attack surface rather than eliminating it — from the payment instruction to the card delivery mechanism, from the payment authorization to the platform access layer, from the individual transaction to the intermediary relationship. An organization that adopts virtual cards as a fraud solution without understanding where the residual risk lies has not eliminated exposure; it has relocated it to points it may be less prepared to defend.

The CFO or Controller evaluating virtual card risk should ask not only what the card's structural controls prevent — the answer to that question is well documented and largely favorable — but where the program's actual vulnerabilities lie given the organization's specific vendor population, card management infrastructure, and operational practices. The answer will vary by program. The question should always be asked.