Virtual Card Guide

A payment card is not an object. It is a set of numbers that a merchant sends to a network, which asks an issuer a question: may this transaction happen?

Once you see the card as a credential rather than a thing, the idea of a virtual card stops being exotic. If the plastic is just a carrier for numbers, there is no reason to have only one set of numbers, and no reason for those numbers to be general-purpose. You can mint a set for a single vendor, a single project or a single purchase, attach rules to it before it is ever used, and discard it afterwards.

That is the whole concept. The rest of this guide is about the consequences — mostly good ones, some awkward — and about how a company actually rolls it out. For the term-level treatment, see virtual cards and the brex card page; for how virtual issuance sits inside a wider program, see the corporate card guide.

A virtual card is a card credential generated on demand, with constraints attached at the moment of creation rather than applied afterwards. Those constraints are evaluated during authorisation, so a transaction outside them does not happen at all — there is nothing to review later because there is nothing to review.

1. Request

   Someone needs to pay a specific vendor for a specific reason. The request names the purpose, not just the amount.

2. Scope

   A ceiling, a period and usually a merchant or category restriction are chosen before the credential exists.

3. Issue

   The credential is generated already constrained. There is no window in which it is an unlimited card.

4. Use

   The vendor charges it. Each attempt is checked against the scope in real time.

5. Attribute

   Because the card maps to one purpose, the charge explains itself when it posts.

6. Retire

   The card is closed or allowed to expire when the purpose ends, without touching anything else.

The step that carries most of the value is attribute. On a single general-purpose card, working out who signed up for which tool is archaeology: you read a merchant descriptor and ask around. With one card per vendor, the question never arises, because the card is the answer. In software-heavy companies this removes a large share of the month-end investigation work described in the expense management cluster.

The mistake most companies make on day one is issuing virtual cards for everything at once. The better first move is narrow, because the recurring-vendor case delivers most of the benefit for almost none of the effort.

1. List every recurring charge on the existing account. This list is usually longer than expected.
2. For each one you intend to keep, issue a card locked to that vendor with a ceiling near the known recurring amount.
3. Move the vendor onto the new credential, one at a time, and watch for a failed renewal.
4. For anything on the list you cannot identify or no longer need, cancel rather than migrate.
5. Only then introduce single-use and trial cards, which need a request habit rather than just a configuration.

Step four is the one that pays for the exercise. A migration is the only time most companies systematically review what they are subscribed to, and it is common to find charges nobody can attribute. The expense controls page covers keeping that list clean afterwards, and the startup card guide walks through the same migration for a company where software is most of the spend.

An employee card is any card in a company program assigned to a named individual. That definition sounds trivial, and the important word in it is assigned: the point of an employee card is not that a person can spend, but that every transaction has an owner from the second it posts.

Employee cards and virtual cards are not alternatives — they answer different questions. An employee card answers "who is spending", which is what you need for travel, hospitality, equipment and the unpredictable middle of business life. A virtual card answers "what is this for", which is what you need for vendors and projects. Most programs run both, and the ratio follows the spending mix.

The topic has its own dedicated page at employee cards, and the policy side — what you tell people, and how you handle exceptions — is covered in employee spending. What this guide adds is the pairing logic above, because choosing the wrong instrument for a spending pattern is the most common cause of a card program that technically works and is quietly resented.

• Every card has an owner and a stated purpose recorded at creation, not added later
• Cards created for a finite purpose carry an expiry date from the start
• Cancelling a vendor and closing its card are one action, not two
• Offboarding closes a person’s cards in the same checklist as their accounts
• Unused cards are reviewed on a schedule and closed rather than kept "just in case"
• Ceilings on recurring cards are revisited when the vendor changes their price

The last item is worth dwelling on. A tight ceiling on a recurring card is a genuine control, and it will also cause a failed renewal the first time a vendor raises a price. That is the control working, but only if someone notices the decline and acts on it. A program that treats declines as errors rather than as signals will loosen every ceiling within a year — which is the pattern the spending controls guide works through in detail.

Every card visual on this site is an original illustration with placeholder digits. This is an independent editorial project: it holds no card data, provides no account access and never requests credentials.