Agentic payment protocols: a responsibility map

Start with jobs, not acronyms

Discovery protocols expose catalogs, capabilities, and checkout state. Interoperability protocols let agents call tools or other agents. Authorization protocols preserve user intent and mandates. Recognition protocols help merchants identify trusted agent traffic. Payment protocols carry a challenge and credential. Rails authorize, clear, and settle value.

A single transaction can legitimately use several of these. For example, an agent may call an MCP tool, use AP2 evidence for authority, receive an x402 challenge, settle USDC through a facilitator, and preserve the merchant receipt in an internal evidence ledger.

Responsibility matrix

Evaluate protocols against the job you actually need to solve.

Fourteen questions for any protocol

A fair comparison needs the same dimensions. Marketing claims often describe a smooth demo without stating custody, reversibility, governance, or the evidence left behind.

• What is the protocol’s primary job?
• How are principal, agent, and merchant identified?
• How is transaction authority represented and revoked?
• Which rails, assets, and networks are supported?
• Who holds or signs with payment credentials?
• Is settlement immediate, authorized-then-captured, or deferred?
• What prevents replay and duplicate execution?
• How are refunds, reversals, and disputes represented?
• What receipt or mandate artifacts remain after the transaction?
• Can policy require human confirmation?
• How does the protocol version and evolve?
• Which components are production, preview, proposal, or demo?
• What trusted third party or facilitator is introduced?
• How can a merchant reconcile the protocol with order and fulfillment state?

Composition is the likely end state

Standards are converging around reusable primitives rather than one universal stack. Signed HTTP requests can coexist with scoped payment tokens. An AP2 mandate can authorize a card or stablecoin flow. MCP can expose either a checkout tool or a payment-gated resource.

Architect for composition by preserving a stable internal transaction model and treating protocols as adapters. The system should be able to say which layer supplied identity, authority, execution, settlement, and post-purchase evidence for each transaction.