Is Everyone Claiming to Do AgentPay: Is There Really a Scenario or Just Narrative Packaging?

Not all payments labeled as Agent are true AgentPay. From narrative, demo, reproducible products, real transactions to sustainable income, I have organized a set of noise-reduction methods using 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 to be doing AgentPay. Curious about what scenarios they have implemented, I checked their official website. The page has product capabilities, payment processes, and a demo. But where are the scenarios? What real scenarios exist? Are there 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, they all want to be labeled with the term Agent. Companies that originally focused on wallets are now talking about Agent Wallets, those that used to provide payment APIs are now discussing AgentPay, and those involved in trading, custody, stablecoins, and data services can also find an Agent version of their narrative.

I have been observing whether there are any real scenarios of Agentic Payment that can actually be established and have communicated with several teams. Some teams are already experimenting: providing agents with wallets, connecting payment protocols, allowing them to purchase data, search, models, or other tools; some are using agents for trading. There are also teams that, after thoroughly reviewing everything, decided not to pursue this narrative for now and continue to focus on their original business.

In the past few months, to continuously understand the developments 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 every day, and then filters them according to my standards. I also regularly check the push notifications.

My filtering criteria are simple: the matter must genuinely relate to Agent payments, with first-hand information such as products, documentation, interfaces, or transaction records, and it must be clear where it currently stands. If it only adds the term Agent in the title or discusses future content vaguely, I usually won’t pay much attention.

The Agentic Economy is essentially a bilateral market; one side must have agents and people willing to pay for them: who are the customers, how frequently do they use it, and what are they willing to pay for; the other side must have goods or services worth purchasing and trading by agents, and this transaction must genuinely solve a problem. Even if both sides exist, we still need to answer: how does the platform charge, can transactions be sustained, and ultimately can it form a business.

I can almost see some new startup projects and major companies’ new moves every month; the industry is indeed advancing. However, the voices of agents in the market remain noisy, making it difficult to distinguish who is just pretending and who is genuinely doing something. Where exactly have these so-called Agent strategies progressed?

I wrote this article not to evaluate who is narrating and who is doing, nor to create a blacklist or whitelist of companies. I just want to present some phenomena I have observed and the different dimensions everyone is currently achieving. More specifically, we can break down what is publicly visible into several levels.

Level One: Just Narrating

Companies that only narrate usually release a complete description of the future. 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."

This content 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 can be executed. (Perhaps the company is developing it, or it may be in a private pilot phase, but it’s just not public.)

If you are an industry practitioner or just interested in AgentPay, when you see a company saying, "one line of code can be integrated," you can first look for that line of code. If you can’t find it, just keep it at the narrative level. Just listen.

Level Two: Has a Demo

---

Some companies have already created demos; you can click a button to see the agent request a service, receive a price, confirm payment, and then get a result. Compared to just having a flowchart, reaching this step at least indicates that the team has indeed written something and connected the entire process, but what the demo can prove stops here.

Because the successful payment you see might just be an animation on the page; the balance might be simulated, and both the buyer and seller could be the company’s own accounts. The entire process only needs to run along a pre-designed route, which does not mean that external users can actually use it.

So when looking at the demo, I usually click a few more times and ask a few more questions: can the input be changed, or can it only replay the same process? Did the backend really receive the request? Did the money actually move? Can we see the transaction records? If the payment fails, the service doesn’t return, or the system executes it again, how will it be handled?

If none of this can be seen, it is still just a product prototype, indicating that the team has indeed created something, but it does not prove that the scenario has landed, nor does it indicate that someone is willing to pay for it.

Level Three: Has Reproducible Products

---

Only at the third level does it start to enter the realm of "really doing things." External developers can find SDKs, CLIs, MCPs, API documentation, code repositories, or testing environments and independently complete a call following the public steps. The product not only showcases the happy path but also explains how identity, authorization, limits, retries, cancellations, and settlements are handled.

The most important word here is "reproducible"; it’s not about company employees demonstrating success at a launch event, but rather that outsiders can achieve the same results following the public documentation. At this level, we can say the product is real, but we still cannot say the scenario is established.

The payment industry can easily change existing capabilities to an Agent entry: the original wallet adds CLI, the original API adds MCP, the original custody system adds session keys, and the original policy engine adds Agent authorization. This isn’t necessarily just a rebranding; agents indeed need machine-callable entry points and new permission boundaries. But producing the product only proves that supply exists, not that demand exists.

