Author: Vikram Singh, Source: Galaxy, Compiler: Shaw Golden Finance

Overview

• Today’s software payment system is built for static, human-driven partnerships. For new developers who have never written a line of code, the configuration and management of API/MCP is very cumbersome. Premium data sources are losing customers because large language models cannot interact dynamically with paywalls.

• In the contactless SaaS mode, AI agents can independently discover, call and pay for APIs and data sources without creating an account, configuring an API key, or establishing a bilateral billing partnership.

• AI Budget empowers research by enabling large language models to efficiently access paywalled data at runtime. The x402/Machine Payment Protocol workflow dramatically removes API integration friction, enables dynamic pricing of software, and solves cold-start challenges for non-enterprise developers.

• The economic logic of contactless SaaS challenges the subscription pricing model and strongly promotes the industry's transition to a pay-as-you-go billing model. If contactless SaaS becomes mainstream, the industry may rethink core SaaS metrics such as customer acquisition cost (CAC) and average revenue per user (ARPU).

SaaS development history to date

In the past few weeks, it is worth watching the industry trends from the perspective of smart payments: Tempo went online on the main network, and the Machine Payment Protocol (MPP) performed particularly well; Ramp launched smart cards last week; Visa released command line tools and actively promoted smart payment business; Coinbase has also been leading the development of the x402 protocol in recent months.

However, most of the current industry focus is on commercial shopping scenarios within the large language model (LLM) chat interface, and the discussion on software and data payment is very limited. I believe that AI will fundamentally change our understanding of software payment and SaaS models in the future, and this article will also explore this point of view.

The first software license agreement was signed in 1969, when IBM decided to separate and sell its large and expensive hardware and software services. Over the years, the software finance field is now dominated by the SaaS model, and SaaS can be divided into two types: high-involvement (such as Salesforce, SAP) and low-involvement (such as X, Stripe).

High-involvement SaaS has a high customer unit price, the customer acquisition cost of a single incremental user is high, and the customer support cost is high; the low-involvement SaaS has a lower customer unit price, and the customer acquisition cost of a single incremental user is even lower, but in order to acquire a large number of users, the overall customer acquisition investment is still very high.

With the unstoppable development of AI, the software payment system is reaching an inflection point, which may lead to the emergence of the contactless SaaS model as I define it.

The gradual disappearance of programming barriers and the birth of contactless SaaS

Programming tools have and will continue to lower the threshold, covering more "developer" groups with limited programming experience. We can definitely foresee that in just a few years, programming experience will no longer be a barrier to software development - in fact, this trend is already emerging.

At this stage, the trivial obstacles to developing personal or non-enterprise software (except for a small amount of operation and maintenance knowledge) are mainly concentrated in:

1. Find the right data sources, tools and APIs

2. Configure API key and complete service payment

3. Integrate it into your own application

The third point has been abstracted and simplified by tools such as Claude Code and Codex, while the first two points still have great room for innovation and optimization (to a certain extent, the machine payment protocol has brought about relevant changes).

Today, the process of configuring API keys is cumbersome and inefficient: ① Find the corresponding API → ② Create an account → ③ Complete identity verification through email verification code → ④ Add payment method → ⑤ Generate API key → ⑥ Store the key → ⑦ Configure call rate limit → ⑧ Set billing reminder → ⑨ Write code. This process cannot be skipped and needs to be repeated for each new API, tool or data source. The process of establishing a machine payment protocol connection is also very similar.

For high-value integration scenarios such as Stripe and

Source: Galaxy Ventures

Putting aside the mindset of skeuomorphic design, let’s think about what the discovery and invocation of contextual data sources should look like. Let's say I ask my big language model: "What happened in New York today?" It should be able to find the New York Times API, access the relevant API endpoint, and get me the relevant news article. Such a one-time API call should not require me to create a Machine Payment Protocol (MCP) connection for a trivial request.

Similarly, if I ask a broader query: "Write an investment analysis report for {ABC} stock. Review SEC filings (using the Financial Datasets API), latest news (using the Parallel Web Systems API), and social sentiment (Twitter/X API)." This would involve 3 MCP connections, so 3 bilateral billing relationships would be established for one query. This user experience (UX) is terrible and can be improved through aggregation and centralization.

In addition to contextual data sources and our high-level large language model workflow, let’s consider how the non-enterprise developer experience will evolve. Let's say you develop a web app that provides the stock analysis workflow described above, and want to roll it out to a user base of 2,500 customers—not enterprise-scale, but certainly not small. In order for the application to run stably in the production environment without crashing, you may need to upgrade the services of Financial Datasets, Parallel, Twitter/X to higher-paid plans at the same time, and your server costs (Vercel, Supabase, Railway, etc.) will also soar.

