x402 and MPP, explained by building a service that takes both.

We built a service that AI agents pay to publish HTML, and we wired it for both standards at once. Building it was the fastest way to actually understand them, so this is a plain-English explainer with a working example underneath, and then the design pattern we have not seen written down anywhere: the handoff from an anonymous agent payment to a resource someone owns and manages.

What x402 actually is

x402 takes the HTTP status code that has sat unused for thirty years, 402 Payment Required, and gives it a real meaning. The loop is four beats. The agent makes a request with no credentials. The server replies 402 with machine-readable terms: the amount, the asset, the network, and the wallet to pay. The agent signs an authorization for that exact transfer and retries with the signed header. A facilitator verifies the signature against the token contract and settles the transfer on-chain, then the server returns the resource.

Two details make it practical for agents specifically. First, the agent only signs; it does not broadcast. On Base and other EVM chains the authorization is an EIP-3009 TransferWithAuthorization, which is gasless for the payer, so the facilitator pays the gas and the agent needs no native token at all, only the stablecoin it is spending. Second, there is no account. The signature is the identity for that one call, which is exactly right for software that has no human to sign up. x402 settles on Base and Solana today, in USDC.

What MPP is, and how it relates

MPP, the Merchant Payments Protocol, is the agent-payment standard Stripe and Tempo are building. It answers the same gap, software paying a merchant per request, and it is best understood as a sibling to x402 rather than a rival. The difference is what is underneath: MPP supports more than one method. There is a card method that runs through a Stripe account, and an onchain method that settles directly on Tempo, a payments-focused blockchain.

So the honest framing is not crypto versus cards. It is one job, two standards, several settlement options. x402 settles on Base or Solana. MPP settles its onchain method on Tempo. The onchain methods share a useful property: they are permissionless. To accept one you need a receiving wallet and a public RPC, with no account to apply for and no regional gate, which is why a small team anywhere can take agent payments without onboarding into anything. We decided not to choose, and to accept all three rails on one endpoint, because agents do not all hold the same asset on the same chain.

Building a service that takes both

The endpoint is a payment front-door at agents.stacktr.ee. An agent posts the HTML it wants hosted and gets back a 402; it pays fifty cents over x402 on Base, x402 on Solana, or MPP on Tempo; on settlement the page is published to a private link and the URL comes back. The discovery half matters too: it is listed on x402scan and mppscan, the directories agents use to find paid resources, so an agent can find it and pay it without being told it exists.

The piece that saved us the most time was agentcash, the open router from Merit Systems. Rather than hand-rolling x402 verification, MPP settlement, and the discovery document for each rail, the router handles the protocol mechanics and we configure which rails are on. A couple of build notes for anyone doing the same. The router is coupled to Next at runtime, so on Cloudflare we run it as a Next app through OpenNext rather than as a plain Worker. And when the front-door hands the paid request to our main API, the two Workers live on the same domain, so they talk over a service binding rather than the public hostname, which avoids a same-zone routing dead end. Those two choices are most of the integration.

The interesting part: a payment that becomes a managed resource

Here is the pattern we think is genuinely new, and the reason any of this is more than a clever way to take crypto. An anonymous, pay-per-call agent is frictionless, but it leaves orphans: a live page that nobody owns and nobody can change. The question every agent-payable service eventually hits is how you get from "an agent did a thing and paid" to "someone can now manage that thing," without bolting a signup onto the front of the frictionless flow.

Our answer is to let the payment carry the identity. The wallet that paid is recorded with the page, so it is both the receipt and a claim ticket. From there the resource can move into management along two different surfaces, for two different actors:

• Into the interface, for a human. A person signs into the dashboard, generates a short link code, and hands it to their agent. The agent signs the code with the wallet it pays from, the wallet links to the account, and every page that wallet has published, plus everything it publishes next, appears in the dashboard to manage visually. The human never touches a signature; the agent, which holds the wallet, does the proving.
• Into the MCP, for the agent. The same link runs through a tool call. The agent calls link_wallet with the code, signs, and from then on it manages its own work programmatically through the rest of the MCP server: read a page back, edit and replace it in place, set a password, or delete it. No human and no dashboard required.

That is the shape worth copying: a single lifecycle that starts as a pure, anonymous, pay-per-action agent and then forks cleanly into either a human-facing interface or an agent-facing MCP, with the paying wallet as the bridge between the two. The agent does the work and pays for it; ownership and management are a later, optional step that either the human or the agent can take, on whichever surface suits them. The payment is not the end of the interaction. It is the thing that makes the rest of it ownable.

What is live

All three rails are live on the endpoint today: x402 on Base, x402 on Solana, and MPP on Tempo, settling real stablecoin on mainnet, with the receipts landing in our wallet. An agent paid fifty cents over x402 on Base to publish a page, and that settlement is a USDC transfer on BaseScan you can verify. The claim-and-manage handoff is live too, on both the dashboard and the MCP. If you build agent products, the standards are worth learning, but the part to sit with is the lifecycle: your next user may pay you as an anonymous agent and want to manage the result as a human later, or never become human at all. It helps to be ready for both.