Custom-Built Commerce Is the Silent Killer of Agent-Led Growth

What We Found: 50 Companies, Zero Industry Commerce Solutions

We sourced a list of known Zuora customers and systematically inspected their public-facing pricing pages, checkout flows, and network requests. We examined URL structures, JavaScript bundles, API calls, and subdomain architectures. No accounts were created and no logins were performed - all evidence was gathered from publicly accessible pages. We classified each company as either "Confirmed Custom-Built" (where we could identify specific custom endpoints and internal API patterns) or "Likely Custom-Built" (where company size, pricing model, and SaaS patterns strongly indicated custom middleware).

Across all 50 companies inspected, we could not finda single one that was using a dedicated commerce platform to handle the layer between their website and Zuora. Every company had built, and now maintains, its own bespoke commerce middleware.

The Evidence Patterns

The custom-built nature of these systems reveals itself in remarkably consistent ways across the industry.

Dedicated ecommerce subdomains running custom applications. DocuSign operates ecom.docusign.com, a Next.js application where checkout URLs contain internally generated GUIDs for plan billing IDs and cart IDs. GitLab runs customers.gitlab.com where Zuora rate plan IDs like 2c92a01176f0d50a0176f3043c4d4a53 are exposed directly in checkout URLs, revealing the thin custom middleware sitting between the UI and Zuora's API. Box routes purchases through account.box.com with plan-specific paths like /signup/n/business/buynow. Bitly operates sp.bitly.com with custom subscription payment endpoints exposing tier and billing parameters.

Plan-specific cart and checkout endpoints baked into main domains. Zoom serves its purchase flow through /opc/buy/config with internal billing endpoints at /billing/report and /billing/payment - custom API routes that JavaScript network calls invoke directly. Vimeo has built plan-specific cart pages at /cart/starter, /cart/standard, and /cart/advanced. Dropbox offers /buy/plus, /buy/family, and /buy/professional. Each of these endpoints represents custom server-side logic that the respective engineering teams built and must now maintain.

Modal-based internal checkout systems with no external URLs. Zendesk handles purchasing entirely through its Admin Center with a modal-based checkout that never generates a navigable URL. Webex operates a dedicated pricing.webex.com subdomain with a custom React SPA for its cart. These patterns demonstrate engineering teams building entire commerce experiences from scratch to avoid exposing their checkout logic to the public web.

Custom authentication and signup flows with internal tracking. FreshBooks routes direct purchases through my.freshbooks.com/#/signup/direct-buy with campaign tracking parameters. Typeform uses admin.typeform.com/checkout with ISO 8601 period encoding and express checkout flags in the URL. PagerDuty passes plan types through custom signup parameters. SurveyMonkey tracks acquisition source through its own UTM-like parameters on internal signup endpoints.

Usage-based billing with custom metering APIs. Twilio, New Relic, and Sumo Logic all implement custom console-based billing that meters usage through internal APIs. So those would be out-of-scope for this analysis.

Why Custom-Built Commerce Blocks Agent-Led Growth

Here is the core problem: AI agents cannot transact through software they cannot understand.

For an AI agent to complete a purchase, upgrade a subscription, apply a promotional offer, or initiate a free trial on behalf of a user, it needs a well-structured, documented API with predictable authentication, standardised data models, and reliable error handling. Custom-built commerce middleware offers none of these things - by design.

Internal APIs are undocumented and expose internal data models

When Zoom's engineering team built /opc/buy/config, they wrote it for their own frontend. There is no OpenAPI specification. There are no versioned endpoints. There are no developer docs describing request and response schemas. The "documentation" is the React component that calls it. For an AI agent, this is a black box.

Worse, these internal APIs frequently expose raw database structures, internal identifiers, and implementation details that were never intended for external consumption. GitLab's checkout URLs contain raw Zuora rate plan IDs. DocuSign passes internal cart GUIDs. Opening these APIs to external agents without significant rearchitecting could mean exposing your internal data layer directly, a security liability no engineering team would accept.

This is not a criticism of these engineering teams. They built what they needed for their own products. The problem is that agent-led growth requires external programmatic access, and internal APIs are architecturally opposed to that requirement.

Authentication is designed for browser sessions, not on-behalf-of access

Custom commerce middleware almost universally relies on browser-based session cookies, CSRF tokens, and OAuth flows designed for human users completing interactive login screens. Grammarly's engineering team has publicly documented their custom-built billing and payment platform - it works brilliantly for humans using Grammarly's interface, but there is no programmatic access layer for third-party agents.

Agent-led commerce requires a fundamentally different authentication model: on-behalf-of authentication, where an agent acts with delegated authority from a buyer. The agent needs to prove both its own identity and the buyer's authorisation to transact - without the buyer completing an interactive browser login. This requires machine-to-machine OAuth grants, scoped API tokens, or emerging standards like Stripe's Shared Payment Tokens, which let agents initiate payments using a buyer's permission without exposing credentials. Custom middleware was never built with these patterns because the original requirement was simple: let our users buy our product on our website through a browser.

