Author: Stablehunter

Last week, I attended the Web3 Festival in Hong Kong, and one very obvious feeling I got was that almost every forum and every panel now revolves around AI.

Regardless of whether the original discussion focused on payments, stablecoins, RWA, wallets, exchanges, or compliance and infrastructure, it almost always comes back to the same question: When AI is no longer just generating content, but begins to perform tasks, call services, make decisions, and even handle cash flows for humans, will the existing financial and payment systems be sufficient?

In a panel I attended, someone directly asked: Is Web3 just riding on the coattails of AI? I don't think so. Of course, there will be projects jumping on the bandwagon. But if we only understand AI × Web3 as a narrative collage, we might miss a more fundamental change: AI is responsible for understanding, decision-making, and action, while Web3 provides assets, accounts, settlement, and a verifiable execution environment. It's not simply a matter of stacking concepts; it's a redefinition of roles.

In his speech at the Web3 Festival 2026, Hong Kong Financial Secretary Paul Chan Mo-po also mentioned that AI agents will analyze information and take action at machine speed, while fully utilizing blockchain infrastructure in the background to improve transaction efficiency and reshape scenarios such as finance, trade, wealth management, supply chain, and logistics. When AI begins to act, the issue is not just "intelligence" itself, but how these actions are authorized, settled, recorded, and accountable.

Among these topics, Agentic Payment is becoming increasingly difficult to ignore. But I initially had a very simple question: why do people assume that Agentic Payment or Agentic Commerce is necessarily tied to Crypto, Stablecoin, and Blockchain when they talk about it?

Can't the AI ​​Agent accept bank cards? Can't it accept credit cards? Can't it accept Apple Pay, Visa, Mastercard, Stripe, or PayPal?

If the agent simply helps me buy a plane ticket, book a hotel, or renew a SaaS subscription, theoretically it can fully utilize the existing payment system. The user authorizes once, and the agent executes the payment within the limit and rules, using a bank card, virtual card, corporate account, or third-party payment wallet in the background—this doesn't sound unreasonable.

So the question isn't "Can bank cards be used?" Of course they can. The real question is: Which part of Agentic Payment is bank card and credit card suitable for, and which part is not? Will AI Agents actually use bank cards? And why, as Agentic Payment develops, it almost inevitably involves stablecoins and blockchain.

First, bank cards handle checkouts, not the agent economy.

If Agentic Payment simply involves an AI agent completing the final payment step—such as buying a plane ticket, booking a hotel, or renewing a SaaS subscription—there are no fundamental obstacles to using bank cards, credit cards, virtual cards, Apple Pay, Stripe, or PayPal in the background. Bank cards can certainly be used, and credit cards can certainly be used as well.

The user grants prior authorization, and the agent executes the payment within the specified limit and rules. This isn't hard to understand; it's essentially similar to a smarter automatic deduction, corporate virtual card, travel card, or automated procurement system.

Therefore, traditional payment players like Visa, Mastercard, and Stripe will not disappear. They may even become important entry points for early agentic commerce.

The Machine Payments Protocol launched by Stripe and Tempo exemplifies this point. It doesn't rely solely on stablecoins; instead, it allows merchants to directly accept payments from agents, supporting both stablecoins and other fiat payment methods like cards and BNPL. In other words, in the early stages of agent payments, traditional payments and stablecoins are more likely to coexist rather than one immediately replacing the other. However, this only solves one aspect of agentic commerce: checkout.

Checkout assumes that the product, merchant, order, payment button, refund, and dispute resolution processes already exist. The agent simply stands beside the user, helping them complete the purchase more automatically.

The real problem arises in another scenario: the agent no longer simply enters a pre-built shopping cart, but rather continuously calls upon resources, combines services, and completes tasks within an open network. For example, an AI research agent, to complete an industry report, might need to access multiple databases, purchase several paid documents, access different model APIs, call a web crawler service, pay for chart generation tools, and even purchase an analysis result from another agent. There might not be a traditional "store" involved, nor a single complete checkout page. Instead, it might be dealing with APIs, data interfaces, model services, computing nodes, content resources, automation tools, and even another agent.

