No-Touch SaaS: API Payments in an AI World

Overview:

• Software payments today are built for static, human-driven relationships. API/MCP setup and management is cumbersome for a new class of developers who have never written a line of code before. Quality data sources are "losing out" on customers since LLMs cannot interact dynamically with paywalls.

• In No-Touch SaaS, AI agents discover, call, and pay for APIs and data sources. No account creation, no API key setup, no bilateral billing relationships.

• "AI budgets" enrich research by allowing cost-efficient access to paywalled data during LLM runtime. x402/MPP workflows could collapse API integration friction, enable dynamic software pricing and solve the cold-start problem for non-enterprise developers.

• The economics of No-Touch SaaS challenge subscription-based pricing and apply a forcing function towards usage-based pricing. We can expect rethinking around SaaS metrics like CAC and ARPU if No-Touch SaaS becomes mainstream.

The SaaS Story So Far

The last few weeks have been interesting from an agentic payments perspective. Tempo launched mainnet and Machine Payments Protocols was a clear standout. Ramp launched Ramp Agent Cards last week. Visa launched the Visa CLI and has been working actively on Visa Intelligent Commerce. Coinbase has been spearheading x402 for the past few months.

However, the focus so far has been largely around commerce/shopping within LLM chat interfaces while discussions around software and data payments have been limited. I believe AI can fundamentally alter how we think about software payments and SaaS going forward and I wanted to engage with that idea through this article.

The first ever software licensing agreement was inked in 1969 when IBM decided to unbundle its bulky, expensive hardware from its software services. Fast forward several years, software finance today is dominated by SaaS which itself can be bifurcated into high-touch (think Salesforce, SAP) and low-touch SaaS (think X, Stripe)

High-touch SaaS involves large ACVs, high CAC per marginal user and exorbitant customer support costs. Low-touch SaaS works on lower ACVs, lower CAC per marginal user but high general CAC to provide for higher customer volume.

With the inexorable ascent of AI, we are approaching an inflection point in the software payment stack which might bring about what I like to think of as No-Touch SaaS.

The Dying Coding Moat and Introduction of No-Touch SaaS

Coding tools have, and will continue to, cast a wider net to a set of "developers" who have limited coding experience. It is not unreasonable to assume that within a few years, programming experience will not be a moat to developing software - in fact, it’s already happening today. That said, except a modicum of devops knowledge, the trivial inconveniences to developing, at least, personal/non-enterprise software today lies in:

1. Finding the right data sources, tooling, and APIs

2. Setting up API keys and paying for the service, and

3. Integrating them within your application.

(3) is already abstracted by Claude Code/Codex while (1) and (2) have room for novel improvements (we are already seeing them through MCP in some senses).

The process of setting up an API key today is cumbersome: (i) find the relevant API (ii) create an account, (iii) verify identity (through email OTP), (iv) add payment method, (v) generate API key, (vi) store API key, (vii) configure rate limits, (viii) set up billing alerts, (ix) write code. This process is not bypassable and must be repeated for every single new API, tool or context source. The process for setting up MCP connections is not too dissimilar.

This overhead and friction is tolerable for high-value integrations like Stripe or X where the cognitive cost of the API selection and the friction of the setup process amortize over hundreds of thousands of API calls but perhaps a bit overkill for infrequent use cases.

If we look past skeuomorphism, consider how a context source discovery and call should look like. Let's say I ask my LLM, “What happened in NYC today?” It should find the New York Times API, touch the relevant API endpoints and fetch me the relevant news articles. This one-time API call should not necessitate me to create an MCP connection for a trivial ask. Similarly, if I ask a broader query: "Develop an investment thesis on {ABC} stock. Look at SEC filings (use Financial Datasets API), recent news (use Parallel Web Systems API), social sentiment (Twitter/X API)." This would involve 3 MCP connections and thus 3 bilateral billing relationships for one query. This is poor UX which can be improved through aggregation and centralization.

Looking past context sources and our high-level LLM workflow, let’s think about how non-enterprise developer experience could evolve. Let's say you built a web app to offer the above-mentioned stock analysis workflow and want to launch it to a user base of 2500 customers, not enterprise scale but certainly not timid. To offer this without your application breaking in prod, you would probably need to upgrade to higher fee tiers across Financial Datasets, Parallel, Twitter/X and your server costs simultaneously skyrocket too (Vercel, Supabase, Railway, etc.).

