Virtual credit card

From CEOpedia
Virtual credit card
See also


Virtual credit card - is a card number issued in digital form only, with its own primary account number (PAN), expiry date and security code (CVV/CVC), that is linked to an existing card account or to a corporate funding account and is used for online, telephone and other remote payments. The holder never gets a piece of plastic. Instead, the issuer generates a number that can be limited to one transaction, one merchant, a set amount or a short period, so that a stolen copy is worth little or nothing to a thief. Researchers writing in 2001 called these "limited-use credit card numbers" and treated them as a way of keeping the real account number away from merchants altogether[1].

For the merchant, a virtual card looks like any other card. It goes through the same card network, gets authorised by the same issuer and settles through the same acquiring bank. That's the whole trick. Nothing in the acceptance infrastructure has to change, yet the buyer gains a level of control over each payment that plastic cards never offered.

History

The idea grew out of early e-commerce fears. Plenty of online shoppers at the turn of the century simply did not want to type their card number into a website they had never heard of. Card issuers answered with substitute numbers.

In September 2000 American Express announced Private Payments, a free service for consumer and small-business cardholders. A cardholder logged in to a secure part of the Amex website, requested a random number and used it for a single online purchase, after which it expired. Computerworld noted at the time that some European banks already offered similar services and that MasterCard was working on its own virtual account number system[2].

Citibank followed. In June 2002 it introduced Virtual Account Numbers for its cardholders, again at no charge: the customer downloaded a small program, signed in at checkout and received a random substitute number that became invalid after one purchase. Merchants processed it like a normal card number. The technology behind it was patented by Orbiscom[3], a Dublin-based software firm whose "Controlled Payment Number" products were licensed to large banks in the US, Europe and Asia.

Then the focus shifted. Consumer interest in one-off numbers stayed modest, but corporate treasurers liked the controls. Orbiscom and MasterCard jointly built MasterCard inControl, a platform offering authorisation controls over how, when and where a card can be used, real-time alerts and limited-use numbers with per-transaction limits; Royal Bank of Scotland became the first institution to implement it, for commercial card customers, in 2008. In January 2009 MasterCard bought Orbiscom for approximately $100 million, part of it contingent on future performance[4].

A separate line of development started in 2014, when EMVCo released its first payment tokenisation framework and mobile wallets began replacing card numbers with network tokens. More recently the card networks have built tools for the supplier side, such as Visa AR Manager (piloted from October 2023), meant to automate virtual card acceptance for businesses that get paid this way[5].

Types of virtual cards

The label "virtual card" covers several quite different products. They share a common idea (a substitute credential), but the controls and the users differ.

Single-use cards

One number, one authorisation. Once the transaction is approved the number dies. These are the descendants of Private Payments and Virtual Account Numbers. Their weakness shows up with merchants who charge in several parts, re-authorise later or take a deposit first. A number that has already been "used up" can't cover the second charge.

Multi-use and merchant-locked cards

The number stays valid for repeated charges, but only at the merchant where it was first used, or only up to a monthly cap. Subscriptions are the typical case: a streaming service or a software vendor keeps billing, and the cardholder can kill the number without touching the main account. Some issuers now build this into their mobile apps as an ordinary part of consumer banking.

B2B virtual cards for accounts payable

Here the virtual card is issued against a commercial card programme, not a personal account. The buyer's AP system (or the bank's portal) generates a number for each purchase invoice, loads it with the exact invoice amount, and sends the details to the supplier by email, portal or direct integration. The supplier charges the card through its terminal or gateway. The issuer then bills the buyer at the end of the cycle. Banks sell this through their corporate banking units, usually with a rebate attached.

Travel and hotel cards

Online travel agencies and corporate travel departments face an awkward problem: the hotel needs a card to guarantee and pay for the stay, but the guest shouldn't carry the company's card, and the agency doesn't want to hand over its own. Solution: a virtual card per booking, valid for the room rate and taxes, often limited to the hotel's merchant category code and the stay dates. Front-desk staff charge it at check-out.

Tokenised device cards

When a card is added to a phone wallet, the phone does not store the real PAN. It stores a network token. This looks like a virtual card, and people often call it one, but technically it is something else (see below).

Virtual card numbers versus network tokens

The distinction matters for security people and for PCI auditors.

A virtual card number (VCN) is a real PAN in its own right. It has a BIN, an expiry date and a CVV, and it can be keyed into any checkout page or terminal that accepts the brand. Controls sit with the issuer: when an authorisation request arrives, the issuer checks whether the VCN is still valid, whether the merchant and amount match, and so on.

A payment token in the EMVCo sense is a substitute value that replaces the PAN and "is constrained in how it can be used," for example to a specific merchant, device or payment channel[6]. A token service provider (in the early years, essentially the card networks) creates the token, keeps the token-to-PAN mapping in a token vault and translates it back before the issuer authorises the payment. Token domain restriction controls tie the token to particular presentment modes (contactless or e-commerce), to an identifiable merchant, or require a cryptogram unique to each transaction[7]. If a breach exposes the token, the fraudster gets a value that won't work elsewhere, and a fresh cryptogram stops replay of the intercepted message.