I recently encountered a specific example myself. I wanted to create a traffic analysis assistant that could automatically call data sources like Semrush when needed to analyze a website's traffic, keywords, competitors, and market trends. However, when I actually started developing the solution, I realized the problem wasn't "can AI analyze?" but rather "how does it obtain the data?" Many commercial data sources aren't designed for a "one-time call, one-time payment, instant return" model. Take Semrush, for example; its API system is closer to an account, package, and API units model. Each API request consumes a certain number of API units, and users need corresponding API access or to purchase an API unit package. While Trends API allows for individual access purchases, it still relies on API units to request data.

However, this model isn't natural for agents. If an agent only needs to access traffic data occasionally, what it really needs isn't registering a SaaS account or buying a whole package of API units, but rather making a request like accessing a webpage: How much does this data cost? Am I authorized to purchase it? If it's within budget, pay, and get the results immediately.

This is the disconnect between Agentic Payments and the traditional API business model. Today, many APIs are still priced according to the model of "human companies buying software," rather than "machines buying resources on demand."

Therefore, the problem with Agentic Payment is not whether the final step can deduct the payment, but how the machine continuously obtains authorization, initiates payment, verifies delivery, and completes settlement throughout the entire task chain.

This is the boundary of the bank card system.

It's not because bank cards are outdated, but because they originally served human consumption scenarios: a person enters a merchant environment, selects goods, confirms the order, completes the payment, and then the bank, card organization, acquiring institution, and payment service provider complete the authorization, clearing, risk control, and dispute resolution.

But the Agent Economy faces another set of questions: What gives this agent the right to spend this money? How can the service provider confirm that this is not a malicious bot, but an extension of the user's true intentions? Can the agent complete small-amount, high-frequency, cross-platform payments without human verification at each step? After receiving the payment, can the service provider immediately release the corresponding resources? If the agent makes a mistake, exceeds its authority, or is attacked, who should bear the responsibility?

This is why, when developing AP2, Google didn't focus on "which payment method to use," but rather on a more universal agent payment trust framework. In Google's official description, AP2 is defined as a payment-agnostic framework that allows users, merchants, and payment service providers to confidently complete agent-led payments across different payment methods. The AP2 specification also explicitly states that agents need a secure and simple way to obtain scoped permissions to perform actions on behalf of users; the security of the protocol relies on cryptographic signing of relevant information by users and merchants.

Therefore, the first question about Agentic Payment is not: Where does the money come from? Rather: What gives the agent the right to spend this money?

The banking card system can solve part of this problem. For example, virtual cards, tokenized credentials, credit limit management, corporate expense control, and risk control rules can all enable agents to complete transactions within the existing merchant system.

Visa is also moving in this direction. Its Intelligent Commerce and Trusted Agent Protocol essentially enable AI agents to be identified, trusted, and allowed to complete transactions on behalf of consumers or businesses within existing merchant networks. Visa Developer's description of the Trusted Agent Protocol is also straightforward: AI agents help users browse merchant websites, discover products, compare prices, and make choices, and the business journey begins long before checkout; in the past, these automated accesses were often blocked as bots by merchants, CDNs, or bot mitigation services.

This illustrates that traditional payment networks also recognize the same issue: Agentic Commerce doesn't just occur at the moment of clicking the payment button, but rather throughout the entire process from searching, comparing, selecting, authorizing, to final payment. However, card networks excel at solving how agents can integrate into existing commerce flows and complete an authorized transaction. What they don't naturally address is how agents can continuously initiate small payments for APIs, data, models, computing power, content, tools, and other agents within an open network.

Therefore, bank cards are not a bad solution. More precisely, bank cards solve the checkout problem for agent commerce, but agent commerce requires a more fundamental payment protocol.

This raises the question to the next level: if the transaction partner is not a traditional merchant, but an API, a model, a data interface, or even another agent, how should a payment be initiated and completed between machines? This is also why protocols such as x402, L402, and T402 have begun to be discussed.

Second, what the agent truly needs is a machine-readable payment protocol.

