Will AI Agents Become Paying Customers of SaaS Products

An AI agent that needs stock fundamentals can already open an account with Financial Datasets without a human touching a signup form. The company's documentation for agents describes the flow: the agent sends a single POST request to a signup endpoint and gets back an API key. The key does nothing yet. Every endpoint answers with HTTP 402, Payment Required, until the account is funded. The agent can request a checkout link but cannot pay it. The person whose email address was used receives a message titled 'An AI agent created a Financial Datasets account with your email,' and the key starts working only after that person pays a Stripe link.

That small flow holds most of the debate. The agent picked the service, registered, and learned the price. A human supplied the money. Whether the next version removes that last step, and whether removing it makes the agent a customer or just a very capable purchasing clerk, is the question this article tries to answer for people who sell software.

Three things people mean by 'agents as customers'

The phrase covers situations that have little in common, and mixing them produces most of the confusion in current coverage.

In the first, an agent holds its own funds and pays per request, with no account and no human in the loop at the moment of payment. This is the model behind x402, the payment protocol built on the HTTP 402 status code. In the second, an agent provisions services and starts subscriptions on behalf of a person or company, spending within a limit that human set. Cloudflare and Stripe's joint work and the Financial Datasets flow belong here. In the third, an agent sits inside a vendor's own product, and the human customer is billed for what it does. Salesforce's Agentforce is the usual example.

Only the first resembles the claim in the title, and it is the smallest by a wide margin. The third has nothing to do with agents buying software; it is a pricing model for software that happens to contain agents. The second is where most of the near-term change sits, and it raises a question that a wallet-holding agent does not: if a human or a company authorized the spend, set the cap and carries the legal obligation, who is the customer?

Under current US law the answer is fairly plain. The Uniform Electronic Transactions Act allows contracts to be formed by electronic agents without anyone reviewing each step, and the user of the agent is generally the one bound. A recent client alert from Quinn Emanuel notes that these statutes address automated transactions only at a general level. They do not settle when an agent's unexpected conduct should be attributed to the business that deployed it, how limits on the agent's authority affect the counterparty, or who bears the loss when an agent exceeds its instructions or is compromised. For now, the customer is whoever is on the hook, and that is a person or an organization.

That does not make the topic a non-event. The party that makes the purchasing decision is changing even if the party that pays is not.

What exists today, and how mature it is

Together these pieces are what the industry calls agentic commerce, and the part that matters to software vendors is machine-to-machine payments for access to APIs and services. The table separates what is live, what is in beta, and what has no evidence behind it yet. The maturity labels are my reading of the sources linked in this article.

x402: real usage, thin numbers

Coinbase released x402 in May 2025. Coinbase and Cloudflare announced a foundation to govern it that September, and the Linux Foundation took over stewardship in April 2026, with Decrypt reporting expressions of initial support from Microsoft, Google, Visa and Mastercard. A summary of Coinbase's own figures puts the protocol at 69,000 active agents, 165 million transactions and roughly $50 million in cumulative volume by late April 2026.

Those numbers need some reading. Divide the volume by the transaction count and the average payment is about 30 cents, by my arithmetic. That is a measure of tiny tickets, not of software budgets. Nothing in the sources says how much of the activity is agents buying something they needed and how much is test traffic or loops, so the totals say little about demand. CoinDesk reported in March that on-chain activity tied to the protocol was small and experimental, at roughly $28,000 in daily volume.

Cloudflare's figure of a billion HTTP 402 responses a day on its network, quoted in the same CoinDesk piece, is often cited as evidence of momentum. It counts responses that ask for payment, not payments completed, and CoinDesk ties it to the strain automated traffic puts on websites. It measures how many doors have a toll sign, not how many people paid.

A small seller's own account is more telling. The operator of ClawMerchants, an x402 data vendor, wrote that agents probe its endpoints and read the price, but conversion from probe to payment is the unsolved part, because most agents do not have funded credentials. That is one vendor, but it describes the likely bottleneck: the agent is willing, and the wallet is empty.

Stripe, the card networks and the protocol pile-up

Stripe and Tempo launched the Machine Payments Protocol on March 18, 2026. In Stripe's description, an agent requests a resource from an API, an MCP server or any HTTP endpoint, the service answers with a payment request, the agent authorizes it, and the resource is delivered. Businesses on Stripe can accept these payments through the PaymentIntents API, in stablecoins or, through Shared Payment Tokens, with cards and buy-now-pay-later methods. Stripe says the same infrastructure used for human payments, including tax calculation, fraud protection and refunds, applies to agent payments.

