A virtual card is a software-generated payment card credential — a 16-digit PAN, CVV, and expiry date — that exists entirely in software. It behaves identically to a physical card on card network rails but is issued in milliseconds via API rather than embossed and mailed over days. Virtual cards have become the default instrument for B2B supplier payments, employee expense programs, and any use case where granular spend control and instant issuance matter more than a piece of plastic.
How Virtual Card Works
Virtual card issuance follows a structured lifecycle: a funding account owner requests a card through an API, parameters are attached at creation, the card is used for a transaction, and it settles or self-cancels based on its configuration. Understanding each step helps payment teams design issuance programs that minimize risk and maximize auditability. Card-issuing platforms handle the network sponsorship and compliance layer that makes this API flow possible.
Card Number Generation
A card-issuing API generates a unique 16-digit PAN, CVV, and expiry date on demand. The number is allocated from a BIN (Bank Identification Number) licensed through Visa or Mastercard. The entire operation typically completes in under 200 milliseconds from API call to credential delivery.
Parameter Assignment
At creation, the issuer attaches spend controls to the card: maximum transaction amount, allowed merchant category codes (MCCs), valid currency, and expiry window. These parameters are enforced by the issuer's authorization system at transaction time — not by the application calling the API.
Credential Delivery
The card number, CVV, and expiry are returned in the API response. For B2B flows, credentials are injected directly into an AP system or transmitted securely to a supplier. For consumer disbursements, the credential may be provisioned into a digital wallet for contactless use at POS.
Transaction Authorization
When the card is presented at checkout — online or via wallet — the acquirer routes an authorization request to the issuer. The issuer validates the transaction against the card's parameters (amount ceiling, MCC, expiry date) and approves or declines in real time, typically within 1–2 seconds.
Settlement and Expiry
Approved transactions settle against the funding account within one to two business days. Single-use cards auto-cancel after the first approved authorization. Multi-use cards remain active until their programmed expiry date or until explicitly revoked via an API call to the issuer.
Why Virtual Card Matters
Virtual cards have moved from a niche treasury instrument to a mainstream payment rail because they solve three problems simultaneously: card fraud, reconciliation overhead, and slow supplier payment cycles. The scale of adoption reflects this utility directly.
B2B virtual card spend is forecast to surpass $6.8 trillion globally by 2026, up from $1.9 trillion in 2021, according to Juniper Research. Organizations that replace check and ACH payments with virtual cards for supplier disbursements report payment processing cost reductions of up to 75%, driven by rebate income on interchange and automation-driven headcount savings (Mastercard, 2022). Fraud rates on virtual card programs run 60–80% lower than on traditional corporate card programs because each card number is locked to a single supplier and maximum spend amount (Accenture, 2023).
Tokenization underpins the security architecture: card numbers that are never reused and never stored in merchant systems carry no value to attackers even if intercepted. For accounts-payable teams, the operational win is that each card carries embedded metadata — cost center code, purchase order number, supplier ID — that flows directly into the ERP at settlement, collapsing a three-way match from hours to seconds.
Interchange rebate economics
Most virtual card programs on Visa and Mastercard commercial rails generate interchange rebates for the issuing entity or corporate buyer — typically 0.5–1.5% of spend volume. At scale, this converts AP from a pure cost center into a modest revenue line, which partially funds the program's operational costs.
Virtual Card vs. Physical Card
The differences between virtual and physical cards extend well beyond form factor. They diverge meaningfully in issuance speed, fraud profile, control granularity, and reconciliation architecture. The table below covers the dimensions that matter most for payment program design decisions.
| Feature | Virtual Card | Physical Card |
|---|---|---|
| Issuance time | Milliseconds (API) | 5–10 business days |
| Fraud exposure | Minimal — locked to single use or specific merchant | Higher — static PAN reusable by any merchant |
| Spend controls | Granular: amount, MCC, expiry, currency | Basic credit or debit limit only |
| Reconciliation | Automated via card-level metadata | Manual, statement-based |
| Primary use case | Online, B2B supplier payments, employee expense | POS, in-person transactions, ATM cash access |
| Cancellation | Instant via API call | Requires card replacement and reissuance |
| Network rails | Visa, Mastercard commercial and prepaid BINs | Visa, Mastercard, Amex, local debit networks |
For most B2B payment scenarios, virtual cards dominate on every dimension except in-person POS transactions. Physical cards retain relevance for field teams, travel cash access, and any context requiring a tangible card present at a terminal.
Types of Virtual Card
Virtual cards come in several configurations, each suited to a different payment workflow. Choosing the right type at program design time prevents authorization failures, reconciliation gaps, and compliance problems downstream.
Single-use (disposable) virtual cards are the most secure variant. The PAN is valid for exactly one authorization and cancelled automatically thereafter. They are the standard choice for one-time supplier invoice payments or high-value isolated purchases where no follow-on charges are expected.
Multi-use virtual cards carry a persistent PAN with a defined expiry date. They work for recurring vendor relationships, SaaS subscriptions, and employee expense accounts where multiple transactions against the same card number are expected and controlled.
Commercial card virtual programs operate on commercial interchange rails, unlocking Level 2 and Level 3 data capture, enhanced rebate rates, and tighter integration with enterprise ERP systems. These are the standard format in large-scale AP automation deployments.
Consumer virtual prepaid cards are issued to end customers for specific disbursement use cases: insurance claim payouts, earned wage access, loyalty rewards, or gift programs. They run on prepaid BINs rather than commercial credit BINs and carry different regulatory treatment.
Ghost cards are multi-use virtual cards assigned to a department or cost center rather than an individual. There is no named cardholder. They are common in mid-market travel programs and marketing agency spend where a team shares a single card with a monthly budget cap.
Best Practices
Virtual card programs succeed when both the merchant-facing acceptance layer and the developer-built issuance layer are configured correctly from the start. Misconfigurations in either layer cause silent authorization failures and reconciliation failures that are expensive to diagnose retroactively.
For Merchants
Accept virtual cards at checkout exactly like physical cards — no special integration is required on the merchant side beyond standard card acceptance. However, merchants processing large volumes of B2B virtual card transactions should request Level 2 and Level 3 interchange data at settlement. Providing purchase order numbers and line-item detail qualifies transactions for lower interchange rates and gives buyers the reconciliation data their ERP systems expect.
Monitor your MCC classification with your acquirer. If a buyer's virtual card is restricted to a specific MCC and your merchant account is classified under a different code, the transaction will decline silently. Confirm your MCC matches your actual product category and communicate this to B2B buyers who issue restricted cards.
For subscription businesses, be explicit in checkout flows about card type acceptance. Single-use virtual cards will fail on recurring billing by design, generating involuntary churn. A brief checkout message flagging this prevents support escalations.
For Developers
When integrating a card-issuing API, always submit idempotency keys on card creation requests. Network timeouts trigger retry logic; without idempotency, retries create duplicate cards against the same funding account. Most issuing APIs support idempotency keys natively — use them on every write operation.
Store only card metadata — card ID, spend limit, cost center, expiry date — never the raw PAN or CVV. Structured logging of card IDs provides a full audit trail for reconciliation without creating a credential store that becomes a liability. Configure spend-controls at issuance time rather than trying to enforce limits at the application layer after authorization has already occurred.
Implement real-time authorization webhooks from the issuer to trigger downstream reconciliation workflows the moment a charge occurs. Polling end-of-day settlement files introduces lag and ordering ambiguity in high-volume programs.
Common Mistakes
Most virtual card program failures are predictable. The mistakes below appear consistently across enterprise AP programs, expense platforms, and developer integrations — and all are preventable with the right configuration at setup.
Issuing one shared virtual card to multiple suppliers. A single card number shared across vendors destroys the spend isolation that makes virtual cards valuable. If one supplier overcharges or the number leaks, every vendor relationship tied to that card is exposed. Issue one card per supplier or per invoice.
Setting no expiry date or unlimited spend ceiling. Unused virtual cards with open-ended parameters are live liabilities on the funding account. Always set the shortest plausible expiry — typically 30–60 days for AP workflows — and a spend ceiling no higher than the expected invoice amount plus a reasonable buffer.
Omitting MCC restrictions. A virtual card issued to pay a specific software vendor can be charged by any merchant if MCC restrictions are not set at issuance. Even a narrow MCC allowlist — for example, MCC 7372 (Prepackaged Software) or MCC 5045 (Computers) — closes this exposure with minimal configuration effort.
Not mapping card metadata before issuance. If cost center codes, PO numbers, and supplier IDs are not attached to the card at creation time, reconciliation reverts to manual matching after the fact. The ERP integration depends entirely on this metadata being present from the first transaction.
Transmitting card credentials over unencrypted channels. PAN and CVV must transit exclusively over TLS 1.2 or higher. Never include raw card credentials in email bodies, internal Slack messages, webhook payloads without HTTPS, or application logs — even in development environments.
Virtual Card and Tagada
Tagada's payment orchestration layer connects to card-issuing APIs to make virtual card generation a native step in automated payment workflows. Rather than maintaining separate integrations for each issuing provider, merchants and platforms can trigger card issuance as part of a broader payment sequence — funding a supplier, disbursing to a customer, or assigning spend to a cost center — all routed through Tagada's unified API. This architecture is particularly valuable for AP automation and customer payout programs that span multiple geographies, currencies, and issuing partners simultaneously.
Orchestrate virtual card issuance through Tagada
Connect your card-issuing provider to Tagada's orchestration layer to automate virtual card creation, parameter assignment, and reconciliation as part of a single payment workflow. Tagada routes issuance requests to the optimal issuer based on geography and network availability — without requiring separate API integrations per provider.