Not all payments labeled as Agent are truly AgentPay. From narrative, Demo, reproducible products, real transactions to continuous income, I have organized a set of noise reduction methods with five levels, and I will also discuss which scenarios are more likely to emerge first.

Written by: Yuki (Liu Yuqing)

Today I saw another payment company claiming that they are doing AgentPay. Curious about what scenarios they have actually implemented, I went to their official website to take a look. There were product capabilities, payment processes, and a Demo on the page. But what about the scenarios? Are there any real scenarios? Are agents using it? Who is paying for it?

Agentic is becoming a new industry narrative.

Whether it's Agentic Payment, Agentic Economy, Agent Commerce, or Agent Trading, all of it must carry the name Agent. Originally wallet providers began to talk about Agent Wallet, previous payment API providers started discussing AgentPay, and those doing trading, custody, stablecoins, and data services can also find a narrative with an Agent version.

I have also been observing whether there are any scenarios of Agentic Payment that can truly establish themselves, and I have had discussions with several teams. Some teams have already been conducting experiments: providing agents with wallets, connecting payment protocols, allowing them to purchase data, search functionalities, models, or other tools; others are using agents for trading. Some teams, after thoroughly examining the concepts, decided not to pursue this narrative for now and to continue focusing on their original business.

In the past few months, to continuously understand the development in this field and to see some real information, I created an Agentic Payment Signal for myself. It searches for new products, collaborations, interfaces, and transaction data from the information sources I set daily and filters it according to my standards. I also make a point to check the updates.

My filtering criteria are quite simple: the matter must genuinely relate to Agent payment, have products, documentation, interfaces, or transaction records as first-hand information, and it must show where it currently stands. If simply adding the term Agent in the title or discussing future concepts, I usually won't focus on them.

The Agentic Economy is essentially a bilateral market, where on one side there must be agents and those willing to pay for them: who the customers are, how frequently they use the service, and why they are willing to pay; on the other side, there must be goods or services worth purchasing and trading by the agents, and this transaction must genuinely solve a problem. Even if both sides exist, there are still questions: how does the platform charge, can the transactions be sustained, and ultimately can a business be formed?

Nearly every month, I see new startup projects and movements from large companies; the industry is indeed moving forward. However, the noise around Agent in the market remains loud, making it difficult to discern who is merely posing and who is genuinely doing something. To what stage have these so-called Agent strategies actually progressed?

I am writing this article not to evaluate who is narrating and who is acting, nor to make a list of companies. I just want to present some phenomena I have observed and the different dimensions some have currently achieved, more specifically, we can break down what is publicly visible into several levels.

First Level: Merely Narrating

Companies that only have a narrative typically release a complete description of a future scenario. Agents can discover services, compare prices, and make automatic payments; systems support multiple chains, currencies, limits, approvals, refunds, and compliance; accompanied by a flowchart and market judgments like "the machine economy is coming."

These contents may come from press releases, speeches, annual strategies, or landing pages, but you cannot find product entry points, documentation, code, interfaces, testing environments, or operational paths that are runnable. (Perhaps the company is in development or in a private pilot stage but has not made it public.)

If you are an industry practitioner or just interested in AgentPay, if you see a company say “just one line of code can be integrated,” you can start looking for that line of code. If you can't find it, stop at the narrative level. Just listen.

Second Level: Having a Demo

Some companies have already created a Demo; with a click of a button, you can see the agent requesting a service, receiving a price, confirming payment, and then obtaining results. Compared to just having a flowchart, achieving this step at least indicates that the team has indeed written something and has integrated the entire process, but a Demo can only prove this much.

Because the successful payment you see may only be a segment of animation on the page; the balance might be simulated, and both buyers and sellers could be the company’s own accounts. The whole process needs to run through a predetermined route, not representing that external users can actually use it.