Level Four: Has Verifiable Payments and Deliveries

---

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

For example, Exa has integrated x402 into its search and web reading APIs, allowing agents to make requests without first registering an account or applying 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 normal search costs less than a cent, and reading a webpage is even cheaper.

Apify has integrated a batch of crawlers and automation tools into x402, allowing agents to temporarily purchase TikTok data scraping, a batch of Google Maps merchants, a set of e-commerce products, or some social media content. It does not need to open an account and buy packages for each tool separately; it can simply provide a maximum budget and settle according to actual results. However, Apify’s official documentation also clearly marks this capability as experimental, indicating that it can be used but is still in the early stages.

These two types of scenarios are relatively easy to run through because the things agents purchase are very specific: a search, a page of content, a batch of product data. It’s relatively easy to judge how much is paid, what is received, and whether delivery occurred.

An agent can automatically initiate hundreds or thousands of small calls in a very short time. In the phased data of x402scan, such situations have appeared: 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, but the buyer addresses were less than a hundred, with a total amount of just over a thousand dollars.

So while the number of transactions looks large, it may just be a small number of programs calling at high frequency, and there may also be tests, subsidies, internal accounts, and associated wallets mixed in.

At this level, who paid whom? What was purchased? Was it delivered? Are the buyer and seller different entities? Will the same buyer purchase again next time?

Level Five: Has Customers and Sustainable Income

---

Only at the fifth level does it start to resemble a business; what we are looking at is no longer "has anyone paid once," but whether external customers are continuously using it, and whether the company can receive money from it.

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

These numbers are more useful than "how many partners have been integrated" or "how many wallets are supported," because they at least simultaneously address calls, transactions, and income. However, it should be noted that this is still data published by the company itself, not third-party audited results. Moreover, it still hasn’t answered all the questions: out of that one million calls, how many came from the team’s own interfaces, and how many came from external merchants? How many different customers are there? How long have customers used it? How much of the $40,000 came from the same group of people making repeated purchases? All of this is still not visible.

In the realm of traditional financial institutions, Mastercard has publicly stated that Itaú and Santander have completed real transactions through its Agent Pay program. This certainly goes further than just "the two parties will explore together"; at least the money and purchasing process have genuinely taken place. However, if it does not disclose how many transactions were made, the amounts involved, the duration, or whether anyone returned to continue using it, then it can at most prove that it has been "tried once" but cannot demonstrate that there are stable customers.

So when reaching the fifth layer, do not just focus on one seemingly large number. It is more important to clarify the following four things:

• Who is using it?
• Why are they using it?
• Have they returned after using it?
• Who is paying, and what does the company gain?

If a company only claims to have many partners, you can continue to ask: Did these companies just issue a joint press release, or have they actually integrated their systems? Is it a small-scale test, or have they truly paid for usage? If it cites tens of millions of users, hundreds of millions of wallets, or billions of API calls from its existing business, you can also ask: How many of these actually come from the new Agent product?

Having a strong existing foundation is certainly an advantage. However, the total data from existing businesses cannot prove that a new product has found customers and a way to make money.

These five layers 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 reached: Is it talking about the future, has it produced a demo, opened the product, run real transactions, or does it already have customers continuously paying?

If you are genuinely interested in this direction, you can also use this method to continue exploring: What specific problem does it solve, what did the Agent buy, did the money actually move, who is using it, who is paying, and is there any repetition?

This way, you will neither overestimate a project based on a press release nor overlook the real scenarios and cases that have already started running just because it has not yet scaled revenue.

Having a demo only indicates that the product is beginning to take shape; having transactions indicates that payment and delivery have gone through; having customers continuously paying indicates that it is starting to approach a business.

Which scenarios are more likely to emerge first?

While observing Signal daily, I found that the progress of Agentic Payment generally occurs at three levels: How Agents pay, how people manage Agents, and what exactly Agents are buying.

The first two levels involve wallets, payment protocols, settlement, budgeting, approval, and boundaries of responsibility. The third level has already begun to show specific purchasing behaviors—from searching, data and model calls, to real physical product orders.

So after judging the product, one must return to a more fundamental question: What exactly is the Agent buying? What problem does this payment solve? Below, I would like to specifically look at which purchasing scenarios are more likely to emerge first.

