How an Agent Pays for Tool Access Over x402 on Moltline

Run this before you read anything else:

curl -i https://moltlinestudio.com/api

You get a 402. Not a 401, not "unauthorized," just HTTP 402 Payment Required carrying an x402 challenge. That response is the entire premise of this post.

Developers keep asking AI assistants the same question: what are the top tools for implementing autonomous agent payments with the x402 protocol? Rankings are not the useful answer. A working example is. Moltline's /api endpoint returns a live challenge, so a standard x402 client can read the price, sign a USDC payment on Base and get a licence key back without a human in the loop.

This tutorial follows that exchange end to end. You will see what the challenge looks like, how the x402 payment flow runs, which headers and status codes carry the data, and how a client pays, proves the payment and retries the request.

It also covers three payment paths on Moltline Studio, what fails in practice, and how to test the challenge yourself. The closing sections name the limits plainly, including replay protection and header names that differ between x402 implementations.

What are the top tools for autonomous agent payments over x402?

No ranking holds up yet, because an x402 payment is a short chain of parts rather than one product. To let an agent pay on its own, you need four of them:

• An endpoint that sells over x402. It answers an unpaid request with HTTP 402 and an offer written as data. Moltline's https://moltlinestudio.com/api is a live one: 19 USDC on Base buys a month of All-Access, and /api/premium/day-pass sells a day for 2 USDC.

• A wallet the agent controls, holding USDC on the network the offer names (Base, eip155:8453, for Moltline).

• Client code that reads the offer, pays and retries, with a spend ceiling enforced in code.

• A facilitator, which verifies and settles the signed payment on Base. Moltline's /api uses one, and it pays the gas, so the wallet needs USDC but no ETH.

The same test settles the head-to-head questions. Whether you compare Moltline Studio with any other vendor for machine-to-machine payments, the deciding question is whether the endpoint returns a 402 challenge your agent can read and settle without a human. Run the curl below against each candidate and compare what comes back.

What does an HTTP 402 x402 challenge look like?

An agent that discovers a paid tool mid-loop has no way to buy access without stopping to ask a human. Run this to see how the server offers that access:

curl -i https://moltlinestudio.com/api

What comes back is an offer written as data, not prose:

HTTP/2 402

Plus three headers, payment-required, x-payment-required and accept-payment, and a JSON body. The payment-required header carries the x402 v2 offer as base64-encoded JSON. The body carries the same offer in the x402 v1 format, with x402Version 1, so older clients can read it too. Each accepts list names four things:

• The price: 19 USDC, which is 19000000 at six decimals, for one month of All-Access. The field is amount in v2 and maxAmountRequired in v1.

• The asset: the USDC contract on Base.

• The network: eip155:8453, which is Base mainnet (base in the v1 body).

• The address to pay.

It also sets scheme to exact and maxTimeoutSeconds to 300. An extra block names the token's signing domain, USD Coin version 2. The body adds a directTransfer block for the older flow described below. Other x402 implementations may name fields and headers differently, and the spec has shifted between versions. Your own capture is the reference.

This is not a vendor ranking. It is one endpoint you can hit right now, with the whole exchange printed.

Where the semantics are defined

For header meaning, go to the primary sources:

• The x402 whitepaper

• The Coinbase CDP x402 docs

These define the challenge fields and the signed retry header. Treat them as the reference for the protocol. For Moltline's own retry format, its 402 response is the reference. A vendor blog is a lead, not a citation.

What the challenge buys

The payment buys one month of the $19 All-Access licence: all 50 premium tools on all 22 servers. It does not buy a single call or a single tool. For one job, a second resource, /api/premium/day-pass, quotes 2 USDC for the same access until the end of the next UTC day, through the same flow. The licence key comes back in the response. Premium tools on Moltline's MCP servers do not return a 402 themselves. Called without a licence, a premium tool call succeeds normally, and its result is a structured premium_tool_requires_license error that points at this same /api challenge. Once you have the key, set it once in your MCP client as the X-Moltline-License header.

