---
title: "ACP, UCP, AP2, MPP, x402, MCP and A2A: Protocol Landscape for Travel"
description: "Compare ACP, UCP, AP2, MPP, x402, MCP and A2A by the architecture layer they solve in agentic travel commerce."
slug: "agentic-commerce-protocol-landscape"
translationKey: "guide-agentic-commerce-protocol-landscape"
locale: "en"
type: "guide"
category: "architecture"
tags: ["acp","ucp","ap2","mpp","x402","mcp","a2a","agentic-commerce"]
publishedAt: "2026-09-27"
updatedAt: "2026-09-27"
reviewedAt: "2026-09-27"
technicalVerifiedAt: "2026-09-27"
codeExampleStatus: "illustrative"
sources:
  - title: "Agentic Commerce Protocol"
    url: "https://www.agenticcommerce.dev/docs"
  - title: "Universal Commerce Protocol"
    url: "https://ucp.dev/"
  - title: "Agent Payments Protocol"
    url: "https://github.com/google-agentic-commerce/AP2"
  - title: "Machine Payments Protocol"
    url: "https://mpp.dev/"
  - title: "x402"
    url: "https://x402.org/"
  - title: "Agent2Agent Protocol"
    url: "https://a2a-protocol.org/"
---

Agentic-commerce protocols should not be treated as one winner-takes-all category. For travel architecture they sit at different layers: **tooling, agent coordination, commerce interaction, payment authorization and payment rails**.

## Layer summary

| Protocol | Primary layer | Possible travel role |
|---|---|---|
| MCP | Tool/resource access | expose search, reprice, booking and servicing tools |
| A2A | Agent coordination | planner/payment/servicing agent collaboration |
| ACP | Agentic checkout / commerce interaction | agent-seller checkout and delegated-payment flows |
| UCP | Commerce interoperability | merchant/agent commerce capability discovery and checkout |
| AP2 | Payment authorization/evidence | mandates, verifiable intent, autonomous payment authorization |
| MPP | Machine payments | agent/API machine-native payments |
| x402 | HTTP-native payments | paid APIs and resources using HTTP 402 |

## ACP

ACP defines purchase interaction and checkout interfaces between buyers, agents and businesses. In travel it is not a replacement for NDC or hotel booking APIs; it is better viewed as a commerce/checkout boundary around travel domain flows.

## UCP

UCP targets interoperable commerce capabilities. Travel implementations should preserve reprice, availability and booking/ticketing semantics rather than forcing retail-cart assumptions directly onto travel offers.

## AP2

AP2 focuses on agent payment authorization and evidence. Travel use cases include delegated limits, human-not-present transactions, verifiable intent and mandate evidence. It is not a booking protocol.

## MPP

MPP addresses machine-to-machine payments. Travel examples can include paid supplier APIs, premium data services or machine-billed ancillary capabilities. It does not by itself solve consumer booking lifecycle.

## x402

x402 brings programmatic payment to HTTP using 402 semantics. It fits paid APIs, premium resources and machine-commerce scenarios more naturally than core booking state.

## MCP

MCP is a useful travel tool abstraction for search, reprice, create/retrieve/cancel and refund operations. It does not define authorization or booking semantics.

## A2A

A2A standardizes collaboration among agents. A travel planner, loyalty agent, payment agent and servicing agent can coordinate through it while keeping their own domain responsibilities.

## Protocol composition

```mermaid
%% title: Agentic travel protocol composition
%% description: Tooling, agent coordination, commerce interaction and payment protocols compose around the travel domain.
flowchart TD
  A[User / Buyer Agent] --> B[A2A Agent Coordination]
  B --> C[MCP Travel Tools]
  C --> D[Travel Domain: Search / Offer / Booking / Servicing]
  A --> E[ACP / UCP Commerce Interaction]
  E --> D
  A --> F[AP2 Authorization Evidence]
  F --> G[Payment Layer]
  H[MPP / x402 Machine Payments] --> G
  G --> D
```

## Selection criteria

Do not ask only which protocol to choose. Ask which problem layer exists: tool access, agent collaboration, checkout interoperability, delegated authorization or machine-native payment. A production system can use several protocols together.

## Travel-specific constraints

Regardless of protocol, preserve offer freshness, reprice, UNKNOWN booking state, idempotency, payment/booking separation, passenger PII boundaries and servicing/reconciliation.

## Failure modes

Treating a commerce protocol as the travel booking model, treating MCP invocation as authorization, equating payment success with booking success, version mismatch and losing travel-specific state under generic checkout abstractions.

## Observability

Track capability-negotiation failures, version mismatches, protocol-specific error rates, authorization rejection, fallback-path usage and any travel-domain reconciliation triggered by protocol-layer ambiguity.

## Production checklist

Maintain protocol-boundary maps, version pinning, capability negotiation, canonical travel models, authorization evidence, idempotent side effects, PII redaction and protocol-specific observability.