One virtual card per vendor

This view turns card issuing from a finance perk into core payments infrastructure. A separate virtual card for each vendor means a finance team can lock a card to one merchant, one budget, or one workflow, then shut it off without breaking every other recurring payment. That reduces operational mess, improves reconciliation, and makes the software itself the control layer for spend rather than a single shared card number.

• The practical pain point is not just fraud or loss, it is rework. Pry framed the problem as updating hundreds of vendors if one shared card changes, while Order built around the opposite model, issuing vendor specific cards so each supplier charge flows into one ledger and one consolidated bill.
  1 sacra 2 sacra
• This only works if card creation is close to free. Pry said per card fees of 25 cents to $1 would break the unit economics, because the value comes from creating lots of cards by default, not rationing them. That is why developer first issuers like Lithic matter, they make high volume virtual card workflows fast to launch.
  1 sacra 3 sacra
• The broader market has moved this way. Order issues hundreds of thousands of single and multi use virtual cards, Pleo offers dedicated vendor cards for subscriptions, and Zip has added vendor cards to extend procurement into payment. The common pattern is one spend object, one vendor, one trail of data.
  2 sacra 5 sacra 6 sacra

The next step is that the card disappears into the workflow. Finance products will increasingly generate a vendor specific card, ACH payment, or another rail in the background based on supplier preference and economics, while preserving the same approval and reconciliation layer. The winners will be the products that make vendor level controls feel automatic and cheap enough to use everywhere.