2026-11-19

How AI Agents Pay With Stablecoins: x402, MPP and AP2

HTTP has had a status code for payments since the 1990s. 402 Payment Required was reserved for "future use" and then sat unused for almost thirty years. In 2025 and 2026 it started being used, as the way an API tells an AI agent that a request costs money, and how to pay.

Below are the protocols built on it and where Klap fits among them. Up front: Klap doesn't implement x402 or MPP today. If you need an agent to pay per API call, you'll want one of the protocols below, and we'll say why.

The problem they solve

An agent that wants to call a paid API today usually needs an account with that API: sign up, add a card, get a key. That works for a human setting up a tool once. It doesn't work for an agent that finds a new data source halfway through a task and needs one answer from it for a fraction of a cent.

Cards don't fit that either. A card payment has a fixed fee that's larger than the whole price of a cheap request, and it needs a person behind it who can dispute it. A stablecoin transfer can be small, it settles in seconds, and an agent can sign it from its own wallet.

x402

x402 came out of Coinbase in 2025, and in April 2026 the Linux Foundation announced the x402 Foundation to take over the protocol, with Coinbase, Cloudflare and Stripe behind it.

The flow is short:

  1. The agent requests a resource, say GET /forecast?city=lisbon.
  2. The server answers 402 with the price, the token, the network and the address to pay.
  3. The agent signs a USDC payment for that amount and repeats the request with the signed payment in a header.
  4. A facilitator, a service the seller trusts, checks the signature and settles the payment on-chain.
  5. The server returns the forecast.

The seller never creates an account for the agent and the agent never signs up. The facilitator handles the on-chain side, so the API server only has to understand one header. Coinbase runs a facilitator for USDC on Base, and Coinbase Business has accepted x402 payments since July 2026.

MPP

The Machine Payments Protocol was announced by Stripe and Tempo on March 18, 2026, alongside Tempo's mainnet launch. It also uses 402 and the same basic shape: the server asks for payment, the agent pays, the request goes through.

Where it differs is in what's behind it. MPP is written to work across payment rails, not only stablecoins, and it adds sessions, so an agent can open a spending limit with a service and make many small payments without a separate on-chain transaction for each one. For Stripe merchants it plugs into the payment objects they already use, which is a big part of its appeal.

AP2

Google's Agent Payments Protocol launched in September 2025. It doesn't move money. It records what a person authorized an agent to buy.

It does that with mandates, signed records of what the user authorized: buy these items from this merchant, or spend up to this amount on this kind of thing. A merchant receiving a payment from an agent can check the mandate and know there's a real authorization behind it, which matters most when the agent is buying something a person will later want to dispute or return. AP2 doesn't move money itself, and it's designed to sit on top of whichever payment method is used, stablecoins included.

Where Klap fits, and where it doesn't

Klap is built around the charge: one payment, one dedicated address, a payout to the merchant's wallet when it confirms. That shape suits orders and invoices. It's a poor fit for paying per API request. Three limits get in the way:

  • Minimums. A live charge has to be at least $0.10. x402 prices are often a small fraction of a cent.
  • One payment per charge. Every charge gets its own address and its own payout, which suits a $49 order. Doing that for every request an agent makes would be a lot of on-chain work for very little money.
  • Gas per charge. Paying out a charge costs gas, which the payer covers, with a floor of one cent. On a $0.001 request that's ten times the price.

So if you're selling API calls to agents, look at x402 or MPP. Neither needs anything from us.

What does work today is an agent paying a normal Klap charge. Paying a charge is a plain USDC or USDT transfer to an address. There's no wallet connection or browser to deal with, so an agent with its own wallet can pay a checkout the same way a person would. Your backend still gets the same charge.confirmed webhook either way.

The other side is agents working for the merchant. Klap's MCP server lets an assistant like Claude look up charges, check why a payment is stuck or create test charges, with read-only access to live data by default. It doesn't pay anything. It's an agent doing back-office work on the merchant's payments.

What a merchant should do now

If you sell to people, not much changes yet. Agent shopping is early, and the protocols are still settling which one handles what.

If you sell an API or data, it's worth trying x402 on one endpoint. The seller side is small, the facilitator handles settlement, and you'll find out whether agents actually come.

Either way, keep the parts that don't depend on the protocol: price in dollars, settle in a stablecoin you're happy to hold, and treat a payment as confirmed only when your backend has seen it on-chain. If you're choosing between stablecoins for that, USDC vs USDT for merchants has the comparison, and does USDC have gas fees? covers the costs a small payment runs into.