How virtual cards work: the complete guide for UK users

A virtual card is a card number that lives in software. There is no plastic card, no chip, no magnetic stripe. The number itself is real. It sits on a real BIN, belonging to a real card-issuing bank, and it travels through the Visa or Mastercard network the same way any debit card does. From a payment network's point of view, a virtual card and a physical card are the same thing. The difference for the user is at the layer above: which number a merchant receives, how long that number stays usable, and what the card is allowed to do.

That difference matters because "virtual card" in UK consumer marketing covers four distinct mechanisms. They protect against different things, and they suit different purposes. Picking the wrong one for the wrong job leaves the user either inconvenienced or exposed.

How a card payment actually works

To see what each kind of virtual card does, it helps to start with what happens when any card is used online. The card payment system has four parties.

The cardholder is the person paying. The merchant is the business being paid. The acquiring bank is the merchant's bank, the one that processes incoming payments on the merchant's behalf. The issuing bank is the cardholder's bank, the one that issued the card and that holds the funds the payment will draw from. A card network, Visa or Mastercard in the UK, sits in the middle, routing messages between the acquiring bank and the issuing bank.

When a card is presented for an online payment, the merchant captures a small set of fields: the long card number (the Primary Account Number, or PAN), the expiry date, the CVV, and usually a billing address. These fields go to the merchant's acquiring bank. The acquiring bank reads the first six digits of the PAN, which form the Bank Identification Number (BIN), and uses them to identify the network and the issuing bank. The network forwards the request to the issuing bank, which checks whether the card exists, whether funds are available, and whether the transaction looks fraudulent, then replies approve or decline. The reply travels back the same way it came.

The merchant receives the PAN and stores it, often for years, alongside whatever else was captured at checkout. The card network itself does not transmit the cardholder's name or address; those are collected separately by the merchant through the checkout form.

The PAN is the same number every time. If you pay the same merchant ten times over two years, the merchant sees the same sixteen-digit number ten times. If the merchant shares its transaction database with a payment processor, an analytics provider, or a data broker, that number appears in those datasets too. If the merchant suffers a data breach, every PAN it stored is exposed. The PAN ended up doing a job it was never designed to do.

Virtual cards address this by giving the user a different number, or several different numbers, to give the merchant. Which kind to use depends on what is being paid for.

Mechanism one: device tokenisation

Apple Pay and Google Pay are the most widely-used virtual cards in the UK, although most users do not think of them that way. When a card is added to Apple Pay or Google Pay, the underlying card's PAN is sent to the issuing bank, which asks Visa or Mastercard's tokenisation service to generate a token. This token is a real card number on a real BIN, but it is not the underlying card's number. It is a Device Account Number, or DPAN, specific to that device. The DPAN is stored in a hardware-isolated chip on the user's phone (the Secure Element on iPhone) and is the number that gets transmitted at checkout. Each transaction also carries a one-time cryptogram, generated by the device, that authorises that specific transaction and cannot be reused.

What this protects against is precise. If a merchant's database is breached, the number exposed is the DPAN, not the underlying card. The merchant never received the underlying card. The DPAN is bound to the device, and Visa or Mastercard can deactivate it without affecting the underlying card.

What it does not protect against is what most users assume. The DPAN is the same number every time. The same merchant sees the same DPAN every time you pay them through Apple Pay. If you buy from a merchant ten times via Apple Pay, the merchant builds the same kind of transaction history they would have built from a physical card, just under a different sixteen-digit identifier. Your name, billing address, email, and shipping address still go to the merchant through the checkout form. Apple Pay protects the underlying card from breach exposure. It does not break the identifier or change what the form collects.

It also has a coverage limit: device tokenisation only works at merchants that have integrated Apple Pay or Google Pay. Most large UK retailers have. Smaller services and many overseas sites have not. For those merchants, you are back to typing in the underlying card.

In the UK, every Apple Pay or Google Pay transaction works this way. The mechanism is invisible to the user, which is why most users do not think of Apple Pay as a virtual card. Functionally, it is one.

Mechanism two: multi-use virtual cards

The virtual card products UK challenger banks promote in their apps sit in this category. The user creates a new card inside the app; the bank's issuing system mints a new PAN on the bank's BIN; the user is given the number, expiry, and CVV; the card stays valid until the user closes it. The number does not change between transactions, so the user can give it to the same merchant repeatedly. From the network's perspective it is a fully functional card; from the user's perspective it is a second card number, separate from their primary card, that can be paused or closed without affecting the main card.

