Your agent needs a wallet. Seven protocols want to be it.

An agent that needs to pay for something, an API call, a paywalled page, a compute instance, hits problems that simply do not exist for human-initiated payments. Between February and May 2026, the response to those problems went from one duct-taped pattern to at least seven competing protocols, three of them already carrying real production traffic. This is the lay of the land: the fee math that actually decides it, how the cleanest of the protocols works, the regulatory gap nobody has closed, and what we would pick.

Why this is not just payments.

An agent that needs to pay for things hits three problems that don't exist for human-initiated payments. Each one is structural, not incidental, and each one rules out a chunk of the existing payment infrastructure.

1. Unit economics

   Card payments have a floor: roughly 30¢ plus 2.9% on a standard processor, lower at scale but never zero. An agent paying $0.001 for a tool call across a million invocations doesn't have a payment problem, it has a fee problem. The transaction cost is 300 times the transaction. No amount of negotiating processor rates fixes a structural mismatch this large.

   structural · not incidental
2. Authorization

   A human clicks "pay." An agent acts on a standing mandate: the user authorized a scope, a budget, a set of allowed payees, ahead of time. The payment system has to verify that the agent is acting within authority it was actually granted, with no human in the loop at transaction time. This is an identity-and-consent problem that card networks never had to solve before.

   identity · consent
3. Speed and volume

   A human approving every $0.002 API call is not a viable model. Agents transact at machine speed and machine volume, potentially thousands of micropayments per workflow. The settlement layer has to keep up without a human bottleneck and without a per-transaction approval step that would defeat the entire point of autonomy.

   machine scale

The fee problem is the one that quietly determines everything else. It's worth seeing the arithmetic, because it explains why a category that "should" have been solved by Stripe years ago suddenly sprouted seven new protocols.

# An agent makes 1,000,000 tool calls at $0.001 each
transaction_value = 1,000,000 × $0.001 = $1,000

# Settled via card rails (30¢ + 2.9% per txn)
fees = 1,000,000 × ($0.30 + $0.0000290) = $300,029
effective_rate = 30,003%

# Settled via stablecoin micropayment (Base L2, ~$0.0001/txn)
fees = 1,000,000 × $0.0001 = $100
effective_rate = 10%

That gap, $300,029 versus $100 in fees on the same $1,000 of value, is the entire reason the crypto-native protocols exist. Card rails are excellent for a $40 ecommerce purchase and catastrophic for a fraction-of-a-cent machine payment. The category split that follows is downstream of this single fact.

Four layers, seven protocols, one HTTP status code.

The protocols don't all compete on the same axis. They operate at different layers of the stack, and sorting them by layer is the only way to make sense of the field. Crypto-native rails solve the fee problem; card-network frameworks solve the trust-and-identity problem; developer platforms solve the integration problem; and mandate standards try to make them all interoperate.

A few things worth pulling out of that table. x402 is the surprise winner on adoption: it has processed 35M+ transactions on Solana alone, turning the long-reserved HTTP 402 "Payment Required" status code into a working protocol, and Coinbase and Cloudflare co-founded a foundation around it in late 2025. The card networks didn't try to beat the crypto rails on fees. They extended what they're good at (trust, identity, dispute resolution) into the agent context with cryptographic agent credentials. And the mandate layer is a standards war: Google's AP2, now donated to the FIDO Alliance, is the front-runner, with Stripe, Visa, and Mastercard all signing on, while Anthropic pushes a competing approach.

The interoperability story is better than you'd expect from seven protocols. As of April 2026, payment service providers can mint AP2 Mandates that Mastercard accepts as Verifiable Intent. A single agent can, in principle, present one mandate that multiple frameworks honor. Most real agent-commerce flows in 2026 touch two or more of these: a crypto rail for the micropayments, a card framework for the larger purchases, a mandate standard tying the authorization together.

How x402 actually works. It's just HTTP.

The cleanest of the protocols to understand is x402, because it does exactly one thing and does it at the layer engineers already think in. When an agent requests a paid resource, the server responds with HTTP 402 and payment instructions. The agent signs a payment payload, retries the request with an X-PAYMENT header, and receives the resource. No account, no login, no human. The whole cycle settles onchain in seconds.