If the transaction is with a traditional merchant, the agent can certainly access the existing checkout flow and complete the payment using a credit card, debit card, virtual card, or wallet. However, if the transaction is not with a merchant, but with an API, a model, a data interface, a content resource, or even another agent, the situation changes.

At this point, what the machines need isn't a "payment button," but a payment process that the machines can understand: An agent requests a resource. The service provider tells it: this resource requires payment, the price, the receiving address, and the supported payment methods. The agent determines if the payment is within the user's authorized scope. If it does, the payment is completed. After verifying the payment, the service provider immediately releases the resource.

This process sounds simple, but it actually fills a gap in the capabilities that the internet has long lacked: a native payment layer. In the past, the internet naturally supported the flow of information. Web pages could be requested, emails could be sent, APIs could be invoked, and files could be downloaded. But "payment" was usually not part of the internet protocols themselves; instead, it was often externalized into another system: registering an account, linking a bank card, connecting to a payment gateway, purchasing a service plan, managing API keys, and reconciling accounts at the end of the month.

This is tolerable for humans. Humans can register, log in, link cards, approve applications, make purchases, and claim reimbursements. But for agents, this process is too cumbersome.

Agents shouldn't register an account for every API call, shouldn't buy an entire data plan for every data access, and shouldn't go through a complete human payment and purchase process for small calls costing a few cents or dimes. This is why protocols like x402 exist.

The x402 protocol reactivates the long-standing but rarely used HTTP 402 Payment Required status code. It allows services to directly tell clients at the HTTP layer: you need to pay before accessing this resource. The client can be a human or a machine. After payment, the service verifies the payment and then returns the corresponding API, content, or digital service. Coinbase defines x402 simply: it's an open protocol for instant, automatic stablecoin payments over HTTP, allowing human and machine clients to programmatically pay and gain access without requiring accounts, sessions, or complex authentication.

The real issue here isn't whether to use Coinbase or not, nor is it whether USDC must be used. What truly matters is that x402 embeds payments back into the internet's request-response flow. Previously:

First, register an account.

Buy another package.

Get the API key again.

Then call the service again.

We'll reconcile the accounts at the end of the month.

x402 wants to become:

Requesting resources.

Received 402 Payment Required.

Payment completed.

Obtain resources.

This is crucial for Agentic Payments because Agent transactions are not a few large purchases, but rather a large number of small, real-time, on-demand service calls.

A writing agent may purchase a data query once for an article.

An investment research agent may call an on-chain analytics service once for a given question.

A travel agent may request quotes from multiple pricing APIs simultaneously.

A development agent may purchase model inference, code review, or testing environments on a per-use basis.

A traffic analytics agent might only want to buy Semrush-type data once for a specific website, rather than purchasing a complete SaaS package first.

If every service requires an account, subscription, API key, plan, and manual approval, the agent's execution capabilities will be hampered by the payment and procurement processes. Therefore, the significance of x402 is not to make payments "more crypto", but to make payments more like internet protocols: requestable, returnable, verifiable, and automated.

L402 is another similar route.

It also revolves around HTTP 402, but incorporates access credentials and micropayments such as the Bitcoin Lightning Network and macaroons. Lightning Labs defines L402 as: it facilitates the authentication and trading of services such as API endpoints and computing resources, and allows services to charge API endpoints, making it easier for AI agents to participate.

The L402 error indicates that this problem didn't just suddenly appear with x402. People had been trying to combine these three things long before: HTTP access control, micropayments, and digital service permissions. It's just that in the past, there wasn't a sufficiently strong demand from the other side.

Human users won't pay a penny to access an API endpoint. But agents will. Humans won't automatically call hundreds of data sources in a day. But agents will. Humans won't combine calls, quotes, payments, and delivery verifications across different services in real time to complete a task. But agents will.

Therefore, the emergence of AI Agents has suddenly made the HTTP-native payment route meaningful.

