If you're building infrastructure for AI agents, you're about to hit a question that has no clean answer: how does an AI agent actually pay for something?

It sounds simple until you try to implement it. Do you tokenize the agent's authority? Use a new payment method entirely? Build on cards, or go on-chain? What happens when multiple vendors need different pieces of information? Who verifies the agent isn't a fraud? What if the agent was compromised?

We've spent the last year deep in this problem at Prava. And what we've learned is that the payments industry hasn't answered these questions with one standard. It's answered them with eight. Maybe nine, depending on how you count.

That's a sign that the problem is genuinely hard, and that different parts of the problem need different solutions.

What follows is the map we've built internally to make sense of this landscape: every major protocol, where it sits in the architecture, what it actually solves, and where the gaps are. If you work in AI payments, B2B SaaS, or agent infrastructure, you need to understand all of these. Your agents will encounter most of them.

The Stack Structure

Think of agentic payments like a networking stack. Just as the internet works in layers (physical, network, transport, application), agentic payments breaks into distinct layers, each solving a specific problem.

From bottom to top:

• Communication infrastructure at the base

• Trust and identity above that

• Authorization and mandates in the middle

• Transaction flow above that

• Payment rail settlement at the top

Most protocols are specialized. They don't do everything. They do one layer well. That's an important design insight, but it's also why integration across layers is where most of the real engineering difficulty lives.

We'll walk through each layer from the bottom up.

Communication Infrastructure: The Foundation

Before any payment can happen, the agent and the merchant need to talk. And the agent needs to talk to many merchants.

MCP (Model Context Protocol) and A2A (Agent-to-Agent) are the plumbing. MCP is Anthropic's open standard for how AI systems call external tools and services. A2A is the broader pattern of machine-to-machine communication for autonomous systems. Neither is a payments protocol specifically, but both are essential: if the agent can't call the merchant's system reliably, none of the payment standards above matter.

Think of this layer as the TCP/IP of agentic commerce. Everything above depends on it.

Trust and Identity: Proving the Agent Is Real

This is where the problem starts getting genuinely difficult, and where we see the most divergence in approach.

An agent isn't a person. It has no social security number, no credit history, no legal identity. How does a merchant know the agent is legitimate and not a bot designed to commit fraud?

Today, there are two competing philosophies: centralized trust anchored by a network, and decentralized trust anchored on-chain.

Visa TAP: Trusted Agent Protocol

Visa introduced TAP in 2025 as part of their Intelligent Commerce program. The design is cryptographic and sophisticated.

Agents are onboarded into Visa's program. Once accepted, they receive a cryptographic identity. When the agent initiates a transaction, it signs the request using RFC 9421 (HTTP Message Signatures). The signature proves two things: the request came from that specific agent, and the request hasn't been tampered with in transit.

TAP is context-bound. The signature includes details about what's being purchased, how much, and from whom. You can't replay a TAP signature from one transaction to another.

The code is open source on GitHub. 100+ organizations have integrated it; 30+ are in sandbox mode. Visa built it with Cloudflare, so it's designed to handle scale.

What this means in practice: TAP is strong for agents operating within the Visa ecosystem. But if your agent needs to transact across ecosystems, across Visa and non-Visa merchants, on-chain and off-chain, you need a trust layer that can bridge between identity systems. That's a gap we think about constantly.

On-Chain Agent Identity and Reputation

For merchants operating on blockchain rails, there are ERC standards that provides agent identity and reputation directly on-chain.

This is a smart contract standard. It encodes the agent's identity, reputation score, historical transaction history, and escrow logic for trustless collaboration. If an agent needs to prove it's trustworthy without relying on a centralized authority like Visa, it can point to its on-chain track record.

