How Virtual Card Issuing Works

How virtual card issuing works (in brief):

A virtual card is a card number (PAN), expiry, and CVV generated programmatically via a card issuing processor. The card exists only in software — there is no physical plastic. When the card is used for a transaction, the card network routes the authorization request to the issuing processor, which applies your program rules (limits, merchant controls, balance checks) and approves or declines in real time.

Understanding how virtual card issuing works is essential for teams building expense management platforms, ad spend tools, corporate card programs, or any product that wants to offer payment cards to users. This guide explains the full stack: from card networks to BIN sponsors, processors, and what you actually build as a software layer.

The Card Network Stack

When building a virtual card product, you are building the Program Manager layer. You do not need your own banking license — the BIN sponsor bank and processor handle that. Your product layer defines card issuance logic, spending controls, and the end-user experience.

Layer	Role	Examples
Card Network	Routes authorization requests between merchant and issuer; sets rules	Visa, Mastercard
Issuing Bank / BIN Sponsor	Licensed bank that sponsors the card program; holds the BIN range	Sutton Bank, Piermont Bank, Evolve Bank, WebBank
Card Issuing Processor	Technical platform that manages card lifecycle, authorizations, and controls on behalf of the BIN sponsor	Marqeta, Lithic, Stripe Issuing, i2c, Galileo
Program Manager (You)	Product layer that defines business logic, user experience, and controls	Your platform built on Marqeta/Lithic/Stripe Issuing
Cardholder	User who holds and spends with the card	Employee, contractor, buyer, advertiser

How a Card Authorization Works

When a cardholder uses a virtual card to pay (e.g. entering the card number on Google Ads or swiping at a terminal), the following happens in real time — typically in under 2 seconds:

Merchant initiates authorization: The merchant's payment terminal or payment gateway sends an authorization request to the acquiring bank.

Acquiring bank routes to card network: The acquiring bank sends the authorization to Visa or Mastercard based on the card's BIN.

Card network routes to issuing processor: The card network identifies the issuing processor from the BIN and forwards the authorization.

Processor applies program rules: Marqeta/Lithic/Stripe Issuing evaluates the request against your program rules: spending limit, merchant controls (MCC), balance, and any real-time webhook response from your platform.

Approval or decline returned: The processor sends an approve or decline response back through the chain to the merchant terminal — the whole round trip takes milliseconds.

Transaction event sent to platform: The processor sends a webhook to your platform with the authorization details for real-time tracking.

Card Controls and Program Rules

For ad spend use cases, restricting cards by MCC (5940 for online advertising, or specific merchant IDs for Meta/Google) is a key control. For contractor payments, single-use cards with a fixed amount are useful.

Spending limit — maximum balance or per-transaction limit; declines when exceeded
Merchant Category Code (MCC) controls — restrict the card to specific merchant categories (e.g. only digital advertising platforms)
Specific merchant restrictions — allow or block specific merchant IDs (where processor supports)
Geography restrictions — allow or block transactions in specific countries
Time-based controls — active only during certain hours or days
Single-use cards — card number expires or deactivates after first successful authorization
Velocity controls — maximum number of transactions per day or week

Card Issuing Processor Comparison

For most B2B virtual card products, Marqeta or Lithic are the practical choices. Stripe Issuing is suitable for simpler programs or products already deeply integrated with Stripe.

Processor	Best For	Key Strength	Notable Consideration
Marqeta	Complex program logic, marketplace spending cards, corporate cards	Just-in-time (JIT) funding; flexible webhook-based authorization	More complex integration; best for advanced programs
Lithic	B2B and fintech card programs; virtual cards at scale	Clean API; strong virtual card support; fast onboarding	More limited physical card support
Stripe Issuing	SaaS products already using Stripe; simpler programs	Tight Stripe ecosystem integration; easy onboarding	Less flexible for complex authorization logic
i2c	Mature programs; high-volume issuers	Highly configurable; global reach	Longer integration time; enterprise-focused
Galileo	Neobanks; large debit programs	Full banking stack; FinTech-as-a-Service	Primarily US; focused on debit/prepaid programs

What You Build as the Program Manager

As the program manager layer, you build:

Card management dashboard: UI for issuing cards, setting limits, freezing/unfreezing, and viewing transaction history per card.

Card issuance API integration: API calls to the processor to create cards, set controls, retrieve card details (masked), and manage card state.

Balance / funding management: Logic to manage the program's funded balance at the processor. Cards draw from this balance. You need to keep it topped up via bank transfer or stablecoin funding (if processor supports).

Authorization webhook handling (Marqeta JIT): For Marqeta JIT programs, your platform receives a real-time authorization request and must respond approve/decline in milliseconds. This enables completely custom authorization logic.

Transaction tracking and reporting: Ingest transaction events from processor webhooks. Store and aggregate by card, user, campaign, or cost center for reporting.

User and card permission management: User roles that determine who can create cards, set limits, view statements, or export data.

Compliance and Program Requirements

Gizmolab builds the technology platform and integrates the card issuing processor. We do not provide card issuing services, BIN sponsorship, or regulatory compliance services directly. These are provided by the processor and BIN sponsor partners.

KYC for cardholders — identity verification required for cardholders; level depends on program and geography
KYB for businesses — corporate programs typically require business verification
AML monitoring — transaction monitoring for suspicious activity; required at scale
Card network program rules — Visa and Mastercard have program manager requirements; your processor guides compliance
BIN sponsor requirements — the sponsoring bank may impose additional compliance requirements

FAQ

Do I need my own banking license to issue virtual cards?

No. Card programs operate through a BIN sponsor bank that holds the required licenses. Your platform operates as the program manager layer on top of the processor and BIN sponsor. The processor (Marqeta, Lithic, Stripe Issuing) manages the technical relationship with the BIN sponsor. You build the software product on top.

What is JIT funding and why does it matter?

Just-in-time (JIT) funding is a Marqeta feature where the processor sends your platform a real-time webhook on each authorization request, and your platform must respond approve/decline with optional funding within milliseconds. This enables completely custom authorization logic — balance checks, dynamic limits, spend category rules, multi-account funding — that goes beyond static card controls. It is the most powerful (and complex) mode of card issuing.

How long does it take to get a card program live?

With Lithic or Stripe Issuing, a basic virtual card program can be live in 4–8 weeks. Marqeta programs with complex authorization logic typically take longer. The timeline depends on processor onboarding (includes KYC/KYB and program review), integration complexity, and whether you need physical cards (adds more time for card design and personalization).

Can cards be funded with stablecoins?

Yes. Some processors support stablecoin-funded card programs, or the platform can maintain a fiat funded balance that is replenished via stablecoin-to-fiat conversion. Gizmolab builds platforms where the company balance is funded in USDC and converted to fiat for card spending — useful for crypto-native companies that hold working capital in stablecoins.

Key Takeaways

Virtual card programs operate through a four-layer stack: card network, BIN sponsor, issuing processor, and program manager (your platform).

As the program manager, you build the product layer — card management, authorization logic, transaction tracking, and user experience.

Marqeta (JIT funding), Lithic (clean API), and Stripe Issuing (tight Stripe integration) are the primary processor choices for most fintech products.

Granular controls (limits, MCC restrictions, single-use, geography) are enforced by the processor at authorization time — this is the core product value.

KYC, BIN sponsorship, and card network compliance are handled through the processor and BIN sponsor partners — not built from scratch.