So when viewing a Demo, I usually dig a bit deeper, asking additional questions: Can the inputs be changed, or can the same process only be replayed? Did the backend actually receive the request? Was money actually moved? Can you see transaction records? If payment fails, or services do not return, or the system executes again, how will it be handled?

If you can't see these, it’s still just a product prototype, indicating that the team has indeed created something, but it does not prove that the scenarios have landed, let alone that someone is willing to pay for it.

Third Level: Having Reproducible Products

The third level begins to enter "actually doing things." External developers can find SDKs, CLIs, MCPs, API documentation, code repositories, or testing environments and can independently complete a call according to publicly available steps. The product doesn't just showcase the happy path but also explains how identity, authorization, limits, retries, revocations, and settlements are handled.

The most important word here is "reproducible," not that company employees demonstrated success at a press conference, but that outsiders following the public documentation can also achieve the same results. At this level, it can be said that the product is indeed real, but it cannot yet prove that the scenario is established.

The payment industry can easily switch existing capabilities to an Agent entry: the original wallet adds a CLI, the previous API incorporates an MCP, the custodial system adds a session key, and the policy engine adds Agent authorization. This isn’t necessarily a reskin; agents truly need machine-callable entry points and new permission boundaries. But having the product created can only prove supply exists, not that demand exists.

Fourth Level: Having Verifiable Payments and Deliveries

At the fourth level, money has really moved, and external individuals or agents can not only call the product but also verify the payment and delivery paths.

For example, Exa has already integrated x402 into its search and webpage reading API, allowing agents to send requests without needing to register an account or apply for an API key; the service returns a price, and the agent receives search results after paying with stablecoins. According to its currently public pricing, a regular search costs less than a cent, and reading a webpage is even cheaper.

Apify has integrated a batch of web crawlers and automation tools into x402, allowing agents to temporarily purchase a TikTok data scrape, a batch of Google Maps merchants, a set of e-commerce products, or some social media content. It doesn't need to register separately for each tool and buy packages; just providing a maximum budget allows for settlement based on actual results. However, Apify's official documentation also labels this capability as experimental, indicating it is usable but still in the early stages.

These two types of scenarios are relatively easy to run because what the agent purchases is quite specific: a search, a piece of content, a batch of product data. It is easier to judge how much is paid, what is received, and whether delivery happened.

An agent can automatically initiate hundreds or thousands of small calls in a very short time; there have been such occurrences in the phase data of x402scan: BlockRun generated nearly ten million transactions in a month, but the buyer addresses were only around a thousand; claw402 had hundreds of thousands of transactions, with fewer than a hundred buyer addresses, totaling just over a thousand dollars.

So while the transaction volume looks large, it may just be a few programs calling frequently, and it may include tests, subsidies, internal accounts, and related wallets.

At this level, who paid whom? What was purchased? Was anything delivered? Are the buying and selling parties different entities? Will the same buyer come back for another purchase next time?

Fifth Level: Having Customers and Continuous Revenue

Only at the fifth level does it begin to resemble a business; at this point, we are not just looking at "has anyone paid once," but rather if there are external customers continuously using it, and if the company can receive payment from it.

Currently, there are not many publicly available cases that can accurately convey this matter. AgentCash reports on its official website that agents have completed over one million paid calls through its platform. Its backend, Merit Systems, also disclosed that the 44 interfaces operated by the team generated around 765,000 transactions and about $40,000 in revenue this year.

This set of numbers is more useful than how many partners have been integrated or how many wallets are supported, as it at least simultaneously relays calls, transactions, and revenue. However, it's important to note that this is still data publicly released by the company and not from a third party's audit results. Also, it still does not answer all questions: among the million calls, how many were generated by the team's own interfaces and how many came from external merchants? How many different customers are there? How long did the customers use the service? How much of the $40,000 came from the same batch of people re-purchasing? None of these are visible yet.