Similar trends are emerging around the USDT/Tether ecosystem. The Tether WDK x402 documentation explicitly states that x402 is crucial for AI agents because they need to programmatically pay for resources. x402 makes payments first-class citizens on the web stack, allowing agents to discover prices, sign payments, and acquire resources within a single request-response cycle. The t402 project also describes itself as an open standard for internet-native payments, aiming to support multiple value forms such as crypto, fiat, stablecoins, and tokens, and to be compatible with Tether WDK. A word of caution is needed here: I don't recommend directly stating that it "has become an official Tether standard." A more accurate description is that similar protocol explorations to x402 are emerging within the USDT/Tether ecosystem.

Behind this is a noteworthy trend: Agentic Payment is not about competition between individual companies' products, but rather the formation of a new protocol stack.

AP2 seems to be answering the question: On what grounds should the Agent be authorized to make payments?

Protocols like x402, L402, and T402 are more like answering the question: when an agent requests a digital resource, how does the service provider initiate a payment request, and how does the agent complete the payment and obtain the resource?

Stablecoins and blockchain are more like answering the questions: What asset will this money ultimately be settled with, where will it be verified, and how can it be low-cost, real-time, programmable, and cross-platform?

Therefore, the reason Agentic Payment and Crypto are being discussed together is not because Web3 is trying to piggyback on AI. More accurately, it's because Agentic Payment has brought back to the forefront the "native nature of payments" issues that the internet hasn't been able to resolve in the past.

Information can flow naturally on the internet. But value cannot in the long run. The emergence of agents is forcing the internet to fill this gap.

This is why protocols like x402, L402, and T402 are worth paying attention to. They don't simply mean "letting AI pay with cryptocurrency," but rather they're attempting to define a new way of interacting:

The machine requests resources, the machine understands the price, the machine verifies authorization, the machine completes the payment, and the machine receives the service. If a bank card solves the checkout process, then these protocols solve:

How do machines initiate a payment? Once this question is addressed, stablecoins and blockchain are no longer just payment tools, but become the underlying settlement language and execution environment for Agentic Payments.

III. Why Stablecoins? Agents need stable units of account, not volatile assets.

If agents truly need a machine-readable, automatically executed payment protocol, then why is stablecoin the most discussed topic? Why not BTC? Why not ETH? Why not a regular bank card?

The key here isn't the "crypto asset" itself, but rather what kind of payment asset the agent actually needs. If an agent is simply holding the asset long-term, it might be concerned with price fluctuations, returns, and risk exposure. However, if an agent is being paid to complete a task, its primary need isn't a speculative asset, but rather a stable unit of account.

A research agent might spend $0.10 on a single data API call. A coding agent might spend $0.03 on a single model inference call. A marketing agent might spend $1 on a single traffic data purchase. A procurement agent, which automatically compares prices, places orders, and makes payments, might need to control every expenditure within a budget.

In these scenarios, the agent isn't conducting transactions or trading cryptocurrencies. It's completing a task. Therefore, it needs to know: How much does this resource cost? Will this call exceed the budget? Is this payment within the user's authorized scope? After service delivery, can the costs be accurately recorded?

If the payment asset itself fluctuates wildly every day, the agent's budget management becomes very strange. Today an API call costs $0.10, but tomorrow it might cost $0.12 or $0.08 due to price fluctuations. This might not matter much in the trading market, but it adds a lot of unnecessary complexity to a machine's on-demand resource purchasing.

This is why stablecoins, rather than highly volatile crypto assets, are more naturally found in Agentic Payments.

The primary value of stablecoins lies in providing a unit of account that more closely resembles the real world of commerce. Today, a large number of APIs, SaaS, data services, modeling services, and cloud services are priced in US dollars. If an agent wants to purchase these services on demand, using a US dollar stablecoin as a payment asset allows them to directly place budgets, prices, authorizations, and invoices in the same unit.

This may sound mundane, but it's crucial for the Agent. Because the Agent doesn't just "pay"; it also makes judgments. It needs to determine if the call is worthwhile. It needs to assess whether the budget is sufficient. It needs to decide whether user confirmation is required. It needs to record the task cost. And it needs to explain why the money was spent in case of errors.