I believe the first to be established is not letting Agents buy coffee, plane tickets, or hotels like humans, but rather allowing them to make temporary purchases of digital capabilities that can be consumed immediately while completing tasks.

For example:

* Searching and web reading; * Data scraping and enrichment; * Models, inference, and compute; * Merchant, product, and advertising intelligence; * Browser sessions, verification services, and RPC; * Pay-per-visit content and professional data.

These products share several common points: small amounts, fast delivery, machine-readable results, measurable costs, and relatively easy judgment of failure.

For instance, a GTM Agent may need to conduct market entry analysis for a company, which might require first performing an SEO diagnosis: checking website indexing, keyword rankings, backlinks, and page issues; then purchasing competitor website traffic, major customer acquisition channels, and keyword data to determine where the competitor's users come from.

Next, it may also need to read the competitor's landing pages and pricing pages, scrape advertising materials and placement records, organize merchant lists from Google Maps or TikTok, and then call enrichment APIs to complete company size, contacts, and emails. Finally, it combines this information to provide a target customer list, channel assessment, and next steps for outreach suggestions.

Completing such a task may require various services such as searching, crawling, SEO data, traffic analysis, advertising intelligence, and corporate information. However, these capabilities do not necessarily need to be used every day; sometimes, one only needs to temporarily check a domain, purchase a report, or scrape a few hundred data points.

If each service requires a person to first register an account, purchase a monthly plan, bind a credit card, apply for and save an API key, and then inform the Agent in advance which service it should call, its autonomous execution will constantly be hindered by human pre-configuration. Many tasks are not that the Agent cannot perform, but rather that it lacks the data and tool permissions needed to complete this step.

Agent Payment here solves not just "how to pay out money." More importantly, the Agent can discover suitable services during execution, see prices and delivery content, purchase on a per-instance basis within a limited budget, and then bring the results back into the original workflow. Humans are responsible for setting goals, budgets, and boundaries, while the Agent decides which specific tools to buy for this task and how many times to buy them.

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

The data that GTM Agents truly want to use is largely held by mature platforms like Similarweb and Semrush. They already have APIs, and Semrush now also provides an official MCP, which the Agent can technically call. However, users still need to purchase subscriptions, API units, or contact sales in advance, which is a completely different model from the Agent discovering services, seeing prices, and purchasing on a per-instance basis during task execution.

There are also some startup teams repackaging search, crawling, traffic, and corporate data into services that Agents can purchase directly. They can reduce registration, contracting, and API key configuration, but they will also encounter a practical problem: Who owns the underlying data? Is there resale rights? Do data platforms allow third parties to break their products into pay-per-call? When these intermediaries start taking customer relationships, pricing power, and profits, will the original data platforms continue to open up?

This will be a long-term game. Startups hope to combine different data sources into a market of capabilities that Agents can freely purchase; existing platforms may also create their own Agent entry points, keeping the calls within the subscription and account system. The final model that emerges is likely to be a coexistence of open protocols, self-operated Agent interfaces, and closed platforms.

Cloudflare is a case worth continuing to observe; it does not produce SEO, traffic, or business data itself but stands at the entrance of websites and services, attempting to help suppliers decide which content can be accessed for free, which should be blocked, and which can charge Agents.

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

Its value is not just in accessing x402, but in attempting to handle pricing, identity, access control, and payment at the same entry point, allowing suppliers to continue to control pricing and access rules. However, it is still very early: Pay Per Crawl is still in closed beta, and Monetization Gateway is still on the waitlist; public information cannot yet prove scaled revenue or adoption.

Therefore, this direction truly needs to solve not just payment but also data authorization, resale boundaries, service discovery, and profit distribution. Technically, it is not difficult to let Agents pay a sum of money; the challenge is why the supply side would be willing to let them buy this way.

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

Advertising is not simply about putting money into an account. It is simultaneously influenced by platform algorithms, placement strategies, material quality, optimizer experience, budget, and ROI targets. An optimizer makes numerous small decisions every day: which material is starting to fatigue, which audience should have an increased budget, which keyword's cost has risen, which channel needs to be stopped, when should the target be lowered to allow the system to explore new traffic.

This type of work has a characteristic: data changes quickly, feedback is relatively clear, and continuous judgment is required. It is difficult for a person to monitor multiple platforms 24 hours a day, but AI can continuously read impressions, clicks, conversions, CPA, and ROAS, adjusting materials, audiences, bids, and budgets based on pre-set goals.