The UK consumer market has several. Revolut customers on the standard plan can create up to four multi-use virtual cards every thirty days, to a maximum of twenty active at once. Starling personal account holders can create up to five virtual cards, each linked to a Saving Space, free of charge. Monzo paid-tier customers (Plus, Perks, or Max) can hold up to five virtual cards live, each linkable to a Pot. Wise customers can hold up to three digital cards, oriented around multi-currency spending.

What these protect against is real but limited. If a single merchant suffers a breach, you close that one virtual card and the rest of your financial life is untouched. If a subscription becomes a nuisance to cancel, you close the virtual card and the merchant cannot collect future payments. If a card is compromised, you generate a new one without waiting for plastic in the post.

What they do not address is the cross-merchant identity problem. Each virtual card's number is stable for as long as it is open, which means each merchant you give it to sees the same number every time. With five card slots at most, treating one card per merchant runs out quickly, so most users end up putting several merchants on the same virtual card. The merchant breach problem is reduced; the cross-merchant identifier problem is not.

There is also a caveat about subscription cancellation. Closing a virtual card does not cancel the underlying contract. The merchant's claim against you remains; the merchant simply cannot collect on it via the closed card. UK consumer law gives you separate rights to cancel the contract through the merchant directly, including continuous payment authority cancellation through your bank under the Payment Services Regulations 2017. Card-level closure is a useful tool. It is not the same as cancelling the subscription.

There is one more thing about these cards that matters for the next mechanism, and it is the place where UK marketing and merchant reality diverge. Card BINs are classified as either debit or prepaid in the tables payment processors use to decide whether to accept a card. A bank-issued card drawing on a current account is normally classified as debit. A card issued by an electronic money institution (an EMI) is normally classified as prepaid, even if the consumer-facing app calls it a debit card. The classification is set when the BIN is registered with Visa or Mastercard, and it is a property of the BIN, not of the user or the balance.

This matters because subscription merchants often configure their payment processor to decline cards classified as prepaid. The reasons given are higher fraud rates and unreliable balances for recurring billing. The decline is silent and automatic.

In the UK, Monzo and Starling are bank-issued, and their virtual cards classify as debit. Revolut received a full UK banking licence in March 2026 and is migrating its customers from its EMI entity to its bank entity, but most existing UK Revolut cards remain prepaid-classified at the time of writing. Wise UK is an FCA-authorised electronic money institution, so its cards are e-money issuance and classify as prepaid.

For everyday spending and one-off purchases, the classification does not affect anything. For subscriptions, it can be the difference between a card that works and a card that silently fails.

Mechanism three: single-use disposable cards

A disposable card is a virtual card whose number is destroyed after the first transaction. The user creates the card in the app, types its number into a checkout, completes the payment, and the number is then permanently invalid. A new disposable card can be generated for the next purchase. The number is real for one transaction and dead afterwards.

In the UK consumer market, Revolut is the only provider of this mechanism. A Revolut account holds one disposable card slot at a time, and the user is limited to five disposable-card payments per twenty-four hours. Starling, Monzo, and Wise virtual cards are multi-use, not disposable. Apple Pay and Google Pay use device tokens that are not disposable either.

What disposable cards protect against is specific: a one-off purchase from a merchant you do not trust. The card is used once, the number is gone, and any subsequent attempt to charge it fails. If the merchant is breached two months later, the disposable card number that was leaked is already invalid. If the merchant tries to bill you again, the charge declines because the card no longer exists.

What disposable cards cannot do is the inverse property of what makes them safe. By design, they do not work for subscriptions, recurring charges, or any payment that needs the card to remain usable later (hotel reservations, car rentals, ticket collections that scan the card). A disposable card cannot carry a recurring charge because the number dies after the first authorisation. There is also a second problem: Revolut's disposable cards are EMI-issued and classify as prepaid in the BIN tables described above, which is one more reason many subscription merchants would decline them even if the disposable mechanism allowed recurring billing. The two limits compound.

The card is built to die. Merchants whose payment flow needs the card to live cannot transact on it.

Mechanism four: merchant-locked cards

The fourth mechanism combines a permanent card number with a merchant restriction enforced at the issuer level. The user creates a card, ties it to a single merchant either at creation or by inference from the first authorisation, and any later attempt to use the card at a different merchant is declined by the issuing bank before the transaction reaches the network. The card stays valid for as long as the user keeps it open, so subscriptions and recurring charges work. But the card can only be used at the merchant it was created for.