As such, you have racked up (and locked in) high costs for providing said service. At this juncture, you can either (i) forward-pay high costs out of pocket with limited line of sight into revenue streams, (ii) raise venture funding (but your pseudo-serious hobby project probably will not attract venture dollars), or (iii) have your customers pay for their usage in real-time.

The math for real-time payments could look like:

Bundled Cost to User = API Costs Accrued (FinData, Parallel, Twitter/X) + Server Costs Accrued (Vercel, Supabase, Railway) + Premium/Platform Fee

Real-time payments could theoretically solve the cold-start problem of needing to forward pay and could allow for dynamic pricing modes (increase/decrease what you charge based on supply/demand and optimize fee tiers + server space based on real-time usage)

Content, Data, and Aggregation

Consider two cases:

Case 1: "Conduct deep research on the GPU and datacenter market in the US. Who are the most important players? What is the import/export volume for the chipmakers? Where are the new datacenters being built?"
The extent of this search is structurally limited and will yield mediocre results. The deepest it can really go is the free version of SemiAnalysis and other free data sources while true quality data is hidden behind firewalls.

Case 2: Same Prompt as Case 1 +"This research is important to me, you have a budget of $10. Use the best data sources"

Case 2 can touch and fetch from quality sources like Aterio and Cleanview. This search is structurally better. Provided data sources include pay-per-use API endpoints, the LLM could search for those data sources, pay for them using the budget, and enrich the deep research with high-signal data.

If Case 1 were to reach Case 2 parity, the human would need to find the data sources and set up keys and the billing relationships across the API/MCP providers. In Case 2, instead of expending human discovery, cognitive, and monotonic setup costs across the APIs the LLM dynamically searches and pays for the best data source.

A slight digression but an important note. In the above example we notice that there is a fundamental dislocation of the discovery process for data and context sources. The exploratory cost of finding the right API and cognitive cost of deciding whether the API is worth paying for is abstracted from the end user is relocated to the LLM's search engine and budget constraints. In this sense, LLMs become the main aggregation layer for content and data.

Why Do AI Budgets Not Exist Already?

Implementing AI Budgets require LLM runtime API calls. Runtime API calls necessitate atomicity with payments. For instance, if you pay $5 for access to XYZ API for a certain task: what guarantee exists that XYZ actually fulfills the request vs just pocketing the cash? If payment and data reception can be atomic – we have a trustless system. To service this at scale, we need micropayments. However, incumbent financial rails structurally cannot service micropayments. Credit cards charge ~2.9% + $0.30 per swipe. Assuming a $0.01 call, the fixed fee alone is 30x the API cost. The minimum viable transaction wherein fees drop below 10% of the cost is $4.29 for the above. That said, cards can be used as an abstraction layer for micropayments (more on this later).

As such, per-API-call payments were never meant to work on incumbent rails and we solved API payments through batching: prepaid credits, monthly invoicing, and subscription tiers. You don’t get 100,000 line items of $0.001 each for their Claude Code calls. Anthropic just debits $100 from your prepaid account. Similarly, Amazon doesn’t charge you for every invocation of AWS Lambda, they just send you a chunky monthly invoice. Phenomenal, this works. Why fix it if it’s not broken?

Firstly, in both cases, the discovery process is owned by you, the budgeting for them is your (or your companies’) cognitive burden, and the architectural choices in how to invoke the call is also owned by you. Each new API setup is a new static bilateral relationship. Each billing cycle is the fulfillment of a pre-committed capital for services you expect to use.

Static relationship creation is a bottleneck in a dynamic discovery world. Pre-committed capital is meaningless when you don’t even know which API you will use. This mandates infrastructure that can service relationship formation without breaking trust assumptions and facilitate payments without the constraints of atavistic pricing structures. A natural answer that emerges here is micropayments through blockchains.

But Micropayments Have Historically Never Succeeded?

DigiCash, Flooz, Beenz, Blendle are just some of the tombstones that line the micropayments graveyard. However, micropayments were always set up for failure as articulated by Nick Szabo in his essay "The Mental Accounting Barrier to Micropayments" – the mental decision and accounting costs will always generally exceed the actual cost.

