Learn

How AI Agents Pay With USDC: x402, EIP-3009, and Agentic Commerce

AI agents can't fill out a Stripe form. This developer primer walks through agentic payments end-to-end: why stablecoins beat credit cards for autonomous software, how to pick USDC over USDT or PYUSD, how x402 and EIP-3009 actually work, a minimal TypeScript demo on Base, and a production risk ch...

Jason Lee, Tong Zhang

08 May 2026 — 11 min read

AI agents finally have a payment primitive — small denominations, instant settlement, no human-in-the-loop card forms.

Somewhere right now, an AI agent is trying to fetch real-time weather data, query a premium financial API, or buy GPU compute for the next step in its workflow. It hits a paywall. It cannot type a credit card number, it cannot log into a billing portal, it cannot complete a CAPTCHA. It simply stops.

That friction is not a bug in the agent — it is a fundamental mismatch between how the internet charges for things (human-initiated, card-network-mediated, batch-settled) and how autonomous software needs to pay (programmatic, instant, sub-cent). The developer community is now wiring a solution out of three interlocking pieces: stablecoins as the value unit, EIP-3009 as the on-chain authorization primitive, and x402 as the HTTP-layer payment protocol that ties them together. This guide walks you through each layer in enough detail to build with it today.

By the end you will understand why USDC on Base is the pragmatic default for agent payments right now, how the x402 handshake actually works at the header level, what transferWithAuthorization does under the hood, what a minimal agent payment flow looks like end-to-end, and which failure modes you need to engineer around before shipping to production. If you want the broader context on what AI agents are in crypto before diving into payments, start there first.

What Is Agentic Payment — And Why Credit Cards Don't Work

Agentic payment is what happens when the paying party is an autonomous program rather than a human tapping a phone or typing card details. The broader x402 and stablecoin payments landscape is evolving fast, but the structural problem is simple: card rails were engineered around human-scale economics — percentage-plus-fixed interchange fees, T+1 banking-hours settlement windows, and rule engines that assume a verified human cardholder exists on one end of every transaction. Agents demolish each of those assumptions in sequence. They need to execute sub-cent transactions where the fixed-fee floor on a card charge is economically absurd. They run 24/7 across time zones and weekends, where a Sunday-night card authorization can sit in a pending state until Tuesday. And they need deterministic payment logic that can be expressed in code, not in a card-network rule book written for human merchants. The result: you cannot hand an agent a Stripe API key and a credit card number and expect it to work reliably at scale. The agent needs a payment primitive that is as programmable as it is.

x402 let's you make any API call with payment embedded right in the API call itself

No sign up, API key, or credit card required.

AI Agents will need an easier way to pay for data, get through pay walls, and spin up resources.

Is your API x402 enabled? https://t.co/qhBiwhNKxe
— Brian Armstrong (@brian_armstrong) May 6, 2025

USDC vs. USDT vs. PYUSD vs. DAI: Picking a Stablecoin for Agent Payments

Not all stablecoins are interchangeable for automated payment flows. The differences in compliance posture, chain availability, and on-chain transfer mechanics matter significantly when you are writing code that will sign and broadcast transactions autonomously.

USDC is the clear frontrunner for agentic commerce today. Circle has deployed native USDC on 32 blockchain networks as of early 2026, including Ethereum, Arbitrum, Base, Optimism, Polygon, Solana, Avalanche, and Stellar, each connected to Circle's Cross-Chain Transfer Protocol (CCTP). Crucially, USDC v2 natively implements EIP-3009 (transferWithAuthorization), which means an agent can authorize a specific transfer with a single off-chain signature — no ETH required for gas in the hands of the agent itself, because a facilitator submits the transaction. USDC also sits cleanly inside the U.S. GENIUS Act framework and EU MiCA standards, and Circle publishes monthly reserve attestations through independent accounting firms. For a developer building in a regulated context, this audit trail matters.

