Understanding the Parallel Systems Powering AI Commerce
In March, when Stripe and Tempo launched the Machine Payments Protocol, the announcement included a detail many people missed: Visa was a design partner. Not an endorser, but an actual co-architect of how agents would pay with credit cards.
At the same time, Coinbase was contributing x402 to the Linux Foundation for stablecoin-native payments. Google was expanding its Universal Commerce Protocol for agent shopping. Mastercard was shipping Verifiable Intent for transaction trust.
None of them were waiting for the others to finish or building on top of each other - they were all building in parallel. That means these protocols aren't a stack. They're a constellation.
If you try to draw a dependency diagram where x402 sits on top of MPP which sits on top of ACP which sits on top of A2A, you'll end up confused. That's not how any of this works. These are parallel systems addressing overlapping concerns. Some compose with each other. Some compete. Some are payment-rail agnostic. Understanding the difference is the key to making sense of what's actually being built.
Territories, Not Steps
Think of agent payments as a map with five overlapping territories, not a five-story building.
Each territory answers a different question:
1. How does an agent communicate with another agent?
A2A (Agent-to-Agent Protocol) - Google's answer to agent discovery and delegation. Now at the Linux Foundation with 100+ partners and SDKs in Python, Java, and Go. Each agent publishes an Agent Card at a well-known URL describing its capabilities. Other agents discover it, delegate tasks, exchange information. This is about communication, not payments - though payments often follow communication.
2. How does an agent shop?
Two competing answers:
ACP (Agentic Commerce Protocol) - Co-created by OpenAI and Stripe. Live in ChatGPT since September 2025. Handles product discovery, catalog browsing, cart management, and checkout via APIs. If you've bought something inside ChatGPT, you've used ACP.
UCP (Universal Commerce Protocol) - Google's coalition play, announced January 11, 2026 with Walmart, Target, Shopify, Etsy, and Wayfair. Powers checkout in Google Search AI Mode and the Gemini app via Google Pay. UCP and ACP are direct competitors for the commerce orchestration layer - the "shopping cart" of the agentic web.
3. How does an agent authorize payment on a user's behalf?
MPP (Machine Payments Protocol) - Launched March 18, 2026 by Stripe and Tempo. Introduces "sessions" (think OAuth for payments). The agent authorizes once, pre-funds an account or links a payment method, and then every API call settles automatically. The key is that MPP is payment-rail agnostic. It works with cards, stablecoins, buy-now-pay-later. Visa contributed the card-based MPP spec. x402 is one possible settlement rail under MPP, but so is a Visa card. They are not in a dependency relationship.
4. How does an agent pay per request, in real time, over HTTP?
x402 - Created by Coinbase, contributed to the Linux Foundation on April 2, 2026. HTTP-native, stateless, per-request stablecoin settlement. The protocol embeds payment into HTTP via the 402 status code - dormant since 1996, now awakened. The x402 Foundation launched with 20+ founding members: Stripe, Cloudflare, AWS, Google, Microsoft, Visa, Mastercard, Shopify, Circle, Solana Foundation, Polygon Labs, American Express, Adyen, Fiserv, and more.
x402 is crypto-native. It answers how an agent pays when the business model is microtransactions and the rail is a stablecoin. But it doesn't answer who is paying or whether you should trust them. It also doesn't specify where the transaction settles - which chain secures the finality, and what trust assumptions come with it.
5. How do you trust an agent in a transaction?
Three complementary systems:
Visa Intelligent Commerce + Trusted Agent Protocol - Card-network trust layer. Requires verified agent credentials before payment data is shared in checkout. Ensures agents can pay with cards in a way merchants recognize as legitimate commerce, not bot traffic.
Mastercard Verifiable Intent - Co-developed with Google. Creates a cryptographic delegation chain binding user identity, purchase intent, and agent action into a signed, disputable authorization record. Works alongside A2A, UCP, ACP - doesn't replace them, but makes transactions verifiable and disputable on card rails.
ERC-8004 - On-chain agent identity and reputation. Permissionless, cross-chain. Each agent gets a unique on-chain identifier that points to a structured agent card with capabilities, service endpoints, and payment address. The reputation layer records interactions and feedback over time. x402 answers how an agent pays. ERC-8004 answers who is paying and whether you should accept. This is all live on GOAT Network.
How They Fit Together (Without Stacking)
None of these protocols require each other, but many enhance each other.
An agent using ACP to shop in ChatGPT can pay via MPP (which might settle via x402 on Solana or a Visa card on traditional rails). The merchant can verify the agent's identity via ERC-8004 and confirm user authorization via Mastercard Verifiable Intent. Meanwhile, the agent discovered the merchant via A2A Agent Cards.
Or: an agent using UCP to shop in Google Search can pay via MPP with Google Pay. The transaction logs to Mastercard Verifiable Intent for dispute resolution. No x402. No ERC-8004. Different path, same outcome - because these are options, not requirements.
Or: an API charges per request via x402, bypassing MPP entirely. The agent's identity is verified via ERC-8004. No shopping cart. No commerce protocol. Just HTTP 402 and a stablecoin transfer.
But notice what none of these paths specify: which chain the stablecoin transaction actually settles on. That choice - the settlement layer - carries its own trust assumptions. And for autonomous agents optimizing for reliability over loyalty, it might be the most consequential choice of all.
Where GOAT Network Fits
x402 is an open standard. ERC-8004 is an Ethereum standard. Any chain can implement both - many have and will. ERC-8004 agent registries can deploy on any EVM chain. The tooling is open. The playbook is public.
So the question isn't who has x402 and ERC-8004. It's who has the right settlement layer underneath them.
GOAT Network is a Bitcoin-secured Layer 2. That distinction matters much more than it sounds.
When an agent on Base makes a payment, it's trusting Coinbase. When an agent on Polygon pays, it's trusting a validator set. When an agent on GOAT Network pays, it inherits Bitcoin's security model - trust-minimized bridging via BitVM2, settlement finality backed by the most decentralized consensus network in existence.
Unlike humans, agents don't have brand loyalty. They don't care about ecosystems or token appreciation. An autonomous agent choosing a payment rail optimizes for cost, speed, trust assumptions, and censorship resistance. Fewer intermediaries means fewer failure points. An agent that can be deplatformed or whose funds can be frozen by a single operator is a broken agent.
Bitcoin-secured settlement is the strongest answer to that optimization problem.
GOAT Network runs an x402 facilitator across multiple chains including Ethereum, Polygon, Arbitrum, BSC, Solana, and GOAT Network itself. ERC-8004 identity registries live natively on GOAT, linking every payment to a verifiable, reputable agent with a cross-chain track record. So reputation compounds with every transaction.
But the differentiator isn't the protocols - protocols are open and composable. The differentiator is what sits beneath them. Lots of chains are assembling x402 + ERC-8004, but GOAT Network is the only one where that stack settles to Bitcoin.
Agent identity. Agent payments. Bitcoin-grade security.
What This Means for Builders
If you're building in this space, here's the mental model:
Start with the user journey. Is the agent shopping (ACP/UCP) or paying per API call (x402 directly)?
Choose your payment rail. Cards? Use MPP with Visa. Stablecoins? Use MPP with x402, or x402 directly.
Choose your settlement layer. Not all crypto rails are equal. Who secures the chain your agents transact on? A corporate operator, a validator set, or Bitcoin? The trust assumptions underneath your payment rail matter as much as the rail itself.
Add trust. If you're on card rails, integrate Visa Trusted Agent or Mastercard Verifiable Intent. If you're on crypto rails, integrate ERC-8004 for on-chain agent identity and reputation
Enable discovery. If your agents need to find each other, implement A2A Agent Cards.
The beauty of this moment is that the protocols are parallel - you can mix and match. You can skip layers. You can compose in unique and unexpected ways.
The agent payments landscape isn't a stack. It's a map. And the territory is still being explored.
If you're building agents that need to transact - and you want them settling on neutral, Bitcoin-secured rails instead of infrastructure controlled by a single operator - start building on GOAT.Network.