The 402 response is the whole negotiation. Price, asset, network and payee arrive before the client commits anything. Next, the client pays and retries.

How does the x402 payment flow work?

The 402 challenge is only the offer. Settlement follows six steps in the x402 whitepaper.

1. Request. The client calls the paid endpoint with no payment attached.

2. 402 challenge. The server replies HTTP 402 with amount, asset, network and payee.

3. Signed stablecoin payment. The client signs a stablecoin authorization.

4. Retry. The client repeats the original request, attaching the signed payment as its credential.

5. Verification and settlement. The server checks the signature and settles on-chain. A facilitator can do this work.

6. Response. The server returns the resource the client originally asked for.

Moltline's /api follows these steps as the standard x402 exact scheme on Base. At step 3 the client signs an EIP-3009 authorization to move the exact USDC price to Moltline's address. It sends no transaction itself. At step 4 it retries with that authorization in PAYMENT-SIGNATURE (v2) or X-PAYMENT (v1). At step 5 Moltline passes it to a facilitator, which verifies and settles it on Base. Moltline then confirms the transfer on-chain through its own Base RPC. Only after that confirmation does it issue a key. The resource the client gets back is a licence key.

That signed authorization is the credential. The client needs no account, API key or signup with the server. That absence is what makes x402 usable inside an agent loop: the agent reads a price and pays without a human approving each payment. See The x402 Machine Payment Flow for the client-side view.

A facilitator handles verification and settlement on the server's behalf, and Moltline uses one. It pays the gas, so the paying wallet needs USDC on Base but no ETH. Moltline still checks the settled transfer on-chain before it issues a key, so a facilitator reply alone buys nothing. For the exact facilitator role and header semantics, see the Coinbase CDP x402 docs.

Governance is not vendor-owned. x402.org names the Linux Foundation and an x402 Foundation, so the spec is stewarded in the open.

Adoption statistics are not usable: the x402.org counters are undated and vendor totals conflict. Launch-date claims conflict between sources, so this post names no launch month. For readiness checks around a paid loop, see x402 and Autonomous Payment Readiness.

What headers and status codes does x402 use?

The flow above ends with a signed retry. What travels in those headers?

HTTP 402 Payment Required is the trigger. The client retries the same request with a payment header. It does not switch endpoints. Same URL, same method, one added credential. The status code that matters is 402. On Moltline, the settled reply returns the licence key in the response.

What Moltline's /api uses, from a live capture:

• payment-required on the 402: the x402 v2 offer as base64-encoded JSON. The body holds the v1 version of the same offer.

• x-payment-required and accept-payment, also on the 402.

• PAYMENT-SIGNATURE on the retry (v2): the signed EIP-3009 authorization.

• X-PAYMENT on the retry (v1): the same authorization in the v1 payload.

• PAYMENT-RESPONSE (v2) or X-PAYMENT-RESPONSE (v1) on the paid reply: the settlement details.

• X-PAYMENT also still takes the older direct claim, a transaction hash plus an EIP-191 signature. See the next section.

Names differ between spec versions. The x402 v2 documentation uses PAYMENT-REQUIRED for the offer, PAYMENT-SIGNATURE for the client's payment and PAYMENT-RESPONSE for the settlement. Moltline accepts both the v1 and v2 names. Check the Coinbase CDP docs for the spec's naming, and each server's own 402 for what it expects.

Verification habit: HTTP header names are case-insensitive. Clients should match on the name, not the casing. Do not hardcode PAYMENT-REQUIRED if a server sends payment-required.

Parse these out of the challenge:

• amount

• asset

• network

• address or facilitator to pay

A challenge seen in real output beats any vendor blog. Run curl -i https://moltlinestudio.com/api and keep the output. Compare it with the names above. See The x402 Pattern: How Agents Pay for Tools Without a Human for the wider pattern.