In fact, Google, Meta, and TikTok have already used AI for real-time bidding, audience expansion, material combinations, and budget allocation within their respective platforms. Therefore, the opportunity may not just be to create another "automated pricing tool," but to allow the Agent to stand above multiple platforms, understand the company's business goals, compare the performance of different channels, 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 under what circumstances should losses be stopped; is a decline in ROAS a normal fluctuation, or is there a problem with the material, page, or audience; when should the material be changed, and when should the channel be changed; after increasing the budget, are the new conversions still cost-effective?

But this does not mean that writing the experience of optimizers into a few rules will allow the Agent to fully take over the placements. It first needs reliable conversion data and attribution, and it also needs to understand profits, inventory, payment cycles, and customer lifetime value. Otherwise, it may perform well on ROAS on the platform but fail to bring real profits to the company.

Payment here is a very natural combination because advertising decisions will ultimately turn into funding decisions. The Agent does not just suggest "increase the budget for a certain campaign"; it also needs to be allowed to mobilize how much money, spend on which platforms, what the maximum daily loss is, and under what circumstances it must stop and seek human approval.

Therefore, what this scenario needs is not to trigger a micro-payment every time a bid occurs; a more reasonable form is for humans to first give the Agent a controlled budget and set platform whitelists, daily limits, target CPA or ROAS, abnormal loss stops, and approval rules. The Agent continuously optimizes within these boundaries; once it exceeds the range, it pauses or hands it back to humans.

Advertising spending is essentially a continuous decision-making and fund allocation process. When decision-making begins to be automated, funding permissions, stop-loss mechanisms, and responsibility boundaries must also be automated.

Payments always serve the scenario. In advertising spending, the scenario itself already involves high-frequency decisions, clear budgets, and results that can provide continuous feedback. As AI gradually surpasses human capabilities in localized decision-making, it requires not just a set of analytical tools but also a payment and permission system that can safely mobilize funds.

Therefore, different scenarios require different Agent Payments. Small, high-frequency, machine-to-machine digital services need to be priced per transaction and settled instantly; advertising, procurement, and corporate expenditures require more permissions and controls.

How to determine whether an AgentPay is worth further consideration?

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

**First, look at the product**
What exactly is the Agent buying? Is it a clear API, data, model, or service, or is it just the imagination of "future machines trading autonomously"?
**Next, look at the entry points**
Are there publicly available products, documentation, SDKs, CLIs, MCPs, sandboxes, or endpoints? Can external developers call it independently?
**Then, look at the money**
Is payment actually happening? Can we see receipts, transaction hashes, or credible production records? Page animations and test coins do not count as commercial adoption.
**Next, look at the customers**
Are there external customers confirming usage from their 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 they must rely on company subsidies, promotional incentives, or internal traffic, it will be hard to turn high transaction volumes into a business.
Another very important question I believe is: what exactly does the Agent layer add? If it merely renames existing wallets or payment APIs, its value is limited. If it truly reduces friction in account registration, API key configuration, and cross-vendor settlements, or increases budget, authorization, revocation, auditing, and reconciliation, then even if it reuses an old foundation, it could be a meaningful new product.
In conclusion ---
I believe the Agent Economy will arrive, but it will not happen simply because machines have wallets.
Agents are transitioning from providing answers to invoking tools, configuring resources, and completing tasks. When software begins to act on behalf of humans, pricing, authorization, payment, and reconciliation will no longer be peripheral functions but will become part of its operational capabilities.
The true threshold of Agent Payment has never been about enabling machines to make a single payment, but rather about allowing them to continuously make worthwhile payment decisions within limited budgets, clear objectives, and accountable boundaries.
This competition will ultimately not just be about which chain is faster or which protocol is more open. The deeper question is: who defines what machines can buy, who grants them budgets, who judges whether transactions are completed, and when machines make mistakes, who can stop them and bear responsibility?
Wallets are just entry points; scenarios determine whether there is demand, control determines whether they can enter enterprises, and repeat purchases determine whether it ultimately becomes a business.
Therefore, I prefer to view today's Agent Payment as a rewriting of power boundaries.
When Agents no longer just answer questions but begin to mobilize external resources, payments will become part of their operational capabilities. But only when the value created by this action exceeds the costs incurred will the Agent Economy truly transition from narrative to reality.