The launch partners were mostly small and odd: a New York sandwich shop that takes orders from agents, a service that sends physical mail, contributions to Stripe Climate, and Browserbase, which sells headless browser sessions. Browserbase is the SaaS-shaped one, and per a Korean-language summary of the launch and the Hacker News thread that followed, it charges per session.

That discussion raised objections worth repeating. Card networks charge a fixed fee per transaction, so a one-cent charge is uneconomic on cards, and stablecoins only help if the underlying network's fees are low and known. Commenters also found the line between Stripe's two agent protocols unclear. MPP appears to cover the act of paying, while the Agentic Commerce Protocol, which Stripe built with OpenAI, covers the wider shopping flow.

The card networks have their own schemes. Mastercard announced Agent Pay in April 2025, built around agent-specific tokens. Visa followed with its Trusted Agent Protocol in October 2025. Google's AP2, launched in September 2025 with more than 60 partners, introduces signed mandates that record what a user authorized. A neutral comparison frames the three as answers to different questions: whether a merchant can trust the agent, what the user allowed it to buy, and how the network clears the payment. They were designed mainly for consumer purchases with a human authorization at the start.

A SaaS founder reading all this faces a practical problem. There are at least six overlapping schemes, and an agent that speaks one may be unable to pay through another. Most small vendors will not choose; their payment processor will, and that is the most likely way these standards reach ordinary SaaS billing.

A walkthrough: the data enrichment agent (hypothetical)

Imagine an agent working for a sales team. It has been asked to enrich 500 leads and finds that its current tools lack company headcount data. What would have to happen for it to buy that data without anyone completing a step?

First it has to find a provider. Catalogs exist for this: Stripe Projects, which one review describes as listing providers such as Supabase, Clerk and PostHog, and Coinbase's Agent.market, a directory of x402-priced services launched in April 2026. Discovery is the part closest to solved, though both catalogs are run by payment companies with their own interests.

Second, it has to evaluate the provider, and here the plan weakens. An agent can read an OpenAPI file and a price list. It can spend a few cents on a sample. What it cannot easily do is judge whether the headcount figures are right, because checking requires ground truth the agent does not have. A human buyer would ask a colleague, read reviews, or run a trial against known accounts. Until agents have a reliable way to test quality, they will pick on price, documentation and availability, which are exactly the things SaaS vendors can game.

Third, it needs authorization to spend. Cloudflare and Stripe's design gives the agent a budget instead of a card number, with a default cap of $100 a month. The mechanism has three parts: service discovery through a catalog API, identity through Stripe acting as an identity provider on OAuth and OIDC, and tokenized payment. AP2 mandates play a similar role on the card side.

Fourth, it needs an account. Cloudflare's post says agents can now be customers: they create an account, start a paid subscription, register a domain and receive an API token. Cloudflare also offers temporary accounts that an agent can use at once and a human can later claim through a link.

Fifth, it pays, through a token or a 402 exchange, and uses the data. Sixth, someone has to be able to reconstruct what happened: what the agent was allowed to do, what it bought, what it got. This matters most when something goes wrong.

Several pieces are missing. The agent cannot judge quality. The terms of service and any data processing agreement still have to be accepted by someone with the authority to bind the company. Refunds are unresolved, especially when payment settles in stablecoins that lack the dispute mechanisms of card networks. And the company still needs a procurement owner, because finance will want to know why a sales agent holds a vendor relationship nobody approved. The scenario works for a developer's side project. For a sales team's data supplier, it is a long way off.

Who pays, and who answers for it

The Financial Datasets design shows a pattern that may prove common: the agent handles registration, a human handles payment. The vendor emails the account owner, makes clear an agent created the account, and refuses to turn the key on until a person pays. That arrangement solves identity, consent and liability in one move, at the cost of the autonomy that makes agents attractive.

Fully autonomous spending raises harder questions. Vendors operating internationally cannot assume US rules apply. A commentary in Bar & Bench argues that under Indian contract law, which requires consent from a competent contracting party, an AI agent's lack of legal personhood raises the possibility that a contract made through it is not valid. That is one lawyer's analysis of one jurisdiction, but it shows that the settled-looking answer in the US is not a global answer.

In practice, spending caps do two jobs. They limit the damage when an agent loops on a paid endpoint, and they serve as evidence of authority if a dispute arises. A vendor can help its customers here by building caps, per-key budgets and alerts into the product, which any customer running agents will want anyway.

What happens to SaaS pricing

Most commentary on pricing blends two separate trends. The first is vendors pricing their own agents. Salesforce charges for Agentforce through Flex Credits at $500 per 100,000 credits, with a standard action costing 20 credits, or about ten cents; through $2 conversations; and through per-user licenses, according to coverage of its pricing. The company still sells seats alongside usage. That is a story about software that contains agents, and it says little about agents as buyers.

