MPP
An open protocol standardizing machine and agent payments inside HTTP request flows through payment challenges, credentials and receipts. It is designed to be payment-method agnostic.
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?
MPP 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 →Canonical Offer, Order and Booking State Model
Design canonical Offer, Order and Booking lifecycle boundaries with an explicit booking state machine for travel integrations.
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 →