Agents cannot understand your pricing and packaging

Consider what happens when an agent needs to upgrade a subscriber from a Basic to a Pro plan. In a custom-built system, the agent would need to understand the internal mapping between plans, know which upgrade paths are valid, understand prorated billing, and navigate company-specific parameter names - all through an undocumented API. Upgrade and downgrade are not just API calls; they are path problems that require the agent to understand your full pricing and packaging structure to route users to the correct destination.

Add-ons present a similar challenge, but as a compatibility problem. An agent recommending an additional seat pack, an advanced analytics module, or a priority support tier needs to know which add-ons are compatible with which base plans, how they interact with existing subscriptions, and what effect they have on billing. Custom middleware encodes this logic in application code that no external agent can interpret.

And then there are free trials - arguably the most natural starting point for agent-led discovery. An agent evaluating software options for a user should be able to programmatically initiate a free trial or free tier to explore a product before recommending a purchase. In fairness, most checkout systems — custom or licensed — tie trial creation to interactive signup flows. But this is precisely where a commerce platform can differentiate: by exposing free trial initiation as a first-class API operation, letting agents trigger trials programmatically without requiring a human to complete a signup wizard with CAPTCHAs, email verification, and onboarding steps.

Custom APIs are chatty, fragile, and not built for agent scale

Custom commerce APIs are typically designed around the needs of a single-page application making sequential calls as a user clicks through a checkout wizard. This produces "chatty" APIs - five, ten, sometimes twenty round-trips to complete a single transaction: validate the cart, check inventory, calculate tax, apply promo, create payment intent, confirm payment, create subscription, provision entitlements. Well-architected custom systems can minimise chatter through careful API design, but the overwhelming majority of checkout APIs were optimised for single-user UX, not agent-scale concurrency.

When your checkout flow is a side project maintained by a small team that also works on your core product, it does not get the same reliability investment as your primary service. It does not have dedicated SLAs, rate limiting designed for high-throughput agent traffic, or load testing for the scenario where thousands of AI agents simultaneously attempt to complete purchases. Agent-led growth could generate order-of-magnitude more transaction attempts than human-led growth. Custom middleware was not built for this.

Security was an afterthought and now it's the biggest blocker

Perhaps the most dangerous aspect of custom-built commerce middleware is the security posture. Internal APIs built for a trusted frontend frequently lack the hardening expected of externally-facing services: no rate limiting, minimal input validation, no audit logging, no abuse detection - or often done after the first attack scare. Many expose raw database identifiers that could enable enumeration attacks, and some rely on security-through-obscurity rather than proper authorisation checks.

Opening these systems to agents, external software operating at machine speed, would dramatically increase the attack surface. Engineering teams know this, which is why many of these systems will never be opened up. Teams consistently underestimate the security work required to expose internal APIs externally - adding rate limiting, replacing raw identifiers with stable non-enumerable handles, building audit logging, and implementing proper authorisation checks. These are not optional extras; they are table stakes for any externally-facing API, and they represent significant engineering investment on top of a codebase that was never designed with external access in mind.

The Agentic Commerce Problem Is Real and the Industry Is Responding

It is worth acknowledging that agentic commerce, AI agents making purchases on behalf of customers, is not a fully solved problem yet. The payments layer alone presents fundamental questions: how does an agent prove a buyer's intent? How are disputes handled when no human clicked "confirm"?

The industry is actively working on this. Stripe and OpenAI have co-developed the Agentic Commerce Protocol (ACP), an open standard that lets AI agents discover products, negotiate with merchants, and initiate checkout on behalf of buyers using Shared Payment Tokens, a new payment primitive designed specifically for agent-to-business transactions. Salesforce has announced support for ACP as well.

These initiatives solve the payment authorisation piece, how an agent proves a buyer's intent and initiates a payment using delegated authority. But they presuppose that the merchant has a commerce layer capable of receiving and processing agent requests in the first place. ACP handles the payment primitive; it does not handle cart assembly, upgrade path discovery, add-on compatibility, tax calculation, or proration logic. Those require a merchant commerce API, and if that API is a custom-built internal system behind browser-session authentication, ACP cannot help you. The agent has nothing to talk to.

What It Looks Like When You Get It Right: The OpenText Story

The drawbacks of custom-built commerce middleware are not theoretical. OpenText experienced them when managing the subscription checkout for its Webroot and Carbonite brands.

Their previous checkout was custom-built, burdened with technical debt, and tightly coupled to internal tools. Over time, it became slow and inflexible for the business team. Simple commercial changes, a pricing tweak, a promotional campaign, required developer involvement and long release cycles, leaving business teams unable to act quickly. Legacy edge cases tripped over each other, creating a system where every change risked breaking something else. The custom-built checkout was sparesely documented, was never planned for external services, and had accumulated years of internal workarounds.