USDT is the largest stablecoin globally by market cap — USDT and USDC together account for roughly 93% of stablecoin market capitalization — and its liquidity depth on chains like Tron is difficult to match for high-volume, emerging-market flows. But USDT does not implement EIP-3009 on Ethereum. Integrations relying on signed authorizations with USDT typically have to route through Permit2 or the legacy approve/transferFrom two-step, which adds friction and gas overhead. USDT's reserve composition — which has historically included non-T-bill assets — also means that some institutional compliance frameworks restrict or prohibit holding it. For agent developers whose primary corridor is EVM chains with a compliance-conscious operator behind the scenes, USDT is harder to justify as the default.

PYUSD, issued by Paxos Trust Company (NYDFS-regulated) and distributed by PayPal, has a similar compliance profile to USDC — monthly KPMG attestations, reserves in U.S. Treasuries and cash equivalents — and also implements EIP-3009. Its edge is consumer distribution through PayPal and Venmo's 400 million+ accounts. Its weakness for agent developers is coverage: PYUSD is available on Ethereum mainnet and Solana, which is a narrower footprint than USDC's 32-chain deployment. If your agent needs to operate across many L2s, PYUSD's chain availability becomes a constraint.

DAI (now USDS under Sky/MakerDAO) is crypto-collateralized and governed by a DAO, which appeals to builders who want fewer centralized choke points. DAI does not natively implement EIP-3009, and a growing portion of its collateral is USDC itself — creating what critics call a "decentralization paradox." DAI's role in agent payments is mostly relevant when censorship resistance is a design requirement and EVM-only operation is acceptable.

Bottom line for builders: Start with USDC on Base. It gives you native EIP-3009 support, a free facilitator tier (1,000 transactions/month), sub-cent settlement costs, and the compliance posture most enterprise operators will require. When your agent expands to Solana or needs to settle in a PayPal ecosystem, layer in PYUSD. Avoid USDT as a primary payment asset in automated flows until native gasless transfer support improves.

The Protocols: x402, EIP-3009, and Coinbase AgentKit

x402: HTTP 402, Finally Used

The HTTP status code 402 Payment Required has existed in the spec since 1991, reserved for future use. Coinbase shipped that future in May 2025 with the x402 protocol. The core idea is deceptively simple: make payment negotiation a native part of the HTTP request-response cycle, so that any client — human browser or autonomous agent — can discover a price, pay it, and get the resource in a single round trip.

Here is the exact flow, step by step:

Initial request. The agent makes a standard HTTP GET or POST to a resource endpoint — say, GET /api/weather?city=london.
402 response. If the resource requires payment, the server responds with HTTP 402 and a PAYMENT-REQUIRED header containing a base64-encoded PaymentRequired object that describes accepted payment schemes, networks, prices, and the payee address.
Client selects a scheme. The agent reads the payment requirements and picks a PaymentRequirement it can satisfy — for example, exact scheme, $0.001 USDC on Base (chain ID eip155:8453).
Agent signs an authorization. The agent's wallet produces an EIP-3009 transferWithAuthorization signature — an off-chain EIP-712 typed message that authorizes moving exactly the requested USDC amount to the payee. No on-chain transaction has happened yet.
Signed retry. The agent re-sends the original HTTP request, this time with a PAYMENT-SIGNATURE header containing the encoded payment payload.
Server verifies and settles. The resource server (or a facilitator it delegates to) validates the signature — either locally or by POSTing to a facilitator endpoint. If valid, the facilitator submits the on-chain transferWithAuthorization transaction, gas included. Settlement on Base takes roughly 2 seconds.
Resource delivered. The server returns the resource content plus a PAYMENT-RESPONSE header confirming the transaction.

The Coinbase Developer Platform runs a hosted facilitator for this — 1,000 transactions/month free, then $0.001/transaction — supporting Base, Polygon, Arbitrum, World, Ethereum mainnet, and Solana. The protocol is fully open source; you can run your own facilitator if you need more control or want to avoid the Coinbase dependency. Cloudflare's case for x402 and its co-governance of the x402 Foundation mean the ecosystem is not a single-vendor dependency.

EIP-3009: transferWithAuthorization

EIP-3009 is the on-chain primitive that makes x402's gasless flow possible. Before it existed, paying for something with an ERC-20 token required two separate on-chain transactions: first an approve call granting a spender allowance (one gas fee), then a transferFrom call to actually move the tokens (another gas fee). The agent had to hold ETH for both. EIP-3009 collapses this into a single signed message.

