AP2
An open payment-authorization protocol for proving user authority and transaction intent in agent-performed payments through verifiable mandates. It is not itself a commerce protocol; it focuses on the payment trust and authorization layer.
Why it matters
Agentic commerce combines model reasoning with deterministic transaction systems. Tool access, commerce state, payment authorization and user intent are not the same thing; each layer needs explicit boundaries and an authority model.
What does it look like in practice?
A travel agent may use MCP or provider APIs for capabilities, prepare checkout through a commerce contract such as UCP/ACP, and involve separate authorization/payment layers such as AP2, MPP or x402. These protocols do not solve the same problem.
Implementation questions
- Which capabilities can the agent access?
- What action and amount did the user explicitly authorize?
- Is transaction state held in a deterministic system independent of the model?
- Where are audit trails and human-approval checkpoints?
Common mistakes
- Treating an LLM decision as payment authorization
- Equating tool access with purchase authority
- Treating protocol names as one interchangeable agentic-commerce standard
Where does it appear in the travel stack?
AP2 commonly appears across agentic layers. Its implementation should make source-of-truth, identity, freshness and transaction-ownership boundaries explicit.
Related terms
Related technical guides
ACP, UCP, AP2, MPP, x402, MCP and A2A: Protocol Landscape for Travel
Compare ACP, UCP, AP2, MPP, x402, MCP and A2A by the architecture layer they solve in agentic travel commerce.
Explore →Agentic Travel Authorization, Mandates and Human-in-the-Loop
Design user intent, mandates, delegated authority and human-in-the-loop checkpoints for AI-driven travel purchase and servicing side effects.
Explore →Agentic Travel Reference Architecture
Design AI agent → search → offer → reprice → confirmation → payment → booking → servicing with travel-specific authorization, idempotency and audit boundaries.
Explore →Agentic Travel Servicing, Consent and Auditability
Design agent-driven cancellation, refund and servicing with explicit consent, traceability, versioned evidence and post-booking authorization boundaries.
Explore →Agentic Travel Transaction Safety
Prevent duplicate booking and payment caused by agent loops, retries and tool invocation using idempotency, side-effect guards and UNKNOWN-aware recovery.
Explore →Cloudbeds API: PMS and Hospitality Connectivity Profile
A technical profile of Cloudbeds APIs for PMS reservations, guests, rooms, payments, reporting and hospitality application integrations.
Explore →