Simply put, humans optimize for predictability over precision. A $15/mo Spotify subscription that you use 50% of is psychologically preferable to a metered system that you might end up paying $7.50/mo for. The former has lower mental transaction costs while the latter invokes multiple brain cycles. This is why subscriptions won: they converted a distribution of micro-decisions averaging out to a certain value into a single predictable macro-decision (where they can charge higher than the expected value of usage). This is why breakage is common across SaaS pricing where customers might pay for more than they actually end up utilizing.

The math breaks when the economic actors shift from humans to LLMs/AI agents. AI agents don’t experience decision fatigue. Their mental accounting costs are not measured in cognitive cycles but in inference units. The agent's only constraint is the budget assigned to them by their human principal, which can be distilled to a simple cost minimization function.

Achieving No-Touch SaaS

Low-touch SaaS reduced CAC by eliminating salespeople. No-touch eliminates the customer acquisition process entirely by making tools/context sources discoverable and payable in the same atomic action.

This requires three infrastructural changes:

Machine-readable price discovery: This treads into the territory of somewhat an API marketplace. One could think of this as a header/metadata containing standardized pricing information on top of MCP which already handles capability description. We already see inklings of this through the skills(.)sh leaderboard and the plugins marketplace.

Payment and API abstraction: The touch and fetch flow exists more so in theory today since most services mandate API key creation. MCP is somewhat of an abstraction. x402 from Coinbase and Machine Payments Protocol from Tempo are very interesting here.

Instant settlement: Settlement needs to be fast and cheap for structural reasons for this. Money notoriously moves slower than software. Generally, this has not been a bottleneck but in this use case ultra-fast payment is crucial. If the payment does not complete approximately as fast as the information is revealed, the service provider takes on credit risk on the agent which necessitates intermediation. Atomicity requirements set a floor on data retrieval latency determined by the execution speed of the underlying monetary rails.

Exploring No-Touch SaaS Economics

The fundamental, bare-bones SaaS revenue equation is, as described by Stripe’s Patrick McKenzie (@patio11):

Revenue = ∑ acquisition × conversion × ARPU / churn

High-touch SaaS optimized for ARPU through six-figure ACVs. Low-touch SaaS maximizes acquisition x conversion through product-led-growth, freemium models, and low friction onboarding.

In the no-touch mode, acquisition costs theoretically approach zero – unless there are ways to bribe agents or pay to be higher in the "API rankings" – since the agent discovers things automatically. Conversion is effectively 100% since discovery and payment happen atomically. However, ARPU collapses. Instead of $15/mo subscriptions, you earn $0.0X per call, with highly variable call volume.

Here, the unit economics work only if volume scales dramatically. A service earning $0.003 per call needs 5,000 calls per month to breakeven with a $15/mo subscription.

There is more work to be done here, but I might save it for a future article.

In parting, some high-level thoughts/open questions:

With instant onboarding and increased discoverability, the provider can serve millions of agents simultaneously rather than some thousand human subscribers. Thus, while ARPU decreases, number of "users" could actually increase exponentially.

No-touch SaaS assumes the existence of players willing to engage in low-margin, high-volume math. Will the lure of dynamic LLM discoverability be enough for businesses to shift from subscription-based to pay-per-use today?

If we assume mass real-time pay-per-use, the cost of the financial rails must be diminutive enough to not eat into already compressed margins.

Which layer captures what value? The aggregation layer of LLMs (Anthropic/OpenAI) could charge a platform fee for including an API in their API catalogue? What does margin look like for financial layers/blockchains? (they structurally cannot charge high fees?)

How does authorization/KYC look? How do you differentiate between a true LLM-originated API call vs. sybil?

How do cards fit in here (MPP accepts cards as a payment mechanism)? How does session-based payment look like in practice? Who bears credit risk? Virtual cards are quite interesting here.

The New Payments Paradigm

No-Touch SaaS exposes a new paradigm about how we think about software payments. The discovery layer switches from humans to agents. The decision costs around which service to use shifts from human emotions to a mathematical cost/benefit tradeoff. Real-time payments become necessary as data retrieval and payment require atomicity.

In Part 2, I’ll dig deeper into how these forces reshape API bundling, where margins settle across layers, and what a fully agent-native economy might actually look like in practice.