Put simply: a VCN protects the payment by being disposable; a token protects it by being unusable outside its domain. They can be combined. A corporate virtual card can itself be tokenised into a mobile wallet, which is exactly what several commercial card programmes now allow.

Feature Virtual card number EMV payment token
What it is Separate PAN issued by the card issuer Surrogate for an existing PAN, issued by a token service provider
Where controls are enforced Issuer authorisation system Token service provider plus issuer
Can be typed into any checkout Yes Normally no; bound to a device, wallet or merchant
Typical users Online shoppers, AP departments, travel agencies Mobile wallets, card-on-file merchants
Cryptogram per transaction No Usually yes

How a virtual card works

The chain of parties is the ordinary card chain: issuer, network, acquirer, merchant. What is new happens at the issuer before and during authorisation.

  1. The cardholder or the buyer's software asks the issuer for a number, usually through an API, banking app or browser extension.
  2. The issuer creates the credential and attaches rules to it.
  3. The number is given to the merchant like any card.
  4. The merchant's acquirer sends an authorisation request through the network.
  5. The issuer matches the request against the rules. Pass, and the charge is approved against the funding account. Fail, and it's declined.
  6. Settlement and clearing proceed as for any card. The charge lands on the parent account's statement, often with extra reference data.

Typical rules include:

  • Amount limits - exact invoice amount, a ceiling, or a tolerance band (say, ±2% for currency swings).
  • Number of uses - one, a fixed number, or unlimited.
  • Validity window - activation and expiry dates, sometimes only a few days.
  • Merchant restrictions - a single merchant ID, or a set of merchant category codes (MCC), e.g. "hotels only" or "no cash-like transactions".
  • Geography and channel - card-not-present only, domestic only.
  • Reference data - cost centre, project code, PO number, traveller name. Not a control, strictly, but it's what makes reconciliation work.

Corporate use

Most of the money in virtual cards today flows business to business. Three reasons dominate.

Rebates. Card issuers earn interchange from the supplier's side of each transaction and share part of it with the paying company as a cash rebate. For a large payer this can become a noticeable line of non-operating income. Nobody should forget who funds it, though: the supplier.

Working capital. The buyer pays the supplier on the due date, but the issuer only collects from the buyer at the end of the card cycle plus a grace period. The gap, often a few weeks, extends days payable without stretching the supplier. It shows up as a lower payables turnover and a shorter cash conversion cycle.

Process and reconciliation. Each invoice gets its own number, so every card transaction maps one-to-one onto an open item in the purchase ledger. Matching becomes almost automatic. No cheque printing, no envelopes, no chasing remittance advices. Compare that with a single plastic purchasing card shared by a department, where somebody has to guess which of thirty charges belongs to which order.

There's a fourth benefit, less talked about. Control. A virtual card can't be used for anything except the specific invoice it was created for, which shuts down several classic schemes of accounting fraud, like fictitious vendors receiving a payment that exceeds the approved amount.

Security and fraud reduction

Card-not-present fraud runs on stolen card numbers, traded in bulk on carding forums and as card dumps. A virtual card shrinks the value of each stolen record. A single-use number that has already been spent is junk. A merchant-locked number stolen from one shop's database fails everywhere else. An amount-capped number limits the damage to the cap.

The PCI side is subtler than vendors sometimes suggest. The PCI Security Standards Council's tokenisation guidance points out that storing tokens instead of PANs "can help to reduce the amount of cardholder data in the environment," which may cut a merchant's compliance effort[8]. A virtual card number, though, is not a merchant-side token. It is a PAN. A merchant or hotel that receives, stores or keys in virtual card numbers is handling cardholder data and stays in PCI DSS scope just as with plastic cards. The same guidance also warns that tokens usable as payment instruments ("high-value tokens") may be worth as much to an attacker as the data they replace and may themselves fall in scope[8]. What the buyer gains is different: its own master account number is exposed far less often. Good information security management at both ends still matters.

Example of a virtual card programme

The company and all figures below are hypothetical and serve only to illustrate the calculation.

Northfield Components, a mid-sized manufacturer, pays suppliers about $40 million a year. After a supplier enrolment campaign, vendors representing $8,000,000 of annual spend in 4,000 payments (average $2,000) agree to take virtual cards instead of cheques and bank transfers. The assumptions:

  • rebate from the issuer: 1.25% of card spend,
  • extra float: on average 20 days between paying the supplier and paying the card bill,
  • cost of capital: 7% a year,
  • internal cost per payment: $3.50 under the old cheque/transfer mix, $1.20 by virtual card (including reconciliation),
  • suppliers holding 15% of the card spend add a 2.5% surcharge to their invoices.

The annual benefits:

\[ Rebate = 8{,}000{,}000 \times 1.25\% = 100{,}000 \]

