AWS AgentCore payments x402 went GA — agents can now meter what they buy, and the seller side is the bottleneck

What AWS actually shipped on August 18, 2026

AgentCore payments has been in preview since earlier this year, built with Coinbase and Stripe. On August 18 it went generally available. The AWS announcement is worth reading as a document about payment design, not as a cloud release note. The framing is that an agent should be able to "autonomously discover, access, and pay for paid APIs, MCPs, and content" — discovery, access and payment treated as one problem.

The mechanics are the ones this blog has been describing for a year. An agent hits a paid resource, receives an HTTP 402, and AgentCore handles the protocol negotiation, wallet authentication, the stablecoin payment and delivery of the payment proof back to the endpoint — without interrupting the agent's reasoning loop. If you want the handshake itself, we've written up what an x402 call looks like end to end.

What changed between preview and GA is the interesting part:

Every row moves in the same direction: making it boring for a machine to spend money. That is what "generally available" means on a hyperscaler — not that the feature is new, but that it is now a default a platform team can adopt without a special case.

The upto scheme is the change that matters most to sellers

Until now, x402 mostly answered a fixed question: this call costs three cents, pay it. That works beautifully for deterministic endpoints — a geocode, a lookup, a validation. It does not work at all for the largest category of things agents actually buy, because nobody knows the price before the work is done. An LLM completion costs whatever the token count turns out to be. A query costs whatever the scan turns out to touch. A download costs whatever the bytes turn out to be.

The upto scheme in the x402 Foundation spec resolves this with one elegant move: the amount field means different things in different phases. At verification it is the maximum the client authorises. At settlement it is the actual amount to settle, which must be less than or equal to that maximum. The seller does the work, measures it, then settles the real number.

The spec's guardrails are the reason this is safe to hand an autonomous process: each authorisation settles at most once and cannot be reused; it is time-bound with explicit validAfter and deadline timestamps; and the recipient address is cryptographically bound, so an authorisation cannot be redirected to a different wallet. The named use cases are exactly what you'd expect — per-token LLM generation, per-byte data transfer, dynamic compute pricing.

Read commercially rather than technically, this is a business-model unlock. A fixed-price-per-call protocol forces every seller to quote the worst case or eat the tail. A metered protocol lets a seller price the way software has always wanted to be priced, and lets a buyer commit a budget without committing to a quantity. That is the first time machine payments have had the pricing vocabulary that human SaaS contracts take for granted.

Two protocols, one wallet — and what that says about standards risk

The second GA change is quieter and easy to under-read. AgentCore now supports MPP alongside x402, and AWS's framing is that a developer can pay for any MPP-compatible service "without an additional line of code."

The instinctive reading is fragmentation: a second standard means a standards war. We think the opposite is closer to the truth for anyone selling. The protocol choice has been abstracted into the buyer's wallet layer. An agent's engineer no longer picks a payment standard when they pick a vendor; the runtime negotiates whatever the endpoint speaks.

That drains most of the risk out of the decision that has been paralysing API providers all year — which protocol do I implement, and what if I pick wrong? If the buyer side is protocol-plural, the cost of publishing an x402 price is no longer a bet. It is a door. x402 in particular now sits under open, neutral governance through the x402 Foundation at the Linux Foundation, which we covered when the foundation formalised — you are not adopting a vendor protocol, and you are not required to adopt only one.

Spend caps moved below the model

The third change is the one that should reassure any finance team that has been nervous about agent budgets. AgentCore payments run inside a payment session: a scoped context for a single agent interaction, with two configurable limits — a maximum spend amount in a specified currency, and an expiry time. AWS is explicit about why: agents are non-deterministic, so they can misread a response as authorisation to spend, or repeat a payment on an unexpected retry.

The fix is to stop asking the model to be careful. Requests are validated against the session budget at the infrastructure layer, deterministically, before any payment is authorised, with end-to-end observability over what was spent.

This is the same structural argument we made about the agentic commerce trust gap, arriving from the other direction. Consumer agentic checkout needs an elaborate trust framework because card rails are credential-based and reversible: somebody has to prove, months later, that a human authorised a payment. Machine-to-machine spending on a stablecoin rail replaces that with two things a computer can enforce — a ceiling that cannot be exceeded, and a settlement that is its own receipt. AWS just shipped the ceiling as infrastructure.

The tell is in the discovery layer

Buried in the same announcement is the sentence that reframes everything above. AgentCore exposes pay-per-use x402 endpoints as an MCP server via AgentCore Gateway — and at GA, that discovery experience was upgraded to a curated list, selected on "social proof, metadata richness, description quality, and availability."

Nobody curates an abundant market. You curate when the inventory is thin and uneven, and you need to protect the buyer's first experience. A hyperscaler hand-picking which paid endpoints are worth surfacing to millions of agents is not a sign that the supply side is crowded. It is a sign that it is not.

The public numbers say the same thing. As of late August 2026, x402.org's own dashboard reported, for the last 30 days:

• 75.41M transactions
• $24.24M volume
• 94.06K buyers
• 22K sellers

