Virtual Cards in B2B Payments: How Single-Use Numbers Fix Corporate Spend

A virtual card is a tokenized card number with programmable controls attached, issued instantly by API, and it rides the same card rails as the plastic in an executive's wallet. It is not a new payment network, which is the first thing most finance leaders get wrong about it. What is new is the control surface: a number that can be locked to one supplier, one invoice amount, one merchant category, and one date range, then disabled forever once used. That combination solves three problems accounts payable has lived with for decades. Fraud is contained by construction rather than by detection, because a compromised number is worth nothing outside its locks. Reconciliation becomes deterministic, because a unique number per invoice removes the matching guesswork. And the interchange that funds card networks flows partly back to the buyer as rebate, which turns a payables function from a cost center into a modest revenue line. The catch, and it is a real one, is that interchange lands on the supplier, which makes acceptance the constraint that determines whether any virtual card program works. This guide covers the mechanics, the economics on both sides, the rail comparison, and where virtual cards genuinely lose to ACH.

Key Takeaways

• A virtual card is not a separate rail. It is a tokenized number on the existing card networks, with programmable spend controls and API issuance layered on top. Everything that makes it useful in B2B is a control-and-data property, not a settlement property.
• The buyer economics rest on interchange rebate. Commercial card interchange is materially higher than consumer debit, and issuers share part of it back with the buyer, which is why a large payables program can turn a cost into a rebate line while extending days payable outstanding through the card billing cycle.
• The same interchange is the supplier's objection, because acceptance cost lands entirely on the receiving side. A supplier accepting a card on a large invoice absorbs a percentage that dwarfs the flat cost of receiving ACH, which is why supplier enablement, not technology, is the binding constraint on program growth.
• The reconciliation benefit is the most underrated one. A unique card number per invoice makes matching deterministic rather than probabilistic, eliminating the remittance-matching work that consumes accounts receivable and payable teams on every other rail.
• Virtual cards win on mid-size, high-volume, supplier-diverse spend where control and reconciliation are worth a few percent. They lose decisively on large-ticket payments, thin-margin suppliers, and recurring high-value vendor relationships where ACH costs cents.

What a Virtual Card Actually Is

A virtual card is a card number generated on demand, tied to an underlying account, and constrained by rules set at the moment of issuance. The number, expiry, and security code are real credentials on a real network, so any merchant that accepts commercial cards can process one with no integration, no onboarding, and no awareness that the number was created seconds earlier for this transaction alone. That backwards compatibility is the entire reason the model scaled.

Two properties distinguish it from plastic. The first is programmability: the controls travel with the number and are enforced at authorization, so a card locked to five thousand for a single merchant category will decline anything else without any human intervening. The second is disposability: issuance is cheap enough that a number can be created per invoice, per supplier, per booking, and then retired, which is what turns the card number into an identifier rather than a credential to be protected.

The economics underneath are ordinary card economics, examined in interchange fees explained: the supplier's acquirer pays interchange to the buyer's issuing bank, the network takes a smaller assessment, and the issuer shares part of its interchange revenue back with the corporate buyer as rebate. Nothing about that structure changes. Virtual cards simply apply it to invoice payments that historically moved by check or bank transfer, which is why the growth story is a substitution story rather than a new-rail story.

The Mechanics

Issuance

A virtual card program runs through an issuing platform, either a bank's commercial card product or a fintech issuer built on a bank sponsor. The buyer's system, typically the accounts payable module of an ERP or a dedicated AP automation tool, calls an API with the amount, supplier, and control parameters, and receives card credentials back in under a second. Those credentials are then delivered to the supplier by remittance email, supplier portal, or straight-through file, or keyed by the buyer directly into the supplier's payment page.

The issuance path matters because it determines what the program can automate. A bank portal where a clerk manually generates numbers produces control benefits and no efficiency benefits. An API embedded in the payment run produces both, and it is what allows a card to be issued as a byproduct of invoice approval rather than as a separate task.

The three card types

Single-use. One number, one transaction, typically locked to an exact amount with a small tolerance and a short validity window. It expires after authorization. This is the strongest control posture and the natural default for one-off invoice payments, and it is also what makes reconciliation deterministic, since the number maps to exactly one invoice.

Lodged. One number held on file by a specific supplier and used repeatedly, constrained by a spend limit and velocity rules rather than a single amount. This is common in travel, where an agency holds a number for a corporate account, and in recurring vendor relationships where reissuing per transaction adds friction with no benefit. It trades some fraud containment for operational simplicity.

