# MCP, A2A, PAP and Agent Payments: What Each Layer Actually Does

Compare MCP, A2A, PAP, ACP and AP2 by responsibility and maturity, with a shopping\-agent example separating access, approval, payment and verified results\.

Published: 2026-10-12T14:38:21.156Z
Updated: 2026-10-12T14:38:21.156Z
Canonical: https://realtimeavatar.ai/blog/mcp-a2a-pap-agent-payment-protocols
Markdown: [en](https://realtimeavatar.ai/blog/mcp-a2a-pap-agent-payment-protocols.md)

MCP connects an agent to tools and data; A2A coordinates communication between agents; PAP proposes how personal agents interact with businesses. ACP describes commerce flows, while AP2 addresses verifiable purchase and payment authorization. These responsibilities overlap, but the protocols are not interchangeable. None is, by itself, your application's persistent personal memory, proof of correct execution, or trustworthy approval interface. A speaking avatar is another layer: it can explain an action, not authorize or verify it.

This developer guide reflects evidence reviewed on October 12, 2026. It distinguishes published documentation from announcements, not winners from losers. The MCP references below are explicitly versioned 2025-06-18; that is the version cited, not a claim that it is the latest release.

## MCP and A2A: access is different from collaboration

### MCP: expose tools, retrieve context, enforce access

The Model Context Protocol defines how servers expose tools and resources. A shopping assistant might call an inventory tool or read a product-policy resource. The resource supplies context; the tool performs an operation. Neither tells your application whether a particular purchase is appropriate.

MCP also has an authorization specification. The cited version describes authorization for HTTP-based transports, says authorization is optional for implementations, and treats standard-input/output credentials differently. For protected HTTP services it specifies token audience validation and prohibits passing the incoming token unchanged to upstream services. So 'MCP has no authorization' is wrong; 'using MCP makes every action authorized' is also wrong.

The tools specification recommends human oversight and confirmation interfaces without mandating one interaction design. Your application must implement that experience and its enforcement. A tool appearing in a manifest is not evidence that the current user approved its next invocation.

### A2A: exchange messages, tasks and results with another agent

Agent2Agent addresses communication between agents across frameworks and organizations. Its documentation describes discovery through an Agent Card, authentication, messages, task updates and artifacts. It supports long-running and asynchronous work, including interactions where the parties do not stay continuously connected.

That makes A2A relevant when a specialist agent must investigate a delivery constraint and return later. It does not make the investigation correct or install a durable worker in your application. Persist the local task, correlate the remote identifier, and inspect the returned evidence. An agent's completed status is a protocol-level report, not independent proof that a merchant accepted an order.

## PAP: distinguish the announcement from an available contract

Sierra's October 6, 2026 announcement says Meta and Sierra are developing Personal Agent Protocol with industry partners. It describes website discovery, an OAuth-based session, guest and authenticated access, and interaction through websites, APIs or business agents. Consumers choose access while companies set what their interfaces permit.

The important maturity detail is explicit: the announcement plans publication of the v0.1 specification later in October. It presents finer permissions, push notifications and payment extensions as possibilities. The evidence reviewed here does not establish a released v0.1 specification or working interoperability. Treat PAP as a direction to evaluate, not a contract to invent from an announcement. Its mention of MCP and OpenAPI also makes it misleading to call PAP simply an MCP replacement.

## ACP and AP2: checkout and payment authority are different jobs

Here ACP means Agentic Commerce Protocol, developed by OpenAI and Stripe. Its official site describes programmatic commerce between buyers, agents and businesses, including checkout coordination and payment-credential sharing. Merchants retain their merchant-of-record role and fulfillment control. Implementing ACP does not automatically list products in an agent platform; the site's FAQ expressly separates compatibility from participation.

Agent Payments Protocol, AP2, focuses on verifiable authority for agent-initiated transactions. The reviewed documentation describes cryptographically signed credentials: checkout mandates capture purchase details, while payment mandates authorize use of a payment instrument. This is more specific than an assistant inferring permission from conversation.

Both have public technical material, but documentation is not proof that your merchant, agent and payment provider interoperate. Do not assume an ACP checkout accepts an AP2 mandate without an explicitly supported integration. Neither a signed mandate nor checkout acceptance proves settlement, shipment or a successful refund; obtain the relevant provider evidence for each claim.

- [MCP tools, version 2025-06-18](https://modelcontextprotocol.io/specification/2025-06-18/server/tools)
- [MCP resources, version 2025-06-18](https://modelcontextprotocol.io/specification/2025-06-18/server/resources)
- [MCP authorization, version 2025-06-18](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization)
- [A2A: responsibilities and request lifecycle](https://a2a-protocol.org/latest/topics/what-is-a2a/)
- [Sierra's October 6 PAP announcement](https://sierra.ai/blog/introducing-personal-agent-protocol)
- [Agentic Commerce Protocol: official overview and FAQ](https://www.agenticcommerce.dev/)
- [AP2: official overview and mandate terminology](https://ap2-protocol.org/)

## A shopping example: compare first, purchase only after approval

Consider a fictional request: 'Find a desk lamp under $80 delivered by Friday, but ask before buying.' The following is a recommended application design, not an RTA feature or a tested integration among these protocols. It deliberately does not require every protocol.

1. Compare with read-only access. Retrieve two offers through a merchant API or an implemented MCP integration. Save product identifiers, source links, quoted totals, delivery estimates and retrieval times. Do not expose a purchase operation merely because the user asked for recommendations.
2. Delegate only when needed. A merchant's supported A2A agent could investigate delivery availability. Keep that task pending until evidence returns. If no compatible agent exists, use the merchant's supported API or direct the user to its checkout. PAP's announcement alone supplies no executable endpoint.
3. Present a specific proposal. Suppose the selected lamp costs $74 including tax and shipping. Show seller, variant, address, delivery estimate and the exact charge before requesting approval. If the total changes to $82, stop and obtain fresh approval rather than reinterpreting the earlier request.
4. Submit and reconcile. Use the supported checkout and payment integration, checking authorization again at execution. Store an application operation identifier and use the provider's idempotency facility where available. If submission times out, query that operation before retrying; an unknown outcome is not a failed purchase.

Show merchant order acceptance separately from payment authorization, capture or settlement. Attach the order reference and the provider status actually obtained. A Friday delivery estimate must remain an estimate. For the detailed proposal-and-approval interface, use the separate guide below rather than rebuilding that tutorial around protocol names.

- [Designing a personal agent users can understand, correct and approve](https://realtimeavatar.ai/blog/personal-agent-trust-approval-interface)

## Where Realtime Avatar fits, and where it stops

Realtime Avatar manages speech recognition, conversational language-model processing, speech synthesis and avatar video. Your server owns session instructions and selected context. Your application owns persistent memory, credentials, permissions, protocol adapters, durable jobs and payment execution. This guide does not establish native RTA support for MCP, A2A, PAP, ACP or AP2.

Tool handlers run in your application, with a 2.5-second deadline on the client tool plane. Cancellation is cooperative: a handler ignoring its abort signal can still commit a side effect after its result is discarded. Recommended pattern: durably accept slow work, acknowledge within the deadline, and display its eventual authoritative result. Ending a call must not be presented as cancelling a purchase.

An external language-model endpoint requires workspace approval and a host allowlist. The public SDK does not accept arbitrary live audio from your own text-to-speech service. Optional signed transcript delivery is separate from diagnostic logs, which can contain conversation text and have a 30-day storage lifecycle. Disabling delivery does not establish zero retention. Keep payment credentials out of conversational context.

## Frequently asked questions

### Do I need both MCP and A2A?

Not necessarily. A direct tool-backed lookup may need no agent-to-agent conversation. Choose A2A when a supported remote agent must exchange messages and task progress. Choose interfaces by the boundary you need, not by collecting protocol names.

### Can I implement PAP from the October announcement?

Use it for requirements discussions, not invented wire formats. This review has not established v0.1 availability. Before implementation, obtain the published specification, version and a compatible counterparty; the announced publication plan alone is insufficient.

### Does AP2 replace my payment processor?

No. Its documented roles include credential providers, payment networks and merchant payment processors. Verifiable authorization is not the movement of funds. Confirm support with your providers and retain their transaction evidence.

### Where should cross-session memory and purchase history live?

In application-owned storage with explicit access and deletion policies. Keep approved proposals and provider receipts distinguishable from conversation summaries. Supply only relevant context to a new call; neither protocol compatibility nor an RTA session automatically supplies persistent personal memory.

If spoken comparison would help your users, start with a read-only RTA prototype. Review the session and tool boundaries before connecting any purchase capability.

- [Realtime Avatar session policy and context](https://realtimeavatar.ai/docs/sessions)
- [Realtime Avatar tool execution and deadlines](https://realtimeavatar.ai/docs/tool-calling)