Agent Payments Protocol (AP2)
The most detailed open attempt at verifiable user intent for agent purchases.
Flows / Agent to agent, agent to web
Agent payments with signed mandates
The user signs what the agent may buy. The agent proves, to the merchant and to the payment network, that a purchase falls inside it.
Payments are where “the agent says the user wanted this” stops being good enough. If an agent buys the wrong thing, someone bears the cost, and the merchant, the card issuer and the user will each want evidence of what was authorized.
The Agent Payments Protocol answers with mandates: digitally signed statements of what a user has approved. In the current version there are two kinds. A checkout mandate shows a merchant that the agent may complete a particular purchase. A payment mandate shows the payment side that the agent may pay for it. Each comes in two forms. A closed mandate authorizes one specific checkout. An open mandate sets out constraints in advance, for when the user will not be there, and names the agent’s key so the agent can later sign closed mandates that stay within those limits.
The diagram shows the second case: the human approves the boundaries, leaves, and the agent shops inside them.
Step by step
10 steps between 4 parties. Each step shows the message and who holds which credential afterward. Use ←→ or select any arrow.
Sequence diagram4 participants, 10 steps
- Direct call
- Via the user’s browser or device
- Response
- Local action
Drag to see every party and step. Tap a step to jump to its explanation.
The user approves constraints, not a purchase
“Buy these running shoes in size 43 if the price drops below €120, this month.” The user reviews and signs on a trusted surface, a piece of interface that the protocol requires to be non-agentic. The result is a pair of open mandates, checkout and payment, that carry the constraints and the public key of the agent allowed to act on them.
Who holds what after this step
- Shopping agent
- newopen mandates (user-signed)
Parties not listed hold none of this flow’s credentials at this point.
The agent works alone
Days later, with the user absent, the agent finds an offer that satisfies the constraints.
Who holds what after this step
- Shopping agent
- open mandates (user-signed)newagent key
Parties not listed hold none of this flow’s credentials at this point.
The agent builds a checkout with the merchant
Through whatever commerce protocol the merchant supports. The payment protocol sits beneath it as the authorization layer.
Who holds what after this step
- Shopping agent
- open mandates (user-signed)agent key
Parties not listed hold none of this flow’s credentials at this point.
The merchant commits to the terms
The merchant signs the checkout: items, price, totals. This fixes what is being bought, so the agent’s authorization can refer to it by hash.
Who holds what after this step
- Shopping agent
- open mandates (user-signed)agent keynewsigned checkout
Parties not listed hold none of this flow’s credentials at this point.
The agent authorizes this specific purchase
Using the key named in the open mandates, the agent signs closed checkout and payment mandates bound to the merchant’s signed checkout. Anyone verifying them can follow the chain: the user authorized this key within these limits, and this key authorized this purchase.
Who holds what after this step
- Shopping agent
- open mandates (user-signed)agent keysigned checkoutnewclosed mandates (agent-signed)
Parties not listed hold none of this flow’s credentials at this point.
The agent asks the payment side for a credential
The credential provider holds the user’s payment methods. It receives the payment mandate and only the details it needs.
Who holds what after this step
- Shopping agent
- open mandates (user-signed)agent keysigned checkoutclosed mandates (agent-signed)
Parties not listed hold none of this flow’s credentials at this point.
The payment side checks the delegation
Is the open mandate genuinely signed by the user? Does it name this agent’s key? Is the closed mandate inside the constraints? The protocol requires this to be done by deterministic code, not by a model.
Who holds what after this step
- Shopping agent
- open mandates (user-signed)agent keysigned checkoutclosed mandates (agent-signed)
Parties not listed hold none of this flow’s credentials at this point.
A credential usable for this payment
Typically a network token or similar single-purpose credential, not the underlying card number.
Who holds what after this step
- Shopping agent
- open mandates (user-signed)agent keysigned checkoutclosed mandates (agent-signed)newpayment credential (this purchase)
Parties not listed hold none of this flow’s credentials at this point.
The agent completes the purchase
The merchant receives the checkout mandate, proof that this agent is entitled to complete this checkout, together with the payment credential.
Who holds what after this step
- Shopping agent
- open mandates (user-signed)agent keysigned checkoutclosed mandates (agent-signed)payment credential (this purchase)
Parties not listed hold none of this flow’s credentials at this point.
Receipts close the loop
The merchant returns a checkout receipt and the processor a signed payment receipt. With the mandates, they form the evidence trail if the purchase is ever disputed.
Who holds what after this step
- Shopping agent
- open mandates (user-signed)agent keysigned checkoutclosed mandates (agent-signed)used up
payment credential (this purchase)
Parties not listed hold none of this flow’s credentials at this point.
Watch out for
- This is pre-1.0 and changing. The mandate model was redesigned between the first and second versions, and stewardship has moved to a standards body where work is only starting.
- There are several competing and overlapping efforts from card networks, payment processors and AI vendors. None has settled as the standard.
- An open mandate is a signed blank cheque with limits. The limits are the security: amount, merchant, items, expiry.
- The user’s consent must be captured on a surface the agent does not control. If the agent draws the approval screen, the signature proves nothing.
The same idea in OAuth terms
A mandate is a transaction-specific authorization that can be verified offline by several parties. Rich Authorization Requests express the same intent inside OAuth, with the authorization server as the single verifier. The payments world chose signed credentials because merchants, processors, networks and issuers each need to check the evidence independently, sometimes long after the fact.
Standards in play
See the full tracker for status and links.
Verifiable Intent
A card network’s take on the same problem AP2 addresses.
SD-JWT
The format behind payment mandates and delegated credentials in agent commerce.
OpenID for Verifiable Presentations
How an agent, or a user on its behalf, presents a signed mandate to a verifier.
Agentic Commerce Protocol
Payment delegation by scoped token instead of signed mandate.
Trusted Agent Protocol
Web Bot Auth extended with commerce context.
x402
Payment as the credential. No identity layer; suited to pay-per-call access by autonomous agents.
Related flows
Web Bot Auth
An agent that browses the open web signs its requests, so a site can tell which operator it belongs to without trusting a user-agent string.
With or without a humanEmerging
Backchannel approval (CIBA)
The agent asks the authorization server to go and find the user. Approval arrives as a push notification, not a redirect.
Human reachableStable standards
Step-up authorization
Start with a weak token. When the agent reaches something sensitive, the API says so and the user is asked for exactly that.
Human presentStable standards
Agent to agent (A2A)
One agent discovers another, reads what credentials it wants, and presents them. When the remote agent needs more, it says so mid-task.
With or without a humanEmerging