Virtual cards are one of those features that sound simple until you start building them. A card number, an expiration date, a CVV — merchants use them to pay for business expenses without handing out physical plastic. Clean concept. The implementation reality is messier, and the path to offering virtual card issuance inside a B2B SaaS platform has a few decision points that aren't obvious from the outside.
In my experience working with platforms that have evaluated card programs, the biggest misconception is thinking that a BIN sponsorship arrangement is something your platform can manage directly. It isn't — and understanding why tells you a lot about how card issuance actually works.
BIN Sponsors and Why You Can't Skip Them
Every payment card issued in the US carries a Bank Identification Number — the first six digits — that ties the card to a specific issuing institution. To issue cards with your own branding (or with any branding at all), you need a BIN sponsor: a bank that holds the issuer relationship with Visa or Mastercard and allows you to issue cards under their program.
BIN sponsors review program applicants carefully. They want to see that the issuer has a compliant cardholder agreement, a functioning KYC process, spend controls in place to limit fraud exposure, and a clear dispute resolution workflow. For most SaaS platforms with no prior card issuing history, the review process alone takes 3-6 months. Some BIN sponsors require minimum monthly card volume — often 5,000-10,000 active cards — before they'll commit to a new program.
Working through an embedded finance provider changes this equation. The provider already has the BIN sponsor relationship established. Your platform issues cards under the provider's existing program. The compliance review, the cardholder agreements, the dispute process — all of it is handled at the program level. The platform's role is to configure spend controls and surface the card management UI to merchants.
How Spend Controls Actually Work
The spend control layer is where platform operators have the most direct influence over card behavior. Controls operate at several levels:
| Control Type | What It Restricts | Common Platform Use Case |
|---|---|---|
| Merchant Category Code (MCC) block | Entire categories of merchant types (e.g., casinos, airlines, liquor stores) | Restaurant platform restricting cards to food service and restaurant supply MCCs only |
| Velocity limit | Maximum spend per day, week, or month | Contractor platform capping cards at $2,500/week to match typical materials budgets |
| Per-transaction limit | Maximum spend per single transaction | Limiting any individual charge to $500 to prevent large unauthorized transactions |
| Specific merchant block | Individual merchant IDs | Blocking specific vendors after a pattern of unauthorized charges |
| Geographic restriction | Transactions outside a defined region or country | US-only cards to prevent international fraud exposure |
Spend controls are set via API. Platform operators — typically the SaaS team, not individual merchants — configure the default control profile for all cards issued through their program. Individual merchant cards can then be adjusted within those defaults. This matters because it means the platform sets the outer bounds of what any merchant card can do, and merchants operate within those bounds.
The default control profile is worth deliberate design thought. A platform serving restaurants should think about which MCCs are legitimate for a restaurant operator's purchasing — kitchen equipment, food distributors, cleaning supplies — versus MCCs that are clearly outside the business purpose of the card. Tighter defaults reduce fraud exposure. Overly tight defaults generate merchant support tickets every time a legitimate purchase gets declined.
Instant Issuance: What "Instant" Actually Means
One of the clearest merchant benefits of virtual cards over physical plastic is issuance speed. When a merchant completes KYC and their account is provisioned, a virtual card can be ready for use within minutes. No mailing address required, no 7-10 business days for card delivery. The card number is surfaced directly in the platform's merchant dashboard.
Practically, "instant" has two components. First, the technical issuance — generating the card number and provisioning it in the card management system — is genuinely fast, typically sub-second via API. Second, the card becomes usable as soon as it's provisioned and activated by the cardholder, which can be as simple as the merchant viewing the card in the dashboard and acknowledging terms.
The catch is that card provisioning is gated on KYC completion. A merchant who hasn't passed identity verification can't receive a card. For platforms that want to offer cards as a day-one feature for new merchants, the critical path is how fast the KYC flow runs. With automated identity verification, most legitimate merchants clear in under 2 minutes. That's the number that determines how "instant" the end-to-end card experience feels.
Dispute Resolution: The Piece Nobody Talks About Upfront
Chargebacks and disputes are inevitable in any card program. A merchant is charged twice for the same purchase. A vendor is paid for goods that never arrived. A card number is compromised and used fraudulently. Each of these events triggers a formal dispute process governed by Visa or Mastercard network rules.
In an embedded card program, dispute resolution works like this: the cardholder (your merchant) submits a dispute through your platform interface. The dispute is transmitted to the BIN sponsor bank, which initiates a chargeback with the acquiring bank on the other side of the transaction. The merchant may receive a provisional credit while the dispute is under investigation. Resolution takes 30-90 days depending on the transaction type and dispute category.
What this means operationally for your platform: you need a dispute intake workflow. Merchants will expect to report disputes through the same platform they use for everything else. You don't need to adjudicate disputes yourself — that happens at the card network level — but you do need to surface the right information fields, track dispute status, and communicate outcomes back to merchants.
Platforms that don't design this workflow upfront end up fielding dispute-related support tickets through email and resolving them manually, which is expensive and slow. We've seen platforms where unresolved disputes from months prior were sitting in a founder's inbox because nobody had built the intake flow. That's the kind of operational debt that cards create if you don't plan for it.
Revenue Mechanics for the Platform Operator
Virtual card programs generate interchange revenue on every transaction. When a merchant uses a Visa or Mastercard card at a merchant that charges 2.0% interchange, a portion of that interchange flows back up through the card network, to the BIN sponsor, and through the program to the platform operator and the embedded finance provider.
Interchange splits vary by program structure, but for a typical B2B card program, platform operators can expect net interchange revenue in the range of 0.5-1.0% of card spend. On a platform where merchants collectively spend $2M per month on virtual cards, that's $10,000-$20,000 per month in incremental revenue that requires no direct fulfillment effort from the platform team once the program is live.
The revenue is modest at small scale. It becomes meaningful as card adoption grows — and in our experience, merchants who receive cards as part of their SaaS platform tend to use them for a meaningful portion of their recurring business purchases, because the spend is already tracked inside the platform they use every day. That's the compounding advantage of embedded cards over standalone card programs that live outside the merchant's primary workflow.
For B2B platforms evaluating whether to add virtual card issuance, the question isn't just whether merchants want cards — they almost always do. The question is whether the platform team has the operational capacity to support the dispute workflow, configure spend controls thoughtfully, and communicate card limits clearly to merchants during onboarding. Get those pieces right and the card program pays for itself quickly.