Therefore, agentic payments require a low-volatility, machine-readable payment asset that can be directly invoked by programs. Stablecoins are closer to this requirement than volatile assets like BTC and ETH.

The second layer of value is that stablecoins are better suited for small-amount, high-frequency, and instant settlements. This trend was already evident when discussing x402 earlier. Coinbase defines x402 as enabling instant, automated stablecoin payments via HTTP, allowing APIs, digital content, and services to receive payments from both human and machine clients without requiring accounts, sessions, or complex authentication. Behind this statement lies a crucial change: payments no longer necessarily have to occur within a complete checkout page, but can occur within a single API request.

The agent requests a resource. The service provider returns a 402 Payment Required response. The agent determines the price and authorization. The agent pays in stablecoins. The service provider releases the resource after verification.

This process is naturally suited for scenarios involving small amounts, high frequency, and on-demand calls. Examples include a data query, a model call, content unlocking, on-chain analysis, and chart generation. Tether WDK's x402 documentation also clearly states this: AI agents need to pay for resources programmatically, and x402 allows agents to discover prices, sign payments, and acquire resources within a single request-response cycle.

This is not in the same usage context as bank cards. Bank cards are more suitable for merchant checkouts in human consumption. Stablecoins are more suitable as instant settlement assets when machines access resources. Of course, this does not mean that bank cards will disappear. Stripe and Tempo's Machine Payments Protocol explicitly support two paths: one is direct on-chain crypto payments, and the other is fiat payments such as cards and wallets. Stripe also mentions that merchants can accept payments from agents through MPP, using both stablecoins and fiat payment methods such as cards and BNPL.

Therefore, a more accurate assessment is not "stablecoins are replacing bank cards," but rather: bank cards are suitable for existing merchant networks and checkout scenarios. Stablecoins are more suitable for machine-to-pay scenarios in open networks.

The third layer of value lies in the inherent suitability of stablecoins for cross-platform and cross-border transactions. Agents don't necessarily operate on a single platform. One agent might utilize US data APIs, European model services, Asian content interfaces, and on-chain analytics tools to transact with another agent. If each layer relies on different countries' bank accounts, acquiring institutions, local payment methods, and settlement cycles, the entire task chain will be fragmented by the payment system. However, stablecoins are native internet assets. They can circulate 24/7, can be accessed across platforms, wallets, and applications, and can be directly processed by smart contracts or payment protocols. For human users, this might simply mean "faster settlement." But for agents, the significance is far greater, because agent execution doesn't occur according to bank operating hours.

It shouldn't be interrupted by weekends, cross-border transactions, bank clearing windows, or merchant account systems. What it needs is a settlement asset that is readily available, automatically invoked, and verifiable.

This is why x402, Tether WDK's support for x402, and the exploration of t402 surrounding the USDT/Tether ecosystem are all moving in the same direction: turning stablecoin payments into web stack components that machines can directly call, rather than having the agent first enter a human-designed payment page.

However, it's necessary to pour some cold water on this. Stablecoins are not without their problems.

Different stablecoins vary in terms of reserve transparency, issuing entities, regulatory status, redemption capabilities, and on-chain liquidity. The BIS also explicitly criticized stablecoins in its 2025 Annual Economic Report, arguing that they are deficient in key monetary system standards such as singleness, elasticity, and integrity, and should not be simply regarded as a complete substitute for the modern monetary system.

A more accurate statement would be: stablecoins are not perfect currencies, but they are one of the internet-native settlement assets that are currently closest to meeting the needs of agentic payments.

Its value lies not in the "decentralized narrative," but in the fact that it simultaneously meets several conditions: relatively stable price; programmable functionality; cross-platform transfer capability; 24/7 settlement capability; and integration with HTTP-native payments, wallets, smart contracts, and on-chain auditing.

This is why stablecoins naturally come to mind when discussing resource usage on open networks in Agentic Payments. Because what agents need isn't a "hand that can swipe cards," but rather a form of money that can be directly understood and used by the software.

If credit cards are payment credentials designed for human consumption, then stablecoins are more like a settlement language prepared for the machine economy.