On the traditional financial institution side, Mastercard publicly stated that Itaú and Santander have completed real transactions through its Agent Pay program. This certainly goes beyond "both parties will explore together," as it indicates that money and purchase processes have indeed occurred. However, if it does not tell you how many total transactions occurred, their amounts, how long they ran, or whether anyone came back to use it again, then at most, it can only prove "it has been realistically tried once" and does not demonstrate there are stable customers.

Thus, at the fifth level, do not just focus on a seemingly large number. It is more important to clarify the following four things:

• Who is using it?
• Why are they using it?
• Did they come back after using it?
• Who is actually paying, and what profit does the company have?

If a company claims to have many partners, you can keep asking: did these companies just publish a press release together, or have they actually integrated their systems? Is it in a small-scale test, or have they truly paid to use it? If it references a few tens of millions of users from previously existing businesses, hundreds of millions of wallets, or billions of API calls, it's also worth asking: how many of those actually stem from the new Agent product?

The original foundation may be strong, which is undoubtedly an advantage. However, the total data of the existing business cannot prove that a new product has found customers and a way to make money.

These five levels are not a ranking of good or bad, nor are they meant to label any company as "true" or "false."

They are more like a set of noise reduction methods for practitioners. When seeing a new AgentPay project, one can first assess which step it has currently reached: is it discussing the future, has it produced a Demo, has the product been opened, has it completed real transactions, or does it have customers continuously paying?

If you are genuinely interested in this direction, you can continue searching with this method: what specific problem does it solve, what did the agent buy, did the money actually move, who is using it, who is paying, and does it happen repeatedly?

This way, you won't overestimate a project based solely on a press release, nor will you overlook the real scenarios and case studies that have already emerged just because it hasn’t scaled into revenue yet.

Having a Demo merely indicates that the product is beginning to take shape; having transactions shows that payment and delivery have been executed; having customers continuously paying confirms it is approaching a business.

Which Scenarios Are More Likely to Emerge First?

During my daily observation of Signals, I found that the progress of Agentic Payment roughly occurs on three levels: how agents make payments, how people manage agents, and what agents are actually buying.

The first two levels involve wallets, payment protocols, settlements, budgets, approvals, and responsibility boundaries. The third level has begun to show specific purchasing behaviors—from searching, data and model calls, to actual physical product orders.

Thus, after assessing the product, we need to return to a more fundamental question: what exactly is the agent purchasing? What issue does this payment resolve? Below, I want to take a more specific look at which purchasing scenarios are likely to emerge first.

I believe that the first scenarios to emerge will not be where agents buy coffee, airplane tickets, or hotels like humans, but rather, where they temporarily purchase digital capabilities that machines can consume instantly as they complete their tasks.

For example:

• Search and webpage reading;
• Data scraping and enrichment;
• Models, inference, and compute;
• Merchant, product, and advertising intelligence;
• Browser sessions, verification services, and RPC;
• Pay-per-access content and professional data.

These goods share several common points: small amounts, quick deliveries, machine-readable results, measurable costs, and relatively easy failure judgments.

For instance, a GTM agent may need to conduct market entry analysis for a company, requiring first an SEO diagnosis: checking website indexing, keyword ranking, backlinks, and page issues; then purchasing competitor website traffic, primary customer acquisition channels, and keyword data to assess where their users come from.

Subsequently, it may need to read competitor landing pages and pricing pages, scrape ad materials and deployment records, organize Google Maps or TikTok merchant lists, and then call enrichment APIs to complete details on company size, contacts, and emails. Finally, it compiles this information to provide a target customer list, channel judgment, and recommendations for subsequent outreach.

Completing such a task may require various services like search, crawling, SEO data, traffic analysis, advertising intelligence, and corporate information. However, these capabilities are not necessarily needed every day; sometimes it only requires a quick check on a domain, purchasing a report, or scraping a few hundred data points.

If every service requires a person to register an account first, buy a monthly package, bind a credit card, apply and save the API key, and then inform the agent of which service to call, its autonomous execution will continually get stuck on human preconfiguration. Many tasks aren't about the agent not being able to perform them, but rather it lacks the necessary data and tool permissions to complete this step.