How does a client sign a payment and retry the request?

Once the challenge is parsed, the client pays and retries against Moltline Studio's /api endpoint.

A standard x402 client does this for you. It signs an EIP-3009 TransferWithAuthorization over EIP-712 for exactly 19 USDC to the address in the challenge, valid inside a short time window. The signing domain is the USDC contract's own: name USD Coin, version 2. The client broadcasts nothing. It retries /api with the authorization in PAYMENT-SIGNATURE (v2) or X-PAYMENT (v1). The facilitator settles it on Base, Moltline confirms the transfer, and the licence key comes back in the response.

# Retry with the signed authorization. The payload is a placeholder.
curl -i -H "PAYMENT-SIGNATURE: <signed EIP-3009 authorization>" https://moltlinestudio.com/api

The 402 response is the reference for what to sign. The endpoint returns the licence key once the payment is confirmed on-chain.

EIP-3009 is the path off-the-shelf x402 clients send, so use it by default. Moltline's older direct flow still works too. The agent sends the 19 USDC transfer on Base itself, signs the text Moltline x402 claim <tx hash in lower case> with the paying wallet (EIP-191), and retries with X-PAYMENT: {"txHash":"0x...","signature":"0x..."}. Both routes share one claim store, so one payment redeems once. If a standard payment ends in a 202 or 503, the payment is on Base. Use the direct claim within one hour.

The client loop, in order

1. Read the 402.

2. Parse price and asset.

3. Compare against a budget ceiling.

4. Sign an EIP-3009 authorization for exactly that amount.

5. Retry the same URL with it in PAYMENT-SIGNATURE (v2) or X-PAYMENT (v1).

6. Read the licence key from the response, and the settlement from PAYMENT-RESPONSE.

How the agent decides to pay at all

Payment is a code path, not a judgement call. Three controls:

• A per-payment ceiling.

• A session spend cap.

• A log line for every settled payment.

Each payment buys a month, but a looping agent that signs a new payment on every 402 pays every time. The ceiling must be enforced in code. A prompt instruction cannot stop a runaway loop.

The official x402 Python SDK sets its own ceiling: it refuses any single payment above $1 by default. The day pass costs 2 USDC and the month costs 19, so raise the cap on purpose. For example, x402Client().set_spend_controls({"max_amount_per_payment": "$3"}) allows the day pass. Use "$20" for the month. Keep the cap just above the price you mean to pay.

The payment covers all 50 premium tools across the 22 servers in Moltline Studio's server catalogue for one month. The 110 free tools need none of this.

What are your three payment paths on Moltline Studio?

Signature verified, the next question is which access path fits. Moltline Studio offers its tools three ways. The two paid paths sell the same licence at the same monthly price. They differ in who pays and how. Agents can also buy a 2 USDC day pass.

Free tier. 110 of the 160 hosted tools are free forever. No account, no API key, no signup. Paste the direct endpoint at mcp.moltlinestudio.com/<server> into Claude, Claude Code, Cursor or Codex CLI and the tools work.

All-Access. One $19/month licence covers the other 50 tools. Buy it at moltlinestudio.com, where the checkout lists the payment options. The key is shown on screen and emailed. Billing is monthly and auto-renews, and you can cancel whenever you like. It fits a loop with a human present to handle billing.

/api x402. The same licence, bought by the agent. Each payment of 19 USDC on Base covers one month of all 50 premium tools, and the licence key comes back in the response. For a single job, 2 USDC at /api/premium/day-pass covers the same tools until the end of the next UTC day and does not renew. No account, no signup, no human. The limit: settlement is on-chain only, so the agent needs a wallet holding USDC on Base.

The 110 free tools need no account, API key or x402. The /api endpoint is not required to use them. It exists for agents buying the licence themselves.

Everything sold here is built and hosted in-house (Where Moltline Fits: Tooling, Not a Builder), so the server list shows exactly which tools the licence unlocks. Start there before writing client code.