The agent signs an EIP-712 typed message containing:

from — the agent's wallet address
to — the payee address
value — the exact USDC amount in base units (6 decimals; $0.001 = 1000)
validAfter — earliest the authorization can be submitted on-chain
validBefore — expiry timestamp
nonce — a random 32-byte value (unlike EIP-2612, which uses sequential nonces)

The resulting v, r, s ECDSA signature travels in the HTTP header. A relayer (the x402 facilitator) submits transferWithAuthorization(from, to, value, validAfter, validBefore, nonce, v, r, s) directly to the USDC contract on-chain, paying gas itself. The agent never touches ETH. The authorization is single-use by design — the nonce cannot be replayed. One important detail: if you are building a contract that calls into USDC from a smart contract context, use receiveWithAuthorization instead of transferWithAuthorization. The receive variant prevents front-running by enforcing that msg.sender equals the payee.

Coinbase AgentKit

AgentKit is Coinbase Developer Platform's toolkit for giving AI agents a crypto wallet and onchain interactions. It is designed to be framework-agnostic — compatible with LangChain, OpenAI Agents SDK, and others — and wallet-agnostic, so you can plug in CDP's managed wallets or bring your own. With AgentKit, the wallet provisioning, key management, and transaction signing are handled by the CDP infrastructure; your agent code interacts through a clean action-provider interface.

AgentKit's Smart Wallet integration enables gasless transactions via CDP's Paymaster, removing the requirement for the agent to hold the network's native token to cover gas fees. This is a critical UX unlock: an agent funded only with USDC can transact on Base without needing a separate ETH balance. AgentKit also supports Solana (SVM) networks alongside all EVM chains, reflecting the multi-chain reality agents operate in. Solana and Google Cloud's pay-per-call experiment shows how this is already being put into practice at infrastructure scale.

How an Agent Pays for an API Call on Base — End to End

Here is the end-to-end flow of an agent that detects a 402 response and pays for it with USDC on Base using the official @x402/fetch client package and a Coinbase CDP wallet. This reflects the real SDK surface area documented in the Coinbase x402 docs and the x402 GitHub repository.

At a high level, the client side has just four conceptual steps:

Provision a CDP-managed wallet on Base mainnet. The private key never leaves Coinbase's HSM-backed infrastructure — your agent only ever holds a wallet handle.
Wrap the agent's fetch with the x402 helper. The @x402/fetch package exposes a single drop-in function called wrapFetchWithPayment. Your agent code keeps using fetch exactly as before — except now it transparently survives a 402 challenge.
Set a maxPaymentValue ceiling. This is your circuit breaker. It prevents the wrapper from honoring a maliciously large payment demand from a compromised or misconfigured endpoint — say, an API server that suddenly insists on charging $50 per call instead of half a cent.
Read the PAYMENT-RESPONSE header on the way back. It carries the on-chain transaction hash that your logs need for reconciliation, billing, and post-incident forensics.

The whole flow fits in roughly twenty lines of TypeScript that any builder familiar with fetch can reason about. The libraries do the heavy lifting: signing the EIP-3009 authorization, attaching the payment payload to the X-PAYMENT header on retry, and surfacing the transaction hash to your application code.

On the server side, adding a paywall to an Express endpoint is equally compact. The @x402/express middleware mounts onto any route you choose — say, GET /v1/weather — and you declare exactly two things per route: which network and asset you accept (typically USDC on Base) and how much you charge per call (often denominated in atomic USDC units, so a tenth of a cent is 1000).

The middleware then handles the entire lifecycle automatically: it returns the 402 challenge with the proper X-PAYMENT-REQUIRED envelope, validates the EIP-3009 signature when the client re-submits, calls a facilitator to broadcast the on-chain transaction, and only invokes your route handler after settlement is confirmed. From the perspective of the route author, you ship a normal Express endpoint — and x402 monetizes it for both human and agent clients without you ever touching the payment internals.

Risk Checklist Before You Ship

