Module 22: How Virtual Card Programs Are Really Built and Operated

🧠 Learning Objectives

By the end of this module, you will:

Understand how card programs are set up, from BIN sponsorship to network certification

Know the relationships between issuers, program managers, processors, and platforms

See what goes into getting a card product live: certification, scheme rules, PCI, etc.

Learn how revenue is split behind the scenes (interchange, fees, rebates)

Understand what banks, scheme partners, and regulators care about — and how to speak their language

What Most Builders Don’t Know

Virtual cards seem simple: create → fund → spend.

But behind every successful card product is a multi-party legal and technical structure:

Program setup

Scheme onboarding

Legal approval

BIN control

Settlement rails

Risk management

Reconciliation pipelines

This module teaches the invisible work that makes a card system actually run.

Who Actually Powers a Card Program?

Here’s the true anatomy of a virtual card product:

Cardholder ↓ Frontend App (You) ↓ Program Manager ↓ Card Processor ↓ Card Issuer (licensed bank) ↓ Card Network (Visa, Mastercard) ↓ Merchant & Acquirer

You are not the card program — you’re the product layer. The real power sits with the issuer and the program manager.

Step-by-Step: How a Card Program Gets Built

1. BIN Sponsorship

The issuer must allocate a BIN for the card product

May take weeks or months of negotiation

Network (e.g., Visa) must approve usage type (e.g., prepaid, debit, region)

2. Scheme Onboarding & Compliance

Issuer and program manager must be registered with Visa, Mastercard, etc.

BIN must be mapped to merchant categories, currencies, and usage limits

Scheme sets rules on MCCs, cross-border charges, refunds, fraud

3. Processor Setup

Processor (e.g., Interswitch, Galileo) maps PAN ranges

Connects to real-time authorization network

Configures fraud rules, lifecycle logic, limits, top-up channels

4. Card Issuance Policy

Defines who can get a card

Limits: daily spend, total float, FX exposure

Tiering: KYC level → card feature access

Funding source (wallet, USDT, NGN, etc.)

5. Dispute Management and Chargeback Routing

Platform must define how chargebacks are handled

Network requires SLA compliance and evidence submission

Frequent chargebacks affect program eligibility

6. Reporting and Reconciliation

Daily and monthly reports from processor → program manager → issuer

Network fees, interchange earnings, refunds, fraud alerts

Float vs. issued balances tracked in real time

Settlement files match spend → merchant → clearing amounts

Who Owns What?

responsibility	owner
Legal ownership of card	Issuer (bank)
Card number generation	Processor
Fraud rule configuration	Program manager + processor
UX, funding, top-ups	You
Disputes and support	Shared (you → processor → issuer)
Scheme compliance	Issuer + network
Marketing and education	You

How Revenue Is Split

Let’s say a user tops up $100 and spends it.

actor	earns from
You	Top-up fee, FX markup, possible subscription
Processor	Per-transaction and card issuance fee (to issuer or to you)
Issuer	Interchange fee from merchant (e.g., 1.4%)
Card Network	Scheme fee (~0.1–0.2%), FX fee
Merchant	Net revenue after acquiring fees and discounts

Note: Most of the actual "card revenue" (interchange) goes to the issuer, not you.

You earn on:

User fees (top-up, creation, subscription)

Rebates (if your volume is high enough to negotiate them)

Internal KPIs Issuers and Partners Care About

kpi	why it matters
Activation-to-spend ratio	Tells if your product drives real usage
Average spend per card	Higher = better interchange and network trust
Fraud rate	Affects scheme reputation and compliance
Decline rate	Too high = user complaints, network alerts
Chargeback ratio	>1% = risk of penalties or removal
Float usage efficiency	Measures how much issued balance is actually spent

Questions to Ask If You’re Partnering With a Program Manager

Who controls the BINs and what MCCs are supported?

What’s the card classification? (e.g., Visa Commercial Debit Prepaid USD)

What’s the typical approval rate across regions or MCCs?

How are chargebacks handled and who pays dispute fees?

What transaction velocity rules are enforced by default?

Can we brand cards, or are they generic under your name?

Recap

Behind every card product is a complex stack of regulated, contracted, certified infrastructure

Issuers and program managers govern the boundaries — you design within them

BINs, schemes, settlement rules, and risk flows shape what’s possible

If you want to scale, you need to know the business of card programs — not just the APIs

Treat your program as a regulated ecosystem, not a feature