Two pieces of arithmetic fall out. First, the average ticket is roughly 32 cents — a price point that has no meaningful existence on card rails, where the fixed cost per authorisation eats the sale. (Other trackers using different methodologies report lower averages for shorter windows; we covered one such week in x402's busiest week of the year. Treat any single number as a measurement, not a law.)

Second, and more usefully: buyers outnumber sellers more than four to one, and that ratio was measured before a hyperscaler made agent wallets a general-availability default. Every announcement of 2026 has been on the buyer's side — cloud platforms issuing wallets, spend-management firms issuing wallets, model providers documenting how an agent pays. Each one adds funded machines looking for something to buy. None of them adds an endpoint that answers with a price.

To a budget-bounded agent mid-task, a signup form is a dead end. It will not create an account, wait for an API key, or read your pricing page. It will go somewhere else, or come back to its user without the data.

What this means if you sell an API — and exactly what Payzum does

Precision matters here, because the roles in x402 get conflated constantly. Payzum is the middleware/proxy that sits in front of your existing API. Payzum is not the facilitator. On-chain settlement is handled by an external facilitator — Coinbase's today. What Payzum removes is the engineering that would otherwise land on your roadmap: implementing the 402 handshake, verifying payment, guarding against replay, and forwarding the paid request to your real service with your own credentials.

You configure the endpoint you already run, the API key or bearer token it already expects, and a price per call. Payzum publishes an x402 URL, answers agents with the 402 and the payment terms, waits for settlement, then proxies the paid call to your real endpoint and returns the response inside the same request cycle. No SDK, no protocol implementation, no redeploy of your service.

Being straight about the pricing model: what you configure today is a price per call — the fixed-price shape. The metered upto scheme described above is a protocol-level capability that the ecosystem is rolling out, and for most providers a flat per-call price is the right first product anyway: it is the easiest thing for an agent to evaluate against a remaining budget, and the easiest thing for you to reason about. If your unit genuinely is per-token or per-byte, that is a good conversation to have on a call rather than a claim to make in a blog post.

Settlement is non-custodial: USDC on Base lands directly in a wallet you control, with roughly two-second confirmations. Payzum never holds, pools or routes your money — the settlement is the payment. That also means the payment is final when the call is served: no chargebacks, no reversal window, nothing sitting in a processor balance for one to three days. Pricing is usage-shaped: around 1,000 transactions per month free, then roughly $0.001 per transaction plus gas. If you want the settlement mechanics in depth, we've written up why USDC on Base fits per-request pricing.

How it works, step by step

1. Connect the endpoint you already have. In the Payzum dashboard, paste your existing API URL and the key or bearer token it expects. Your service keeps its current authentication, rate limits and deploy pipeline — nothing changes on your side.
2. Set a price and a destination wallet. Choose what one call costs in USDC and the Base wallet where funds should land. Because settlement is non-custodial, that wallet is yours from the very first payment — there is no Payzum balance in between.
3. Payzum publishes the x402 URL. An agent that hits it receives an HTTP 402 with the price and payment terms — a machine-readable offer it can evaluate against its session budget without a human in the loop — and pays in USDC. Settlement is verified through an external facilitator.
4. The paid call is proxied to you. Payzum forwards the request to your real endpoint with your key and returns the response in the same request cycle. Signed webhooks, a full audit log, 2FA and encrypted secrets cover every call, and you can watch the first one land using the integration playground and REST API.

Who is on the other side of this today

AWS's own GA post names a customer that makes the shape concrete: Travala integrated payments into their MCP servers, serving 2.2 million properties globally. An agent booking travel does not fill in a form — it finds a tool, gets a price and pays. Three more shapes, all of them B2B, all of them reachable this week:

• A data provider with a long tail it cannot sell. The firm licences its feed to enterprises and turns away everyone below the contract minimum. It publishes the same lookup at three cents a call over x402. Research agents, pricing bots and one-off scripts pay per query. Nobody negotiates, nobody signs, and the segment that was uneconomic to invoice becomes the segment that pays instantly.
• An MCP tool discovered mid-task. A geocoding, enrichment or document-parsing service is exposed to agent runtimes. When an agent needs it, it meets a price instead of a signup page, pays from its session budget and gets the answer in the same request cycle. That is precisely the inventory a curated discovery list is short of — and we've written a full walkthrough of monetising an MCP server with x402.
• A regional API provider with no international collection account. A team in LATAM or Southeast Asia bills in dollars but cannot easily open a US merchant account. Agents anywhere pay USDC on Base straight into the team's own wallet — no acquirer, no cross-border card fees, no rolling reserve, and no payout to be frozen, because no balance is held anywhere to freeze.

Selling to agents on card rails vs an x402 URL with Payzum

Objections worth taking seriously

"If MPP exists too, isn't publishing an x402 price a bet on the wrong standard?"

That was a fair worry a year ago and it is much weaker now, precisely because of what GA changed. The buyer's runtime handles protocol negotiation — AWS's stated position is that an MPP-compatible service is payable "without an additional line of code" on the agent side, alongside x402. The seller's exposure is also small: with Payzum the x402 URL is a configuration in front of an endpoint you already run, not a rewrite of your service. If the landscape shifts, what you change is a setting, not an architecture.

"We already have API keys, plans and invoicing. Why add another door?"

Keep all of it. x402 is additive, not a migration — your existing customers keep their keys, contracts and invoices untouched. What an x402 URL adds is a second door for a buyer who cannot walk through the first one: an autonomous process, mid-task, with a session budget and no ability to complete a signup flow, enter a card or wait on procurement. Today that buyer sees a login page and leaves. The change is not to your billing model; it is to your addressable market. We compared the two side by side in x402 vs API-key billing.

"Is final settlement risky if something goes wrong on a call?"

Finality cuts both ways and it is worth stating plainly. You cannot claw a payment back, and neither can the buyer — which is exactly why per-call pricing suits this rail: the unit at risk on either side is cents, not a monthly contract. If you need to make a buyer whole, you refund as a payment you initiate, on your terms. What finality removes is the months-long reversal window that makes conventional processors hold reserves against your revenue in the first place.

"Do I need to be on AWS for any of this?"

No. AgentCore is one buyer-side runtime among several, and the significance of its GA is what it says about demand, not about where you have to host. x402 is an open HTTP standard under Linux Foundation governance; an endpoint published through Payzum answers any client that speaks it, whichever cloud, framework or agent runtime that client happens to be running on.