Autonomous payments introduce failure modes that do not exist in human-initiated flows. Work through this checklist before pushing any agent with spending authority to production.

☐ Gas exhaustion. Even with facilitator-sponsored gasless transfers, gas costs exist — the facilitator pays them and prices them into its fee structure. On congested networks, gas spikes can cause settlement failures. On the agent side, if you are running a non-facilitator flow or are on a chain where gas sponsorship is unavailable, ensure your agent wallet maintains a gas buffer. Monitor ETH (or native token) balance separately from USDC balance. Set alerting thresholds, not just hard stops.

☐ Runaway agents. A bug in your agent's loop logic — an infinite retry, a misread 402 response, a malformed maxPaymentValue guard — can drain a wallet quickly. The x402 maxPaymentValue parameter is your first line of defense. Layer on top of it: daily spend caps at the wallet policy level (CDP's Agentic Wallets support configurable per-transaction and daily limits), circuit breakers in your orchestration layer that halt the agent when cumulative spend exceeds a threshold, and out-of-band alerting when spend velocity is anomalous.

☐ KYC obligations. The agent itself does not need KYC — it is software, not a person, and has no government ID. KYC and AML obligations apply to the humans and businesses that fund the agent's wallet and receive its outputs. However, the Coinbase CDP facilitator runs KYT (Know Your Transaction) screening and OFAC checks on every settlement transaction. If you run your own facilitator, you must build equivalent sanctions screening and Travel Rule compliance infrastructure. Regulators are increasingly clear that the human principal behind an agent inherits the compliance obligations of the payments it initiates.

☐ Private key custody. A compromised agent wallet drains in a single transaction — there is no chargeback mechanism on-chain. Do not store raw private keys in environment variables, code, or unencrypted config files. The CDP managed wallet approach (keys in CDP's HSM) is appropriate for most teams building today. For larger deployments, institutional custody providers (Fireblocks, Anchorage, Coinbase Custody) offer hardware-backed multi-signature arrangements. If you use a local key, wrap it in a secrets manager (AWS Secrets Manager, HashiCorp Vault) and rotate it on a schedule.

☐ Transaction reversibility. On-chain stablecoin transfers are final. Unlike a credit card charge, there is no dispute window, no issuer to call, and no chargeback. This is by design — agents need irreversible settlement so the next step of their workflow can proceed without uncertainty — but it means your error handling must be bulletproof before the payment fires. Validate the PaymentRequired payload from the server before signing. Check that the payee address is on your allowlist. Verify the asset contract address matches the expected USDC deployment for the target network (spoofed asset contracts are a real attack vector). Set the validBefore timestamp tightly — a 30-to-60 second window is sufficient for synchronous API calls and limits replay exposure.

☐ Server-side validation. If you are building the receiving end of an x402 payment, never trust a client-supplied payment proof without routing it through the facilitator's verification endpoint. Validate the payment amount server-side before releasing the resource. Implement rate limiting per wallet address. Monitor for signature replay attempts, even though EIP-3009 nonces are designed to prevent them — defense in depth applies.

Where to Go From Here

The stack described in this guide is production-capable today. USDC on Base via x402 and the Coinbase AgentKit is the lowest-friction path from zero to a paying agent: a free CDP facilitator tier, TypeScript and Python SDKs, gasless transfers via EIP-3009, and a growing ecosystem of paid API endpoints to connect to. The next steps in order of priority: clone the coinbase/x402 examples directory and run the fetch demo against the Base Sepolia testnet; read the EIP-3009 specification to understand exactly what you are signing; wire up the risk controls — spend caps, wallet monitoring, facilitator KYT — before touching mainnet. The payment primitive is ready. The operational discipline around it is where most production deployments will succeed or fail.

Sources

Primary sources

Related coverage on BlockAI News

Stay close to BlockAI News.

The HTTP 402 status code waited 30 years for the right client — build the agent that finally uses it.

How we report: This article cites primary sources, regulatory filings, and on-chain data where available. BlockAI News uses AI tools to assist with research and first-draft generation; every article is reviewed and edited by a human editor before publication. Read our full How We Report page, Editorial Policy, AI Use Policy, and Corrections Policy.