In five months, OpenText and Limio delivered a new checkout built with Limio's modular Checkout and Cart Components, with PayPal and credit card support, regional compliance for auto-renewal consent, and native Zuora integration. Marketers can now launch campaigns, adjust pricing, and refine messaging instantly - without developer support.

The OpenText migration illustrates a critical point: moving from custom-built to platform-based commerce is not just about agent readiness. It eliminates technical debt, accelerates time-to-market, and puts control back in the hands of the business. Agent readiness is the next dividend of that same architectural decision.

The Industry Commerce Layer: What Agents Actually Need

The solution is not for every SaaS company to "just document their APIs" or bolt an agent-friendly layer onto their existing custom middleware. The architectural decisions that created these systems, internal-only access patterns, browser-session authentication, company-specific data models, are fundamental, not superficial.

What the market needs is a dedicated commerce platform that sits between the website (or the agent) and the billing system, providing standardised, well-documented commerce primitives that any client, human or agent, can transact through.

These primitives must include:

• A Cart for assembling and managing orders, with add, remove, and swap operations available as atomic API calls
• A Checkout flow with pluggable authentication supporting both interactive and machine-to-machine access
• Upgrade and Downgrade paths that encode your pricing and packaging logic, so an agent can navigate valid transitions without understanding your internal plan hierarchy
• Add-on compatibility rules that let an agent discover and attach complementary products to an existing subscription
• Promo Code validation and application as a first-class operation
• Free Trial initiation that can be triggered programmatically, letting agents do discovery before transacting
• An Orders API with preview capabilities, so agents can show users what will happen before confirming, including prorated charges, tax calculations, and effective dates
• An Order Orchestration framework that can enable the agent to immediately get access to the resources they made the purchase for

When these primitives are provided by a platform rather than built in-house, they come with versioned APIs, OAuth-based authentication designed for server-to-server access (including on-behalf-of patterns), comprehensive documentation, dedicated reliability engineering, and, critically, a consistent interface that works the same way regardless of which company's subscription you are purchasing.

This is the architectural approach Limio takes. As a commerce platform purpose-built for subscription businesses, Limio provides the commerce layer between your website, your sales team, your partners, your AI agents, and your billing system. One set of commerce primitives, one API surface, multiple channels - including the agent channel that every subscription business will need to support in the coming years.

From API to MCP: Making Commerce Truly Agent-Native

But a well-documented REST API is just the first step. To make commerce truly agent-friendly, you need to package those primitives into a format that AI agents understand natively.

This is where the Model Context Protocol (MCP) comes in. MCP is an open standard that lets AI assistants discover and connect to external services. Instead of an agent needing to construct REST API calls with the correct headers, authentication, and payload structure, an MCP server exposes your commerce capabilities as tools that any MCP-compatible AI agent can discover and invoke directly. MCP does not replace REST APIs. It is a discovery and invocation layer on top of them. But that layer is what makes the difference between an API an agent could use and one it will use.

Limio's MCP Server already lets AI assistants browse offers, create subscriptions, update pricing, and query order data through natural language - "show me all our published offers of our standard plan", "create a monthly subscription at $9.99", "how many orders came through our trial offers this month". The full pricing model - including free trials with delayed billing, usage-based pricing, and multi-currency support - is exposed through MCP tools that agents can reason about without human guidance.

This is the progression: custom-built APIs that only your frontend can use → documented REST APIs that any authorised client can use → MCP servers that any AI agent can discover and use. Companies stuck at step one will struggle to begin this journey.

The Clock Is Ticking

Agent-led growth is not a 2030 problem. The companies that cannot offer programmatic commerce access will be invisible to this new distribution channel.

If your checkout flow lives at a custom subdomain with internal GUIDs in the URL, maintained by a team that also builds your core product, you have a choice to make. You can try to retrofit agent support onto a system that was never designed for it - hardening internal APIs, documenting undocumented endpoints, adding on-behalf-of authentication, building rate limiting and abuse detection, and praying the technical debt does not collapse under the weight. Or you can adopt a commerce platform that was built from the ground up to support every growth channel - including the ones that do not involve a human clicking a button.

Custom commerce is the industry default for understandable reasons - flexibility, tight integration with the core product, and control over the buyer experience. The 50 companies we investigated are not making bad engineering decisions. But the tradeoff that made sense when the only client was a browser no longer holds when the next client is an AI agent.

This analysis is based on primary research conducted in March 2026, inspecting the checkout flows and commerce architecture of 50 Zuora-billing companies. All evidence was gathered from publicly accessible pages - no accounts were created and no logins were performed during this research.. For companies classified as "Confirmed Custom-Built," evidence includes direct browser inspection of URLs, network requests, JavaScript bundles, and API endpoints.