As a result, you have accrued (and locked in) high costs to provide the service. At this node, you have the following choices:

• Pay high costs upfront out of your own pocket, but the prospects for revenue sources are unclear;

• Seek venture capital, but your semi-formal side project is unlikely to attract venture capital;

• Let your customers pay based on real-time usage.

The cost calculation method of real-time payment can be:

User bundle cost = cumulative API cost (Financial Datasets, Parallel, Twitter/X) + cumulative server cost (Vercel, Supabase, Railway) + value-added/platform service fee

Real-time payment can theoretically solve the cold-start problem that requires prepayment, and supports a dynamic pricing model (adjust charges based on supply and demand, and optimize charging packages and server space based on real-time usage).

Content, data and aggregation

Let’s look at two cases:

Case 1

"Dive into the U.S. GPU and data center market. Who are the most important players? What are chipmakers' import and export volumes? Where are new data centers being built?"

The depth of such searches is structurally limited and the results are often mediocre. At best it only provides access to the free version of SemiAnalysis and other free data sources, while the truly high-quality data is hidden behind a paywall.

Case 2

Use the same prompt words as Example 1 + "This research is important to me, you have a budget of $10, please use the best data source."

Source: Galaxy Ventures

Case 2 can access and retrieve high-quality data sources such as Aterio and Cleanview. This type of retrieval is structurally better. When data sources support pay-as-you-go API endpoints, large language models can autonomously retrieve these data sources, use budgets to complete payments, and use high-value information to complete in-depth research.

For Case 1 to achieve the same effect as Case 2, human users must find data sources, configure keys, and establish billing relationships with various API/MCP service providers. In case 2, the large language model will dynamically retrieve and pay to call the optimal data source, eliminating the cost of human search, decision-making, and repeated configuration.

A slight digression, but this is very important: from the above example, we can see that the discovery process of data and contextual data sources is fundamentally misaligned. The exploration cost of finding a suitable API and the decision-making cost of determining whether the API is worth paying are separated from the end user and transferred to the search engine and budget constraints of the large language model. From this perspective, big language models are becoming the core aggregation layer for content and data.

Why is AI budget not yet popular?

Implementing AI budgets requires API calls while the large language model is running, and runtime API calls require payments to be atomic. For example, if you pay $5 for a task and call the XYZ API: how to ensure that XYZ will actually provide the service and not just take away the money? If payments and data acquisition could be done atomically, we could have a trustless system. To achieve this at scale requires micropayments. However, existing financial infrastructure is structurally unable to support micropayments. Credit card fees are approximately 2.9% + $0.30 per transaction. Assuming a call costs $0.01, the flat fee alone amounts to 30x the cost of the API. At the above rates, the minimum feasible transaction amount for a fee less than 10% of cost is $4.29. However, credit cards can serve as an abstraction layer for micropayments (more on this later).

Therefore, pay-per-API is not suitable for running on existing payment channels. The industry can only solve the API payment problem through batch billing: pre-deposited quota, monthly bills, and subscription packages. You won’t see the breakdown of 100,000 individual $0.001 transactions in the Claude Code call, Anthropic will only deduct $100 from your pre-deposited account. Similarly, Amazon does not bill each AWS Lambda call individually, but instead issues a total monthly bill. This model is effective. If it’s not broken, why change it?

