AP2: How Can a Merchant Verify an Agent Is Authorized to Buy?

You ask a shopping agent to buy black shoes in stock today for at most $100 total. Hours later it finds an item and prepares to pay. A merchant and payment provider need more than the identity of the requester: was the agent authorized, and does this purchase meet the user’s conditions? AP2 (Agent Payments Protocol) addresses how such authorization can be expressed and verified.

Shoes and prices are hypothetical. This describes the public AP2 specification; no merchant or payment service was tested. Sources reviewed October 28, 2026.

Two kinds of mandate

AP2 uses verifiable, tamper-evident digital credentials called mandates:

Record	Main question	Interested parties
Checkout Mandate	What checkout contents were authorized?	Merchant validating purchase and terms
Payment Mandate	Was a payment instrument authorized for that checkout?	Credential provider, network and merchant payment processor, according to their roles

Mandates can bind to specific checkout contents so participants can verify signatures, content and restrictions. The specification also describes receipts for recording results and potential disputes; it does not completely resolve dispute outcomes or retention periods. See the AP2 specification.

User present and absent

When present, the user may review a concrete checkout in a trusted interface and confirm the purchase and payment. When absent, they first approve conditions; the agent later finds a suitable item and forms authorization for the transaction.

flowchart TD A[User provides conditions] --> B[Trusted interface obtains consent] B --> C[Create open authorization with limits] C --> D[Agent finds item and forms checkout] D --> E[Create closed authorization for transaction] E --> F{Merchant and payment parties verify signature and conditions} F -->|Pass| G[Continue payment and order] F -->|Fail| H[Reject or handle error]

An open authorization describes limits on future transactions; a closed authorization binds a particular transaction. The specification binds open authorization to an agent public key and recommends a short expiry. Verifiers must check whether the transaction satisfies the limits. See the authorization framework and specification.

For example, black shoes totaling $95 including tax might satisfy a $100 limit; if shipping brings the total to $105, the system should reject or obtain new authorization under its rules. This explains the design, not a claim that every product supports these exact conditions.

What does a signature prove?

A valid signature helps establish origin and integrity. Verifiers must also check constraints, transaction binding and trust. A signature alone does not prove product quality or merchant delivery and cannot make an issuer approve a card transaction. Stolen agent keys or a flawed signing step require other security controls.

AP2 is neither a wallet nor a payment network. It provides authorization evidence; supported payment instruments move funds, while other commerce components handle catalog, inventory, delivery and checkout APIs.

AP2, UCP and x402

UCP’s AP2 extension describes including mandates in a UCP checkout. AP2 also offers x402-related examples. Examples and extensions do not prove arbitrary products work together out of the box: verify versions, mandate formats, payment methods and validation. See AP2.

Further reading: specification, user-present and absent flows, and UCP’s AP2 extension.