Virtual cards explained: types, use cases and how the API works

Technically, a virtual card is indistinguishable from a physical one at the network level. It has a BIN, a PAN, an expiry and a security code; it authorises through the same rails; it produces the same transaction records. The difference is issuance and lifecycle: a virtual card is created by an API call in under a second, can be frozen or destroyed just as fast, and costs a fraction of what manufacturing and posting plastic costs.

That speed is what makes single-use and per-vendor cards practical. If issuing a card is free and instant, you can create one per subscription, one per supplier or one per employee trip, and close it the moment it is no longer needed.

Card types are usually confused with each other because the plastic looks the same. The distinction that matters is where the money comes from at the moment of authorisation.

• Debit — draws directly from a linked account balance; declines when the balance runs out.
• Credit — draws from a credit line extended by the issuer; the cardholder repays later.
• Prepaid — draws from funds loaded onto the card itself, with no account behind it. Most virtual card programs are prepaid in structure.
• Charge — spending is settled in full at the end of each period rather than revolving.
• Single-use — a card, usually prepaid, that is destroyed after one authorisation or one merchant.
• Multi-use virtual — a persistent virtual card tied to a cardholder, reloadable and long-lived.

Cutting across those categories is the consumer versus commercial split. Consumer cards are issued to individuals for personal spending; commercial cards are issued to a business and given to employees, contractors or systems, with spend controls set by the business rather than the cardholder.

• Online subscriptions — one card per service, so cancelling is a matter of closing the card.
• Ad spend — a card per campaign or per ad account, with hard limits that cap the downside of a runaway budget.
• Employee and contractor spend — issue on hire, freeze on departure, no logistics.
• Marketplace and gig payouts — pay out to a card the recipient can spend immediately.
• Crypto-funded spending — a stablecoin balance made spendable at any merchant that accepts cards.
• Travel and procurement — one card per booking or per supplier, closed once reconciled.

The common thread is control. A virtual card is a spending permission you can grant narrowly and revoke instantly, which is a much better primitive than sharing one corporate card across a company.

A virtual card API turns card issuance into ordinary application logic. Instead of a bank relationship and a manual process, you get endpoints — and everything a card can do becomes something your product can do programmatically.

1. 1.Register a cardholder with the identity data the program requires.
2. 2.Issue a card under the program's BIN and receive its details.
3. 3.Fund the card from your wallet balance.
4. 4.Read live balance and transaction history.
5. 5.Freeze, unfreeze, unload or close the card as the product requires.
6. 6.Receive webhooks for authorisations, settlements and completed operations.

Two details separate a well-built integration from a fragile one. First, money is integers in minor units with an explicit currency and scale — never floats, and never added across currencies without normalising the scale. Second, card operations are asynchronous: you submit an operation, get an order back, and treat the webhook as the source of truth rather than assuming success on a 200 response.

Crypto-funded virtual cards are the fastest-growing category, because they solve a genuine gap: stablecoin balances are liquid and global, but almost nowhere accepts them at the point of sale. A card bridges that. The user holds USDT, the card spends USD, and the conversion happens inside the program.

For the builder, the moving parts are the crypto ledger, the conversion step, and the card ledger — with different currencies and different decimal precision on each side. Getting those boundaries right is most of the engineering work in a crypto card program; the card operations themselves are straightforward API calls.

2328 issues multi-use virtual cards funded from a USDT wallet. Cardholders and cards are created through the API, funding converts USDT to a USD card balance, and every asynchronous operation is confirmed by webhook. Card balances are USD at scale 2, the wallet is USDT at scale 6 — the API is explicit about both so you never guess.

• Bearer-authenticated REST API, JSON only, camelCase fields
• Cardholders, cards, funding, unload, freeze, close and transactions
• Idempotency on write operations and orders for async tracking
• Webhooks for authorisations and completed operations