Agent Commerce, Payments and Identity

Why payments and identity are the next layer

Modules 4 and 5 covered how agents reach tools and other agents. That plumbing assumes something important: that every party knows who it is dealing with and what it's allowed to do. For a read-only search, a mistake is cheap. For a purchase, a refund, or a contract, it isn't.

Today's payment systems were built around a human at a checkout page. Fraud checks, card-security codes, and "Are you sure?" screens all assume a person is present. An agent breaks those assumptions in three ways:

Between September 2025 and March 2026, several groups published protocols aimed at these problems. They overlap and compete, and none has clearly won. The goal of this module is to understand what problem each one solves, so you can read announcements critically.

The commerce protocols at a glance

A rough way to group them: AP2 is about proving consent, ACP and UCP are about the shopping and checkout experience, and x402 and MPP are about moving money between machines. In practice a single purchase might involve more than one.

AP2: mandates as proof of consent

AP2's central insight is that the hard part of agent payments isn't moving money; it's producing evidence of what the user agreed to, so that merchants, payment networks and banks can trust the transaction and resolve disputes. AP2 does this with mandates, signed digital statements carried as W3C Verifiable Credentials (tamper-evident, cryptographically signed claims).

1. 1

   Intent Mandate

   Captures what the user asked the agent to do, along with its limits, such as "buy two concert tickets under $200 each when they go on sale." This covers cases where the user isn't present at purchase time.

2. 2

   Cart Mandate

   Captures approval of a specific cart: these exact items at this exact price from this merchant. When the user is present, they sign off on the final cart.

3. 3

   Payment Mandate

   Shares the necessary signals with the payment network and issuer, so they know an agent was involved and can apply the right risk checks.

Because mandates are signed, they form an audit trail. If something goes wrong, everyone can see whether the agent stayed within what the user authorized. AP2 is rail-agnostic (cards, bank transfers and stablecoins) and is designed to ride on top of A2A and MCP rather than replace them.

ACP and UCP: checkout inside the agent

ACP, from OpenAI and Stripe, focuses on letting a user complete a purchase without leaving the conversation. Its key security idea is the Shared Payment Token. Instead of handing the agent or merchant a reusable card number, the payment provider issues a token that is:

• scoped to one merchant,
• limited to one amount,
• time-limited, and
• single-use.

Even if the token leaks, it can't be reused elsewhere or for more money. This is the principle of least privilege applied to payments. ACP powered ChatGPT's Instant Checkout. Some secondary sources report that OpenAI scaled back in-chat checkout in 2026; that hasn't been confirmed by primary sources.

UCP, unveiled by Google with major retailers in January 2026, takes a broader view: an agent needs to discover products, check out, and handle post-purchase steps like order tracking and returns. Having a common protocol for all three means a merchant can integrate once and be reachable by many agents.

x402: payments built into HTTP

HTTP has had a status code reserved for payments since the 1990s: 402 Payment Required. It was almost never used, because there was no standard way to pay. x402, started by Coinbase, gives it a job. The flow is simple enough to sketch:

# 1. The agent requests a paid resource
GET /api/market-data/today HTTP/1.1
Host: data.example.com

# 2. The server replies with a price instead of the data
HTTP/1.1 402 Payment Required
Content-Type: application/json

{
  "accepts": [{
    "scheme": "exact",
    "network": "<blockchain network>",
    "asset": "USDC",
    "amount": "0.01",
    "payTo": "<merchant wallet address>"
  }]
}

# 3. The agent signs a payment and retries with proof attached
GET /api/market-data/today HTTP/1.1
Host: data.example.com
<payment header>: <signed payment payload>

# 4. The server verifies or settles the payment and returns the data
HTTP/1.1 200 OK
<payment response header>: <settlement receipt>

{ "prices": [ ... ] }

The appeal for agents is obvious: no account signup, no API key, no monthly invoice. An agent with a funded wallet can pay per request, which makes micropayments for data, APIs and content practical. Cloudflare co-founded the x402 Foundation, and secondary reports say x402 later moved under the Linux Foundation with support from AWS, Anthropic, Circle and others, though that detail hasn't been verified against primary sources.

MPP: machine payments across rails

MPP, the Machine Payments Protocol, launched on March 18, 2026 from Stripe and Tempo, a payments blockchain project associated with Stripe and Paradigm. Like x402 it targets machine-to-machine payments, but it is designed from the start to work across multiple rails: cards, stablecoins and others. Visa announced a card specification for MPP on launch day.

The difference in emphasis is useful to remember. x402 grew out of crypto-native, pay-per-request web payments. MPP comes from a large card-payments company and aims to make agent payments feel like any other payment method a business already accepts.

Agent identity: who is this agent?

Payments are one case of a broader problem. Whenever an agent calls an API, another agent, or a merchant, the receiver wants to know which agent this is, who it acts for, and what it may do. Traditional identity systems know about users and about services, but agents are a bit of both. Several efforts are working on this.

The IETF drafts are worth knowing by name if you work in this area, because you'll see them cited. Examples include draft-aap-oauth-profile-00, draft-klrc-aiagent-auth-00, draft-mishra-oauth-agent-grants-02, draft-mcguinness-oauth-ai-agent-instance-00 and draft-oauth-ai-agents-on-behalf-of-user-02. Anyone can submit an individual draft; it says nothing about whether the IETF will adopt it.

Identity vendors are shipping products too. Microsoft's Entra Agent ID gives agents first-class identities created from "agent identity blueprints" and applies Conditional Access policies to agent tokens; secondary sources say it became generally available in April 2026. Okta has announced Agent SSO, reported as generally available in August 2026 and built on ID-JAG tokens. Treat those dates as reported rather than confirmed.

Delegation, on-behalf-of and consent

The deepest problem in agent identity is delegation. When your assistant books a hotel, at least three identities are involved: you (the principal), the agent (the actor), and the hotel's systems (the resource). A good design keeps all three visible, rather than letting the agent simply impersonate you with your password.

1. 1

   Act on behalf of, not as

   Tokens should say both "this is agent X" and "acting for user Y." Several IETF drafts focus on exactly this on-behalf-of pattern. Logs then show which agent did what, for whom.

2. 2

   Scope narrowly

   Grant only the permissions the task needs, for only as long as it needs them. The Shared Payment Token's one-merchant, one-amount, single-use design is a good model.

3. 3

   Capture consent as evidence

   Record what the user approved in a form others can verify, as AP2's mandates do. "The user clicked OK somewhere" isn't enough when money or data is at stake.

4. 4

   Re-confirm at the moment of risk

   Ask the human again before irreversible or high-value actions. A2A's TASK_STATE_AUTH_REQUIRED and MCP's URL-mode elicitation exist so agents can pause for authorization mid-task.

5. 5

   Make delegation revocable

   Users should be able to see what each agent can do and revoke it instantly, without changing their own password.

Delegation also chains. Your agent may hand part of a task to another agent, which calls a third. Each hop should carry a narrower grant than the one before, never a broader one, and the original user's intent should remain traceable all the way down.

Risks to keep in mind