learn · the money mechanics
Where does the money come from — and how does it move?
When an AI agent buys something, real money moves. This page follows the money: where it sits, how it travels, what limits it, and what happens when a payment must be undone.
Part of the Learn path. Every term links to the glossary the first time it appears.
What kind of money do agents use?
Two kinds. Some agents pay with card money: a charging credential on the card networks, scoped to that one agent. Others pay with digital dollars called stablecoins, moved directly between machines on a public ledger. Those are the two families of payment rails — and both are in real use today.
How do card rails work?
A card rail gives an agent its own way to charge, instead of borrowing a person's card. Often that is a virtual card: a card number that exists only in software, with its own spending cap, sometimes valid for a single purchase. The money then moves the way card money always moves. The card networks' dispute machinery, including the chargeback, comes attached.
Two of the rails this site covers live in this family. Stripe machine payments give an agent scoped payment credentials on Stripe's rails. Verifiable Intent & Agent Pay, Mastercard's pairing, add a provable record of what the buyer authorized to agent-initiated card payments.
How do stablecoin rails work?
A stablecoin rail skips the card networks. The agent holds digital dollars in a wallet its owner controls, and pays by transferring them on a public ledger. Because the ledger is public, anyone can inspect the payment afterward — it is on-chain.
The rail this site covers in this family is x402. As of 2026-09-01, x402 payments settle in USDC — a dollar stablecoin issued by Circle — on the Base network. The next section walks through how.
One more protocol pair sits above both families. AP2 & UCP, both Google-backed, govern permission and the shopping flow rather than moving money themselves. AP2 defines the mandate: signed, standing permission for what an agent may buy. UCP covers the discovery, offers, and checkout around it. They ride above rails; they are not a third kind of money.
That is the whole cast. This site covers the four as peers, always in one alphabetical order: AP2 & UCP · Stripe machine payments · Verifiable Intent & Agent Pay · x402. Read the four protocol pages for rail-by-rail specifics.
Why does an old web error code matter?
An old web status code — 402, “Payment Required” — matters because it gives machines a standard way to ask each other for payment. The HTTP standard has reserved 402 for future use since the 1990s, and still reserves it today. The x402 protocol puts it to work: a service can answer any request with “pay first, then ask again.”
The flow has four steps:
- The agent asks a service for what it needs.
- The service answers 402: payment required — this amount, to this place.
- The agent pays, then asks again with proof of payment attached.
- The service delivers, and a receipt exists.
Here it is with numbers on it. OTTO, our example agent, is an invoicing agent that buys OCR — text pulled out of scanned pages — at $0.01 per page. (OTTO is invented for teaching; its prices describe nothing but OTTO.)
OTTO asks the OCR service to read one page. The answer comes back 402: one cent, in USDC, to this address. OTTO's wallet signs the one-cent transfer, and OTTO asks again with the proof attached; the page comes back, read. No human watched any of it — a machine-to-machine payment.
One practical piece hides in step three. Most sellers use a facilitator — a payment processor for the x402 world — to check the payment and confirm settlement, so they never touch the ledger directly.
Card rails skip the 402 exchange entirely. A charge on an agent-scoped card flows like any other card charge — familiar plumbing, no new status codes. Different mechanics, same outcome: service delivered, money moved.
What is a wallet, for an agent?
A wallet is software that can approve payments. For an agent it is the spending hand: it holds a balance, and it signs the payments its operator allows. The operator — the person or company the agent works for — stays in control of it.
Under the hood, a wallet holds secret keys, and the keys make signatures — approvals written in math instead of ink. The money itself lives on the ledger. The wallet holds the authority to move it, the way a checkbook is not the bank account.
Funding is plain: the operator loads a balance, like a prepaid phone. A wallet can never spend more than it holds — that alone is a hard limit.
Card rails have a counterpart for each piece. The agent-scoped credential plays the wallet; the card network's authorization plays the signature; the spending cap plays the balance.
What stops an agent from spending everything?
Limits you set, enforced by machinery rather than by trust. Three control surfaces do the work: the mandate, the spending cap, and the human-in-the-loop checkpoint. Together they work like a company card: purpose agreed in advance, a hard ceiling, and a manager's sign-off above a threshold.
The mandate is the standing permission slip: what the agent may buy, up to what amount. Inside it, the agent acts alone. Outside it, the agent must come back and ask.
The spending cap is the hard ceiling — per purchase, or per period. It holds even when the agent misjudges.
The human-in-the-loop checkpoint puts a person before the payment. The agent prepares the purchase; a human says yes or no.
Where enforcement lives depends on the family. On card rails, the card issuer declines any charge over the cap. On stablecoin rails, the wallet cannot spend what it does not hold, and will not sign outside its rules. AP2 works at this layer across rails: it turns the mandate itself into a signed object that machinery can check.
Why do tiny payments need tiny fees?
Because every payment costs something to process — and when the fee outweighs the payment, the payment stops making sense. The size of the fee sets the size of the smallest sensible purchase. That one fact shapes which rails carry which purchases.
OTTO's $0.01-per-page purchases are micropayments: payments shrunk below what card fees normally allow. They only work where the fee underneath is near zero.
On a public ledger, the fee is the gas fee — the postage on a transaction. Layer-2 networks such as Base are built partly to keep that postage tiny, which is what makes cent-sized payments practical there.
Card rails are built for bigger tickets, and sellers there handle small usage the old way: bundling. Many small uses, one larger charge — the way a phone bill bundles a month of calls. Neither approach is wrong; they fit different purchase sizes.
What happens when a payment must be undone?
It depends on the family — and this is the deepest difference between them. On card rails, undo machinery is built in: the network can reverse a charge through a chargeback, inside a formal dispute process. On stablecoin rails, settlement is final by design: once the ledger records the payment, there is no built-in reversal — a refund is a new payment in the other direction.
| Question | Card rails | Stablecoin rails |
|---|---|---|
| When is a payment final? | Not right away. A cleared charge can still be reversed later. | At settlement — quickly, and then for good. |
| Can it be undone? | Yes. The chargeback exists for exactly this. | No built-in undo. A refund is a new, separate payment. |
| Who referees a dispute? | The card network, through its formal dispute process. | No built-in referee. Any dispute process must be built on top. |
| What the seller lives with | A received payment can be clawed back later. | Payment received is payment kept. |
| What the buyer lives with | Recourse exists when something goes wrong. | Check before paying — there is no undo after. |
Neither column wins, because each protection is also a cost. Finality means a seller keeps what it earns — and a buyer's mistake sticks unless the seller chooses to refund. Reversibility means a buyer has recourse — and every seller lives with the chance of a claw-back. Which fits depends on the purchase.
Keep going
This page covered the machinery the rails share. The rail-by-rail specifics — who backs each protocol, exactly how each flow works, and what is verifiable about each — live on the protocol pages.