Of course, this language is still immature. It needs a better compliance framework, a more stable issuance mechanism, clearer risk control, and more comprehensive wallet permission management. It also needs to be integrated with protocols such as AP2, x402, and MPP in order to truly enter the large-scale use of Agentic Payment scenarios.

But the direction is clear: Agents need stable price units, instant settlement assets, money that can be called by programs, and cross-platform, cross-border, and cross-service payment capabilities.

This is why stablecoins are indispensable in agentic payments. It's not because all payments need to become crypto payments. Rather, it's because, for the first time, stablecoins make "money" feel more like part of the internet protocol when the transaction object changes from "human consumers" to "software entities."

Stablecoins only answer one question: what money does the agent use to make payments? They don't answer another: once the agent spends money on the open network, who authorized that spending, where was it spent, was there any overstepping of authority, and was the service delivered? This question leads us to blockchain.

IV. Why is blockchain needed? Not just for putting things on the chain, but to make the agent's behavior verifiable.

Even if the agent needs stablecoin payments, why does it have to be blockchain? Can't it be a centralized ledger? Can't it be Stripe, Visa, a bank, or some platform keeping its own ledger?

Of course. If the agent only operates within a closed platform, such as only shopping on Amazon, only calling services within a specific SaaS platform, or only making purchases within an internal enterprise system, then a centralized ledger is perfectly adequate. The platform itself knows who the user is, who the agent is, what their permissions are, how much money was spent, and whether the service was delivered.

But the truly interesting aspect of Agentic Payment isn't just that the agent clicks the payment button for you within a closed platform. It's that it can potentially cross platforms, services, wallets, countries, and even different agents to complete a task. At this stage, the question isn't just "can the money be paid out?", but rather why the money is being paid out, who authorized it, whether the agent overstepped their authority, whether the service provider delivered the payment, and where the responsibility lies if errors occur.

These are the key questions that truly highlight the value of blockchain in Agentic Payments. It's not because all transactions must be recorded on the blockchain, nor because on-chain transactions are inherently more advanced than bank transactions, but because every economic action an agent takes when performing tasks, calling services, and processing funds requires a verifiable record.

Humans can tolerate a lot of opacity when making payments. If you buy a service and don't receive it, you can contact customer service; if there's a problem with company procurement, you can check the contract, talk to finance, check emails, and hold meetings to argue; if your bank card is charged incorrectly, you can go to the bank to handle the dispute. These mechanisms are clumsy, but that's how human society has operated for a long time.

Agents are different. Agents may have higher transaction frequency, smaller transaction amounts, more service providers, and longer execution chains. If every transaction requires manual post-transaction verification, screenshotting, email comparison, and contacting customer service, then Agentic Payment loses its meaning. Therefore, what agents need is not a cooler wallet, but a clearer chain of responsibility.

For example, a user gives an agent a task: spend a maximum of $100 this week to do a market analysis for me, only purchasing data, model calls, and chart generation services. The agent then requests a data API, and the service provider returns $0.20 for this query. The agent determines this amount is within budget, completes the payment, and the service provider releases the data after receiving the money. In this process, what's truly important isn't "which blockchain was used," but rather whether we can answer several questions afterward: What authorizations did the user grant? What did the agent purchase? Did the amount exceed the budget? Did the service provider actually return the data? If it's later discovered that the agent was misled by prompt injection into purchasing inappropriate items, can we trace the source of this information?

This is why I think revisiting the Bitcoin white paper when discussing Agentic Payments isn't really about nostalgia. The core problem Satoshi Nakamoto was trying to solve wasn't "inventing a tradable asset," but rather how to ensure that a transfer of electronic cash could be verified, ordered, and recorded by the network without a trusted third party. The white paper clearly states that the network hashes transactions into a continuously growing proof-of-work chain, creating a record that cannot be altered without redoing the work.

Agentic payments face slightly different issues. It's not just about double-spending, but also about agent authorization, overreach, delivery, and liability. However, they share a common thread: once economic activity occurs within an open network, verifiable transaction records are no longer secondary, but integral to the infrastructure itself.

