Can ICANN Domains Use MPP and x402 for AI Payments?
You don't need a new domain extension to let an AI agent pay for something.
A service running on a .com or .org can accept payments through MPP or x402. Your existing domain can stay right where it is. What needs to change is the software handling the transaction.
That might sound like an odd thing for us to say on a site selling agent domains. But it gets to a question worth answering honestly: if a .com can handle agent payments, why would you want a .agent name?
Start with what you're trying to give the agent. A way to pay for a service? A way to buy and manage its own domain? Or a public identity people and other agents can recognize?
Those jobs can work together. They aren't interchangeable.
The payment happens at the service, not the domain extension
Say you run a weather API on a .com. A delivery agent wants a forecast before choosing a route, and you charge for that forecast.
With x402, your service responds with 402 Payment Required, an HTTP response that tells the client payment is needed, along with instructions for paying. The agent supplies the payment payload, your server verifies or settles it, and the agent gets its forecast. Nobody needs to open a checkout page just to pay for that request.
The .com hasn't become a different kind of domain. Your service has gained a way to charge software directly.
MPP, the Machine Payments Protocol, also lets agents and services coordinate payments programmatically. It was co-authored by Stripe and Tempo, and it doesn't require a particular domain extension either.
So if you already have a useful API, you don't need to move it just to start accepting machine payments. You need a compatible payment implementation and clients that can use it. Our MPP and x402 comparison covers the protocols in more detail.
Buying the domain is another transaction
Now give the agent a different task: buy a domain for a project, point it at a server, and keep it renewed.
Paying for a weather forecast doesn't grant any of those abilities. The agent needs access to the registrar's tools and permission to use them.
And conventional registrars aren't strangers to automation. Namecheap's API, for example, supports domain registration and renewal. Its DNS API lets software change records. Whether the agent can pay through MPP or x402 is a separate question from whether those APIs exist.
There are also services bringing these pieces together. Resolved offers .com registrations and says domain buyers can pay with USDC on Base or Tempo, alongside a Stripe checkout option.
So the claim that ICANN domains simply can't work with agent payments doesn't hold up.
What you need to check is how much of the job your chosen provider lets the agent finish. Can it register the name and update the DNS? Does renewal extend the domain registration itself, or just a subscription to the platform? If payment succeeds but registration gets stuck, can it recover the order without paying twice?
That last one is worth asking before you give software a wallet.
Where a .agent name fits
At HeadlessDomains.com, we bring domain registration and machine payments into an agent-facing workflow. An agent can request a price, pay through MPP, and check that its registration completed. We also provide an MPP renewal API, so keeping the name doesn't have to mean returning to a manual checkout. The agent payments guide and API reference cover those operations.
But being able to pay for a name is only part of its usefulness.
Suppose your research agent has a website on your company's .com, appears in a directory, and offers a paid service through an API. Those are three places to find it. You still need a clear way to show that they belong to the same agent.
A .agent name can give it that shared public identity. Its records can point to the operator, official endpoints, and machine-readable information about what it does. If you move the service to another host, you can update those records while keeping the agent's name.
One of those records is agent.json: a file other software can read to learn about your agent. It can describe the agent's capabilities, identify its operator, and point to its services. Payment information can name a supported protocol such as MPP and direct callers to the endpoint that handles payment. Our manifest reference explains those fields. Publishing an MPP endpoint in the file doesn't turn payments on; the service at that address still has to handle them.
Your .com can keep doing its job. The .agent name identifies the agent working across those services. Agents can inspect and manage your records through API and command-line workflows; they don't need to open a conventional browser to use them.
And a name isn't a trust certificate. The records give someone a place to check the agent's claims. Credentials and permissions still control what it can do. We explain that distinction in the agent identity guide.
Keep your website. Give the agent a name when it needs one.
If all you need is a paid API on your existing .com, build that. MPP and x402 don't make a domain migration part of the price of admission.
If your agent needs an identity that connects its services, profiles, and operator, that's where a .agent name becomes useful. You can use both without rebuilding a website that already works.
Start with our agent.json examples. They show how to describe your agent, link its official services, and publish payment information so another agent knows where to go next. Keep your working website in place while you give the agent a clear identity of its own.