Cards as Programmable Payment Rail
Bo Jiang, CEO of Lithic, on the power of the cards as a digital payment rail
Cards win as a software rail because they bundle money movement, decisioning, and exception handling into one global system. A developer can create a card instantly, set merchant or amount limits, approve a charge now and settle a different amount later, and rely on the network for disputes and acceptance across merchants and countries. That is why cards keep showing up inside products like procurement, travel, and insurance payouts, even when ACH is cheaper.
-
The product difference is concrete. With cards, software can issue a single use virtual card for one vendor, one invoice, or one employee spend event. Order uses this to pay vendors, watch transactions by webhook, and tie charges back to one consolidated bill, turning payments into a controlled workflow instead of a bank transfer.
-
The hidden advantage is exception handling. Card rails support partial capture, force posts, clearer merchant data, and a standardized dispute process. Jiang argues that once payments leave the happy path, those built in rules make reconciliation and customer support much easier than stitching together ACH files, bank statements, and returns logic.
-
This is also why the market is moving toward rail abstraction. Order and Brex both describe customers as caring less about whether a payment used card or ACH, and more about whether the software delivers certainty, control, and clean reconciliation. The winning payment product is the one that makes the rail mostly disappear.
The next step is not cards replacing every rail, but cards becoming the programmable layer inside multi rail software. As more payment products bundle cards with ACH and other methods, the strongest platforms will route each transaction to the best rail while keeping the card network’s speed, controls, and reconciliation model as the template for how digital payments should feel.