This is the significance of blockchain. It doesn't make payments mysterious; rather, it transforms some states that were previously hidden in the platform's database into states that can be externally verified. At least ideally, payment records, authorization credentials, service access, refund conditions, and budget expenditures can all be recorded and verified in a more standardized way. For human users, this might simply mean "clearer accounts"; but for agents, it could be the foundation of their trustworthiness.

Because an agent is not a person. It cannot explain its behavior based on "I remember thinking this way at the time." It needs a set of externally verifiable chains of evidence.

This is why AP2, x402, stablecoins, and blockchain are often discussed together in the same diagram, but they are not the same thing. AP2 itself is neither a decentralized protocol nor a blockchain protocol. Google positions AP2 as a payment-agnostic open framework that allows users, merchants, and payment service providers to confidently complete agent-led payments across different payment methods; the AP2 specification also defines it as an open protocol that enables AI agents to securely and autonomously complete payments on behalf of users.

Therefore, more accurately, AP2 is more like the authorization and trust layer of Agentic Payment, responsible for expressing user intent, the scope of authorization, and the boundaries of responsibility. x402, L402, and T402 are more like the payment request layer, resolving how the service provider initiates a payment request when an agent requests a resource. Stablecoins are settlement assets, resolving what stable unit the agent uses for payment. Blockchain, on the other hand, is the verifiable state layer, resolving whether transaction records, settlement status, and subsequent execution can be externally verified.

These layers are not the same thing, but together they resemble a true agentic payment infrastructure. Otherwise, it becomes an awkward situation: the agent is intelligent, helping you find services, compare prices, and make decisions, but when it comes to payment, it reverts to the human world's process: registering an account, linking a card, buying a plan, checking bills, contacting customer service, and processing reimbursement. Then it's not agentic payment; it's just a browser assistant that's better at clicking buttons.

Of course, we shouldn't be overly optimistic. Integrating agents into on-chain payments isn't without risk; in fact, the risks can be more direct. In traditional payments, many transactions can be disputed, frozen, or withdrawn. Once an on-chain transaction is sent, it's often much harder to recover. If the agent is attacked, if the user's authorization scope is too broad, if the service provider takes the money and doesn't deliver, if a malicious website induces the agent to make payments, or if an agent spends its entire budget in one night—these are all serious problems.

Therefore, Agentic Payment isn't simply about giving an agent a wallet and saying, "Go ahead and spend your money." That's too risky. What's truly needed is a comprehensive control mechanism: limits, whitelists, blacklists, authorization scope, risk levels, human verification, a pause/on switch, and audit logs. Small, low-risk transactions that are natively machine-generated can be automated; large, high-risk transactions involving real-world fulfillment should still require human verification.

Therefore, I prefer to understand the role of blockchain in agentic payments as follows: it's not used to prove that Web3 is superior to traditional finance, but rather to provide a verifiable foundation for the economic behavior of agents. Agentic payments need blockchain, not because all payments should be on-chain, but because when AI agents start spending money on open networks, we need a way to prove that the money they spend is authorized, what they buy is recordable, their behavior is traceable, and the problems they cause are accountable.

This is the true place of blockchain in this problem. It's not about faith, narrative, or a brute-force "AI + Web3" approach; it's about how, as machines begin to participate in economic activities, the existing account systems and platform databases may no longer be sufficient. We need a more open, standardized layer of economic state that is easier for machines to read and verify, and blockchain, at least, provides a direction in that direction.

Fifth, it's not a replacement for bank cards, but rather the beginning of a tiered payment system.

Therefore, in the end, I don't believe that Agentic Payment will simply lead to one conclusion: stablecoins will replace bank cards, and blockchain will replace traditional payment networks.

This judgment is too simplistic and too easily contradicted by reality. At least for a long time, systems like bank cards, credit cards, Apple Pay, Visa, Mastercard, Stripe, and PayPal will still exist and continue to serve as payment gateways in numerous real-world consumption scenarios. The scenarios of people buying things on e-commerce websites, booking hotels and airline tickets, making offline purchases, and corporate procurement will not suddenly disappear simply because agents have emerged.

