AWS has quietly shipped an integration that lets publishers set per-request prices for AI agents and receive payment in USDC through the x402 protocol, settling on Solana or Base. The move takes x402 from a specification we have covered extensively—most recently in the context of Coinbase and AWS putting it on the CloudFront WAF—to a live product that any publisher on AWS infrastructure can enable. The architecture is straightforward: a publisher defines a price for content access, an AI agent making a request receives an HTTP 402 response with a payment demand, the agent pays in USDC onchain, and the publisher serves the content. The settlement happens on Solana or Base, not on a legacy rail, which means the entire loop—request, payment, delivery—can complete in seconds without a credit card, a subscription, or a human in the middle.
How the x402 Payment Loop Works on AWS
The x402 protocol is built on HTTP status code 402, which was reserved decades ago for digital payment but never implemented. When an AI agent requests a resource from a publisher that has enabled x402, the server returns a 402 response instead of the content. That response includes a payment address, an amount in USDC, and a chain identifier—either Solana or Base. The agent’s wallet software constructs and signs a transaction on the specified chain, sends the USDC, and then re-requests the resource with proof of payment. The publisher verifies the transaction onchain and serves the content.
The AWS integration means publishers do not need to run their own payment verification infrastructure. The enforcement logic sits at the edge, likely in CloudFront or a similar layer, and the publisher simply configures a price and a receiving address. This is the same architecture we described when Coinbase and AWS put x402 on the WAF, but the new development is that it is now available to publishers as a product, not just a demonstration. The settlement chains—Solana and Base—were chosen for their low fees and sub-second block times, which matter when an agent might make hundreds of requests per minute and each payment is a fraction of a cent.
Why Solana and Base, Not Ethereum Mainnet
The choice of Solana and Base as the settlement layers is a practical one. Ethereum mainnet would be unusable for this use case: a single request might cost a fraction of a cent in content value but incur dollars in gas fees. Solana offers sub-second finality and fees measured in fractions of a cent, making it viable for high-frequency microtransactions. Base, as an Ethereum L2, offers similar economics with the added benefit of Coinbase’s infrastructure and USDC liquidity.
The dual-chain support also reveals a design philosophy: x402 is chain-agnostic at the protocol level, and the settlement chain is a parameter in the 402 response. A publisher could theoretically specify any chain that supports USDC, though the current product only surfaces Solana and Base. This flexibility matters because it means the payment rail can evolve without changing the protocol. If a faster or cheaper chain emerges, publishers can adopt it by updating a configuration, not by rewriting their integration.
The Economics of Per-Request Pricing for AI Agents
Per-request pricing is a departure from the subscription and API-key models that dominate today’s web. A human user might pay $10 per month for access to a news site and make a few dozen requests. An AI agent might make thousands of requests per day to the same site, each for a single article or data point. A subscription model breaks down for agents because the usage pattern is so different: the agent does not need “unlimited” access, it needs granular, pay-per-use access.
x402 enables a model where the publisher sets a price per request—say, $0.001—and the agent pays exactly for what it consumes. This aligns incentives: the publisher gets revenue proportional to the value extracted, and the agent does not overpay for access it does not use. The challenge is that the agent must manage a USDC balance and make a payment decision for every request, which introduces a new layer of logic: how does the agent decide whether a piece of content is worth the price? That question is not answered by the protocol itself, but it is the next problem that agent developers will need to solve.
The Open Question: Agent Wallet Management and Liability
The x402 protocol assumes the agent controls a wallet with a USDC balance and can sign transactions autonomously. This raises the same custody and liability questions we have been tracking across the AI-agent payments space. If an agent makes thousands of micro-payments per day, who funds the wallet? Who is responsible if the agent overspends, pays for low-quality content, or falls victim to a spoofed 402 response that directs payment to an attacker?
The AWS integration does not solve these questions; it provides the payment rail. The agent’s wallet architecture—whether it is an MPC wallet controlled by the agent’s code, a traditional keypair, or a custodial wallet managed by a platform—determines the security and liability model. We have written about this tension in the context of Coinbase’s Agent SDK and Locus Founder, and x402 on AWS surfaces the same issue from the publisher’s side. The publisher receives USDC and does not need to know or care how the agent manages its keys, but the agent’s developer absolutely does.