Wallet-scoped or category-scoped. A number provisioned to a specific spend category or a specific employee wallet, constrained by merchant category codes, geography, and time. This is the model behind most modern corporate spend management: an employee gets a number for a defined purpose, and policy is enforced at authorization rather than reviewed in an expense report afterward.

The controls

Controls are enforced at authorization by the issuer, so a violation is a decline rather than a violation to be discovered later. The common dimensions are amount (exact, maximum, or a tolerance band), merchant identity (locked to a single acquirer merchant identifier), merchant category code, validity window, transaction count, and geography.

Amount and merchant locks together are what make fraud containment structural. A stolen single-use number locked to one supplier for one amount inside a short window is close to worthless to an attacker, because the network declines any attempt that falls outside those parameters. This is a different security model from consumer cards, where the number is a durable secret defended by monitoring and reissued after compromise. Here the credential is designed to be exposed, which removes most of the value of stealing it.

Why Accounts Payable Adopts Them

Three benefits drive adoption, and they are worth ranking honestly, because the one that sells the program is not always the one that delivers the most value.

Rebate economics. Commercial card interchange is meaningfully higher than debit or consumer interchange, and issuers pass a share back to corporate buyers as a rebate on spend, generally scaled by volume and by how quickly the buyer settles. Moving a large volume of supplier payments from check and ACH onto cards converts a payables process that costs money to run into one that returns a percentage of spend. There is a second, quieter benefit: paying by card extends days payable outstanding by the length of the card billing cycle, since the buyer's cash leaves at statement settlement rather than on the payment date, which is working capital obtained without negotiating terms with any supplier.

Reconciliation. This is the most underrated benefit. On every other rail, matching a payment to an invoice is an inference problem: a bank credit arrives, remittance detail is truncated or missing, and someone reconstructs which invoices it covers. A single-use card number issued per invoice makes the mapping deterministic, because the number itself is the identifier, and it arrives in the transaction data on both sides. This eliminates a category of manual work rather than merely automating it, which is a different order of improvement, and it is why the reconciliation case, laid out in payment reconciliation explained, is often the strongest internal argument. It also compounds with the automation now reaching the receivables side, covered in the agentic receivables back office: deterministic identifiers are what let automated matching work reliably rather than approximately.

Fraud containment. Business email compromise attacks that redirect payments generally target bank account details, and the defense on ACH and wire is verification of the account before payment. A single-use card locked to a merchant and amount defends differently: even if the credential is intercepted, it cannot be used elsewhere. It also removes the standing risk of a supplier holding durable payment credentials on file, since there are none.

The Supplier Acceptance Problem

Every benefit above accrues to the buyer, and the cost lands on the supplier. That asymmetry is the defining constraint of the model, and no amount of buyer-side technology resolves it.

A supplier accepting a commercial card absorbs merchant discount on the full invoice value, typically a percentage in the low single digits. Receiving an ACH credit costs cents. On a small invoice the difference is negligible; on a large one it is a meaningful transfer of margin from supplier to buyer, funding the buyer's rebate out of the supplier's revenue. Suppliers understand this, and the ones with pricing power decline.

Three things determine whether a supplier says yes.

Margin structure. A supplier operating at forty percent gross margin can absorb two percent as a cost of doing business. A distributor at five percent cannot, because card acceptance would consume a large fraction of the margin on the sale. This is why virtual card penetration varies so sharply by industry, and why programs that target suppliers indiscriminately stall.

What the supplier gets back. Faster settlement is the honest counter-offer. Card funds settle in days against invoice terms that may run thirty, sixty, or ninety, so a supplier accepting a card is effectively buying early payment at a discount rate. Framed that way, acceptance is a financing decision with an implied annualized rate, and it is favorable for a supplier whose alternative cost of capital is high and unfavorable for one sitting on cash.

Processing burden. A supplier that receives card details by email and keys them into a terminal has taken on manual work and a security obligation. Straight-through processing, where the buyer's issuer pushes the payment directly to the supplier's acquirer with no human handling the number, removes that burden and is what distinguishes a mature program from an irritating one. Suppliers that decline cards frequently object to the handling, not only the fee.

The practical consequence is that supplier enablement is the program. Segmenting the supplier base by margin profile and invoice size, targeting the segment where acceptance is economically rational, and offering straight-through processing rather than emailed numbers determines penetration far more than the issuing technology does.

How Virtual Cards Compare to Other Rails

