AI-to-e-commerce traffic grew by roughly 4,700% year-over-year in 2025. Morgan Stanley estimates that agentic shoppers could capture between $190 billion and $385 billion in US e-commerce by 2030. Two protocols are now competing to define how AI agents actually transact online, and both are running into the same infrastructure wall.
UCP: Shopify and Google’s Full-Stack Commerce Protocol
Universal Commerce Protocol (UCP) is an open standard developed by Shopify in collaboration with Google. Over 20 major retailers back it, including Target, Walmart, Best Buy, plus payment processors like Visa, Mastercard, and Stripe.
The protocol standardizes how AI agents discover products, manage carts, complete checkouts, and handle post-purchase flows like returns and order tracking. Before UCP, any developer building an AI shopping agent needed custom integrations for every merchant. UCP removes that friction by defining universal primitives that map to standard retail operations.
On the transport layer, UCP supports REST, GraphQL, JSON-RPC, MCP (Model Context Protocol), and Agent-to-Agent communication. Merchants and agents declare their supported capabilities, and UCP negotiates the differences automatically. Shopify’s engineering team built the protocol on top of data from billions of transactions processed across their merchant network.
Google’s UCP integration enables purchases directly within Gemini, AI Mode in Search, and Google Shopping. Merchants can choose between native checkout (direct API integration) or embedded checkout (iframe-based) depending on how much control they want over the buyer experience. In both cases, the merchant remains the Merchant of Record, keeping customer relationships, data ownership, and post-purchase control.
x402: Coinbase’s HTTP-Native Crypto Payment Layer
x402 takes a narrower approach. Developed by Coinbase, it doesn’t handle commerce workflows at all. It handles payments, specifically turning HTTP’s long-dormant 402 status code (“Payment Required”) into an actual payment trigger.
The protocol spec is open source and the flow works like this:
1. Agent requests a paid resource (API endpoint, content, service)
2. Server returns HTTP 402 with payment address, amount, and currency
3. Agent wallet signs a USDC transaction
4. Agent retries the request with payment proof in headers
5. Server validates on-chain settlement - returns the resource
Settlement happens on-chain in 4-8 seconds with zero protocol fees. This makes x402 well-suited for micropayments, pay-per-request API access, content unlocking, and agent-to-agent payments, use cases where traditional payment rails are either too slow or too expensive.
Where They Differ
UCP and x402 are not competitors – they solve different problems.
| | UCP | x402 |
|—-|—-|—-|
| Scope | Full commerce workflow | Payment settlement only |
| Built by | Shopify (with Google) | Coinbase |
| Payment method | Negotiated (Shop Pay, cards, etc.) | USDC on-chain |
| Settlement | Varies by payment handler | 4-8 seconds |
| Protocol fees | Standard processing fees | Zero |
| Best for | Retail product purchases | APIs, micropayments, pay-per-request |
An agent could theoretically use UCP for product discovery and cart management while using x402 for payment if a merchant supported both, but the protocols weren’t designed as a required pairing. UCP already has its own payment handling through Shop Pay and negotiated payment handlers.
The Infrastructure Challenge Neither Protocol Solves
Both protocols work on paper. The technical specs are sound, the backing is strong, and early implementations are live. But there’s a shared infrastructure problem that neither protocol addresses directly: anti-bot detection.
UCP merchants and x402 endpoints both deploy bot detection systems – they have to. The same open protocols that let AI agents complete legitimate purchases also attract scrapers, credential stuffers, and inventory bots. Merchants can’t reliably tell the difference between a helpful AI agent and a malicious one, so the default response to anything that looks automated is to block it.
This creates a real deployment gap between “protocol works in a test environment” and “protocol works at scale in production.”
Datacenter IPs Get Blocked Fast
Agents running from AWS, GCP, or DigitalOcean IP ranges trigger bot detection systems almost immediately. UCP discovery queries get rate-limited within minutes. x402 payment endpoints flag cloud hosting ASNs. Transaction success rates from datacenter IPs typically land between 15-25%, with blocks kicking in after 2-5 minutes.
Residential Proxies Are Better but Unreliable
Residential proxy pools improve success rates, but IP geolocation mismatches still trigger fraud checks. Shared pools carry reputation risk – other users’ bad behavior contaminates your IPs. CAPTCHA challenges interrupt agent workflows that need to be fully autonomous.
Mobile Carrier Proxies Are What Actually Pass Detection
Mobile proxies from real 4G/5G carrier networks (Verizon, T-Mobile, AT&T, and equivalents globally) produce traffic that’s indistinguishable from legitimate smartphone users. CGNAT (Carrier-Grade NAT) means these IPs are naturally shared with thousands of real mobile users at any given time, so merchants can’t block the ranges without blocking real customers.
Reported success rates on mobile carrier IPs sit around 85-95%, with sessions holding stable for 30+ minutes and CAPTCHA trigger rates below 5%.
Session Persistence: The Technical Detail That Breaks Workflows
Both UCP and x402 workflows span multiple sequential HTTP requests. A UCP purchase goes through discovery → cart → checkout → payment confirmation. An x402 flow goes through resource request → 402 response → payment submission → access grant.
If the proxy rotates mid-workflow, merchants see requests from different geographic locations hitting the same session token. That reads as a compromised account – a classic fraud signal. The agent gets blocked not because it’s doing anything malicious, but because the IP switching pattern looks identical to credential stuffing.
The fix is sticky sessions: maintaining the same proxy IP for the full duration of a workflow. For UCP retail transactions, that typically means 10-30 minute sessions. For x402 micropayments, 5-10 minutes is usually enough since the flow completes faster.
A simplified proxy configuration pattern for a UCP agent:
import requests
class UCPAgent:
def __init__(self, proxy_url: str):
self.session = requests.Session()
self.session.proxies = {
'http': proxy_url,
'https': proxy_url
}
self.session.headers.update({
'X-Session-Duration': '1800',
'User-Agent': 'Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)'
})
def discover_products(self, query: dict) -> dict:
return self.session.post(
'https://merchant.example/ucp/v1/products/search',
json=query
).json()
def checkout(self, cart_id: str, payment: str) -> dict:
return self.session.post(
'https://merchant.example/ucp/v1/checkout',
json={'cart_id': cart_id, 'payment_method': payment}
).json()
The key detail: self.session keeps the same proxy connection from discovery through checkout. Rotation should happen between sessions, not during them.
The Mobile Proxy Landscape for Agent Commerce
Several providers offer mobile proxy infrastructure that can support these workflows, each with different trade-offs.
Bright Data and Oxylabs are the largest enterprise players, with IP pools exceeding 150M+ and 175M+ respectively. Both offer shared mobile proxy pools with extensive geo-targeting, well optimized for high-volume scraping and data collection. Their AI tooling focuses on scraper APIs and data extraction rather than full proxy access for autonomous agents. Smartproxy (now rebranded as Decodo) sits in the mid-tier with more accessible pricing and a simpler interface, solid for teams that don’t need the full enterprise feature set.
The challenge for agent commerce specifically is that shared pools rotate IPs, carry reputation damage from other clients, and cap sticky sessions at 10-30 minutes. AI agents need human-like connectivity: IPs that don’t get burned, sessions that hold for hours, and programmatic control over the proxy layer. Providers like VoidMob address this with dedicated mobile proxies on real 4G/5G carrier connections, 24-hour stable IP sessions, and full MCP server access for proxy management, so the agent itself can select and control its infrastructure as part of the workflow.
The right choice depends on the use case. Shared pools handle data collection fine. Dedicated mobile infrastructure is what agent commerce demands when every transaction needs to look like a single, consistent user from start to finish.
Common Failure Patterns in Production
Teams deploying agent commerce workflows keep hitting the same set of issues:
“Security check” errors during UCP checkout typically trace back to IP rotation mid-session. Some proxy providers silently rotate IPs when connections drop, which breaks the session continuity merchants expect.
x402 payment accepted but resource still blocked happens when payment validation and bot detection are separate systems. The USDC transaction confirms on-chain, but the request still gets flagged because the originating IP is a datacenter ASN. These are independent layers, passing one doesn’t guarantee passing the other.
Rate limiting on UCP discovery queries results from either too many requests from one IP or a flagged ASN. Real users don’t fire 50 product searches per second. Adding realistic delays and using carrier ASNs instead of hosting ASNs resolves most cases.
CAPTCHA challenges interrupting autonomous flows usually indicate degraded proxy pool reputation. Shared pools carry cumulative risk from other users’ activity. Dedicated mobile IPs with a clean history cost more but eliminate the interruptions.
What Comes Next
UCP and x402 represent two distinct bets on the future of agent commerce. UCP is an ecosystem play, with Shopify and Google building standardized rails across their massive merchant networks, traditional payment processing, and full workflow coverage. x402 is an open protocol play, where any server can accept crypto payments through standard HTTP semantics, no integration meetings required.
Both are technically ready. The $190-385 billion market opportunity Morgan Stanley projects isn’t blocked by protocol design. It’s blocked by the gap between how these protocols assume agent traffic will be treated and how merchant infrastructure actually handles it.
The teams that figure out the proxy and session management layer first will be the ones that ship working agent commerce products. Everyone else will be stuck debugging 403 responses.
