Onchain agentic payments are how AI agents buy things from APIs, services, and other agents without a human in the loop. Instead of a card, a Stripe account, or a human approving every charge, the agent holds a stablecoin balance and settles each purchase onchain in seconds. This article walks through a concrete agent-to-API payment flow using the emerging HTTP 402 pattern, explains why blockchain rails fit autonomous software better than traditional payment networks, and shows where cross-chain routing fits when the agent's funds live somewhere other than the API's settlement chain.

If you are building an agent that needs to call paid APIs, coordinate with other agents, or manage its own budget, the payment layer is not a footnote. It is the difference between a demo and a system that can operate unattended for weeks at a time.

A payment is "agentic" when the paying party is an autonomous program rather than a person tapping a phone. It is "onchain" when settlement happens on a public blockchain in a stablecoin like USDC or USDT, with a cryptographic signature from the agent's wallet rather than a card network authorization. The combination matters because agents are bad at the things card rails assume and good at the things blockchains assume.

Card rails assume a human cardholder, a KYC'd merchant, a chargeback window, and batched settlement. Agents do not have government IDs, they need to settle instantly so the next step of their workflow can run, and they work best with deterministic rules that can be encoded in smart contracts. Running agent payments through legacy rails means either routing them through a human-owned account (which breaks the autonomy) or through a crypto-to-card adapter that adds latency, fees, and a surface area for fraud.

The architecture that is winning instead looks like this: the agent owns a smart wallet, holds a stablecoin balance, and signs transactions directly. The merchant or API operator publishes a price, the agent pays, the transaction finalizes, and the agent receives the resource. No clearinghouse, no settlement delay, no reliance on a shared human custodian. Coinbase and Anthropic have both written about this pattern, and the x402 open payment standard formalizes it at the HTTP layer.

The clearest way to understand onchain agentic payments is to trace a single agent-to-API call from start to finish. Suppose an AI agent needs to query a premium market-data endpoint that charges $0.10 per request in USDC on Base.

The agent sends a GET request to the API endpoint exactly like any other HTTP client. It has no advance knowledge of the price, no API key provisioned in advance, and no subscription. The request body is identical to what a free endpoint would receive.

HTTP 402 was reserved in the original HTTP/1.1 specification for future payment use. For 25 years it sat unused. The x402 pattern finally puts it to work. The server returns a 402 status code with a JSON body that specifies the price, the accepted token, the settlement chain, and the receiving address. For example: 0.10 USDC on Base, payable to 0xAbc... The response also includes a nonce and a short expiry so the payment quote cannot be replayed.

The agent's wallet constructs a payment matching the quote. If the agent is running on an ERC-4337 smart account, this is a UserOperation that transfers USDC and attaches a memo referencing the nonce. The agent signs with its session key, which can be scoped to a spending limit (say, $5 per day on API purchases) so a compromised agent cannot drain the wallet. The signed payment is sent back to the API in a header on a second HTTP request.

The API verifies the signature, submits the transaction to the chain (or accepts an offchain attestation if it runs a facilitator), waits for confirmation, and then serves the requested resource. On Base, this typically takes a few seconds. On an L1 like Ethereum it would take longer and cost more in gas, which is one reason most agent payment activity is landing on low-fee L2s.

The API returns the resource as if the call had been authenticated from the start. From the agent's perspective, it made an HTTP request, handled one redirect-like 402 response, and got its answer. From the server's perspective, it received a confirmed onchain payment before releasing the data. Neither side needed to pre-provision credentials, store a card, or trust a third party.

Four properties of blockchain payments map cleanly onto how autonomous agents actually operate.

Programmability. The agent's spending rules live in the wallet contract, not in a bank's back office. ERC-4337 session keys let you say "this agent can spend up to $50 today, only to these ten addresses, only for these four token types." If a jailbreak or prompt injection tries to redirect the agent, the wallet refuses to sign. Traditional rails cannot enforce that kind of scoped authority at the transaction layer.

Instant settlement. When the payment confirms, the funds have moved. There is no T+2, no chargeback window, no risk of reversal after the API has already served the resource. For an agent running a loop of hundreds of small purchases, the ability to treat each payment as final within seconds is what makes the economics work.

24/7 availability. Blockchains do not have banking hours, weekends, or wire cutoffs. An agent that wakes up at 3 a.m. on a Sunday to restock data is the same as one running on a Tuesday at noon. Global agent traffic does not respect NYC business hours, and the rails should not require it to.

No KYC for the agent principal. The agent is not a person. It does not have a passport, a date of birth, or a social security number. KYC rules apply to the humans and businesses that fund the agent's wallet and receive the outputs, but the agent itself does not need to impersonate a human to transact. This is a big deal for programmatic commerce at scale: it removes a step that blocks 99% of autonomous use cases on traditional rails.

The Coinbase announcement of x402 frames this as "a new way for agents to pay for anything on the internet," and the framing fits. A recent a16z piece on AI agents and crypto argues the same point from the investor side: stablecoins are the native payment layer for software that runs without human approval.

The x402 flow above assumes the agent's USDC balance lives on the same chain as the API's settlement address. In practice, agents increasingly hold balances across several L2s — some on Base because that is where Coinbase-native services live, some on Arbitrum for DeFi integrations, some on Optimism for its ecosystem grants. When the agent has to pay a Base-native API but its funds are on Arbitrum, it needs cross-chain routing.