The buyer-side comparison against bank transfer is covered in more depth in how ACH payments work, and the summary is that ACH wins on cost per payment by orders of magnitude while losing on reconciliation quality, fraud containment, and reversibility. Virtual cards buy those three properties, and the supplier pays for them.

Where Virtual Cards Fit and Where They Do Not

The pattern is consistent. Virtual cards win where the acceptance cost is small in absolute terms, the supplier's margin can absorb it, and the control and reconciliation benefits are worth paying for. They lose where the percentage becomes a large number, which is precisely where finance teams initially want to use them, because that is where the rebate would be largest. That inversion is the single most common strategic error in virtual card programs.

The Issuer Landscape

Three models compete, and the choice determines both economics and integration effort.

Bank commercial card programs. The buyer's existing banking relationship extends into virtual card issuance. Rebate terms are negotiated as part of the broader relationship, credit is underwritten against existing facilities, and the treasury relationship is unified. The trade-off is typically the interface: bank issuing portals and APIs vary widely in quality, and integration into an AP workflow can be slower than a purpose-built platform.

Fintech issuers. Specialist platforms built on a sponsor bank, competing on API quality, issuance speed, control granularity, and the surrounding spend management software. They generally offer the better developer experience and the better product, and they introduce a sponsor bank dependency, a counterparty to diligence, and rebate terms that may be less favorable than a large buyer could negotiate directly with its own bank.

Embedded issuance. Virtual card issuance appearing as a feature inside software the organization already uses: the AP automation platform, the procurement suite, the travel booking tool. The integration cost approaches zero because the workflow is already there. The trade-off is dependence on that vendor's issuing partner, rebate economics set by the software vendor rather than negotiated, and card issuance now coupled to a software decision that may be revisited for unrelated reasons.

For a large payables volume, the bank program usually wins on rebate and the fintech issuer on product, and the practical answer is often both: the bank program for the high-volume enabled supplier base, an embedded or fintech option for tail spend and employee purchasing where the workflow integration matters more than a few basis points.

Frequently Asked Questions

What is a virtual card and how does it differ from a physical card?

A virtual card is a card number generated on demand with spend controls attached, running on the same networks as physical cards. The differences are that it can be created and destroyed instantly by API, locked to a specific amount, merchant, category, or date range at the moment of issuance, and issued per transaction rather than per person. The rails, the authorization flow, and the settlement are identical.

Who pays the fee on a virtual card payment?

The supplier does, through the merchant discount their acquirer charges on the transaction, typically a low single-digit percentage of invoice value. The buyer pays nothing directly and generally earns a rebate funded from the interchange portion of that fee. This asymmetry is why supplier acceptance, rather than technology, is the binding constraint on virtual card programs.

When is ACH better than a virtual card?

Whenever the invoice is large, the supplier's margin is thin, or the relationship is recurring and high value. ACH costs cents per payment regardless of amount, so on a large-ticket invoice it is dramatically cheaper in total, and no supplier with pricing power will accept a percentage fee on it. Virtual cards earn their cost on mid-size, supplier-diverse spend where control and reconciliation carry real value.

How do virtual cards improve reconciliation?

By making the mapping between payment and invoice deterministic. When a unique number is issued per invoice, the number itself identifies the invoice in the transaction data on both sides, so matching requires no inference from truncated remittance information. On ACH, wire, and check, reconciliation is a matching problem solved with incomplete data, which is where most accounts payable and receivable manual effort goes.

Are virtual cards more secure than bank transfers?

They fail differently rather than simply better. A single-use number locked to a merchant and amount is close to worthless if intercepted, and there are no standing credentials for a supplier to hold or lose, which defends well against the redirection attacks that target bank details. Card payments also carry chargeback rights that bank transfers lack. The offsetting risk is credential handling when numbers are emailed and manually keyed, which straight-through processing removes.

The Bottom Line

Virtual cards are best understood as a control and data product delivered over a payment rail that already exists everywhere. The settlement mechanics are unremarkable. What is valuable is that the payment instrument itself carries policy, expires on schedule, and doubles as a reconciliation key, which is a set of properties bank transfers have never offered.

The strategic discipline is knowing where that is worth paying for. The value is real on mid-size, supplier-diverse, control-sensitive spend, and it evaporates on large-ticket payments to thin-margin suppliers, where the acceptance cost the supplier bears exceeds any benefit either side receives. Finance teams that segment the supplier base by margin and invoice size before building the program, and that invest in straight-through processing rather than emailing numbers, get penetration. Teams that chase the largest invoices for the largest rebate get a stalled program and irritated suppliers.