How we evaluate

Accepting payment from an AI agent is judged on what you are charging for and how the agent pays you. The criteria that matter:

• Per-call versus one-off. Are you charging per use of a service, or receiving a single payment?
• Server shape. Do you run a standard Fastify or Express service, or something non-standard that needs custom handling?
• Who pays. Agents you do not know in advance, or known counterparties?
• Setup effort. How much do you build to start receiving, and how much do you maintain?
• Confirmation. Can you durably confirm and attribute each payment that arrives?
• Distribution. Does the method also help paying agents find you, or only collect?

No method is best for every case, so start by naming what you are charging for.

Per-call service or a single payment?

Before choosing a method, decide whether you are charging per call for a service or receiving a single payment. If agents consume a service you offer and should pay per use, you gate the service endpoint so each call settles, which is what the x402 adapter does. If you are receiving a one-off, a payout, a sponsorship, a single agreed amount, you do not need to gate a service at all; a payment link or a direct transfer fits.

That distinction resolves most of the choice. Per-call revenue from a service points to the adapter or, for non-standard servers, the lower-level x402 path. A single inbound payment points to a link or a transfer. And either can be amplified by listing where paying agents find you. Fix what you are charging for, and the method follows.

The five realistic ways

In 2026 the realistic ways to accept payment from an agent are the x402 server adapter, lower-level x402, a payment link, a direct wallet, and marketplace collection. They map onto the per-call versus one-off distinction above.

Way 1: The x402 server adapter

The standard way to accept per-call payment is the x402 server adapter. You register createX402Plugin (Fastify) or createX402Middleware (Express) in front of your service route with per-route pricing; an unpaid call gets a 402, the agent's client settles in USDC on Base, and the adapter verifies it through settle before your handler runs.

It fits best when agents consume a service you offer and should pay per use, including agents you do not know in advance, since there is no signup. It needs a standard Node server and the route on an HTTP transport. Choose it for almost all per-call revenue from agents; pair it with the payment.received webhook to confirm and attribute, and see how-to-add-payments-to-mcp-server for a worked receive-side example.

Way 2: Lower-level x402

If your server is non-standard or you want control over the flow, handle x402 yourself with the wire helpers. You return the 402 and read the payment header using parse402Response, buildPaymentHeader, and parsePaymentHeader, and verify by calling settle on the payment request directly, doing by hand what the adapter does for you.

It fits best when an adapter does not fit your server or you need custom behavior in the flow. The cost is that you own more of the handling, so most teams use the adapter and reach for this only when they must. Choose it when you need the protocol directly rather than the convenience layer, and keep the verification through settle exactly as the adapter would.

Way 3: A payment link

To receive a one-off payment without gating a service, use your agent's payment link, its public profile URL on Blockchain0x, which can receive USDC. An agent or a person sends a single amount, no per-call wiring needed.

It fits best for one-off inbound payments, a payout, a sponsorship, a single agreed transfer, rather than charging per use. It will not meter usage or verify per call, so it complements the adapter rather than replacing it. Choose it when the payment is a single act rather than ongoing per-call revenue, and keep the adapter for the metered side.

Way 4: A direct wallet

If a known counterparty pays you a specific amount, publishing your agent's wallet to receive a direct transfer works. The paying agent sends USDC straight to it.

It fits best for a known, agreed inbound transfer from a counterparty you already deal with, outside the context of a per-call service. It carries little context on its own, so record what the payment was for, and the payment.received webhook still gives you the durable record. Choose a direct receive for a specific agreed amount from a known payer, and use the adapter or a link for everything routine.

Way 5: Marketplace collection

Listing your service or agent on a marketplace that handles billing lets the platform collect payment from agents on your behalf, while bringing discovery. Its strength is reach: paying agents find you there.

It fits best as a distribution layer paired with a direct receive method, not as your only path. The trade is a platform dependency and a cut of revenue, and sometimes less control over pricing and the relationship. Use it to get discovered and collect where the platform handles it, while keeping your own x402 endpoint for agents that come to you directly.

No signup is the real advantage

The reason per-call x402 fits agents so well is worth stating on its own: a paying agent never signs up. With a traditional billing model, a buyer creates an account, enters a card, and agrees to terms, none of which an autonomous agent you have never met can do. With x402, the agent simply calls your endpoint, gets a 402, settles, and proceeds, so a counterparty you did not onboard can pay you on first contact.

That is what makes accepting payment from arbitrary agents possible at all. Your reachable buyers are no longer just the ones who completed a signup funnel; they are every capable agent that can find your endpoint and afford the price. For a service meant to be consumed by machines across the open web, removing signup is not a convenience, it is the thing that opens up the audience, which is why the adapter is the default rather than a billing account model bolted onto agents.

Summary comparison

How to pick

Name what you are charging for and the method follows. For per-call revenue from a service, choose the x402 server adapter, which is the low-effort standard, or the lower-level x402 path if your server is non-standard. For a single inbound payment, choose a payment link, or a direct wallet for a known agreed transfer. And whatever your primary method, a marketplace can add discovery.

For the common case, accepting per-call payment from agents for a service, the x402 server adapter is the answer, because it lets agents you have never met pay you per use with no signup, verified before your handler runs. Confirm each payment with the payment.received webhook. To put this in context, read how-to-monetize-ai-agent, and for a worked receive-side build see how-to-add-payments-to-mcp-server. Pricing is on the pricing page.