Protocol Comparison

The four agentic commerce protocols represent different approaches to the same fundamental challenge. This page maps their coverage, identifies the structural gaps they share, and describes where Integra's infrastructure complements them.

Feature Comparison

What They All Handle

Despite their different approaches, the four protocols collectively cover the purchase transaction lifecycle. This is the problem they were built to solve, and they solve it with varying degrees of sophistication.

Discovery and Initiation

Three of the four protocols (UCP, AP2, ACP) define discovery mechanisms that allow agents to find and evaluate potential transaction partners without prior arrangement. VI focuses on the delegation chain rather than discovery, assuming the agent has already identified the merchant.

Authentication and Trust

Each protocol provides a mechanism for parties to authenticate each other, ranging from bearer tokens (ACP) to multi-level credential chains (VI). The sophistication varies, but the core function is consistent: before transacting, parties establish that the other party is who they claim to be.

Cart and Checkout

All four protocols define how an agent selects items, confirms a purchase, and initiates payment. The abstractions differ — mandates, sessions, composable capabilities — but the functional coverage is similar.

Payment Processing

All four protocols integrate with existing payment infrastructure rather than creating new payment rails. This is a sound architectural decision. Payment processing is a solved problem with decades of infrastructure, regulatory compliance, and fraud prevention. The protocols focus on the agent-specific aspects (delegation, constraint verification, trust establishment) and delegate the actual movement of money to established processors.

What They All Defer

The gaps are more revealing than the coverage. Five structural capabilities are absent from all four protocols. These are not oversights — they are genuinely hard problems that the protocol designers chose not to address in their first specifications. But they are also not optional for a functioning agent commerce ecosystem.

1. Dispute Resolution

This is the most consistently deferred capability. The protocols' own language tells the story:

• VI (Section 2.4): "VI does not define how disputes are initiated, routed between parties, escalated, or resolved."
• AP2: "Disputes follow existing regulations; innovate only where necessary."
• ACP: The specification does not mention disputes.
• UCP: Order lifecycle webhooks provide status updates, not dispute mechanisms.

Current fallback: credit card chargebacks, platform-specific complaint processes, and direct negotiation. These mechanisms were designed for human parties interacting through web interfaces. They assume a complainant who can write a description of the problem, a respondent who can review evidence, and a timeline measured in days or weeks.

When both parties are AI agents, when transactions span milliseconds, and when the volume of transactions exceeds human review capacity, these fallback mechanisms will not scale.

2. Persistent Identity

All four protocols scope identity to the transaction or session.

• VI's L1 credential has a longer lifetime (~1 year), but it is bound to Mastercard's card network
• UCP's DNS-based identity persists as long as the domain does, but carries no transaction history
• AP2's VDCs are credential-scoped, not relationship-scoped
• ACP's bearer tokens are session-scoped

No protocol provides a mechanism for an agent to accumulate a verifiable reputation across transactions, carry a dispute history, or maintain a persistent identity that spans protocols. An agent that has completed a thousand successful transactions through VI has no way to present that track record when interacting through UCP.

This matters because trust in commerce is cumulative. Businesses evaluate counterparties based on history. An identity that resets with every session cannot accumulate trust.

3. Entity Authority

None of the protocols verify organizational authority for high-value commitments. When an AI agent claims to act on behalf of Acme Corporation:

• Who within Acme authorized the agent?
• Under what corporate governance rules?
• With what spending limits?
• Subject to what internal approval processes?

VI verifies that a human authorized an agent. It does not verify that the human was authorized to make that commitment on behalf of their organization. UCP verifies that a domain is controlled by an entity. It does not verify that the person operating the API has the authority to bind that entity. AP2's VDCs can carry organizational claims, but the protocol does not define how those claims map to actual corporate governance.

For consumer purchases, this gap is manageable — the cardholder authorized it, the cardholder is liable. For B2B transactions, enterprise procurement, or any commitment that requires organizational authority, the gap is structural.

4. Agreement Lifecycle

Every protocol models the commitment as a single exchange. Buy, pay, receive. The session ends.

Real commerce includes:

• Multi-year service contracts with performance obligations, renewal terms, and termination clauses
• Subscription agreements with usage-based pricing, tier changes, and billing disputes
• Licensing arrangements with royalty calculations, audit rights, and territory restrictions
• Framework agreements with volume commitments, pricing schedules, and exclusivity terms

None of these can be represented as a checkout session. They require persistent state, ongoing monitoring, periodic reconciliation, and enforcement mechanisms that extend over months or years.

5. Jurisdictional Linkage

All four protocols are jurisdiction-agnostic by design. This is a deliberate choice that maximizes global adoption and minimizes regulatory complexity.

It also means that when a dispute arises, no protocol provides:

• Which country's consumer protection laws apply
• Which courts have jurisdiction
• Which regulatory frameworks govern the transaction
• What remedies are available and enforceable

For domestic consumer purchases, jurisdiction is usually clear — the buyer's location determines applicable consumer protection law. For cross-border transactions, for B2B commitments, and for agent-mediated interactions where the parties may be in different jurisdictions from their agents, the question becomes genuinely complex.

Where Integra Fits

Integra does not compete with these protocols. It complements them.

Sequential Layers

The commerce protocols handle Phase 1: the purchase transaction. Discovery, authentication, cart building, payment authorization, fulfillment tracking. This is necessary infrastructure, and it is being built well by teams with deep domain expertise.

Integra handles what comes after:

Composability, Not Replacement

The design principle is composability. An AI agent might use:

• VI to prove it is authorized by a verified human within specific constraints
• UCP to discover a merchant's capabilities and complete a checkout with a signed merchant authorization
• Integra to bind that transaction to a persistent identity, link it to an enforceable agreement, and route any dispute to a structured resolution process

Or it might use ACP for the checkout moment and Integra for everything that surrounds it. The protocols are interchangeable at the commerce layer. Integra operates at the layer below — identity, agreements, and enforcement — which is protocol-agnostic by design.

The Critical Boundary

The commerce protocols were built by payments and technology companies solving the problem they know best: how to move money in exchange for goods. They solve it well.

The problems they defer — identity, agreements, disputes, jurisdiction — are problems that require different expertise: legal methodology, dispute resolution design, jurisdictional analysis, and the connection between digital systems and legal systems. These are problems that do not resolve through better APIs. They resolve through infrastructure that understands the boundary between what code can enforce and what requires human judgment, legal authority, and institutional trust.

That boundary is where Integra operates.