x402
An open payment standard using HTTP 402 Payment Required so a client can receive payment requirements for a resource and retry the request with proof of payment.
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?
x402 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 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 →Idempotency and Duplicate Booking Prevention
Design idempotency boundaries and duplicate-booking safeguards across travel booking, payment, cancellation and refund operations.
Explore →NDC Offer/Order Lifecycle: Search to Servicing
Model NDC Offer/Order lifecycle across search, offer, revalidation, order creation, payment, ticketing, servicing and reconciliation states.
Explore →