This is the problem Eco Routes solves. The agent submits a stablecoin intent — "move 0.10 USDC from my Arbitrum balance to this address on Base within the next minute" — and solvers compete to fulfill it. The route is atomic: it either completes on Base with the target amount or it reverts and the Arbitrum funds stay untouched. The agent does not need to manage bridge quirks, handle stuck transactions, or babysit the settlement. From the agent's perspective, the cross-chain hop is a single signed intent; from the API's perspective, the payment arrives on its chain in seconds.

Under the hood, Routes uses partner rails like Circle's Cross-Chain Transfer Protocol, Hyperlane, LayerZero, and intent standards including ERC-7683 to pick the best path for each transfer. The agent does not need to know which rail handled its specific payment — the layer above abstracts that choice. Teams building agents can integrate by reading the stablecoin tools for developers comparison to pick the right entry point, or jump straight into the Routes CLI for a working setup in minutes.

The wallet is the single most important piece of an agentic-payment architecture. Get it wrong and every other decision is downstream of a leaky bucket. Most production agent deployments are converging on a three-part structure.

The first piece is an ERC-4337 smart account as the agent's wallet. Account abstraction lets the agent sign transactions without an EOA's rigid key management, and it makes session keys, spending limits, and per-contract allowlists enforceable at the protocol level. The EIP-4337 specification covers the details.

The second piece is a session key scoped to the agent's current task. Rather than giving the agent full signing authority over the wallet, the operator issues a time-limited key that can spend up to a budget, call only whitelisted contracts, and expire at a defined time. Compromise of the session key caps the blast radius.

The third piece is a policy contract that enforces rules the operator wants to be structural. For example, "never transfer more than $100 to any address in a 24-hour window," or "refuse any call to a contract tagged as high-risk by our compliance feed." Because these rules are onchain, they apply even if the agent's prompt is manipulated.

The combination of smart account, session key, and policy contract gives operators a meaningful security posture. The execution-time compliance argument applies directly here: agents move fast enough that after-the-fact controls are worthless. The rules have to be enforced in the signature path.

On the merchant side, supporting agentic payments is lighter than it sounds. A minimal x402-compatible API needs three things.

First, it needs to serve HTTP 402 responses with a structured body describing the price, token, chain, and receiving address. There are open-source middleware packages for Express, FastAPI, and Hono that handle this, including the reference implementation from the x402 project.

Second, it needs a way to verify payments. The simplest pattern is to run a lightweight indexer on the target chain and match incoming transfers to the nonce the API issued. A slightly more sophisticated pattern uses a facilitator service that accepts signed payment intents and handles the onchain piece on the API's behalf.

Third, it needs a receiving wallet per chain it wants to accept payments on. In practice, most API operators pick one or two chains (commonly Base and Arbitrum) and direct agents to settle there. Agents whose funds are elsewhere use Routes to convert and deliver in a single intent.

For teams that want deeper background before building, the intent-based routing protocols overview and B2B stablecoin payout APIs round out the integration side.

Agent payments look easy in a demo. The hard parts show up when you are running thousands of agents making millions of calls per day.

Gas volatility. A spike in gas on the settlement chain can turn a $0.10 API call into a $0.30 call once fees are included. Agents need either a gas-aware budgeting logic or a wallet that can pay gas in stablecoin (via a paymaster) so the accounting stays predictable.

Nonce management. Under heavy concurrency, a single agent sending hundreds of payments per minute can hit nonce conflicts that cause transactions to revert. Smart accounts handle this better than EOAs because UserOperations can be parallelized across multiple bundlers, but it still requires attention.

Dispute resolution. Blockchain settlement is final. If an agent paid for a resource that the API failed to serve, there is no chargeback. The merchant has to honor it through an offchain credit or a smart-contract-mediated dispute. Most teams handle this with a receipt system and a manual reconciliation process rather than trying to build true onchain dispute logic.

Onchain agentic payments are transactions where an AI agent pays a service, API, or other agent directly from its own stablecoin wallet, settled on a blockchain. There is no card, no intermediary bank, and no human approval per transaction. The agent's spending rules are enforced at the wallet level, usually through an ERC-4337 smart account with session keys.

x402 uses the reserved HTTP 402 status code to signal "payment required." An API responds to an unpaid request with a 402 and a price quote; the agent signs a matching stablecoin payment; the API verifies it onchain and returns the resource. The whole flow happens over standard HTTP with one extra round trip, so it slots into existing agent frameworks without a custom transport.

Stablecoins like USDC and USDT are priced in dollars, which makes agent budgets legible to humans and stable across the short horizon most agents operate on. ETH is a great settlement asset for large value transfers, but for per-request API payments the price volatility would make every invoice a moving target. See digital dollars explained for more.

The agent itself does not need KYC because it is software, not a person. The humans and businesses that fund the agent's wallet and receive outputs are subject to normal KYC/AML rules, and the wallet can be provisioned to only accept funds from KYC'd sources. This keeps the agent autonomous while preserving regulatory clarity for the principal.

The agent submits a cross-chain intent through a protocol like Eco Routes. The intent specifies the source chain and balance, the destination chain and address, and the amount. Solvers fulfill the intent atomically — the payment arrives on the API's chain or the source funds are untouched. The agent does not need to manage bridges, gas on multiple chains, or bridge latency.