This is the architecture Privacy.com uses in the United States. A US user creates a card for Netflix; Netflix charges it monthly; if Netflix's database is breached and a criminal tries to use the card at a different merchant, the issuer declines the charge. If Netflix raises its prices and the user wants out, they close the card; Netflix can no longer collect, although the underlying contract still exists and should be cancelled with Netflix directly.

No UK consumer product offers this combination today. Monzo, Starling, Revolut multi-use, and Wise all offer permanent virtual cards but none of them lock to a single merchant. Revolut's disposable card locks the spending to a single transaction (which is a different mechanism with different limits). UK historical products that came closer (Cahoot, AIB, and First Trust offered single-use virtual card numbers in the 2000s) have all been withdrawn from the UK market.

For a merchant-locked card to actually work in practice, the BIN classification matters in the same way described above. The card has to be debit-classified, because subscription merchants decline prepaid cards in the same patterns. A merchant-locked card on a prepaid BIN would technically lock to the merchant but would still fail at the merchant's payment processor for the same reasons Revolut's disposable cards do.

What each mechanism protects against

Each mechanism does part of the work. Stating them compactly:

Mechanism	Same number every time	Locked to one merchant	UK availability
Device tokenisation (Apple Pay, Google Pay)	Yes, per device	No	Live, broad
Multi-use virtual card	Yes	No	Live: Monzo, Starling, Revolut, Wise
Single-use disposable	No, used once	N/A	Live: Revolut only
Merchant-locked card	Yes	Yes	Not currently offered

The choice depends on the failure mode being prevented. For protection against a merchant breach exposing the underlying card, device tokenisation is the obvious answer where the merchant supports it. For separating online spending into a number that can be cancelled without losing the main card, any multi-use virtual card from a UK challenger bank does the job. For a one-off purchase from a merchant that is not trusted, Revolut's disposable card is the only consumer product available. For subscriptions, where the card needs to keep working but should not be reusable elsewhere, the architecture that fits the use case is not currently shipped in the UK consumer market.

What none of these mechanisms address is the identity flow at the checkout form. The user's name, email, shipping address, and any other field the merchant requires still goes to the merchant directly. A virtual card protects the card layer; it does not protect the form layer. A digital subscription that requires only an email address gains the most from any of these mechanisms; a physical-goods purchase that needs a real shipping address gains less, because the merchant ends up with most of the identity data anyway.

What UK users can use today

For protecting the underlying card from merchant breaches, where the merchant supports Apple Pay or Google Pay, device tokenisation is automatic, free, and works at most major UK retailers.

For separating spending into compartments (one card for online shopping, one for travel, one for groceries) UK challenger banks have made this a normal feature. Starling offers up to five virtual cards free, on a fully bank-issued debit BIN. Monzo offers up to five live, paid-tier only. Revolut offers up to twenty across multi-use slots. Wise offers up to three. The right choice depends on what kind of account the user already has.

For a one-off purchase from a merchant the user does not trust, where recurring billing is not needed, Revolut's disposable card is the only UK consumer product that does the job.

For subscriptions, where the card needs to work over time but should not be usable anywhere else, the UK does not currently provide this. Eigin is being built to.

A note on what is missing

Each of the three live mechanisms was designed for a specific problem, and each does its part. Device tokenisation came out of the card industry's response to merchant breaches. The multi-use virtual card came out of bank product development around budgeting and digital-first card management. The disposable card came out of the need for a number that could be used once and then stop existing.

Merchant-locked cards are the architecture for a different pattern: one card per service the user pays for, kept open so the service can keep charging, locked so the card has no value to anyone other than that one merchant. The pattern makes subscription control a property of the card itself rather than a battle with each merchant's cancellation flow. It also breaks the persistent-identifier problem at the architectural level, because each merchant sees a different card number and the cross-merchant transaction history that the same number would otherwise underwrite cannot be assembled without effort that data brokers and analytics platforms do not currently invest.

This combination is what eigin is being built for: a card per merchant, kept open, locked to that merchant, on a debit-classified BIN through a card issuing partner. Until eigin launches, the practical guidance for a UK reader paying a subscription is to use a multi-use virtual card from Monzo or Starling, treat it as that subscription's card, and close it if the relationship with the merchant ends. It is not the same architecture, but it is the closest UK users can do today with what is shipped.

For everything else, the choice is the mechanism that fits the situation. Apple Pay where the merchant supports it. A multi-use virtual card from your bank for online shopping you want kept separate from your main card. A Revolut disposable for an untrusted one-off. The card layer is one part of payment privacy. The form layer is another. The point of knowing how each mechanism works is being able to choose the right one for what you are actually doing.