Virtual Cards

Technically a virtual card is unremarkable: the same kind of credential as a physical card, generated on demand, with no plastic attached. Operationally it is a different instrument entirely, because the constraints travel with it.

A physical card is a general-purpose object. It goes in a wallet, it works nearly everywhere, and any restriction on it has to be expressed as a rule sitting behind the account. A virtual card is a specific-purpose object. It is created for a vendor, a project, a purchase or a subscription, and the restriction is bound to the credential itself. Nobody has to remember what it is for, because it cannot be used for anything else.

That property changes three things at once: attribution becomes automatic, fraud exposure becomes bounded, and subscription management becomes possible without a spreadsheet. Those three benefits are why virtual issuance has become the clearest dividing line between modern card programs and traditional business banking, as described on the cards hub and in Brex Corporate Card.

Scoping

The set of constraints attached to a credential at creation: merchant, amount, period, expiry and owner.

Vendor lock

A restriction confining a credential to a single merchant, so it declines everywhere else.

Single-use credential

A card intended for exactly one transaction, which closes or expires immediately afterwards.

Blast radius

The maximum damage possible if a credential is compromised — bounded by its scope rather than by the account’s total capacity.

Rotation

Replacing a live credential with a new one for the same purpose, without disturbing the underlying arrangement.

Three scoping patterns cover almost every legitimate use. Choosing between them is mostly a question of how many times the credential will be presented and whether the amount is known in advance.

The most common configuration error is over-restricting recurring cards. A subscription card sized to exactly the current monthly amount will decline the moment the vendor adjusts pricing, adds a seat or bills annually instead of monthly — and the failure surfaces as a service interruption rather than as a helpful alert. Leave sensible headroom on recurring credentials and reserve exact-amount scoping for single-use cases.

A good issuance process takes seconds and records enough information that the credential can be reviewed a year later by someone who was not involved in creating it. Those two goals pull against each other, and the resolution is to capture very little but capture the right things.

Where issuance is genuinely fast, employees use the system as intended. Where it takes a day and an approval chain, they reuse an existing card instead, and every benefit described on this page quietly disappears. Speed of issuance is therefore a control feature, not a convenience feature — a point that applies equally to employee cards and to the escalation routes covered in spending controls.

Expiry is the most underused control in the whole toolkit. A credential with an end date requires no discipline to clean up: it retires itself, and if the purpose still exists someone will notice and reissue. A credential without one persists until a human remembers it, which in practice means it persists.

• Set an expiry on every credential created for a bounded purpose, including "temporary" ones nobody expects to last
• Give project cards an end date matching the project, not a generic twelve months
• Treat open-ended vendor cards as an explicit decision, recorded with a review date rather than left implicit
• Rotate credentials after any suspected exposure, rather than waiting for confirmed misuse
• Rotate on ownership change too, so a departing owner’s credential does not silently continue under a new name

Rotation deserves a word of caution. Replacing a credential attached to a live subscription means updating the vendor’s billing details, and if that step is missed the service lapses. Rotation is therefore worth doing deliberately and with the owner informed, not as a bulk hygiene sweep run by someone who does not know which cards are load-bearing.

Software spending has a specific pathology. Each individual subscription is small enough to approve without much thought, renewals are automatic, and cancellation requires someone to notice and act. The result compounds quietly: a company can be paying for tools that nobody has opened in a year without a single person having made a bad decision.

One credential per vendor turns that invisible problem into a visible list. Every recurring charge is already attributed, every card has a named owner, and cancelling a tool means closing a card rather than navigating an unfamiliar billing portal. The review that was previously an archaeology project becomes a list you can read in ten minutes.

The trial case is worth highlighting on its own. A single-use credential with a small ceiling and a short expiry makes silent conversion structurally impossible rather than merely discouraged — the charge simply does not go through. That is a much more reliable mechanism than a reminder in someone’s calendar, and it is the pattern most often cited by teams described in small business and startups.

Card credentials leak. They leak through compromised merchants, through phishing, through browser extensions, through screenshots in support tickets and through people who genuinely did nothing wrong. The realistic security posture is not to prevent every leak but to make each one cheap.

This is exactly what scoping achieves. A vendor-locked credential with a per-cycle ceiling is worth very little to anyone who obtains it: it declines at every merchant except one, and at that one it cannot exceed a modest amount. Compare that to a general-purpose card with a high limit, where a single compromise exposes the full spending capacity of whoever holds it.

The right-hand column is the reason virtual cards are a containment mechanism rather than a security strategy. They limit the consequences of a compromise; they do not remove the need for access control on the card platform itself, or for the review habits described in expense controls.

The accounting case for virtual cards is stronger than the security case and gets discussed far less. Reconciliation is fundamentally a matching problem — this charge belongs to that purpose, that budget and that piece of evidence — and scoping solves a large part of it at the point of issuance rather than at month end.

• Vendor identity is certain, because the credential only works at one merchant regardless of how the descriptor is formatted
• Cost centre coding can default from the card, removing a manual selection on every recurring charge
• Owner attribution is intrinsic, so questions route to a person instead of to a channel
• Anomalies are obvious, since a stable recurring amount changing is immediately visible on a single-purpose card
• Close is faster, because the majority of subscription lines need no human decision at all

For a company with a few hundred recurring charges a month, this is the difference between a close that runs on rules with exception handling and a close that consists of somebody working through a list. The workflow itself is described in expense management and the automation boundaries in expense automation.

Virtual cards are frequently oversold, and a page that only listed benefits would be doing the same thing. There are real situations where they are the wrong instrument, and knowing them prevents a lot of avoidable friction.

• In-person payment. Anywhere a card must be tapped, inserted or handed over, a physical instrument is required. Digital wallet provisioning helps in some contexts and not in others.
• Verification against a physical card. Some merchants, particularly in travel and hospitality, ask to see the card used for booking. A virtual credential cannot satisfy that.
• Open-ended amounts. Where the final total genuinely cannot be estimated, any ceiling tight enough to be useful risks a decline at an inconvenient moment.
• Deposits and holds. Pre-authorisation amounts can substantially exceed the eventual charge, which catches out tightly scoped cards.
• Administrative overhead at low volume. A company with four vendors gains little from per-vendor issuance and should not build a process around it.

The balanced position is that virtual and physical instruments are complements. Most programs need both: physical cards for people, virtual cards for purposes. Employee cards covers the first half and card limits covers how ceilings should be sized on either type.

Closure is the step programs skip, and skipped closure is what turns a tidy virtual card estate into a long list nobody wants to audit. A credential should have a defined end from the moment it is created.

1. Request

   Purpose, owner, expected amount and duration are captured in a few seconds — enough for review, not enough to deter anyone.

2. Issue

   The credential is created with scope attached: merchant, ceiling, period and expiry. It never exists in an unconstrained state.

3. Operate

   Charges post already attributed. Coding defaults from the card, and only genuine exceptions reach a person.

4. Review

   On a schedule, check whether the purpose still exists, whether the ceiling still fits and whether the owner is still with the company.

5. Rotate or reissue

   Where exposure or ownership changes, replace the credential deliberately and update the vendor’s billing record in the same action.

6. Close

   When the purpose ends, close the card and cancel the underlying service. Closing the card alone leaves an unpaid subscription, not a cancelled one.

That last point catches people out regularly. Closing a card stops the payment; it does not terminate the contract behind it. The vendor will treat the failed charge as non-payment, which can mean chasing, service suspension or an outstanding balance. Cancel the service first, then close the credential.

For the full lifecycle treatment see the virtual card guide; for how virtual issuance fits alongside everything else in a program, return to the cards hub or read Brex Card.