Virtual Cards, Programmatic Limits, and Why Your Retry Logic Is Wrong

Virtual cards are not new. An Irish company called Orbiscom built the first controlled payment number system in the late 1990s. American Express launched "Private Payments" in 2000. The original use case was consumer fraud protection: generate a disposable card number for an online purchase so your real PAN never touches the merchant's system.

The pivot to corporate use came later. Privacy.com launched in 2016 targeting consumers, but the real shift started around 2019-2020 when Ramp, Brex, and Divvy (now BILL) began building spend management platforms around virtual card issuance. The value proposition changed from "protect your card number" to "control every dollar your company spends."

The growth since then has been steep. Global virtual card transaction value hit $3 trillion in 2024 and is projected to reach $17.4 trillion by 2029, according to Juniper Research. Transaction volume is expected to grow from 36 billion in 2023 to 175 billion by 2028. The B2B segment accounts for over 70% of the market and is growing faster than the consumer side.

When a company creates a virtual card on Ramp or Brex, four entities are involved:

1. Card network (Visa or Mastercard) licenses BIN ranges to the issuing bank
2. Issuing bank (Celtic Bank and Sutton Bank for Ramp; Emigrant Bank and Fifth Third Bank for Brex) holds the banking license
3. Issuer processor (Marqeta, in most cases) provides the API infrastructure and real-time transaction processing
4. Card program manager (Ramp, Brex) builds the product, defines business logic, and manages the cardholder experience

The card number comes from a standard Visa or Mastercard BIN range. From the merchant's perspective, it looks like any other card. There is no flag in the authorization message that says "this is a virtual card with a $500 monthly limit." The merchant learns about the limits only when a charge is declined.

Single-use cards deactivate after one successful authorization. They hold nearly 60% of the virtual card market. They are common for one-time vendor payments and purchase orders. They are fundamentally incompatible with recurring billing since the second charge will always fail.

Multi-use cards with programmable limits stay active over time but carry configurable controls: per-transaction maximums, daily or monthly caps, lifetime spend limits, and admin-set expiration dates.

Vendor-locked cards are assigned to a single merchant. Ramp calls these "vendor-specific cards" where only the designated merchant can charge. Brex calls them "ghost cards." Both platforms let admins set deactivation dates in advance to automatically kill a card before an unwanted renewal.

Employee expense cards are issued per-employee with per-person controls: per-transaction caps, monthly limits, category restrictions (e.g., travel and meals only), and in some cases time-based restrictions that limit the card to business hours.

This is the technical detail that explains why virtual card declines look like insufficient funds when they are actually policy violations.

Marqeta, the issuer processor behind Ramp and most major virtual card platforms, uses a model called Just-in-Time (JIT) funding. The card carries a $0 balance at all times. When a merchant submits an authorization request, the request routes through the card network to Marqeta, which sends a funding request to the card program manager's (Ramp's) API endpoint. Ramp checks the transaction against its spending policies: Is the card active? Is the merchant allowed? Is the amount within the limit? Is the budget still open?

If the answer is yes, Ramp approves the funding, the money moves into the card account for that specific transaction, and the authorization succeeds. If the answer is no, Ramp denies the funding request, the card still has $0, and the authorization fails with what the network sees as insufficient funds.

The merchant receives Code 51 (Insufficient Funds) or Code 05 (Do Not Honor). Not "spending policy violation." Not "budget cap reached." Just a generic decline that looks identical to a consumer whose checking account is empty.

When a programmatic limit causes a decline, the response code rarely reflects the actual reason. Here is what merchants see and what is typically happening behind the scenes:

The mismatch between Code 51 and the actual cause is the central problem. A retry system that sees Code 51 thinks "the cardholder is temporarily short on cash, retry in a few days when they get paid." In reality, the card has a $500/month budget that was already spent, and no amount of retrying will change that until someone at the company logs into Ramp and raises the limit.

Virtual cards create specific failure patterns for subscription merchants that do not exist with consumer cards.

Price increases break limits. A buyer sets up a virtual card with a $500/month cap for a SaaS subscription that costs $450/month. The vendor raises the price to $520. The next charge is declined. Every automated retry fails. The buyer's admin has to find the card, understand why it failed, and manually raise the limit. SaaS price increases of 9-25% are increasingly common, and each one creates this exact scenario for every customer paying with a capped virtual card.

Annual renewals fail on single-use cards. If a buyer pays for an annual subscription with a single-use virtual card, the initial charge succeeds. Twelve months later, the renewal hits a dead card number. Account Updater cannot help because the card was intentionally disposed. The merchant must contact the buyer to get a new payment method from scratch.

Scheduled deactivation catches renewals. Both Ramp and Brex let admins set a future deactivation date on virtual cards. A common pattern: the admin creates a card, sets it to deactivate at the end of the contract term, and forgets about it. When the subscription renews, the card is dead.

Account Updater and network tokens have gaps. For multi-use virtual cards, both Visa Account Updater and network tokens generally work as expected. For single-use cards, neither system can help because there is no updated card to provide. And even for multi-use cards, if the admin deactivates the card through Ramp/Brex, the token becomes invalid and the updater returns a "contact cardholder" response rather than new credentials.

The assumptions baked into standard payment retry logic do not hold for programmatic virtual card declines:

The result: your dunning system sends 4 retry attempts and 3 emails to someone who cannot change the spending limit on their own card. Meanwhile, the finance admin who could fix it in 30 seconds never hears about the problem.

BIN data (the first 6-8 digits of a card number) can tell you whether a card is commercial or corporate, which is the first step toward routing these declines into a different recovery flow.

Available signals from BIN lookups:

• Account funding source: Credit, debit, or prepaid
• Product platform: Consumer vs. commercial/corporate
• Card type: Standard, prepaid, virtual, gift card
• Issuer name: Celtic Bank or Sutton Bank on a Visa likely means Ramp. Emigrant Bank or Fifth Third Bank likely means Brex.

Visa offers the BIN Attribute Sharing Service (VBAS) for merchants. Third-party BIN databases like Pagos and BinDB also maintain lookup services. Most payment processors (Stripe, Adyen, Braintree) return card metadata in their API responses, including the funding type and whether the card is commercial.

The limitation: BIN data tells you the card is corporate. It does not tell you whether it has a spending limit, what that limit is, or whether it is vendor-locked. But knowing it is corporate is enough to change your retry behavior.

This is not a niche issue. The numbers tell the story:

• 70% of U.S. corporations now use virtual cards, up from 55% in 2022
• B2B accounts for over 70% of the virtual card market by transaction value
• Ramp alone has 50,000+ customers processing $100B+ in annualized purchase volume
• Brex serves 30,000+ customers across 50 countries
• 82% of current virtual card users plan to expand their use in the next year

There is still a large adoption gap: despite 70% of corporations having virtual card programs, virtual cards represent only about 2% of total accounts payable transactions. That gap is closing fast. As companies shift more spend onto these platforms, merchants will see a growing share of their recurring payments coming from cards with programmatic limits.

For B2B SaaS merchants specifically, the exposure is significant. If even 10-15% of your subscriber base pays with corporate virtual cards, that segment has fundamentally different decline behavior than your consumer customers. Treating them identically means your recovery rate on that segment is far lower than it should be.