Agent Payments here resolve more than just "how to pay out money." More importantly, agents can discover suitable services during execution, see prices and delivered content, purchase on a per-instance basis within a limited budget, and bring results back into the original workflow. Humans are responsible for setting goals, budgets, and boundaries, while agents determine specifically what tool to purchase and how many times.

However, whether this scenario can succeed also depends on whether the supply side is willing to open up.

Many of the data that a GTM agent genuinely wants to use is held by mature platforms like Similarweb and Semrush. They already have APIs, and Semrush now also provides an official MCP, which technically allows agents to call. But users still need to purchase subscriptions, API units, or contact sales in advance, which contrasts with the agent discovering services, seeing prices, and purchasing per instance during task execution – these are two completely different models.

There are currently some startup teams repackaging search, crawling, traffic, and corporate data into services that can be directly purchased by agents. They can reduce registration, contracting, and API key configuration but will also encounter a practical question: whose underlying data is it? Is there resale rights? Does the data platform allow third parties to break their products into per-call billing? When these intermediary layers begin to take customer relationships, pricing power, and profits, will the original data platform continue to stay open?

This will be a long-term game. Startups hope to combine different data sources into a capabilities market freely purchasable by agents; existing platforms may instead create agent entry points, keeping calls within subscription and account systems. The final models that emerge will likely be a combination of open protocols, self-operated agent interfaces, and closed platforms coexisting in the long run.

Cloudflare is a case worth continuing to monitor; it does not produce its own SEO, traffic, or business data but instead stands at the entry points of websites and services, trying to help suppliers determine which content can be accessed for free, which should be intercepted, and which can charge agents.

Pay Per Crawl allows websites to set prices for AI crawlers accessing content; the Monetization Gateway aims to further enable websites, datasets, APIs, and MCP tools to charge per instance.

Its value is not merely to connect to x402 but to attempt to handle pricing, identity, access control, and payments all in one gateway, allowing suppliers to retain control over pricing and access rules. However, it is still quite early: Pay Per Crawl remains in closed beta, and the Monetization Gateway is still in a waitlist; public materials cannot yet demonstrate scalable income or adoption.

Therefore, what this direction truly needs to solve is not only payments. It also includes data authorization, resale boundaries, service discovery, and profit distribution. Technically, having an agent pay a sum is not difficult; the challenge lies in why the supplier is willing to let it purchase that way.

Advertising is another scenario that I have always believed is quite suitable for the implementation of Agentic Payment.

Advertising is not simply putting money into an account. It is affected by platform algorithms, placement strategies, material quality, optimizer experience, budgets, and ROI goals. An optimizer makes numerous small decisions daily: which material is starting to fatigue, which audience should have their budget increased, which keyword costs have risen, which channels should be paused, and when the goals should be lowered to allow the system to explore new traffic.

This type of work has a characteristic: data changes rapidly, feedback is relatively clear, and continuous judgments must be made. It is hard for a human to monitor multiple platforms 24 hours a day, but AI can continually read impressions, clicks, conversions, CPA, and ROAS, adjusting materials, audiences, bids, and budgets according to pre-set goals.

In fact, Google, Meta, and TikTok have already deployed AI internally for real-time bidding, audience expansion, material combinations, and budget allocation on their platforms. So the opportunity might not just be to create another "automated pricing tool," but to allow agents to stand above multiple platforms, understand corporate business objectives, compare different channel performances, and decide where the next budget should be allocated.

What needs to be distilled here is the judgment ability of excellent optimizers: under what circumstances should the algorithm continue to learn, and when should losses be stopped; is a drop in ROAS a normal fluctuation or an indication of issues with materials, pages, or audiences; when should material or channel be changed; after increasing the budget, are the new conversions still cost-effective?