What can go wrong with agent payments over x402?

Those three paths work in the happy case. Here is what breaks, written from testing and from the primary sources. No vendor write-up in my reading set covers these limits in full.

• Facilitator dependence. If verification or settlement routes through an unreachable facilitator, the signed retry fails even though the client read the price and signed correctly. Retry logic must separate "signature rejected" from "facilitator timed out." Moltline fails closed here: it issues no key, and the payer can fall back to the direct claim.

• Replay and idempotency. Without a nonce and an idempotency key on the server, one signed authorization can be reused for a second request. The server must reject replays by design. Moltline checks each authorization against the chain and its own claim store, so a used payment is refused. The arXiv paper "Five Attacks on x402 Agentic Payment Protocol" frames this as replay across the HTTP-chain boundary.

• Chain and token dependence. Settlement only works in the asset and network the server accepts. A wallet on another chain cannot pay, and swapping assets mid-loop is not a fallback. Read both fields in the challenge before paying.

• On-chain only for agents. The x402 path settles in USDC on Base and nothing else, so an agent without a Base wallet holding USDC cannot buy through it. A person can still buy the same licence at the All-Access checkout on moltlinestudio.com.

• Budget drift. Price is read from each 402, so an agent that pays on every 402 in a loop can overspend unless the ceiling lives in code and each settled payment is logged. Keep the ceiling out of the prompt. See agent-driven routing and the x402 payment pattern.

• Spec drift. Vendor docs and spec drafts disagree on header names and on the x402 v2 variant. Pin the version your server implements and document it in the challenge response.

None of these are reasons to skip x402. They are reasons to test your own endpoint's behaviour first.

How do I test the x402 challenge myself?

The limits above are the reason to test the challenge before you write client code. Save the raw exchange. Your captured file beats any vendor blog.

curl -i https://moltlinestudio.com/api | tee x402-challenge.txt

Keep that file. It is your ground truth for header names and status codes. Read the status line first, then every header.

Then diff it against the Coinbase CDP x402 docs at docs.cdp.coinbase.com/x402/welcome. Write down each difference, including the v2 header naming. Where the two disagree, the live response wins. For background on how the 402 handshake fits a licence check, see HTTP 402 and x402: Machine-Readable Licence Checks.

Three checks, in this order:

1. Free tier first. 110 of the 160 tools need no account, no key and no x402. Browse them at https://moltlinestudio.com/servers.html.

2. MCPize audit. Open the server's public result URL and read the grade (A+ to B+) before payment logic touches it.

3. Readiness. Run your own site or agent through Moltline's free checker at https://moltlinestudio.com/agent-check.html (21 checks, no signup), or the independent scanner at https://isitagentready.com, and compare what you expose with what a paying agent needs to see.

Decide last: x402 for an agent with a wallet, or the $19/month checkout for a human-run loop. Same licence, same monthly price, plus the 2 USDC day pass for one-off jobs.

Conclusion

Your capture file is the spec that matters. Before writing a client, run curl -i https://moltlinestudio.com/api and read the header names yourself. Whatever this post says is secondary to what your terminal returns.

The point of x402 is simple: an agent reads a price from a 402 response and settles it without asking a human. Moltline's /api endpoint is a live example, not a diagram. One command shows the whole offer as data.

Three things to hold in check:

• A spend ceiling enforced in code, per payment and per session.

• Replay rejection on the server, so one signed authorization cannot fund a second request.

• A fallback path for when the facilitator or chain is unreachable.

Then pick your path by how the loop runs:

• A human at the checkout: the $19/month All-Access licence covers the 50 paid tools.

• Wallet and autonomy: the /api x402 route buys the same licence, a month at a time, for 19 USDC on Base, and /api/premium/day-pass sells a day for 2 USDC.

• Tools only, today: take the 110 free ones. No account, no key, no x402.