One detail in Salesforce's billing documentation for Agentforce Coworker is relevant, though. Seat-based pricing applies only to authenticated users with eligible licenses, and guest, unauthenticated and portal users are billed by usage. Anyone who is not a licensed human falls into the metered lane. A non-human principal does not fit a seat model, and vendors will have to put it somewhere.

The second trend is the one that concerns the title: pricing that agents can read and pay. For anyone working on SaaS API monetization, the evidence here is thin but consistent. x402 charges per request, Browserbase charges per session, and Cloudflare's setup uses a monthly cap. What these have in common is that none of them requires a person to read a pricing page and choose a plan.

Whether SaaS companies should create separate plans for agents is a hypothetical for now. The more useful question is how a vendor's existing pricing behaves when the buyer is a machine. A pricing page that says 'contact sales' cannot be used by an agent. A plan with a fixed monthly fee and a free trial that needs email verification is awkward. Per-call or credit pricing with hard caps is easy for an agent to evaluate and easy for a company to authorize, which suggests that API-first products with usage pricing will meet agent buyers first and seat-based tools last.

Heavy use brings a second problem. When thousands of agents call the same API, a vendor needs to tell them apart. Web Bot Auth, a set of IETF drafts built on HTTP message signatures, lets an agent operator sign requests and publish keys so a site can verify who sent them. Cloudflare has a signed agents category, and WorkOS lists ChatGPT agent, Goose, Browserbase and Anchor Browser among the first. Adoption has limits: AWS's documentation warns that not every site recognizes signed traffic and that domain owners can block or rate-limit agents regardless of signatures. Identity gives a vendor a handle for rate limits and billing, not a right of access.

Agents as a customer acquisition channel

If agents do choose vendors, acquisition changes character. A human is persuaded by a landing page, a case study and a free trial. An agent is satisfied by an OpenAPI description, predictable errors, a clear price and a signup that works without a browser. A competitor with a worse product and better documentation can win a decision that a human would have made the other way.

Two features of the current setup deserve attention. The first is Cloudflare's temporary accounts, which exist to remove the signup barrier: an agent deploys first and a human claims the account later. That inverts the usual funnel, in which a person signs up and then uses the product. The second is that discovery runs through catalogs controlled by payment companies. If agents mostly find services through Stripe's or Coinbase's directories, those companies hold something like an app store's position, with the fees and ranking power that implies. That is my inference, not something any source claims, but the structure invites it.

The competitive angle cuts both ways. Switching costs fall when an agent can provision a replacement in seconds, so a vendor's lock-in matters less. A vendor whose API is a little cheaper or more forgiving can take volume from an incumbent without a sales cycle. This is hypothetical today, since no source shows agents switching vendors on their own.

Why this may take longer than the headlines suggest

Several obstacles point the same way. The volume so far is small and its composition unknown. Conversion from probing to paying is poor because agents lack funded credentials. Payment standards are fragmented. Micropayments are uneconomic on cards. The law is unsettled outside the narrow question of whether an agent-formed contract is valid, and agents cannot judge quality well enough to be trusted with a budget they allocate themselves.

There is also an argument that the whole framing is wrong. Developers already buy per-use APIs, and an agent working for a developer is a more convenient interface to the same purchase. Companies are unlikely to give software an open wallet. A more plausible arrangement looks like corporate cards: a virtual card per project, a limit, an approval rule and a log. In that world the agent is a delegate, and the human organization remains the customer.

Vendors, too, may not welcome the traffic. Many SaaS products rely on CAPTCHAs, rate limits and terms that forbid automated signup. Cloudflare's own framing of its work is about giving sites control over bots, and AWS's warning that domain owners keep full control applies equally to SaaS vendors who prefer human customers.

Agent-to-agent transactions, where one vendor's agent buys from another's, appear in protocol specifications and vendor roadmaps. I found no live SaaS example, so they belong in the hypothetical column for now.

What to do now

None of this justifies rebuilding pricing. A few inexpensive steps make sense because they also serve human customers who run agents.

Make signup and key issuance possible without a browser, using OAuth-based provisioning, and consider temporary accounts that a person can claim later. Publish pricing, limits and error behavior in forms a machine can read, and keep them consistent with your pricing page. Add spend caps, per-key budgets and usage alerts, because customers running agents will ask for them. Meter usage per key or per principal so you can see which traffic is automated. Keep a human payment path, such as a checkout link, as Financial Datasets does.