However, this does not mean that by writing a few rules based on the optimizer's experience, the agent can fully take over advertising placement. It first needs reliable conversion data and attribution; it also needs to understand profits, inventory, collection cycles, and customer lifetime value. Otherwise, it might perform well in terms of ROAS on the platform but fail to bring actual profits to the company.

Payments here are a very natural combination, as advertising decisions will ultimately turn into funding decisions. The agent should not merely suggest "adding the budget to a certain campaign," but it should also be allowed to mobilize how much money, where to spend on which platforms, maximum losses in one day, and under what circumstances must it halt to seek human approval.

Therefore, this scenario requires not a micro-payment occurring every time a bid happens but rather a more reasonable form where humans first give agents a controlled budget and set platform whitelists, daily limits, target CPAs or ROAS, abnormal loss limits, and approval rules. Agents continuously optimize within these boundaries; once they exceed the limits, they pause or revert to humans.

Advertising placement itself involves continuous decision-making and fund allocation. When decisions begin to automate, funding permissions, stop-loss mechanisms, and responsibility boundaries must also be automated together.

Payments always serve the scenario; in advertising placements, there are already high-frequency decisions, clear budgets, and results that can provide ongoing feedback. As AI progressively surpasses human capabilities in localized decision-making, it requires not just a set of analytical tools but also a payment and permission system capable of mobilizing funds safely.

Therefore, different scenarios require different Agent Payments; small, high-frequency, machine-to-machine digital services need per-instance pricing and immediate settlement; advertising, purchasing, and corporate expenditures require permissions and controls.

How to Determine if an AgentPay is Worth Following?

When I see a company announcing an AgentPay, Agent Wallet, or Agentic Economy strategy in the future, I will check in this order:

First Look at the Products

What exactly is the agent purchasing? Is it a clear API, data, model, or service, or merely an imagination of "machines will trade autonomously in the future"?

Then Look at the Entry Points

Is there a public product, documentation, SDK, CLI, MCP, sandbox, or endpoint? Can external developers independently call it?

Then Look at the Money

Has an actual payment occurred? Can you see a receipt, transaction hash, or reliable production records? Page animations and test currency do not count as commercial adoption.

Then Look at the Customers

Are there external customers confirming use from their own channels? Are they supporters, co-developers, pilot users, or paying customers?

Finally Look at Repeat Purchases

Why would customers use it a second time? If each time it has to rely on company subsidies, promotional incentives, or internal traffic, it is hard to turn even large transaction volumes into a business.

There is also a question that I think is very important: what new value does this agent layer bring? If it is merely renaming existing wallets or payment APIs, its value is limited. If it truly reduces friction in account registration, API key configuration, and cross-supplier settlement, or adds budgets, authorizations, revocations, audits, and reconciliations, then even if it reuses the old foundation, it could still be a meaningful new product.

Finally

I believe the Agent Economy will come, but it will not happen naturally just because machines have wallets.

Agents are transitioning from providing answers to calling tools, configuring resources, and completing tasks. When software begins to act on behalf of people, pricing, authorization, payment, and reconciliation will no longer be peripheral functions but will become part of its operational capabilities.

The real threshold for Agent Payments has never been about enabling machines to make a single payment but rather enabling them to continuously make worthwhile payment decisions within limited budgets, clear objectives, and accountable boundaries.

This competition will ultimately not just revolve around which chain is faster or which protocol is more open. The deeper question is: who will define what machines can buy, who will grant them budgets, who will judge whether transactions are complete, and when machines make mistakes, who can stop them and take responsibility.

Wallets are merely entry points; scenarios determine demand, control dictates whether they can enter enterprises, and repeat purchases decide if they ultimately become a business.

Therefore, I prefer to view today's Agent Payment as a rewriting of power boundaries.

When agents no longer merely answer questions but start to mobilize external resources, payments will become part of their operational capabilities. However, only when the value created by this action exceeds the costs incurred will the Agent Economy truly transition from narrative to reality.