First of all, in the above two scenarios, the retrieval process is completed by yourself, cost planning is your (or company's) decision-making burden, and the architectural design of the calling method is also decided by you. Every time a new API is added, a new static bilateral cooperation relationship needs to be established. Each billing cycle, funds are prepaid for the services expected to be used.

In the world of dynamic retrieval, establishing static cooperative relationships is a major bottleneck. There’s no point in paying money upfront when you don’t even know which API you’re going to use. This requires a new infrastructure: one that can establish partnerships without breaking the premise of trust and enable payments without the constraints of antiquated pricing systems. A natural solution is: blockchain-based micropayments.

But micropayments have never been successful historically?

Digicash, Flooz, Beenz, Blendle, etc. are all failures in the field of micropayments. But as Nick Szabo said in the article "The Psychological Accounting Barriers of Micropayments", micropayments are doomed to fail from the beginning - human decision-making and accounting costs are usually always higher than the actual transaction costs.

Simply put, humans value predictability over accuracy. A $15 monthly Spotify subscription, even if only half used, is psychologically better than a pay-as-you-go model that might end up costing just $7.50. The former has lower psychological transaction costs, while the latter requires multiple thinking decisions. This is why subscriptions win: It turns a series of small decisions with a fixed average value into one large, predictable decision (which also allows the service provider to charge more than the actual usage value). This is also why “leakage” is prevalent in SaaS pricing – users often pay more than they actually use.

But when the economic subject shifts from humans to large language models/AI agents, this set of logic no longer holds true. AI agents will not suffer from decision-making fatigue, and their “mental accounting costs” are not measured in terms of cognitive energy, but calculated in terms of reasoning computing power. The only constraint on the agent is the budget allocated by the human, which can be reduced to a simple cost minimization function.

Implementing contactless SaaS

Low-involvement SaaS reduces customer acquisition costs by eliminating the sales team. Contactless SaaS allows tools and data sources to be retrieved directly and complete atomic payments, completely eliminating the customer acquisition process.

This requires three infrastructure changes:

• Machine-readable price discovery: This amounts to forming an API marketplace. It can be understood as adding a layer of request headers or metadata containing standardized pricing information on top of the MCP that already has the capability description function. This kind of prototype has already appeared in the skills.sh rankings and plug-in market.

• Payment and API abstraction: At present, "one-click retrieval of payment data" is more of a theoretical stage, because most services still require the creation of API keys. MCP enables abstraction to a certain extent, and Coinbase’s x402 protocol and Tempo’s Machine Payment Protocol (MPP) are extremely valuable in this area.

• Instant settlement: Due to structural requirements, settlement must be fast and low-cost. As we all know, money moves much slower than software. Normally this wouldn't be a bottleneck, but in this scenario ultra-fast payments are crucial. If the payment completion speed is slower than the data return speed, the service provider will bear the credit risk brought by the agent, which will require the intervention of an intermediary. The atomicity requirement sets a lower bound on data retrieval latency, which is determined by the execution speed of the underlying payment channel.

Discussion on the economic model of contactless SaaS

As Stripe’s Patrick McKenzie (@patio11) said, the most basic SaaS revenue formula is:

Revenue = Σ (customer acquisition × conversion rate × average revenue per user) / churn rate

High-involvement SaaS maximizes average revenue per user with six-digit transaction volume per customer. Low-involvement SaaS maximizes customer acquisition and conversion efficiency through product-driven growth, free value-added model and low entry threshold.

In the contactless mode, the customer acquisition cost is theoretically close to zero - unless there is a means of bribing the agent or paying to improve the API ranking - because the agent will automatically retrieve resources. Conversion rates are also almost 100% because retrieval is done simultaneously with payment atomization. But the average revenue per user will drop significantly: the revenue is no longer a monthly subscription fee of $15, but a single call fee of $0.0X, and the call volume fluctuates greatly.

Under this model, the unit economic model can only be established if the transaction volume achieves large-scale growth. A service that earns $0.003 per call would need 5,000 calls per month to equal revenue from a $15 subscription fee.

There are still a lot of issues worthy of research in this area, which I will leave for subsequent articles.

Finally, some macro thoughts and open questions are raised:

1. With instant onboarding and higher searchability, service providers can simultaneously serve millions of agents instead of thousands of human subscribers. Therefore, even if per-user revenue declines, the number of “users” may grow exponentially.

2. Contactless SaaS requires participants to accept a low-margin, high-volume model. At present, is the attractiveness of dynamic retrieval of large language models enough for enterprises to shift from subscription to pay-as-you-go?

3. If large-scale real-time pay-as-you-go is to be realized, the cost of the underlying payment channel must be extremely low so as not to erode the already meager profits.

4. How is value allocated at each level? Can large language model aggregation layers (Anthropic/OpenAI) catalog APIs and charge platform fees? What are the profit margins at the financial layer/blockchain (structurally unable to charge high fees)?

5. How to design the authorization and real-name authentication process? How to distinguish real large language model API calls from Sybil attacks?

6. What role does credit card play (MPP supports credit card as a payment method)? How does session-based payment actually work? Who bears the credit risk? Virtual cards are a direction worth paying attention to.

New payment paradigm

Contactless SaaS reveals a new software payment paradigm: the retrieval layer shifts from humans to agents, and the decision-making cost of service selection shifts from human emotions to quantified cost-benefit trade-offs. Since data acquisition and payment require atomic synchronization, real-time payment has become an inevitable requirement.

In the next article, I’ll dive into how these trends are reshaping the API bundling model, how profits are distributed at each level, and what a fully native agent economy might look like in reality.