Skip to main content

Agent Payments: x402, MPP and AgentCore GA

Advanced

For two years agents have been very good at deciding to buy something and very bad at actually paying for it. The workaround was always the same — pre-provision an API key, hand the agent a shared credit card, and hope it doesn't rack up a bill you can't unwind. In 2026 that gap closed. A small stack has emerged around one big idea — use HTTP 402 the way it was always meant to be used — and a real, generally-available AWS service now wraps it in the guardrails an actual business needs. This page is a practical field guide to that stack: how x402 works on the wire, why the upto scheme is the interesting one, what AgentCore Payments actually gives you at GA, and where the sharp edges are.

What you'll learn
  • Read a raw x402 challenge and understand the three headers, the two facilitator calls, and the three payment schemes
  • Tell exact from upto and know which one your endpoint should advertise
  • Set a payment session's spend cap and expiry so an agent cannot drain your wallet on a bad prompt
  • Choose between Coinbase Privy (crypto rails) and Stripe Privy (card rails) inside AgentCore Payments
  • Recognize the three real threats: prompt-injection-to-buy, facilitator misbehavior, and 'upto' over-settlement

Why "the agent just pays" is harder than it sounds​

The moment an agent has real spending authority, four things break at once:

  • The API key model was a workaround. Every "agent-friendly" API today asks you to mint a key, top up a balance, and hand the string to the agent. That's the human doing the accounting; the agent is just a client. Anything the agent buys spends the human's pre-committed pool.
  • Cards were designed for one buyer per session. Cards assume there is a person clicking "Pay". Agents want to fan out — buy 200 tiny things across 30 sites in an hour — and each purchase should be atomic, cheap, and reversible.
  • There is no discovery. Human buyers can read a pricing page. An agent needs a machine-readable "here's what this costs and how to pay for it" inline in the response.
  • Guardrails have to be enforced somewhere other than the agent. If the only limit is a prompt saying "spend under $10", the agent will disobey it at some point. The limit has to live in infrastructure the model can't argue with.

x402 attacks the discovery problem. AgentCore Payments attacks the guardrail problem. They are complements, not competitors.

x402 on the wire — the whole protocol in one flow​

x402 is an open protocol maintained by the x402-foundation/x402 organisation on GitHub (Apache-2.0, ~6.5k stars at time of writing). Its whole trick is to give HTTP status code 402 Payment Required the semantics people always assumed it had.

The full flow is exactly six moves. There is no session, no login, no key.

Guided walkthrough1 of 6
  1. Agent makes a normal HTTP request to a paid endpoint. No auth header, no wallet.

Two design points are worth pausing on. First, the server — not the client — decides when to settle. If the request fails after step 4, the server never calls /settle, so the agent is not charged; the signature was an authorisation with a short expiry and it simply times out. That is the property that makes x402 usable at all for agents: a failed download is a free download. Second, the facilitator never has custody of client funds; the protocol's stated invariant is "all payment schemes must not allow facilitators to move funds outside client intentions." A rogue facilitator can refuse to settle; it cannot over-settle.

The three schemes — and why upto is the interesting one​

x402 defines schemes as how the amount is agreed, not what currency is used. The current stable set:

  • exact — the server advertises a fixed price and the client signs for exactly that amount. Best for content with a known cost per read: "$0.02 for this article". Simple, boring, correct.
  • upto — the server advertises a ceiling. The client signs authorising up to that ceiling; the server chooses the actual charge at settlement time, up to the cap. This is the one that unlocks the interesting economics.
  • batch-settlement (EVM) — for high-frequency use. The client posts an escrow deposit once, then racks up many off-chain vouchers that get redeemed in a single batched on-chain settlement. Same trust model, dramatically lower per-request gas.

upto is the scheme that makes pay-per-inference and dynamic pricing possible. If you sell inference by the token, you don't know at request time how many tokens the completion will use; you only know at response time. With exact you either overcharge (round up to the ceiling and refund — needs a second on-chain move) or undercharge (the client pays for 4k tokens and you generate 10k). With upto the client signs "charge me for at most 10k tokens' worth", you produce the response, then you settle for the actual usage. The AWS AgentCore Payments GA release specifically highlights this as the pattern their launch enables: "the upto scheme within x402 enables an agent to set a spending ceiling rather than committing to a fixed price."