\[ Float\ value = 8{,}000{,}000 \times 7\% \times \frac{20}{365} \approx 30{,}685 \]

\[ Processing\ saving = 4{,}000 \times (3.50 - 1.20) = 9{,}200 \]

Gross benefit: $100,000 + $30,685 + $9,200 = $139,885.

Now the surcharges:

\[ Surcharge\ cost = 8{,}000{,}000 \times 15\% \times 2.5\% = 30{,}000 \]

Net benefit: $139,885 - $30,000 = $109,885, or about 1.37% of the card spend.

Item Annual amount ($)
Rebate 100,000
Float value 30,685
Processing saving 9,200
Supplier surcharges -30,000
Net benefit 109,885

Two observations. First, the rebate dwarfs the processing saving; the business case is mostly about interchange, not paperwork. Second, the case is fragile. If the share of surcharging suppliers rose from 15% to about 70% of card spend, the surcharges would wipe out the entire gross benefit (139,885 / (8,000,000 × 2.5%) ≈ 0.70). And on the other side of the table, if the suppliers' card acceptance fees averaged 2.4%, they would be paying around $192,000 a year in total, or $48 on a typical $2,000 invoice. Some will accept that in exchange for faster, more predictable payment. Some won't. A transaction cost analysis done only from the buyer's side tells half the story.

Advantages of virtual credit cards

  • Card details exposed in a breach are of limited or no use to criminals.
  • Fine-grained control of each payment: amount, merchant, MCC, dates.
  • The real account number stays private; a compromised virtual number can be cancelled without reissuing the main card.
  • Rebates for corporate payers and longer effective payment terms.
  • Near-automatic reconciliation of card charges with invoices.
  • No changes needed at the merchant; the number runs on existing card rails.
  • Instant issuance, so a buyer can pay a new supplier the same day.

Limitations of virtual credit cards

  • Supplier acceptance. Many suppliers, especially in construction, raw materials or anything with thin margins, refuse cards or demand a surcharge, because the merchant fee comes out of their revenue. Virtual card acceptance has been described by Visa itself as "an incredibly manual, time-consuming and costly process" for suppliers[5].
  • Refunds and returns. A refund needs a live card to credit. If a single-use number has expired, the merchant may have to issue the refund by other means, or the issuer has to route it back to the parent account; either way someone spends time on it.
  • Holds and pre-authorisations. Hotels, car rental firms and fuel stations block an amount larger than the final bill. A tightly capped virtual card can decline, or the hold can eat the whole limit and leave nothing for the actual charge. Released holds can take days to clear, and a voided transaction may still show on the statement for a while.
  • Split and recurring charges fail on single-use numbers.
  • In-person use is awkward: a hotel may ask to see the physical card used at booking, and there isn't one.
  • Not a complete security answer. The number can still be phished during its validity window; phishing of AP staff and fake supplier bank details are separate risks for cybersecurity risk management.
  • Programme costs - integration with ERP, supplier enrolment campaigns and occasional disputes about who pays the merchant fee.

Related approaches

Virtual cards sit among several other ways of paying without exposing a reusable credential or without plastic at all. Digital cash and the electronic purse store value in a token or on a chip rather than referencing an account. Affinity cards share the rebate logic, but on the consumer side. Network tokenisation, discussed above, protects card-on-file and wallet payments. In B2B, the alternatives are electronic bank transfers (cheap for the supplier, no rebate for the buyer), commercial purchasing cards issued in plastic, and supply chain finance, which extends terms through a bank rather than through the card cycle. Which one wins usually comes down to the supplier's margin and its willingness to pay a card fee, a question that belongs to procurement and supply policy as much as to treasury.

References

Footnotes

  1. ↑ Rubin A.D., Wright R.N., Off-Line Generation of Limited-Use Credit Card Numbers, Financial Cryptography (FC 2001), LNCS Vol. 2339, Springer, 2002
  2. ↑ Trombly M., Amex unveils disposable credit numbers, Computerworld, 11 September 2000
  3. ↑ The Christian Science Monitor, Buy online without revealing card number, 24 June 2002
  4. ↑ MasterCard Incorporated, MasterCard Acquires Orbiscom to Accelerate Development of Innovative Payment Solutions, Form 8-K Exhibit 99.1, 5 January 2009
  5. ↑ Visa Inc., Visa Announces Pilot Launch of Visa AR Manager to Simplify Commercial Virtual Card Acceptance, press release, 23 October 2023
  6. ↑ EMVCo, EMV Payment Tokenisation, EMVCo website
  7. ↑ Pandy S., Crowe M., Industry Perspectives on the Evolution of EMV Payment Tokenization, Federal Reserve Bank of Boston, 2019
  8. ↑ PCI Security Standards Council, Information Supplement: PCI DSS Tokenization Guidelines, Version 2.0, 2011, sections 1.3 and 4.1
Virtual credit card — recommended articles
Digital cash — Electronic purse — E-commerce — Acquiring bank — Credit card dump — Days payable — Cash rebate — Purchase ledger
Retrieved from CEOpedia