Most devs who've touched payments know virtual cards as a way to control spend, like issuing a company card for SaaS subscriptions, a dedicated card per vendor, that kind of thing.
That's still true. The global virtual cards market was worth $22 billion in 2025 and is projected to nearly triple to $60 billion by 2030, with B2B use making up the majority of it.
But your platform can also make money with virtual card issuing: every time a virtual card gets used, a small fee gets generated, and someone on the other end collects it.
If you're building a platform with users who hold a balance (creators, sellers, gig workers, whatever) that someone could be you.
This post walks through how that actually works, and how to wire it into a product.
How virtual cards actually work
A virtual card is exactly what it sounds like: a card number, expiration date, and CVV, with no physical card attached. It can be debit, credit, or prepaid underneath — "virtual" just describes the form factor.
Everything else works like a normal card. Authorize, settle, show up on a statement. The only thing missing is the plastic.
One thing worth clarifying if you're integrating this into a product: a virtual card is not the same thing as a digital wallet (Apple Pay, Google Wallet). A wallet is a container — it's empty until you put a card into it. A virtual card is the actual card. You can add either a virtual or physical card to a wallet; the wallet just tokenizes it so the real card number is never exposed in transit.
Once a virtual card is sitting in a wallet, it works anywhere contactless does — online and in person. "Virtual" doesn't mean "online only."
Where the revenue actually comes from
- Picture a $100 transaction. That $100 doesn't go straight to the merchant:
- The merchant's bank skims a fee off the top — typically 1–3% of the transaction
- Most of that fee (on a $100 purchase with a $2 fee, roughly $1.60) goes to whoever issued the card being used
- A smaller slice goes to the card network (Visa/Mastercard) for running the rails
- The merchant's bank keeps the rest for processing
That $1.60 is called interchange. Normally, it goes to a bank — specifically, whoever issued the card. If your users are spending from their own personal debit cards, that fee goes to their bank, not you.
_The numbers are bigger than you'd think. The Federal Reserve's most recent data puts total US interchange fees on debit and prepaid transactions at $34.12 billion, across 100.7 billion transactions worth $4.7 trillion.
_
Issue the card yourself, and a share of that fee routes back to you instead, through whichever issuing provider you're integrated with (they take their own cut before passing the rest along).
_FYI: Interchange isn't a flat rate. It moves with card type, transaction location, and online vs. in-person, typically landing between 0.2% and 2.5%. Two regulatory notes worth knowing if you're scoping this out:
_
The good news for anyone reading this as an engineer: you don't need a banking license. You need an integration.
How to start issuing virtual cards
- Pick an issuing provider
Going direct means becoming a licensed bank yourself, or standing up the full compliance/risk stack that comes with a direct sponsor-bank relationship — KYC, AML, fraud liability, PCI compliance, scheme membership negotiated with Visa or Mastercard directly.
Providers like Whop Cards, Stripe Issuing, and Marqeta have already absorbed that cost once and resell access to it. You build on top instead of underneath.
- Wire it up via API
Card issuance happens through the provider's API. In practice: trigger a new card on user signup, on balance threshold, or wherever it fits your product flow. No manual application step for you or your users.
- Decide what the card is linked to
Most platforms link the card to a balance the user already has (earnings, pending payouts, wallet funds) rather than a credit line — simpler, lower risk, no underwriting required. Whop Cards works this way by default. Credit-linked cards are the more complex alternative most platforms don't start with.
- Configure the card
Spending limits, merchant restrictions, single-user vs. reissued, virtual-only vs. physical fallback — these are typically exposed as configuration on the provider's side, not something you build from scratch.
- Ship it
Once issued, a card is usable immediately: online right away, in-person the moment it's added to Apple Wallet or Google Wallet.
- Let it run
Every transaction after that generates interchange, the provider processes the split, your share lands automatically. Nothing to run per-transaction. It scales with usage, not with your engineering effort.
A real example: Poke Human
Poke is an AI assistant living in iMessage, WhatsApp, and Telegram. Poke Human is the layer of real virtual assistants that step in when a task needs a human, for things like booking a car, ordering food, handling something the AI can't.
Those VAs need to actually spend money on a user's behalf. Poke issues each VA their own Whop-issued virtual Visa card, funded by Poke, so they can complete the task without any shared-card chaos or manual reimbursement.
No card infrastructure was built in-house. Individual cards are issued via API, with authorization and tracking handled in the background. And every time a VA taps that card, a slice of the interchange comes back to Poke.
That's the general idea: whether the balance behind the card is money a user earned (creator marketplace) or money the platform loaded for an agent to spend (Poke Human), the mechanic is identical — balance, card, spend, interchange back to whoever issued it.
_Read the full guide on Whop's blog, which also covers building this specifically with Whop Cards.
_
Top comments (0)