Watch the failure mode: if the server settles the ceiling instead of the actual usage, the client has no on-chain recourse for the difference — the signature covered it. The /settle call's amount parameter is trusted. In practice this is why you want a facilitator you either run yourself or trust; more on that below.

The chains and SDKs you'll actually meet​

The current x402 monorepo publishes SDK packages for EVM, SVM (Solana), AVM, Aptos, Stellar, TVM, Hedera and Keeta, but the traffic today is heavily concentrated on Base (Coinbase's EVM L2) and Solana, both settling in USDC. In TypeScript the packages you'll actually import are @x402/core, one of the chain modules (@x402/evm, @x402/svm, …), and a client wrapper — @x402/fetch for a drop-in fetch() replacement that transparently handles the 402→sign→retry loop, or @x402/express / x402-hono on the server side. Python has a single x402 pip package; Go has github.com/x402-foundation/x402/go/v2.

Cloudflare ships an even shorter path: the agents/x402 submodule inside its Agents package gives you an MCP client with x402 built in, and x402-hono is the paywall middleware for a Worker. So a Cloudflare Worker that turns a route into a paid endpoint is roughly:

Turning a Hono route into an x402 paywall

import { Hono } from "hono";
import { paymentMiddleware } from "x402-hono";

const app = new Hono();

app.use("/premium/*", paymentMiddleware({
network: "base",
facilitator: "https://facilitator.x402.org",
routes: {
  "/premium/summary": {
    price: { asset: "USDC", amount: "0.05" },
    scheme: "exact",
    recipient: "0xYourMerchantAddress",
  },
  "/premium/inference": {
    price: { asset: "USDC", maxAmount: "0.50" },
    scheme: "upto",
    recipient: "0xYourMerchantAddress",
  },
},
}));

app.get("/premium/summary", c => c.text("The paid content."));
app.get("/premium/inference", c => c.text("The paid inference result."));
export default app;

A caller using @x402/fetch doesn't need to know any of this — the wrapper sees the 402, signs, retries, and returns the eventual 200 response the same way a normal fetch would.

AgentCore Payments GA — what AWS actually shipped on 2026-08-18​

x402 alone is a protocol. It gets you how an agent pays. It does not get you whether it should. That is the problem Amazon Bedrock AgentCore Payments — GA on August 18, 2026 after a preview in May — actually solves.

The primitive to understand is the payment session. Every payment an agent makes has to run inside one, and a session has exactly two caps:

  • A maximum spend amount in a specified currency.
  • An expiry time.

Both are checked deterministically at the infrastructure layer — outside the model, outside the agent framework, outside anything the model can talk itself out of. A request that would push cumulative spend over the cap is rejected before the payment payload is even signed. A request after the expiry is rejected the same way. That is the guardrail. The model does not need to be well-aligned for it to hold; it needs to be well-constrained, and constraint lives in the session.

Around that primitive AgentCore GA'd:

  • Coinbase & Stripe Privy wallet integration. The credentials live in AgentCore Identity Secrets Manager; the agent never sees them; a short-lived derived token is what actually authorises wallet operations. End users can top up with a card (Stripe) or with USDC (Coinbase).
  • Quick Create for Coinbase. You provision Coinbase credentials from inside the AgentCore console or CLI without leaving the platform.
  • The Machine Payment Protocol (MPP) — the payment abstraction on top of x402 that lets an agent pay for MPP-compatible services and x402 endpoints with the same session and the same session cap. MPP is where card-rail and stablecoin-rail payments meet.
  • A curated x402-enabled MCP server directory — "Coinbase Bazar" — exposed to the agent through AgentCore Gateway. Discoverability of paid endpoints is ranked on "social proof, metadata richness, description quality, and availability," which is a polite way of saying they're trying not to become a listing of shitcoin drainers.
  • Framework plugins. A Strands Agents plugin and a LangGraph middleware ship at GA, so the payment session context is threaded through your agent loop without you writing an HTTP client for x402 by hand.

The Strands wiring is intentionally small — you build a AgentCorePaymentsPluginConfig with the payment-manager ARN, the user ID, the payment-instrument ID and the session ID, and add the plugin to the agent. The session enforcement happens under the plugin.

AgentCore Payments — Strands plugin, minimal shape

from agentcore_payments import AgentCorePaymentsPlugin, AgentCorePaymentsPluginConfig
import os

plugin = AgentCorePaymentsPlugin(
  config=AgentCorePaymentsPluginConfig(
      payment_manager_arn=os.environ["PAYMENT_MANAGER_ARN"],
      user_id="test-user-123",
      payment_instrument_id=os.environ["PAYMENT_INSTRUMENT_ID"],
      payment_session_id=os.environ["PAYMENT_SESSION_ID"],
  )
)
# Attach plugin to your Strands agent; the payment session caps
# (max spend + expiry) are set when you mint the payment session,
# NOT in the plugin config.

Every payment attempt emits a CloudWatch log entry and an AgentCore Observability span; the built-in dashboards show success rates, average transaction value, and end-to-end health per agent. This is the observability piece that makes "the agent bought something weird" actually debuggable a week after the fact.

Not just crypto — where Stripe fits​

A common misread is that x402 and AgentCore Payments are "crypto for agents". They are not. x402 happens to have shipped first on stablecoins because on-chain settlement is the only rail with true machine-native, permissionless per-request settlement. But AgentCore's MPP abstraction and the Stripe Privy integration mean an agent's session can be funded from a card. What Stripe Privy provides in this context is a card-backed wallet with delegation — the human user hands the agent a scoped, revocable authority to spend against a card, and the AgentCore session enforces the spend cap on top. For businesses that don't want stablecoin custody at all, this is the path.

Choosing:

  • Coinbase / Privy (USDC on Base or Solana). Best when you need true per-request, sub-cent settlement; when you want no chargeback; when the counterparty is another agent.
  • Stripe Privy (card). Best when the merchant is a normal business without on-chain rails, when the average ticket is large enough that stablecoin fees don't dominate, when you want the buyer to have card-network dispute rights.

The three threats worth taking seriously​

Autonomous agent payments open a small, specific attack surface. The three you should design against:

  • Prompt-injection-to-buy. A malicious page in an agent's context can instruct it to buy things. The defence is not "make the model refuse" — it's the session cap. Set the smallest spend ceiling that will complete the legitimate task, and set the shortest expiry. If a prompt injection makes the agent try to spend $10,000 and the session cap is $5, the injection fails. This is exactly the same lesson as Cryptographic context injection: Grok — trust boundaries live outside the model.
  • Facilitator misbehavior. The /verify call is honest by construction (a bad /verify can only reject), but a compromised or byzantine facilitator can refuse to /settle after the server has delivered content, silently overcharge in upto mode, or delay settlement past the payload's expiry so the client's signature stops being valid. Defence: prefer facilitators you run yourself for merchant-side use; on the client side use @x402/fetch's built-in receipt check to fail loud if PAYMENT-RESPONSE disagrees with what you signed.
  • upto over-settlement. In upto, the settled amount is server-supplied. A dishonest server can settle at the ceiling regardless of actual usage. The mitigation lives outside the protocol: emit a signed usage receipt in your response body (tokens generated, seconds streamed, bytes served) and refuse to trust a settled amount that isn't consistent with it. Some client wrappers will refuse to accept a settlement if you provide a callback that returns the expected max.

These are also the shape of what Cloudflare's WriteGuard is trying to address at the MCP layer — treating "cost money" as a write with attribution and audit — but AgentCore's session cap is the load-bearing control today. Combining a WriteGuard-style write-tier policy at the MCP layer and a payment-session cap at the wallet layer is the belt-and-braces posture that most production deployments will settle into.

Where this fits in the wider agent picture​

x402 gives an agent a way to transact. MCP gives it a way to reach the endpoints where transactions happen. A2A gives it a way to delegate work to another agent that may itself be paid. In practice you'll see all three composed: an A2A hand-off invokes a peer agent that uses MCP to reach an x402-priced tool, and the caller pays through its AgentCore session. When people talk about "the money layer for agents" this is what they mean — not a single product, but a stack where discovery, capability, and settlement each have a protocol and none of them requires humans in the loop.

Check yourself

0/6
  1. In an x402 exchange, what does the server put in the PAYMENT-REQUIRED header?
  2. Why is the `upto` scheme the one that enables pay-per-inference pricing?
  3. Which invariant does the x402 protocol give you about the facilitator?
  4. In Amazon Bedrock AgentCore Payments, where is a session's spend cap enforced?
  5. What does the `PAYMENT-RESPONSE` header on a successful x402 200 response carry?
  6. You want to protect an autonomous agent against a prompt-injection-to-buy attack via a malicious webpage in its context. Which control does the actual work?

Terms worth memorising​

No cards yet — add some to start studying. 🃏

Sources & further reading​

Next​