Agentic payments:
x402 & AP2.

HTTP has always had a status code reserved for this: 402 Payment Required, dormant since the 1990s. x402 finally uses it. An agent requests a resource; the server replies 402 with payment terms (amount, address, token). The agent pays — typically a tiny stablecoin transfer — and retries the request carrying proof of payment. This time it gets 200 and the resource.

No checkout page, no human. Payment becomes just another part of the protocol — which is exactly what an autonomous agent needs. But a checkout an agent can drive is also a checkout a hijacked agent can drive. That's why x402 is only half the story; the other half is the authority the agent carries into it.

Three roles take part: the resource server that wants payment, the client (your agent), and a facilitator, a service that verifies payments and settles them on the blockchain so the resource server doesn't have to run chain infrastructure. In version 2 of the x402 specification, the HTTP transport carries each step in a base64-encoded JSON header:

Field and header names are from spec v2. Version 1 used different header names, so pin the version your SDK speaks.

Notice what the agent signs: an authorization to move a specific amount to a specific payTo address within a time window, not a blank cheque. The facilitator's /verify must not change any state; only /settle commits the payment. Failures come back as structured reasons (the spec lists codes such as insufficient_funds and settlement_pending, the latter a non-terminal state where a transaction was broadcast but not yet confirmed), so a client can tell "retry" from "stop". The spec leaves client-side budget management out of scope on purpose. That's the gap the next sections fill.

You don't hand the agent your wallet — you hand it a mandate: a signed authorization that scopes what it may spend. Just as an OAuth token grants "read your email but not send," a payment mandate grants "spend up to $20 a transaction, $50 total, only at these merchants, until Friday." Protocols like AP2 standardize these mandates so any agent and any merchant can speak the same authorization language.

The agent acts freely inside the mandate and is refused outside it. Authority is delegated, bounded, and revocable — the model never holds unlimited spending power.

Google announced the Agent Payments Protocol on September 17, 2025, developed with more than 60 organizations, including Adyen and American Express. Its core idea is the mandate: a "tamper-proof, cryptographically-signed digital contract" that serves as verifiable proof of what the user instructed, signed with verifiable credentials. Two mandates carry the weight:

AP2 distinguishes human-present purchases (the user approves the cart in real time) from human-not-present delegated tasks (the agent buys later under an Intent Mandate). The first needs one signature; the second is exactly the case this page's spend caps exist for. AP2 works as an extension of the A2A and MCP protocols, and Google also launched an A2A x402 extension for agent-based crypto payments, so the two protocols compose: AP2 says who authorized what, x402 moves the money.

The mandate is only as good as the check. Before every payment, the payment layer verifies three things against the mandate: is the amount within the per-transaction ceiling, does it keep cumulative spend under the total budget, and is the merchant in scope? All three must pass, or the payment is refused before any money moves.

This is least privilege applied to money: the agent's spending power is the narrowest set of payments that still lets it do its job. Everything else is denied by default.

Crucially, the check runs in the payment layer, not the prompt. You're not asking the model to respect a budget in its reasoning — you're making the budget a precondition it physically cannot bypass, the same way a sandbox enforces file access regardless of what code wants to do.

Here's the threat the caps exist for. A prompt-injected or looping agent decides to make a hundred payments — draining an account is exactly the kind of damage autonomy makes possible. With the mandate check in front of every payment, it can't. Cumulative spend climbs to the cap and then every further payment is refused; the loop spins but the money stops.

The runnable enforcer below makes this concrete: point a "runaway" agent at a $50 mandate, watch it try to spend $200, and watch it get stopped cold at the ceiling. The final spend is bounded by max_total no matter how many times it tries.

The protocols solve different layers, so they overlap less than the acronyms suggest.

For an engineer the takeaway isn't which brand wins; it's that "my agent needs to pay for something" now has real answers at each layer, and each one needs the mandate discipline above bolted on. Check each spec's version before you build. ACP's repository, for instance, has published dated releases from September 2025 onward.

Agents retry, and a retried payment is a second payment unless you design against it. Three patterns do the work.

Reserve, then capture. Before the agent starts a purchase, reserve the amount against the mandate's max_total and release it if the purchase fails. Otherwise ten parallel tool calls can each pass the cap check against the same remaining budget. This is the same atomic check-and-decrement you would use for inventory.

Idempotent retries. Derive one key per intended purchase, not per attempt. Stripe's API accepts an Idempotency-Key header on POST requests (up to 255 characters); for API v1 it saves the status and body of the first request and returns that saved response for retries with the same key, including 500 errors, and it errors if the retried parameters differ. Hold the same discipline on your side of any rail:

Practice the retry half in the Idempotency Key Handler challenge.

Disputes need evidence. When a charge is contested, the question is "did the user authorize this?" A signed Cart Mandate is that evidence, and a bare "the agent decided to" is not. Keep the mandate, the cart and the settlement record together, and log each refusal as well as each payment. For the full backend, see Design an Agent Payment Gateway.

Agentic payments are a genuinely new capability surface, and capability surfaces are where agents get dangerous. The good news is that this one has a clean control story: delegated, bounded, revocable authority checked before execution — the same least-privilege pattern that governs an agent's tool access and file system. If you're designing the backend, the mandate-verification and settlement flow is a system-design problem in its own right; see the payment system and digital wallet designs for the human-rails version this builds on.

The mental shift is the same one that made agents safe to give tools at all: never rely on the model to behave, bound what "behaving badly" can even cost. A mandate is a spending sandbox, and like every good sandbox, it works precisely because it doesn't trust the thing inside it.