Even in the early days of Agentic Commerce, agents may have first connected to these existing payment systems.

Because the existing merchant network is already mature, consumers already have cards and wallets, merchants have already implemented payment processing, and banks and card organizations have mature risk control, dispute resolution, refund, compliance, and identity systems, directly using the existing Rails platform is the most realistic approach for scenarios like "AI helps me complete a purchase."

So the question isn't "whether the card will disappear".

The question is, will Agentic Payments remain at this level? If the agent simply clicks "checkout" for someone, it can certainly continue to use a bank card. But if the agent starts entering a more open network of tasks, calling APIs, purchasing data, payment model services, settling computing power, unlocking content, and transacting with another agent, then what it needs isn't just a smarter payment button, but a completely new payment protocol stack.

This is why I think that what we are more likely to see in the future is not "bank cards vs. stablecoins", but rather a stratification of payment systems.

In human consumption and established merchant networks, bank cards, credit cards, wallets, and bank accounts will remain the mainstream. Traditional payment methods like Rails will continue to play a role in scenarios where agents help people complete shopping, ticket bookings, hotel reservations, and SaaS renewals. Agents simply integrate into existing commerce flows to help users complete transactions more automatically.

However, stablecoins and blockchains are more likely to emerge in more machine-native scenarios such as APIs, data, models, computing power, content, on-chain services, and agent-to-agent transactions. This is because the payment recipients here are not traditional merchants, but digital resources; the transaction amounts may be small, but the frequency may be high; the service providers may come from different platforms, countries, and systems; and the entire process should ideally be automatically understood, paid, and verified by machines.

In short, bank cards solved the payment problem in the era of human consumption, while stablecoins and blockchain are more like solving the problems of settlement language and verifiable execution environment in the era of machine economy.

Of course, this doesn't mean stablecoins and blockchain are ready. The on-chain experience remains complex, wallet management is still not user-friendly, stablecoin regulations are still evolving, and liquidity across different chains is fragmented. More importantly, allowing agents to directly control funds is inherently risky. Without access control, limit management, risk management mechanisms, manual review, and auditing systems, agentic payments can easily go from "automated" to "automatically causing trouble."

Therefore, the true implementation of Agentic Payment will not mean that agents will be able to spend money recklessly with their wallets.

It's more likely to be a gradual evolution: first, it will enter existing payment systems to help users complete more automated checkouts; then, it will gain more granular authorization capabilities, such as budgets, whitelists, scope of use, time limits, and risk levels; then, APIs, data, models, and content services will begin to support machine-readable payment requests, allowing agents to purchase resources on demand; and finally, stablecoins will become settlement assets in some machine-native scenarios, especially for small-amount, high-frequency, cross-platform, and cross-border digital service calls.

From this perspective, Agentic Payment is not something that a single company, blockchain, stablecoin, or protocol can accomplish on its own. It's more like the entire payment system being forced to dismantle and reorganize in the face of a new entity: the AI ​​Agent.

In the past, payment systems primarily served individuals and companies. In the future, payment systems may also serve a new type of entity: authorized software agents.

It is neither a legal person nor a traditional corporate account, but it initiates requests, compares prices, calls services, consumes resources, triggers payments, and leaves records. As such entities begin to emerge in large numbers, payment systems must answer new questions: Who is it, who does it represent, what is it allowed to do, how much money can it spend, what did it buy, has it overstepped its authority, and who is responsible if problems arise?

These problems cannot be solved by a simple payment button.

So let's go back to the question at the beginning of the article: Will the AI ​​Agent use a bank card?

meeting.

But it won't only use bank cards.

Bank cards will continue to handle checkouts, stablecoins will begin to handle machine-native small-amount instant settlements, blockchains will provide some verifiable state and execution environment, and protocols such as AP2, x402, L402, and T402 will attempt to connect authorization, payment requests, and resource access.

This is what makes Agentic Payment so noteworthy. It's not just about adding another payment function to AI. It's about forcing us to rethink: what kind of payment system does the internet really need when machines start participating in economic activities?