How to pay for APIs with x402 using MetaMask Agent Wallet: 8 tips

When an API, data feed, or MCP tool answers your agent with 402 Payment Required, MetaMask Agent Wallet can pay it in USDC with no signup or API key involved. The agent reads the server's offer, shows you the asset, amount, network, and recipient, and signs a one-time payment authorization after you approve. The private key stays in the wallet. The signing request also goes through the wallet service's threat scanning. 

Disclaimer: This guide is for educational purposes only. It is not financial advice, not a solicitation, and not for UK audiences. Crypto payments made by AI agents are risky and not suitable for all users.

This is an operational guide for paying with x402 through Agent Wallet. For what x402 is, how the 402 handshake works, and who governs the protocol, see what is x402. Developers building delegation-based x402 payments into their own apps should start with the Smart Accounts Kit x402 guides instead. If Agent Wallet isn't set up yet, start with the quickstart.

Why agents pay per call instead of holding API keys

A paid API usually means an account and a long-lived API key. For an AI agent, that key has to live somewhere the agent can read it, which makes it a target. In research published February 5, 2026, Snyk scanned 3,984 skills on the ClawHub marketplace and found 283 skills (about 7.1%) that pushed API keys, passwords, or card numbers through the model's context window or into plaintext memory files, where a prompt injection can pull them back out.

x402 removes the standing secret. The agent pays per request with a signed authorization for an exact amount to a specific recipient, valid for a short window. With Agent Wallet, that signature comes from the wallet service through mm wallet sign-typed-data, so the agent never handles a private key or an API key. Each authorization carries a random nonce, so it can't settle twice. A broader look at what x402 changes for agent commerce, including agents that sell services to other agents, is coming in a follow-up piece.

The x402 surface, broken down

x402 support ships as a Python helper script inside the metamask-agent-wallet skill, not as an mm subcommand. Your agent calls it when a request returns 402. You normally just ask in plain language ("Fetch the premium data from this URL and pay if it returns 402"), and the agent runs these steps for you.

The full reference is in the x402 payments guide and the skill's x402 reference.

With that flow in mind, here are 9 tips for running x402 payments through Agent Wallet.

1. Fund USDC on the network the service asks for

The server decides which assets and networks it accepts. The agent can only pay an option the server offers. 

Agent Wallet pays EVM offers only, on networks that mm chains list includes. Balances are per chain, so USDC on Ethereum won't cover an offer on Base.  If you have funds in USDC on another chain, you can also ask the agent to move funds to the required chain. The payment itself is a gasless, offchain authorization. The service's facilitator settles it onchain, so your wallet doesn't need native tokens to cover network fees for the payment.

2. Inspect the offer before paying

inspect reads the 402 without signing or spending. It returns the asset, a human-readable amount, the network, the payTo recipient, and the resource. The skill tells the agent to show you those details and wait for your approval before it runs pay, and pay refuses to run without --confirm.

A few checks run before anything is signed. The resource URL must be https://. The script doesn't follow redirects, so a cross-host redirect can't divert a payment to a server you didn't choose. The amount must be a positive whole number of the token's smallest unit, and the recipient and asset must be valid addresses. For the exact scheme, the signed amount equals the offered amount. It isn't a ceiling the server can charge up to.

3. Set a confirmation for every payment as the default

The Agent Wallet skill can instruct the agent to confirm the asset, amount, network, recipient, and resource with you by default before each x402 payment. The confirmation happens in your conversation with the agent. It's separate from 2FA, which the wallet service triggers only when a request is flagged or falls outside your policy.

That fits an agent that buys a research report, a few data pulls, or a gift card in a session. It's a poor fit for a loop that calls a paid endpoint every few seconds, because each call waits on you. A multi-step purchase that charges at several steps asks at each one.

4. Know what Guard Mode checks on an x402 payment

In server-wallet mode, every signing request goes to the wallet service, which runs threat scanning before it signs. A flagged request pauses in AWAITING_MFA until you approve it. x402 authorizations carry a short validity window set by the server. If Guard Mode pauses the signature for 2FA and you approve after the window closes, the authorization expires unspent. Have the agent rerun pay, which fetches a fresh 402 and signs new values. Approvals arrive where your sign-in method sends them: an email link for Google or email sign-in, or the notifications menu in MetaMask Mobile for QR sign-in.

The rolling 24-hour outflow limit works differently here. The outflow policy tracks token transfers, swaps, and deposits, and as of October 27, 2026 it states that signatures, such as Permit2, aren't included in the outflow calculation. An x402 authorization is a signature, so the 24-hour limit isn't a reliable cap on x402 spend. The confirmation step relies on the agent following the skill, and the hard ceiling is the token balance in the paying wallet. One way to cap exposure is a separate wallet funded only for paid API calls. mm wallet create and mm wallet select manage multiple wallets.

5. Pick one option when the server offers several

When a 402 lists the same scheme on more than one supported network or asset, the script stops with a "multiple eligible options" error instead of choosing for you. A service that accepts USDC on both Base and Monad can trigger it. Rerun with --network (for example, eip155:8453 for Base) or --asset with the token contract. Tell the agent which network you funded, and it can pass the flag on the first try.

6. Check that the offer is one Agent Wallet can sign

The helper signs the exact scheme with EIP-3009 transferWithAuthorization on EVM networks, for x402 protocol v1 and v2. It returns a clear error and signs nothing when it sees:

If a service offers both Permit2 and EIP-3009 on the same asset, the EIP-3009 option is used. The troubleshooting page lists each error.

7. Don't rerun a payment blindly

The script keeps no record of past payments. The EIP-3009 nonce stops the same signed authorization from settling twice, but each new pay run creates a new payment. If pay returns "payment not accepted," check the settlement output and whether the authorization window expired before trying again. A second run for the same resource is a second charge, and the x402 guide tells callers to guard against repeated calls.

8. Pay for MCP tools and POST endpoints, too

x402 isn't limited to GET requests. Pass --method and --data, and the helper replays the same request body with the payment attached, so a paid POST (an AI chat completion endpoint, for example) works like a paid download.

Paid MCP tools use x402 v2's MCP transport. An unpaid tool call returns an error result carrying the payment challenge. The agent runs mcp-inspect, shows you the offer, runs mcp-sign --confirm after you approve, and retries the tool call with the signed payload in _meta["x402/payment"]. The script signs but doesn't speak MCP, so the agent's own MCP session delivers the retry. If the retry comes back with another challenge, the payment didn't settle, and the agent reports it to you instead of signing again.

What agents buy over x402

One use is paid data: a trading agent can pull signals or research dev before it acts, then hand off to swaps or perps for execution. A few services that accept x402, with details from their own documentation as of October 27, 2026:

Each service sets its own offer format, so have the agent run inspect first to confirm the offer is one Agent Wallet can sign (tip 6). Nansen's x402 endpoints, for example, take POST requests and accept x402 v2 only. An example request: "Get Nansen's Smart Money net flows for Ethereum. If it returns 402, show me the cost and pay after I confirm." For discovering more x402 services, x402scan is an explorer for the x402 ecosystem.

What Agent Wallet doesn't do for x402

• Cap x402 spend with the outflow limit. The outflow policy excludes signatures from the 24-hour calculation for now.

• Sign every x402 offer. Permit2-only, upto, and non-EVM offers are rejected.

• Deduplicate payments. There's no payment ledger yet. Rerunning pay pays again.

• Sell over x402. The helper is buyer-side only. Hosting a paid endpoint for other agents is a separate setup.

• Run as an mm command. It's a Python 3 script in the skill. It always prints JSON, so --toon and --format don't apply.