x402 vs AP2 vs send21: three ways AI agents handle payments

Disclosure: this is written by the team behind send21, one of the three approaches below. We have tried to describe the other two from their own documentation, and we link to it so you can check.

"How does an AI agent pay?" has at least three different answers right now, and they are not really competitors. They answer different questions: who holds the money, who authorizes the payment, and what kind of thing is being paid for.

x402: the agent pays for a request

x402 is an open standard for internet-native payments built on the HTTP status code 402 Payment Required. It was started by Coinbase, and the x402 site now announces an x402 Foundation at the Linux Foundation. The reference code is on GitHub.

The flow, from the spec's README:

1. A client (for example an agent) requests a resource.
2. The server answers 402 Payment Required with a PAYMENT-REQUIRED header listing what it accepts.
3. The client picks an option, builds a signed payment payload and repeats the request with a PAYMENT-SIGNATURE header.
4. The server verifies the payment, locally or through a facilitator's /verify endpoint, serves the response, and settles the payment on-chain, itself or through the facilitator's /settle endpoint.

On the server it can be one piece of middleware per route. x402 describes itself as network, token and currency agnostic: there are SDKs for EVM chains, Solana and several others, stablecoins are the main use, and fiat networks may be added. There are no protocol fees beyond network fees. Its principles say a facilitator or server must never be able to move funds other than as the client intended.

Where it fits: pay-per-call APIs, paywalled content and data, machine-to-machine payments where a human signing each request would make no sense. The trade-off is that the client needs a key that can sign payments, which in practice means a funded wallet, and spending limits are something the agent's owner sets up around it.

AP2: the agent buys with your mandate

AP2, the Agent Payments Protocol, is an open protocol published by Google under the Apache 2.0 license (GitHub). It is available as an extension for the Agent2Agent (A2A) protocol and the Universal Commerce Protocol, and the AP2 site says standardization continues in FIDO Alliance working groups.

AP2 starts from a different problem. Payment systems assume a person clicks "buy". When an agent does it, the merchant and the payment side need to know that the user really authorized this purchase, and who is accountable if it goes wrong.

Its answer is verifiable digital credentials called mandates:

• A Checkout Mandate captures the items and purchase details agreed between the agent and the merchant, and is shared with the merchant.
• A Payment Mandate authorizes a payment against a specific payment instrument, and is shared with the credential provider, the networks and the merchant's payment side.

Each comes in an open form (the user's constraints, such as a budget, for an agent acting on its own) and a closed form (authorization for one finalized checkout and amount). Chained together they give an audit trail for both human-present and human-not-present purchases.

The first version supports "pull" payment methods like credit and debit cards. E-wallets, real-time bank transfers and digital currencies are on its roadmap. The AP2 samples already include a human-not-present flow that pays with x402, which shows the two can work together.

Where it fits: agents shopping at merchants on a user's behalf, inside existing card networks, where verifiable intent and accountability matter more than speed.

send21: the agent prepares, someone else signs

send21 (our project) takes a third route: the agent never holds money and cannot pay. It creates a crypto pay link or payment draft through the MCP server or the REST API, using a scoped key that cannot move funds. The payment is then signed in a wallet the agent does not control: the payer's own wallet, or the operator's.

The agent can track the payment and react to an HMAC-signed webhook when it confirms. send21 retries failed deliveries, so the same delivery can arrive more than once, and the receiver should key on the delivery id. On new accounts, API keys can only use receiving addresses the owner approved in the app with a passkey or an authenticator code. An agent can propose an address; it cannot approve one.

Payers can use BTC (on-chain or Lightning), USDC, USDT (on Solana and Ethereum), EURC, SOL or ETH. send21 never holds keys or funds, and it does not implement x402 or AP2 today.

Where it fits: agents that bill people (invoices, checkouts, pay links), agents that hit their budget and hand a purchase to a human with a link to pay, and teams that do not want an agent holding a funded wallet. It is a poor fit for paying per API call: nobody wants to sign a transaction for every request.

Side by side

How to choose

Start from the question you actually have:

• Is your agent the customer of an API or a data source? x402 is built for that. Put a budget around the wallet it uses.
• Is your agent shopping at merchants for a user, with cards? AP2 is designed for that, with mandates that make the user's intent checkable.
• Is your agent the one asking for money, or does it need a person to decide? That is where send21 fits: the agent prepares the payment, and the money moves only when someone signs.

Many agents will end up using more than one. A research agent might pay for data with x402, book a flight under an AP2 mandate, and send its customer an invoice through send21.

The protocols are moving quickly, so check the primary sources before you build: x402.org, ap2-protocol.org, and for send21 the docs and the testnet demo.

Our own summary page with the same comparison: x402, AP2 and send21: AI agent payments explained. Corrections are welcome at [email protected].