5 Things We Learned Building Agentic Commerce Infrastructure
Arjun Bhargava
Co-founder and CEO @ Rye
9 minutes read
Stripe shared 10 agentic commerce lessons from the payments layer. Here are 5 more from the checkout execution layer — what breaks when there's no API to call.
TL;DR / Key Takeaways
Stripe just published 10 agentic commerce lessons from the payments and protocol layer — and they're excellent. This piece adds five more from a different seat in the stack.
Rye operates at the checkout execution layer, completing purchases across the open web without merchant integration. That position reveals challenges the payments layer can't see.
The merchant's front door is the first obstacle — anti-bot systems treat all automated purchasing as hostile, including legitimate agent transactions.
Product data staleness doesn't just hurt discovery. At the execution layer, it causes failed checkouts, cancelled orders, and broken trust.
Every merchant checkout is unique, and the variability doesn't converge — it compounds as sites update their flows.
The hardest trust problem isn't fraud. It's proving to the merchant's own infrastructure that this purchase is legitimate.
Protocol adoption follows a power law. Universal checkout isn't a stopgap — it's a permanent structural layer.
Stripe published 10 things they've learned building agentic commerce infrastructure. It's one of the most useful pieces of shared learning the ecosystem has produced — clear-eyed about the real problems, honest about what's hard, and generous with operational detail.
We're adding to it.
Stripe sees agentic commerce from the payments and protocol layer. They process the payment. We process the purchase. Rye operates at Layer 5 of the agentic commerce stack — checkout execution — and Layer 6 — product data. We complete purchases across the open web, on any merchant site, without requiring that merchant to integrate with a protocol or adopt an API. Different seat in the stack, different view of what breaks.
These are agentic commerce lessons from that vantage point. They don't replace Stripe's — they extend them.
5 lessons from building agentic commerce at the checkout execution layer.
1. Agentic Commerce and Merchant Bot Detection: The Access Problem
The merchant's front door wasn't built for agents — and that's where every transaction starts.
Stripe's lessons begin at the point where a structured API exists. A merchant has opted into ACP, connected their catalog, and exposed a checkout endpoint. The protocol takes over. Clean.
Our lessons start earlier — at the point where no API exists at all.
Before any protocol or payment flow matters, an agent has to navigate a merchant's actual website. And merchant sites are built for humans. They use CAPTCHAs, browser fingerprinting, dynamic pricing, A/B-tested checkout flows, JavaScript challenges, and layered anti-bot systems. These defenses are well-engineered. They're supposed to be. The problem is that they can't distinguish between a scalper bot and a consumer-authorized AI agent completing a legitimate purchase.
This is the most underappreciated infrastructure challenge in agentic commerce. The gap between "this product exists" and "this product can be purchased by an agent" is enormous when the merchant hasn't opted into a protocol — which is the case for the vast majority of online stores today.
We've had to build systems that present as what they are: legitimate purchasers acting on behalf of real consumers, with real payment methods, shipping to real addresses. That sounds simple. In practice, it means navigating merchant security infrastructure that evolves continuously and treats all automation as adversarial by default.
If you're building an agent that needs to buy from any merchant — not just protocol-opted-in ones — you're not solving a payments problem first. You're solving an access problem.
2. Why Real-Time Product Data Matters for Agentic Checkout
Product data freshness isn't a nice-to-have — it's the difference between a completed order and a failed one.
Stripe's second lesson covers real-time inventory, and they're right: one platform asked whether inventory verification happens down to the millisecond. We'd go further.
At the execution layer, stale product data doesn't just mean showing the wrong thing. It means charging someone for something they can't get.
The failure modes are asymmetric. An agent that surfaces an out-of-stock product during discovery is disappointing — the user searches again. An agent that completes checkout on a product that went out of stock three minutes ago is a different problem entirely. The order gets placed, the user gets a confirmation, and then twenty-four hours later they get a cancellation email. Or worse: the price changed between the agent's quote and the actual checkout, and the user is charged more than they expected.
These aren't edge cases. They're the default outcome when product data is stale at the moment of purchase. To put this in perspective: the ACP product feed spec accepts updates as frequently as every 15 minutes. That's the ceiling — the maximum freshness the protocol supports, not a minimum requirement. Many merchants will update less often. And even at that best case, 15 minutes is a long time when a popular item can sell out in seconds or a flash sale changes pricing mid-conversation. Discovery-layer freshness and execution-layer freshness have fundamentally different tolerances.
We built the Product Data API specifically to close this gap — real-time product data from any merchant URL, tightly coupled with checkout execution so the same system that tells you what a product costs can verify that price at the moment of purchase. The architecture matters: if your discovery layer and your checkout layer aren't sharing a freshness guarantee, you're building in a class of failures that erode user trust faster than almost anything else.
For developers: build your agent with the assumption that any product data older than a few minutes might be wrong at checkout time. Re-verify at the moment of purchase, not at the moment of discovery.
3. The Universal Checkout Challenge: Every Merchant Site Is Different
Universal coverage is the unlock, but every merchant checkout is a snowflake.
Stripe's third lesson addresses protocol fragmentation — merchants reformatting catalogs for different agents. We see the inverse problem.
Every merchant's checkout flow is unique. Not "a few variations on a theme" unique. Genuinely, structurally different. Button labels, form field orders, confirmation page layouts, error message formats, shipping option presentation, tax calculation timing, promo code input placement, even which bot-detection or fraud vendor the merchant uses — there is no standard. A checkout flow that works flawlessly on one merchant's site breaks on another because they changed a dropdown to a radio button group. Or because they moved the "Place Order" button into a sticky footer. Or because they A/B test their checkout and you're seeing the variant you've never encountered before. Some legacy retailers have checkout inputs nested inside multiple layers of iframes that standard browser automation libraries can't even interact with — and those sites haven't been updated in years.
Deterministic workflows — scripted checkout sequences that follow a fixed path — break constantly. The checkout flows that work reliably at scale are the ones that can adapt. We've had to build systems that learn from successful purchases and adjust when flows change, rather than following rigid scripts. When a merchant pushes a site update on a Tuesday afternoon, the system needs to self-heal, not fail every order until an engineer manually updates the workflow.
This is what makes checkout execution genuinely hard infrastructure. It's not a static integration — it's an ongoing adaptation problem against millions of independently evolving merchant sites. Coverage counts ("works with 100K merchants") don't capture this. What matters is how the system behaves when 5% of those merchants push updates in the same week.
For developers evaluating universal checkout infrastructure: ask about adaptability, not just coverage.
4. Merchant Trust in Agentic Commerce: Why Legitimate Agent Purchases Get Blocked
The trust gap isn't just between consumers and agents — it's between agents and merchants.
Stripe's fifth lesson reports fraud rates at near zero for agentic transactions — and that tracks with what we see on the payments side. Stripe's network-level signals work. The Shared Payment Token model is well-designed. The payment layer is not where trust breaks down.
The trust gap we encounter is different: merchants don't trust agents.
Merchant bot-detection systems, rate limiters, and anti-automation tools treat all automated purchasing as suspicious. This isn't irrational — merchants have spent years defending against scalper bots, credential stuffing, and inventory hoarding. Their security stacks are built to block exactly the kind of automated purchasing that agentic commerce requires. And right now, those systems can't distinguish between a malicious bot and an AI agent shopping on a user's behalf.
The result: legitimate purchases get blocked. Orders get flagged and cancelled post-submission. IP addresses get rate-limited. The payment went through — Stripe sees a clean transaction — but the merchant's own infrastructure rejected the order.
This is why initiatives like the Agentic Commerce Consortium and Visa's Trusted Agent Protocol matter at the execution layer. They're not solving fraud — they're solving legitimacy. Building the verification frameworks that let merchants say: "this agent is authorized, this purchase is real, let it through."
There's a structural benefit here, too. When agent verification moves up the stack — handled by infrastructure providers rather than individual merchants — it unifies the checks. Instead of every merchant needing to build or configure their own fraud stack to distinguish legitimate agents from bots, the verification layer handles it once. That matters most for the less tech-savvy merchants who don't have the engineering resources to make that distinction themselves.
For developers: fraud prevention and merchant acceptance are different problems with different solutions. Your payment provider handles fraud. Whether the merchant's own systems allow the purchase to complete is an execution-layer challenge that requires different infrastructure entirely.
5. Protocol Adoption and the Long Tail: Why Universal Checkout Is a Permanent Layer
The protocols will converge, but the long tail will always need a bridge.
Stripe's third lesson addresses protocol volatility and their role as a protocol-agnostic abstraction layer. We agree with the architectural approach. And we'd add a structural observation from the execution layer: even when ACP and UCP mature and adoption grows, there will always be a long tail of merchants who haven't integrated.
Not because the protocols are bad. Because the economics don't justify it.
A boutique with $200K in annual revenue isn't going to implement ACP or UCP. Neither is a DTC brand on a custom Magento stack, or a specialty retailer running legacy ecommerce software that hasn't been updated since 2019. But those merchants might carry exactly the product a consumer's agent is looking for — and often, the long tail is where the most differentiated products live. Niche gifting, specialty retailers, handmade goods, region-specific brands. The entire value proposition of agentic search is finding the perfect match, not the most popular one.
Protocol adoption follows a power law. The top 1,000 merchants will support every protocol. The next 100,000 will support one. The next millions will support none. We've seen this play out already — even with Shopify handling the technical integration for ACP, only roughly a dozen merchants went live before OpenAI shifted to app-based checkout.
This isn't a temporary gap that closes as protocols mature. It's a structural feature of how commerce works. The agentic commerce stack needs both: protocol-based checkout for the head and a universal execution layer for the tail.
For developers: design your agent's checkout architecture with the assumption that protocol coverage will always be partial. The question isn't "which protocol should I integrate?" It's "what do I do when the merchant I need isn't on any protocol?"
Frequently Asked Questions
What is the execution layer in agentic commerce?
The execution layer is the infrastructure that actually completes a purchase on a merchant's website — handling product validation, form entry, payment submission, shipping selection, and order confirmation. It sits between the AI agent (which decides what to buy) and the merchant's checkout system (which fulfills the order). In the agentic commerce value chain, it's Layer 5 — distinct from the payments layer (Layer 3), which processes the financial transaction, and the protocol layer (Layer 2), which standardizes how agents and merchants communicate.
How is universal checkout different from protocol-based checkout like ACP or UCP?
Protocol-based checkout (ACP, UCP) requires merchants to opt in, integrate their catalog, and expose structured APIs. Universal checkout works on any merchant site via a product URL — no merchant integration required. The agent navigates the merchant's existing checkout flow programmatically. Both approaches have tradeoffs: protocols offer cleaner integration where available, while universal checkout provides coverage across the long tail of merchants who haven't adopted any protocol. Most production agents will layer both approaches.
Why do merchant bot-detection systems block legitimate AI agent purchases?
Merchant anti-bot systems are designed to block automated purchasing — scalper bots, credential stuffing, inventory hoarding. They can't yet distinguish between malicious automation and a consumer-authorized AI agent completing a legitimate purchase. Industry initiatives like the Agentic Commerce Consortium and Visa's Trusted Agent Protocol are building verification frameworks to solve this, but adoption is still early.
How does stale product data cause checkout failures?
When product data is fetched at discovery time but not re-verified at checkout time, the agent may attempt to purchase a product whose price changed, went out of stock, or had its shipping options updated. The result: failed orders, post-purchase cancellations, or users charged more than expected. The fix is tightly coupling product data with checkout execution — re-verifying price and availability at the moment of purchase, not just at the moment of discovery. Rye's Product Data API is built specifically for this.
Will protocol adoption eventually eliminate the need for universal checkout?
Unlikely. Protocol adoption follows a power law — the largest merchants will support every protocol, but the vast majority of online stores lack the engineering resources or business justification to implement ACP or UCP. Even with Shopify handling the technical integration, only about a dozen merchants went live with ChatGPT checkout before OpenAI shifted strategies. Universal checkout infrastructure is a permanent structural layer, not a stopgap — it serves the long tail that protocols can't reach.
Different seats, same stack
These five lessons come from a different seat in the stack than Stripe's ten. Together, they paint a more complete picture of what it actually takes to build production agentic commerce.
The payments layer and the execution layer need each other. Stripe's infrastructure handles the money. Universal checkout infrastructure handles the purchase. Both are essential. And the companies building across both layers — sharing what works and what doesn't — will be the ones that make agentic commerce real for the millions of merchants and billions of consumers who aren't served by protocols alone.
Start building with Rye's Universal Checkout API →
Product
Resources