Post Your First Per-Agent Authorization Hold
Clone Formance Ledger on GitHub, run it locally, and post a per-agent authorization hold as your first transaction.
A procurement agent submits a payment, the request times out, and the agent retries. The virtual card leg authorizes and settles two days later, but the stablecoin wallet leg broadcasts on-chain and sits pending. Your ledger shows one purchase.
Finance asks which agent paid, under what mandate, and on which rail, and the ledger cannot answer because attribution lives in application metadata that reconciliation scripts never read.
Giving an AI agent spending authority comes down to two rails for agentic payments: a virtual card the merchant sees as agent-initiated, or a stablecoin wallet the agent signs from directly.
Virtual cards ride Visa Intelligent Commerce or Mastercard Agent Pay, single-use and issuer-constrained. Stablecoin wallets, by contrast, hold funds on-chain and pay through x402 using signed authorizations. Most fleets end up running both, and the payment rail decision gets harder from there.
The card path and the wallet path differ in merchant reach, settlement speed, cost, and control.
Virtual cards are network-scoped payment credentials issued to an AI agent for a specific transaction, recognized by the merchant as agent-initiated and constrained by the issuer before the agent presents them.
Virtual cards are single-use credentials that run on network standards like Visa Intelligent Commerce and Mastercard Agent Pay. MCC locks, velocity limits, and expiry windows bound what each credential can do. Per-agent issuance happens through APIs and the Model Context Protocol, and the rail carries interchange, settlement lag, and chargeback costs on every capture.
Single-use, transaction-scoped virtual cards run on network agent-recognition standards. The two standards are Visa Intelligent Commerce and Mastercard Agent Pay.
Both let the merchant see that a transaction is agent-initiated. At the same time, the card credential remains single-use and transaction-scoped, so a leaked PAN cannot be replayed against another merchant or another purchase.
Each card can be constrained with merchant category code (MCC) locks, velocity limits, expiry windows, and single-use primary account numbers (PANs).
The controls decide what a single card presents to a merchant, such as which categories it can spend in, how often and how fast, and how long the credential stays valid. The issuer enforces these constraints at the network layer, making card controls safe to expose to an agent.
Per-agent card issuance runs through application programming interfaces (APIs) and, increasingly, through the Model Context Protocol (MCP), so the agent stack can request a card at runtime with the mandate baked into the issuance call.
Formance Ledger tracks how much of the fleet's shared budget the agent has left, and enforces the shared limit and mandate attribution before an issuance call goes out.
The card rail bills you three ways: settlement lag, interchange plus scheme fees, and chargeback exposure. An authorization hold at T+0 precedes clearing files hours later and net batch settlement at T+1 or T+2.
The authorized amount and the settled amount can differ: a partial capture settles less, and a tip or currency conversion settles more. Every capture carries interchange, scheme fees, and processor markup, which appear as a gap between the sum of postings and the single net bank credit the acquirer deposits. Chargebacks and disputes are a running cost too.
Stablecoin wallets give each AI agent an on-chain account funded in tokens like USDC, with the agent's own signer authorizing every transfer instead of a card network.
Programmable spend permissions enforce per-transaction and per-day caps beneath application code, signing keys sit in secure enclaves the model never touches, and x402 carries the actual payment in sub-second on-chain transfers.
However, the rail introduces its own risks, including irreversible finality, issuer freezes, and gas paid in a second asset.
Agent-native wallets carry programmable spend permissions the signer enforces beneath application code, typically a per-transaction cap and a per-day cap.
The agent signs one authorization carrying the exact amount and a one-time nonce, and the authorization defines a validAfter/validBefore window. A relayer submits the signed authorization, and the token contract checks that the nonce has never been used, then executes the transfer.
The domain separator binds the signature to one contract on one chain, so the same payload can't be replayed elsewhere.
Signing keys sit in secure enclaves and never enter model context. The model calls a bounded signer that enforces wallet permissions, so when the signer receives a payment intent, it checks the caps and windows and produces the signature.
The private key never leaves the enclave, and the model never sees the key. The enclave boundary is what makes programmable spend permissions trustworthy.
The enclave checks the caps and windows before producing the signature, and the model can't escape the wrapper by prompting itself into a different code path.
x402 is the on-chain payment protocol that lets an agent settle a payment in sub-second, sub-cent transfers without a human in the loop.
Early production traffic on x402 is small and skews toward testing rather than real commerce, but sub-second settlement, sub-cent transfers, and no interchange are what agentic payments pull toward as adoption grows.
Wallet rail risks come in three forms: irreversible finality, issuer freezes, and gas paid in a second asset.
A settled on-chain transfer is final at the network layer, so a refund is a new transaction the merchant chooses to send, and no reversal primitive exists to fall back on.
Issuer freezes replace disputes, and an agent's balance can leave your control without notice on either USDC or USDT.
Gas is paid in a second asset, the chain's native token, and it needs its own posting or the wallet balance drifts as the agent transacts.
Virtual cards and stablecoin wallets do not compete for the same job over the same time horizon.
Virtual cards win on maturity and merchant acceptance, while stablecoin wallets win the workloads virtual cards structurally cannot serve. A hybrid design combines virtual-card authorization with a stablecoin-wallet settlement leg.
| Dimension | Virtual cards | Stablecoin wallets |
| Merchant reach | Millions of existing merchant locations via Visa Intelligent Commerce and Mastercard Agent Pay | Limited to merchants accepting x402 or on-chain USDC/USDT. Early production traffic is small |
| Settlement speed | Authorization at T+0, net batch settlement at T+1 or T+2 | Sub-second and sub-cent on-chain transfers via x402 |
| Cost | Interchange, scheme fees, processor markup, and chargeback exposure on every capture | No interchange, with gas paid in the chain's native token as a second asset |
| Finality/reversibility | Reversible through existing authorization and dispute frameworks (chargebacks, refunds) | Irreversible at the network layer. Refunds require a new merchant-initiated transaction, and the issuer freezes replace disputes |
| Control | MCC locks, velocity limits, expiry windows, and single-use PANs enforced by the issuer at the network layer | Programmable spend permissions (per-transaction and per-day caps) enforced by a signer in a secure enclave the model never touches |
Virtual cards win the next 12 to 24 months because merchant acceptance and dispute infrastructure already exist at global scale.
As Simon Taylor argues in Fintech Brainfood, agents will use cards first, then stablecoins, as workloads move up the complexity gradient, and not because one rail replaces the other, but because they solve different problems.
Virtual cards for AI agents reach millions of merchant locations your fleet already buys from, and AI-initiated virtual card transactions use existing authorization and dispute frameworks, including their authentication controls.
Virtual card acceptance dominates the decision over that window. A virtual card leg works everywhere your fleet needs to buy, and the MCC, velocity, and expiry controls above are enough to keep an autonomous agent inside its mandate.
Stablecoin wallets beat virtual cards in three workloads virtual card economics cannot serve, such as sub-dollar micropayments, 24/7 cross-border settlement, and thousand-agent sub-wallet hierarchies.
Stablecoin wallet liquidity is already moving through virtual card acceptance. Even so, stablecoin wallets hold ground that virtual cards cannot reach:
A hybrid design authorizes on a card where merchant acceptance demands it and settles the funding leg in stablecoin.
The merchant sees a familiar card transaction, the treasury moves USDC on-chain, and the ledger stitches both legs together under one per-agent account path. The hybrid pattern gets the fleet card acceptance and stablecoin economics in the same flow.
Operators using USDC or similar tokens should separately assess whether their activities create issuer or other regulatory obligations. Attribution and traceability remain an engineering requirement regardless of how the rules land.
Virtual cards and stablecoin wallets both need a unified ledger to answer basic questions about who spent what, on which rail, under what mandate, and neither one provides it.
Spend ends up fragmented across statements and chains: card captures arrive as a net bank credit at T+1 or T+2, on-chain sends resolve at inclusion, and the two never meet in the source systems.
A rail-agnostic ledger holds a per-agent account that both virtual cards and stablecoin wallets post against, so card holds and on-chain sends land in the same record with the rail preserved on the path.
External statements only ever expose the omnibus account: the bank deposit behind one BIN for virtual cards, and one custody wallet serving many agents for stablecoin wallets.
An allocation of, say, $250,000 to procurement_07 never shows up on the bank file or the chain receipt. Attribution has to live inside the ledger as a posting to a per-agent account, under the same double-entry rules as everything else.
One namespace holds both the USD and USDC balances, so a card hold and an on-chain send post against the same @users:procurement07 path, and the path itself identifies which rail carried each leg.
In Formance Ledger, both legs are expressed in Numscript, Formance's purpose-built language for describing financial transactions. A card authorization hold and a wallet settlement post to the same per-agent path while keeping USD and USDC on their own balances:
// CARD_AUTH: place a $48,500.00 hold against the procurement agent's balance
send [USD/2 4850000] (
source = @users:procurement07:available
destination = @users:procurement07:hold:auth9f2c
)
set_tx_meta("event_type", "card_auth")
set_tx_meta("authorization_id", "auth9f2c")
// WALLET_SETTLEMENT: settle 1,250 USDC from the procurement agent to the merchant
send [USDC/6 1250000000] (
source = @users:procurement07:available
destination = @external:base:merchant4471
)
set_tx_meta("event_type", "wallet_settlement")
set_tx_meta("transfer_id", "trf4471")
Both postings hang off @users:procurement07, so a single agent query returns the card hold and the on-chain send together, and the account path identifies which rail carried each leg.
Virtual cards give AI agents merchant reach and dispute infrastructure, stablecoin wallets give them programmable micropayments and 24/7 settlement, and neither rail records who spent what on its own.
Formance Ledger is the open-source, rail-agnostic layer that sits above both, holds USD and USDC balances on the same per-agent account path, and turns two fragmented feeds into one fleet, one record, whatever the money rides on.