It is still early. But if on-chain settlement becomes a dominant payment rail for agents (and for micropayments, it's already heading that direction), this is where identity lives.

The fragmentation problem is already visible here. Two legitimate, well-designed identity standards. Neither talks to the other. An agent that has a strong TAP reputation has zero reputation on-chain, and vice versa. Whoever solves cross-system trust portability will have a massive advantage.

Authorization and Mandates: What Is the Agent Allowed to Do?

Once you trust the agent exists, the next question is: what authority did the human give it? Can it spend $10 or $10,000? Can it buy anything, or only travel bookings? Is the authorization good for one transaction or many?

This is the mandate layer. A mandate is a signed instruction that says: "the human authorizes this agent to do this specific thing within these constraints."

Getting this right is critical. Too loose and you have a fraud problem. Too tight and the agent can't actually do anything useful. The mandate layer is where consumer protection and agent autonomy have to coexist, and that balance is hard.

AP2: Agent Payments Protocol (Google)

Google's AP2 is the mandate standard. It's open source under Apache 2.0. 60+ partners use it: Mastercard, PayPal, Coinbase, Shopify, and many others.

The architecture is elegant. Instead of the agent presenting a payment method directly, it presents a Verifiable Digital Credential (VDC), a cryptographic proof that a human authorized this agent to transact under specific conditions.

Think of a VDC like a letter of credit from a bank, but for software. The human signs it. The merchant verifies the signature. The agent presents it.

AP2 is transport-agnostic. It works with cards, stablecoins, and bank transfers. It just says: "Here's proof the human authorized this agent. Here's the scope: amount, currency, merchant category, expiration." The actual payment rail can be anything.

This separation of mandate from settlement is a critical design choice. It means different merchants can accept different payment methods while the authorization layer stays consistent.

Mastercard Agent Pay

Mastercard's Agent Pay takes a network-centric approach to agent authorization. Rather than separating the mandate from the payment instrument the way AP2 does, Mastercard bundles them together.

The human authenticates (passkey, biometric, or MFA). Mastercard issues a tokenized credential specific to that agent, scoped to that authorization. The token is bound to the agent's identity via the Mastercard network, and it carries metadata: spending limits, merchant categories, DSP ID (digital service provider), and expiration.

The advantage of this approach is that it leverages Mastercard's existing infrastructure and merchant acceptance. The tradeoff is that the mandate and the payment rail are tightly coupled. Your agent infrastructure needs to handle this paradigm alongside the decoupled model that AP2 uses.

Visa Intelligent Commerce

Visa's Intelligent Commerce initiative is their broader strategic umbrella for agent-enabled payments. TAP (covered in the identity layer above) is one piece of it. But Visa's ambition extends beyond identity verification into the full authorization flow.

Through Intelligent Commerce, Visa is positioning itself to issue agent-specific credentials, define spending policies, and provide real-time fraud signals tuned for autonomous transactions. The program also includes partnerships with agent platforms and wallet providers to embed Visa-powered authorization directly into agent workflows.

Where Mastercard's approach centers on tokenization through their existing vault infrastructure, Visa is building a broader framework that spans identity, authorization, and transaction monitoring. Both networks are racing to become the default trust anchor for agentic commerce.

The pattern you should notice: AP2 decouples the mandate from the payment rail. Mastercard and Visa bundle them together in different ways. All three approaches work. But they work differently, which means your agent infrastructure needs to handle multiple authorization paradigms. This is exactly the kind of complexity that compounds as you scale.

Transaction Flow: How the Agent Actually Buys Something

This is where protocols diverge most dramatically. Some handle product discovery. Some handle pure checkout. Some try to span the entire customer journey. Each makes different tradeoffs, and if you're building agent infrastructure, you'll likely need to support more than one.

ACP: Agentic Commerce Protocol (OpenAI/Stripe)

ACP is the narrowest in scope and the most focused. It solves one problem: chat-to-buy.

An AI assistant is talking to a user. The user says "I want this product." The assistant needs to complete the purchase without redirecting to a browser, without re-entering information, without breaking the conversation.

ACP defines four REST endpoints:

• CreateCheckout: Agent initiates a purchase. Returns a session ID and payment details.

• UpdateCheckout: Agent adds items, modifies quantities, applies discounts.

• CompleteCheckout: Agent submits the payment and finalizes the transaction.

• CancelCheckout: Agent abandons the transaction.

Security uses a SharedPaymentToken: single-use, time-bound, specific to that session and amount. Can't be reused, can't be modified, expires in minutes.

ACP is live. OpenAI integrated it into ChatGPT Instant Checkout. Etsy and other merchants are on it. Stripe is rolling it out to over 1M Shopify merchants.

The design is pragmatic, and that's also where its biggest limitation lives. ACP only works with Stripe merchants. If a merchant processes payments through Adyen, Checkout.com, Braintree, or any other processor, ACP simply doesn't reach them.

Think about what that means from the user's perspective. A person talking to an AI assistant says "buy me running shoes." The assistant finds the right pair. The merchant happens to process through Adyen. The transaction fails silently, or the agent has to redirect to a browser, breaking the exact experience ACP was designed to enable.

The user doesn't know or care what payment processor a merchant uses. They shouldn't have to. But ACP makes that infrastructure detail into a hard boundary on what the agent can actually do. For any AI application that wants to offer commerce across a broad set of merchants, ACP alone is insufficient. It needs an infrastructure layer underneath that can route transactions regardless of what processor the merchant sits on.

APP: Agentic Product Protocol (Klarna)

Klarna's APP is the inverse of ACP. Where ACP completes a purchase, APP helps the agent figure out what to buy. An agent doesn't know what products exist until someone tells it. APP defines how merchants publish product information so agents can search and filter.

Two core entities:

• Products: searchable catalog with attributes, descriptions, images. Free text search plus structured filters (price, size, color, availability).

• Offers: rich product details including inventory, shipping costs, promotions, and stock levels.

Merchants can feed APP data from multiple sources: Google Merchant, Shopify, Amazon. Klarna indexes 100M+ products across 12 markets.

APP doesn't complete the purchase. It makes the product findable and understandable to the agent. The purchase itself happens via ACP, UCP, or whatever the merchant supports.

The limitation here mirrors the one we see with ACP. APP's catalog is bounded by Klarna's merchant network. 100M+ products sounds impressive, but the total addressable catalog of global e-commerce is orders of magnitude larger. If a merchant hasn't integrated with Klarna's ecosystem, their products are invisible to any agent relying on APP for discovery.

For an AI application trying to give users the best product recommendation, a discovery layer that only surfaces a subset of what's available creates a quietly broken experience. The user gets a recommendation, assumes it's the best option, and never knows what they didn't see. The agent needs a discovery layer that spans merchant networks, not one locked to a single provider's partnerships.

UCP: Universal Commerce Protocol (Google/Shopify)

UCP is the broadest protocol. Google and Shopify announced it in January 2026 at NRF. It's designed to handle the entire commerce journey in one standard.

The architecture is layered:

• Shopping Service (core primitives): product search, cart management, order placement, tracking.

• Capabilities (what merchants can actually do): checkout, orders, catalog, fulfillment, discounts, offers.

• Extensions (customization): merchants add specific behavior on top of the base capabilities.

Merchant discovery is elegant: merchants publish a /.well-known/ucp manifest that lists what they support.

The transport layer is agnostic. UCP can run over REST, MCP, A2A, or any protocol. The standard defines the commerce flow itself and leaves the transport mechanism to the implementer.

UCP is the most ambitious of the three, and on paper it addresses some of the limitations we flagged with ACP and APP. But ambition and adoption are different things. UCP only works where merchants have implemented it. A merchant that hasn't published a UCP manifest, or has only implemented a partial subset of the spec, is invisible or unreliable to agents using the protocol.

The early adoption is concentrated around Shopify's ecosystem and large retailers with the engineering resources to implement a new standard. The long tail of e-commerce, the millions of merchants on other platforms, custom stacks, and legacy systems, remains largely unreachable through UCP today.

This is the recurring pattern across all three transaction-layer protocols. Each one works well within its own ecosystem. ACP works with Stripe merchants. APP works with Klarna's catalog. UCP works with merchants who've adopted the spec. None of them solve the universal coverage problem on their own.

For any AI application that wants to offer a seamless commerce experience, the question becomes: who stitches these ecosystems together? The agent shouldn't need to know which protocol a merchant supports. The agent shouldn't need to know which payment processor the merchant uses. That complexity belongs in the infrastructure layer, abstracted away from both the AI application and the end user. That's the layer we're building at Prava.

Payment Rail and Settlement

Once the transaction is authorized and the purchase completed, the money has to move. This layer is where payment methods live: cards, bank accounts, stablecoins.

Cards (ACP, UCP, AP2 Backends)

The existing card rails (Visa, Mastercard, American Express) are still the dominant settlement layer. Both ACP and UCP can settle to cards. AP2 is payment-method-agnostic, but cards are often the backend.

Cards work. But they weren't designed for how agents transact: high-frequency, low-value, often autonomous. The friction shows up in floor costs, authorization latency, and dispute mechanics that assume a human was involved.

x402: HTTP 402 for Micropayments and Stablecoins

x402 solves a problem that cards structurally can't: sub-cent transactions.

A model querying an API thousands of times a day needs to pay fractions of a cent per query. Credit card rails have floor costs that make this impossible. Stablecoins don't. x402 is live. Visa endorsed it. It's integrated into AP2 as a settlement option. x402 solves a specific problem where cards break (micropayments) and operates in a domain where cards don't exist (pure on-chain). That specificity is what makes it valuable.

The Real Picture: Protocols Are Scaffolding

If you've read this far, one thing should be obvious: there is no single standard for agentic payments. There won't be one anytime soon.

But here's the deeper insight that most analysis misses. These protocols are solving today's problem with today's constraints. ACP exists because Stripe needed a way to bring its merchants into conversational commerce. APP exists because Klarna needed a way to make its merchant catalog visible to agents. UCP exists because Google and Shopify needed a broader framework. Each protocol reflects the strategic position of the company that created it.

That means each protocol carries the limitations of its creator's ecosystem. And as the market matures, those limitations will become increasingly visible. An AI application that can only transact with Stripe merchants will lose to one that can transact with any merchant. An agent that can only discover products in Klarna's catalog will lose to one that can search everything.

The protocols themselves are valuable as early coordination mechanisms. They're establishing shared vocabulary, defining data formats, and proving that agent commerce works. But in the long run, the protocol layer will be commoditized. The value will accrue to the infrastructure that sits beneath it: the layer that can route transactions across processors, bridge identity across trust systems, and give agents universal coverage regardless of which protocol a given merchant supports.

This is how technology markets have always worked. HTTP won because it was simple and universal. But the value didn't stay in the protocol. It moved to the platforms built on top of it. The same dynamic is playing out here. The protocols are the starting point, not the destination.

What We're Building For

At Prava, this fragmentation is our daily engineering reality. But we're building with a clear thesis: the company that builds the full infrastructure stack, processor-agnostic, protocol-agnostic, rail-agnostic, will own the agentic commerce layer.

That means we have to:

• Bridge identity across systems. An agent's reputation should be portable, whether it was established via TAP, on-chain, or somewhere else entirely.

• Support multiple authorization paradigms. Mandates (AP2), tokens (Mastercard Agent Pay), cryptographic signatures (TAP), and whatever comes next.

• Settle across rails. Cards, ACH, stablecoins. The agent shouldn't care how money moves. The infrastructure should handle it.

• Abstract away processor boundaries. Whether a merchant is on Stripe, Adyen, Checkout.com, or a custom integration, the agent should be able to transact. This is the gap that current protocols leave wide open, and it's the gap that matters most for real-world adoption.

• Integrate with discovery. APP, UCP manifests, merchant catalogs. An agent that can pay but can't find what to buy is useless.

• Handle the unhappy path. Every protocol defines the happy path beautifully. The real complexity lives in failed transactions, disputes, chargebacks, partial refunds, and reversals.

The protocols we've mapped in this piece are important. They're how the industry is learning to talk about agentic commerce. But they're also incomplete. Each one covers a slice of the problem, within a slice of the merchant ecosystem.

The companies that build flexible, full-stack payment infrastructure now, infrastructure that works across every protocol, every processor, and every rail, will own the integration points as this market matures. The ones that tie themselves to a single protocol will find their reach limited to that protocol's merchant base.

At Prava we're building the layer that makes all of these protocols work together.

If you're working on AI agent infrastructure/ AI Assistant and want to go deeper on any of these protocols, reach out. We spend our days in the details.