Virtual card issuing is the process of generating payment card credentials programmatically — creating a card number, expiry, and security code on demand and delivering them through an API rather than manufacturing plastic and posting it.
For the merchant accepting the payment, nothing is different. The card arrives through the same network rails, carries the same BIN structure, and authorises the same way. What changes is everything upstream: cards can be created in milliseconds, scoped to a single merchant or a single transaction, and destroyed the moment they are no longer needed.
This guide covers the architecture behind virtual issuing, the parties involved, what building a programme actually requires, and the decisions that determine whether a programme is viable. For the API mechanics specifically, see card issuing API.
What Happens When a Virtual Card Is Issued
A virtual card is not a lesser version of a physical card. It is the same object without the manufacturing step. The issuing process runs as follows:
- Request. Your system calls the issuing API with the parameters for the card — the account it draws on, spend limit, merchant restrictions, and validity period.
- Number allocation. The platform assigns a card number from the issuer's available BIN ranges, generating the remaining digits and a check digit that validates the number structurally.
- Record creation. The card is registered against the cardholder and the funding account, with its control rules attached.
- Network registration. The card becomes known to the network, so authorisation requests carrying that number route back to the correct issuer.
- Credential delivery. The number, expiry, and security code are returned to your application, usually through a secure element that keeps raw card data outside your own systems.
- Activation. The card is live and can authorise immediately.
End to end this typically completes in under a second, which is what makes per-transaction and per-vendor card issuance economically sensible.
The Parties in a Virtual Issuing Programme
Almost no company issues cards entirely alone. Four distinct roles exist, though a single vendor may cover several:
Role
Responsibility
Card network
Operates the rails, sets scheme rules, allocates BIN ranges, routes authorisations
Issuing bank / BIN sponsor
Holds the network licence and regulatory permissions, owns settlement, carries compliance accountability
Issuer-processor
Runs authorisation decisioning, card lifecycle management, ledgers, and the APIs you build against
Programme manager
Owns the product, brand, customer relationship, and user experience — usually you
The practical decision is how many of these roles you take on. Taking on the issuing bank role means obtaining your own licence and principal network membership: better economics, complete control, and a twelve-month-plus timeline with substantial capital and compliance requirements. Working through a sponsor compresses launch to weeks or months at the cost of a share of the economics and some constraints on product design.
Card Control Primitives
The value of virtual issuing lies in what you can specify at creation time. The core primitives available on most platforms:
- Spend limit. A ceiling on total spend, per-transaction value, or spend within a rolling period.
- Merchant lock. The card authorises only at a specific merchant, usually bound on first use. Leaked credentials are worthless elsewhere.
- Merchant category rules. Allow or block by merchant category code — commonly used to block cash advance, gambling, and adult categories.
- Single-use. The card closes after one successful authorisation.
- Validity window. Active only between defined dates, after which it declines automatically.
- Geographic restriction. Limited by merchant country.
- Currency constraints. Restricted to a specific settlement currency.
These are enforced at the authorisation layer by the issuer, not in your application. A transaction breaching a rule is declined by the network response, which means the control holds even if your own systems are compromised or unavailable.
Authorisation: The Decision That Defines the Programme
When a merchant submits a transaction, the network routes it to the issuer, which must respond within a strict time window — typically a small number of seconds before the network times out and the transaction fails.
In that window the platform checks whether the card exists and is active, whether the funding account holds sufficient balance, whether every control rule permits the transaction, and what the fraud engine scores it. Approval places a hold on funds; decline returns a reason code.
Some platforms support just-in-time funding, where the issuer calls your system during authorisation and you decide whether to approve and release funds. This is powerful for programmes where the balance lives in your own ledger — a crypto platform converting at the moment of spend, for example — but it puts your infrastructure directly in the authorisation path. Your latency and uptime become the cardholder's experience at the till, which is a meaningful operational commitment.
Tokenisation and Wallet Provisioning
A virtual card with no plastic can still be used in physical shops if it is provisioned into a mobile wallet. Tokenisation replaces the card number with a device-specific token, so the actual number is never transmitted to the merchant and a compromised token is useless on another device.
Push provisioning — adding the card to Apple Pay or Google Pay directly from your own app, without the user typing the number — has become an expectation rather than a differentiator. It requires specific support from the issuer-processor and certification with the wallet providers, so confirm it is available rather than assuming it.
Handling Card Data Securely
Raw card credentials are the most sensitive data in the system. Storing, processing, or transmitting them brings your infrastructure into scope for PCI DSS, which is a substantial and ongoing compliance obligation.
Most programmes avoid this by never touching raw data. Common patterns:
- Hosted card display. The provider renders card details in an iframe or secure component embedded in your interface. The data never reaches your servers.
- Client-side SDK. A mobile SDK retrieves and displays credentials directly on the device.
- Tokenised references. Your systems handle only a card identifier and the last four digits, never the full number.
Designing for this from the start is far cheaper than retrofitting it after a compliance review. Treat any architecture where full card numbers pass through your application as a decision to be justified rather than a default.
What Launching a Programme Requires
Commercial and Regulatory Foundations
- A sponsoring issuer whose licence covers your target markets and whose risk appetite accommodates your use case
- Regulatory standing appropriate to your role — programme managers face lighter obligations than licence holders, but not none
- A defined KYC and AML programme, whether operated by you or delegated to the sponsor
- Agreed programme economics: setup fees, per-card fees, transaction pricing, interchange share, and volume commitments
Technical Build
- Card lifecycle. Create, activate, freeze, unfreeze, update controls, and terminate.
- Funding and ledger. How balances are held, how holds are applied, and how settlement reconciles against your own records.
- Webhook handling. Authorisation, decline, settlement, reversal, and dispute events, handled idempotently. Duplicate deliveries are normal and must not double-count.
- Reconciliation. Daily matching of your ledger against issuer settlement files. Discrepancies are routine and need a defined resolution process.
- Dispute workflow. A path for cardholders to raise disputes and for you to submit evidence within scheme timeframes.
- Card data handling. Secure display without bringing your systems into PCI scope.
Operations
The part most often underestimated. Cards fail in production for reasons that have nothing to do with your code: a merchant category the issuer blocks, a country restriction, a fraud rule firing on legitimate spend, a merchant that rejects prepaid ranges. Support staff need visibility into decline reason codes and the authority to adjust controls. Without this, every declined transaction becomes an engineering escalation.
Cost Structure
- Setup. One-off integration, certification, and programme establishment fees.
- Per card. Charged at creation. If your model issues a card per transaction, this line dominates and must be checked carefully.
- Per transaction. A fixed fee, a percentage, or both on each authorisation.
- Interchange. Revenue rather than cost — paid by the acquirer to the issuer and shared with you under the programme agreement. Regulated caps in markets such as the European Union materially change programme economics compared to the United States.
- Foreign exchange. Conversion margin on cross-currency transactions, frequently the largest cost in international programmes.
- Minimums. Monthly platform fees or volume commitments that make small programmes disproportionately expensive.
Common Failure Modes
- Underestimating time to launch. Sponsor selection, due diligence, and certification take longer than integration. Build time is rarely the constraint.
- Choosing a sponsor that cannot serve your markets. Licensing is territorial. Confirm the eligible country list before signing.
- Ignoring risk appetite. Crypto, gaming, and high-risk categories are excluded outright by many issuers. Establish this in the first conversation.
- Non-idempotent webhooks. Duplicate events double-count balances. Idempotency is not optional.
- No reconciliation process. Small daily discrepancies compound into unresolvable positions within months.
- Per-card fees against a per-transaction model. Economics that work at one card per user collapse at one card per purchase.
Virtual Issuing for Crypto and Fintech Platforms
Platforms holding customer balances — exchanges, wallets, OTC desks — issue cards to turn a stored balance into something spendable, which improves retention and adds a revenue line while keeping funds on the platform.
The technical distinction is conversion at authorisation: the user holds crypto, the merchant expects fiat, and the exchange happens inside the authorisation window. This usually implies just-in-time funding, which places real latency and availability requirements on your infrastructure.
The harder constraint is commercial. Many traditional sponsors decline crypto-linked programmes regardless of technical readiness, which is why platforms in this segment generally work with specialists, the same way issuing branded crypto debit cards works in practice. Providers such as SimplifyLabs package sponsorship, processing, and compliance tooling into a single white-label programme for this reason.
Frequently Asked Questions
What is virtual card issuing?
The programmatic generation of payment card credentials through an API, without producing physical plastic. Cards can be created instantly, scoped with controls, and terminated on demand.
Do I need a banking licence to issue virtual cards?
Not to run a programme. You do need a licensed issuing institution behind it. Most companies work through a BIN sponsor, which holds the licence while you own the product and customer relationship.
How long does it take to launch?
Through an established sponsor with a ready processing stack, typically weeks to a few months, dominated by due diligence and certification rather than engineering. Obtaining your own licence and principal membership generally takes a year or more.
Can virtual cards be used in physical stores?
Yes, if provisioned into Apple Pay or Google Pay. Push provisioning from your own app requires specific support from the issuer-processor.
What is just-in-time funding?
An authorisation model where the issuer calls your system in real time to approve the transaction and release funds, rather than drawing on a pre-funded balance held by the issuer. It suits programmes where the balance lives in your ledger, but places your uptime and latency directly in the payment path.
Does issuing cards put my systems in PCI DSS scope?
Only if raw card data passes through them. Using hosted display components or client-side SDKs keeps full card numbers out of your infrastructure and substantially reduces scope.
What is the difference between an issuer and an issuer-processor?
The issuer holds the licence and the regulatory responsibility. The issuer-processor provides the technology — authorisation decisioning, card management, and the APIs. Some vendors do both; many specialise.
Are single-use cards more secure?
For one-off purchases, yes. The number is dead after one authorisation, so intercepted credentials have no value. They cannot be used for recurring billing, where a merchant-locked persistent card with a hard cap is the better pattern.