If you sell a data or compute API with small tickets, one 402-priced endpoint is a cheap experiment, as long as you expect little volume. Measure how many signups come from agents and how many convert before you invest more. Review your terms with a lawyer, since they probably assume a human accepts them.

So will agents become paying customers?

On the evidence available now, agents are becoming buyers before they become customers. They can discover services, register accounts, and in some designs pay, but the money and the legal obligation still trace back to a person or a company, and the autonomy that exists is bounded by caps and checkout links. Agents that hold their own funds and choose vendors alone exist, but at a scale and ticket size that says little about SaaS revenue.

What is more likely, and already partly visible, is that agents take over the choosing and provisioning steps of software buying while humans keep the budget. Vendors that are easy for machines to evaluate and sign up for will be chosen more often. The signs worth watching are the share of your own signups that come from agents, whether Stripe Projects leaves beta and on what terms, how x402 volume breaks down by who is buying, and whether a court or regulator says who bears the loss when an agent overspends.

FAQ

Can an AI agent legally sign up for a SaaS account? In the US, contracts formed through electronic agents are generally recognized, and the person or company using the agent is typically bound. The open questions concern agents that exceed their instructions or are compromised. Other jurisdictions may differ, so a vendor selling internationally should check its terms with a lawyer.

Do agents need crypto to pay for software? No. x402 settles in stablecoins, but Stripe's Machine Payments Protocol also supports cards and buy-now-pay-later methods through Shared Payment Tokens, and the card networks are building agent credentials of their own. Which method your customers' agents use will depend on which wallet or processor they have.

Should I create a separate plan for AI agents? Probably not yet. A usage-based plan with hard caps and per-key metering serves both agents and humans. Revisit once you can measure how many signups come from agents and how they behave.

How can I tell whether a visitor is an agent? User-agent strings are easy to fake. Web Bot Auth lets agent operators sign requests so a site can verify them, and some CDNs, including Cloudflare, already classify signed agents. Support varies and the standard is still in draft, so treat verification as one signal among several.

Sources

• Financial Datasets, agent signup documentation: https://docs.financialdatasets.ai/agents.md

• Cloudflare, Agents can now create Cloudflare accounts, buy domains, and deploy: https://blog.cloudflare.com/agents-stripe-projects

• Cloudflare, Temporary Cloudflare Accounts for AI agents: https://blog.cloudflare.com/temporary-accounts

• Stripe, Introducing the Machine Payments Protocol: https://stripe.com/it/blog/machine-payments-protocol

• MPP specification: https://mpp.dev/

• Decrypt, What Is x402: https://decrypt.co/resources/what-is-x402-how-ai-agents-pay-with-crypto

• CoinDesk, AI agents are breaking web economics, but Cloudflare says x402 can help: https://www.coindesk.com/tech/2026/05/05/ai-agents-are-breaking-web-economics-but-cloudflare-says-x402-can-help

• Eco, x402 Protocol Explained (secondary summary of Coinbase figures): https://eco.com/support/en/articles/14839402-x402-protocol-explained

• ClawMerchants, Agent payments in 2026: x402 vs MPP: https://dev.to/nathanielc85523/agent-payments-in-2026-x402-vs-mpp-and-why-we-built-both-4df3

• wikidocs, summary of the MPP launch and Hacker News discussion (Korean): https://wikidocs.net/blog/@jaehong/9593/

• Eco, Mastercard Agent Pay vs Visa Trusted Agent: https://eco.com/support/en/articles/15192003

• Didit, Agentic commerce needs an identity layer: https://didit.me/sw/blog/agentic-commerce-identity-layer/

• DevToolPicks, Stripe Projects review: https://devtoolpicks.com/blog/stripe-projects-ai-agents-deploy-buy-domains-pay-infrastructure-2026

• WorkOS, Web Bot Auth: https://workos.com/blog/web-bot-auth-identify-ai-agents

• AWS, Reducing CAPTCHAs with Web Bot Auth: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/browser-web-bot-auth.html

• Salesforce, Billing considerations for Agentforce Coworker: https://developer.salesforce.com/docs/data/agentforce-coworker/guide/agentforce-coworker-billing-considerations

• Let's Data Science, Salesforce expands consumption pricing for Agentforce: https://letsdatascience.com/news/salesforce-expands-consumption-pricing-for-agentforce-5cc905f5

• Quinn Emanuel, When AI Agents Do the Transaction: https://www.quinnemanuel.com/the-firm/publications/client-alert-when-ai-agents-do-the-transaction-managing-contract-and-payment-risk/

• Bar & Bench, Agentic Commerce and the Law: https://www.barandbench.com/view-point/agentic-commerce-and-the-law-are-we-ready-for-ai-driven-transactions