# 1. Agent requests a paid resource, gets a 402 back
resp = requests.get("https://api.example.com/premium-data")

# HTTP/1.1 402 Payment Required
#   X-Payment-Amount:    0.001
#   X-Payment-Currency:  USDC
#   X-Payment-Recipient: 0x1234...abcd

if resp.status_code == 402:
    # 2. Agent signs a payment payload against its wallet
    payment = agent.wallet.sign_payment(
        amount=resp.headers["X-Payment-Amount"],
        token=resp.headers["X-Payment-Currency"],
        recipient=resp.headers["X-Payment-Recipient"],
    )

    # 3. Retry the SAME request with the payment header
    resp = requests.get("https://api.example.com/premium-data",
        headers={"X-PAYMENT": payment.encode()})

# 4. Server verifies on-chain, returns the data. Done in seconds.
data = resp.json()

The elegance is that it's invisible to the rest of your stack. The payment is a header on a request you were already making. There's no separate billing integration, no webhook reconciliation, no checkout flow. For agent-to-API and agent-to-tool payments, the high-volume, low-value case where card rails fall apart, this is the right shape. The catch is that it requires a funded onchain wallet per agent and exposure to the operational realities of stablecoins, which not every organization wants.

Agent payments are cost tracing with teeth.

If you've been reading these notes, the agent-payment problem should feel familiar. Our note on making cost a first-class metric was about measuring what each agent step spends. Payment protocols are about authorizing and settling that spend in real time. They are two ends of the same pipe.

The cost tracer answered which steps eat the bill. The payment layer answers a sharper version: which steps are authorized to spend money, how much, and to whom. Once an agent is paying for its own tool calls, the spend-rate alert stops being a dashboard metric and becomes a hard authorization boundary. The per-session dollar cap that would have stopped the runaway loop early, instead of nine hours and $3,200 later, is now enforced at the wallet, not just the monitor. A loop can't spend money it was never granted.

This is the architecture worth internalizing: the same guardrails that stop a runaway loop from burning compute are the ones that stop it from burning money. Products like AWS's AgentCore Payments already ship per-transaction caps, daily caps, allowlisted payees, and IAM-integrated permissioning, so a finance team can revoke an agent's spend authority without touching application code. That is the confidence budget, denominated in dollars and enforced by the rail.

The law hasn't caught up. Build accordingly.

The card networks have shipped the technical mechanism for agent transactions. The regulators have not shipped the legal framework. This gap is real, it's current, and it's the thing most likely to bite an operator who ships an agent-payments integration without thinking about it.

The practical guidance from legal analysis: treat agent transactions as merchant-initiated transactions where the consumer mandate clearly covers the scope, document the mandate-setup authentication carefully, and monitor the regulatory text as it evolves. In other words, operators building agent-payment integrations today are working in the gap between what the card networks have shipped and what the regulators have addressed. That gap is closing, but it's open right now.

What we'd actually pick.

There's no single winner, because the protocols solve different problems. The right answer is a function of what your agent is paying for and who you are. Here's the decision tree we'd actually use.

If we had to commit today, three picks, by job:

1. Micropayments: x402

   The only one whose economics actually work for the high-volume tool-call case. It has real production traffic, and it's HTTP-native, so it doesn't pollute your agent logic. Accept the operational cost of running funded wallets.

   the high-volume case
2. Commerce: card-network frameworks, settled via Stripe MPP

   When the agent is buying real things, you want dispute resolution and merchant trust, the things card networks are genuinely good at. Don't reinvent those on crypto rails.

   real-world purchases
3. Authorization: AP2 mandates, whatever the settlement

   The mandate layer is where lock-in will hurt most. Adopting the vendor-neutral standard now is cheap insurance against being trapped in one network's consent model later.

   the long game

The meta-point: agent payments are not a single decision. A production agent in 2026 will likely use a crypto rail for tool-call micropayments, a card framework for any real-world commerce, and a mandate standard tying the authorization together, the whole thing instrumented by the cost trace and bounded by spend caps that double as loop protection. The category moves fast enough that any specific recommendation has a short half-life. The structural reasoning (fees, authorization, speed) is what will still be true in a year.

If you want a second read on which rail fits the payments your agents are about to start making, the contact form is the fastest way in. We do 30-minute reviews for production agent stacks, free.