Why can't Agentic Payments avoid stablecoins and blockchain?

Author: Yuki (Liu Yuqing) Stablehunter/Money in Motion

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

Regardless of whether the original discussion was about payments, stablecoins, RWA, wallets, exchanges, or compliance and infrastructure, it almost always came back to the same question: When AI is no longer just generating content, but starts to perform tasks, call services, make decisions, and even handle cash flows, are the existing financial and payment systems still sufficient?

In one of the panels I attended, someone directly raised the question: Is Web3 just riding the AI ​​wave? I don't think so. Of course, there will definitely be projects that ride the wave. But if we only understand AI × Web3 as a narrative collage, we may 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.

The two are not simply overlapping concepts, but rather a redefinition of roles. Hong Kong Financial Secretary Paul Chan Mo-po also mentioned in his speech at Web3 Festival 2026 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, Agentic Payment is an increasingly difficult topic to ignore. But I initially had a very simple question: why does everyone assume that Agentic Payment or Agentic Commerce is necessarily tied to Crypto, Stablecoin, and Blockchain? Can't AI Agents use bank cards? Can't they use credit cards? Can't they use 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, the agent executes the payment within the limit and rules, and the payment is processed through a bank card, virtual card, corporate account, or third-party payment wallet—this doesn't sound unreasonable. Therefore, the question isn't "Can bank cards be used?" Of course they can. The real question is: which part of Agentic Payment is suitable for bank cards and credit cards, and which part is unsuitable? Will AI Agents actually use bank cards? And why, as Agentic Payment develops, it almost inevitably involves stablecoins and blockchain.

I. Bank cards solve checkout, not Agent Economy

If Agentic Payment simply allows an AI Agent to complete the final payment step for people, 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 behind the scenes. Bank cards can certainly be used, and credit cards can certainly be used.

Users authorize in advance, and the Agent executes the payment within the limit and rules. This is not difficult to understand; essentially, it's similar to a smarter automatic deduction, corporate virtual cards, travel cards, or automated procurement systems.

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 illustrates this point well.

It doesn't just stake stablecoins; instead, it allows merchants to directly accept payments from agents, supporting both stablecoins and 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 part 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 automate the purchase process. The real problem arises in another scenario: the agent no longer simply enters a pre-built shopping cart but continuously calls resources, combines services, and completes tasks within an open network. For example, to complete an industry report, an AI research agent might need to access multiple databases, purchase several paid resources, 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 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 concrete 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 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 "one-time call, one-time payment, instant return." For example, Semrush's API system is closer to an account, package, and API unit model. Each API request consumes a certain number of API units, requiring users to have corresponding API access or 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 is less natural for agents. If an agent only occasionally needs to access traffic data, what it truly needs isn't registering a SaaS account or purchasing a full package of API units, but rather initiating 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 result immediately. This is the disconnect between Agentic Payment and the traditional API business model. Many API pricing methods today are still designed for "human companies purchasing software," not for "machines purchasing resources on demand." Therefore, the problem with Agentic Payment isn't whether the final step can deduct payment, but rather how the machine continuously obtains authorization, initiates payments, verifies delivery, and completes settlement throughout the entire task chain. This is where the boundaries of the bank card system truly lie. 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 an order, completes payment, and then the bank, card organization, acquiring institution, and payment service provider handle authorization, clearing, risk control, and dispute resolution. However, the Agent Economy faces a different set of problems: What gives this agent the right to spend this money? How can the service provider confirm that this isn't a malicious bot, but rather 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 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 Google developed AP2, it didn't focus on "which payment method to use," but rather on a more universal agent payment trust framework. In Google's official introduction, 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 Payments is not: Where does the money come from? Rather: What gives the agent the right to spend this money? The banking card system can address part of this issue. For example, virtual cards, tokenized credentials, credit limit management, corporate expense control, and risk control rules all allow agents to complete transactions within existing merchant systems. Visa is also moving in this direction. Its Intelligent Commerce and Trusted Agent Protocol essentially enable AI agents to be identified, trusted, and permitted to complete transactions on behalf of consumers or businesses within existing merchant networks. Visa Developer's description of the Trusted Agent Protocol is straightforward: AI agents help users browse merchant websites, discover products, compare prices, and make choices, with the commercial journey beginning 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 problem: Agentic Commerce doesn't just happen at the moment of clicking the payment button, but rather throughout the entire chain from search, comparison, selection, authorization, to final payment. However, card networks excel at solving how agents can enter the existing commerce flow 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 another agent within an open network. So, bank cards aren't necessarily a bad thing. More precisely: bank cards solve the checkout problem in Agentic Commerce, but Agent Economy requires a more fundamental payment protocol. This pushes the issue to the next level: if the transaction partner isn't a traditional merchant, but an API, a model, a data interface, or even another agent, how should machines initiate and complete a payment? This is why protocols like x402, L402, and T402 have begun to be discussed. II. What Agents Really Need is a Machine-Readable Payment Protocol If the transaction partner is a traditional merchant, the agent can certainly enter the existing checkout flow and complete the payment using a credit card, debit card, virtual card, or wallet. But if the transaction partner isn't a merchant, but an API, a model, a data interface, a content resource, or even another agent, the problem changes. At this point, what machines need isn't a "payment button," but a payment process that 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 meets the rules, 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 internet's capabilities: 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 called, and files could be downloaded. But "payment" was usually not part of the internet protocol itself, but rather externalized to another system: registering an account, binding a bank card, connecting to a payment gateway, purchasing a package, managing API keys, and reconciling accounts at the end of the month. This was tolerable for humans. People could register, log in, bind cards, approve, purchase, 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 package 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. x402 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 first to access 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's definition of x402 is straightforward: it's an open protocol for instant, automatic stablecoin payments via 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 is absolutely necessary. What's truly important is that x402 embeds payment back into the internet's request-response flow. Previously: First, register an account. Then buy a package. Then get an API key. Then call the service. Then reconcile accounts at the end of the month. x402 wants to change this to: Request resources. Received 402 Payment Required. Payment completed. Resources acquired. This is crucial for Agentic Payments because Agent transactions are not just a few large purchases, but rather a large number of small, real-time, on-demand service calls. A writing Agent might purchase a data query for an article. A research Agent might call an on-chain analytics service for a problem. A travel Agent might simultaneously query multiple price APIs. A development Agent might purchase model inference, code review, or testing environments on a per-use basis. A traffic analytics agent might only want to purchase Semrush-like data once for a specific website, rather than buying a complete SaaS package. If every service requires an account, subscription, API key, package, and manual approval, the agent's execution capabilities would be hampered by the payment and procurement process. Therefore, the significance of x402 is not to make payments "more crypto," but to make them more like internet protocols: requestable, returnable, verifiable, and automated. L402 is another similar approach. It also revolves around HTTP 402, but incorporates access credentials and micropayments like those from the Bitcoin Lightning Network and Macaroons. Lightning Labs defines L402 as: facilitating the authentication and transaction of services such as API endpoints and computing resources, allowing services to charge API endpoints, and making it easier for AI agents to participate. The L402 explanation indicates that this problem didn't just suddenly appear with x402. People have been trying to combine these three things for a long time: HTTP access control, micropayments, and digital service permissions. It's just that a sufficiently strong demand side was lacking in the past. Human users won't pay a few cents to access an API endpoint. But agents will. Humans won't automatically call hundreds of data sources a day. But agents will. Humans won't combine calls, inquire about prices, make payments, and verify delivery between different services in real time to complete a task. But agents will. Therefore, the emergence of AI agents suddenly makes the HTTP-native payment route meaningful. Similar directions are also beginning to emerge 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 are emerging around the USDT/Tether ecosystem. This reflects a noteworthy trend: Agentic Payments are not just about competition between individual companies' products, but rather the formation of a new protocol stack. AP2 seems to be answering the question: Why should an 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, on the other hand, are more like answering the question: What asset will this money ultimately be settled with, where will it be verified, and how can it be achieved at low cost, in real-time, programmable, and cross-platform? Therefore, Agentic Payment and Crypto are discussed together not because Web3 is trying to piggyback on AI. More accurately, it's because Agentic Payment has revived the "payment nativeness" problem that the internet hasn't solved well in the past. Information can flow natively 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 say "let AI pay with cryptocurrency," but rather attempt to define a new way of interaction: 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 bank cards solve the checkout problem, then these protocols solve: How do machines initiate a payment? Once this problem 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 Denomination, Not Volatile Assets. If agents truly need a machine-readable, automatically executable 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 needs. If an agent simply holds the asset long-term, they might care about price fluctuations, returns, and risk exposure. But if an agent is being paid to complete a task, what they need most isn't a speculative asset, but a stable unit of account. A research agent calling a data API might cost $0.10. A coding agent calling a model inference might cost $0.03. A marketing agent buying traffic data might cost $1. A procurement agent automatically compares prices, places orders, and makes payments, and may need to control every expenditure within a budget. In these scenarios, the agent isn't trading or speculating on 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? Can the cost be accurately recorded after service delivery? If the payment asset itself fluctuates wildly daily, the agent's budget management becomes very strange. Today an API call might be worth $0.10, tomorrow it might be $0.12 or $0.08 due to price fluctuations. This might not matter much in the trading market, but for machines purchasing resources on demand, it adds a lot of unnecessary complexity. This is why stablecoins, rather than highly volatile crypto assets, are more naturally used in Agentic Payments. The first layer of value of stablecoins is providing a unit of account that is closer to the real-world business world. Today, a large number of APIs, SaaS, data services, model services, and cloud services are priced in US dollars. If an agent wants to purchase these services on demand, using a stablecoin as the payment asset allows them to directly combine budget, price, authorization, and billing into a single unit. This sounds ordinary, but it's crucial for agents. Because agents don't just "pay"; they also make judgments. They need to determine if the call is worthwhile, if the budget is sufficient, if user confirmation is needed, record task costs, and 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, automatic 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. A key change behind this is that payments no longer necessarily occur within a full checkout page, but can happen within a single API request. The Agent requests a resource. The service provider returns a 402 Payment Required. The Agent determines the price and authorizes the transaction. The Agent pays the stablecoin. The service provider verifies and releases the resource. 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 states this point clearly: 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 doesn't mean bank cards will disappear. Stripe and Tempo's Machine Payments Protocol explicitly supports 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 replace bank cards," but rather: bank cards are suitable for existing merchant networks and checkout scenarios. Stablecoins are better suited for machine-to-demand payment scenarios in open networks. The third layer of value is that stablecoins are inherently better suited for cross-platform and cross-border transactions. Agents don't necessarily work on only one platform. One agent might call data APIs in the US, model services in Europe, content interfaces in Asia, on-chain analytics tools, and then 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. But stablecoins are internet-native assets. They can circulate 24/7, can be called across platforms, wallets, and applications, and can be directly processed by smart contracts or payment protocols. For human users, this might just mean "faster payments." But for agents, the significance is much greater. Because agent execution doesn't occur according to bank opening 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 always 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 requiring agents to first access a human-designed payment page. However, a word of caution is necessary. Stablecoins are not without problems. Different stablecoins vary in reserve transparency, issuing entities, regulatory status, redemption capabilities, and on-chain liquidity. The BIS, in its 2025 Annual Economic Report, explicitly criticized stablecoins, arguing that they lack key standards of the monetary system 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 is: stablecoins are not perfect currencies, but they are currently one of the closest internet-native settlement assets to meeting the needs of agentic payments. Their value lies not in the "decentralized narrative," but in the fact that they simultaneously meet several conditions: relatively stable price; programmable functionality; cross-platform transferability; 24/7 settlement; and integration with HTTP-native payments, wallets, smart contracts, and on-chain auditing. This is why stablecoins naturally emerge when discussing resource usage on open networks in agentic payments. Because what agents need is not a "hand that can swipe a card," but a form of money that software can directly understand and use. 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 requires a better compliance framework, a more stable issuance mechanism, clearer risk control, and more comprehensive wallet permission management. It also needs to integrate with protocols like AP2, x402, and MPP to truly enter a scalable Agentic Payment scenario. However, the direction is clear: Agents need stable price units, instant settlement assets, money that can be used programmatically, 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 when the transaction object changes from "human consumers" to "software entities," stablecoins, for the first time, make "money" more like part of the internet protocol. But stablecoins only answer one question: What money does the Agent use to pay? They haven't answered another question: After an Agent spends money on an open network, who authorized that money, 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 On-Chain Registration, But for Verifiable Agent Behavior. Even if an agent needs stablecoin payments, why is blockchain absolutely necessary? Can't it be a centralized ledger? Can't it be Stripe, Visa, a bank, or a platform keeping its own records? Of course it can. If the agent only operates within a closed platform, such as only shopping on Amazon, only calling services within a SaaS platform, or only making purchases within an internal enterprise system, then a centralized ledger is perfectly sufficient. 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 is not that the agent clicks the payment button for you within a closed platform, but rather that it may cross platforms, services, wallets, countries, and even different agents to complete a task. At this stage, the issue is no longer 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 service, and where the responsibility lies if errors occur. These are the questions where the real value of blockchain in Agentic Payment lies. It's not because all transactions must be on-chain, nor because on-chain is necessarily more advanced than banking, but because when an agent begins to perform tasks, invoke services, and process funds, every economic action it takes needs to leave 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 contracts, contact finance, check emails, and hold meetings to argue; if your bank card is charged incorrectly, you can go to the bank for dispute resolution. These mechanisms are cumbersome, but this is 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 that this amount is within the budget, completes the payment, and the service provider releases the data after receiving the money. In this process, what truly matters is not "which chain was used," but whether we can answer several questions afterward: What authorizations did the user grant at the time? What did the agent purchase? Did the amount exceed the budget? Did the service provider actually return the data? If it is later discovered that the agent was misled by prompt injection into purchasing inappropriate items, can we trace it back? This is why I think revisiting the Bitcoin white paper when discussing Agentic Payments isn't about nostalgia. Satoshi Nakamoto's core problem 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 problems. It's not just about double-spending, but also about the authorization, overreach, delivery, and responsibility of agents. However, they share a common thread: once economic activity occurs on an open network, verifiable transaction records are no longer secondary, but part of the infrastructure itself. This is the significance of blockchain. It doesn't make payments mystical, but rather transforms states previously hidden in platform databases into externally verifiable states. At least ideally, payment records, authorization credentials, service access, refund conditions, and budget expenditures can all be recorded and verified in a more standardized manner. For human users, this might simply mean "clearer accounts"; but for an agent, this could be the foundation of its trustworthiness. Because an agent is not human. It cannot explain its behavior based on "I remember thinking this way." It needs an externally verifiable chain of evidence. This is why AP2, x402, stablecoins, and blockchain are often discussed together, 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. So, 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, solving how the service provider initiates a payment request when an agent requests a resource. Stablecoins are settlement assets, solving what stable unit the agent uses for payment. Blockchain is the verifiable state layer, solving 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, able to help 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 package, checking bills, contacting customer service, and processing reimbursement. Then it's not Agentic Payment, but just a browser assistant that's better at clicking buttons. Of course, we can'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 receives payment but doesn't deliver, if a malicious website induces the agent to make payments, or if an agent spends their 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 dangerous. What's truly needed is a comprehensive control mechanism: limits, whitelists, blacklists, authorization scope, risk levels, manual confirmation, a pause/on switch, and audit logs. Small, low-risk, machine-native calls can be automated; large, high-risk transactions involving real-world fulfillment should still rely on human confirmation. 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 spent is authorized, the things purchased are recordable, the behavior is traceable, and the problems caused are accountable. This is the true position of blockchain in this issue. It's not about faith, narrative, or a brute-force "AI + Web3" competition, but rather that when machines begin to participate in economic activities, the original account system and platform databases may no longer be sufficient. We need a more open, standardized, and machine-readable/verifiable layer of economic state, and blockchain at least provides a direction. Fifth, it's not about replacing bank cards, but rather the payment system beginning to be layered. Therefore, in the end, I don't believe that Agentic Payment will simply lead to the conclusion that 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 many real-world consumption scenarios. Humans buying things on e-commerce websites, booking hotels, buying plane tickets, offline consumption, and corporate procurement—these scenarios won't suddenly disappear just because agents appear. Even in the early stages of Agentic Commerce, agents are likely to first integrate with these existing payment systems. This is because existing merchant networks are already mature, consumers already have cards and wallets, merchants have already implemented acquiring, and banks and card organizations have mature risk control, dispute resolution, refund, compliance, and identity systems. For scenarios like "AI helps me complete a purchase," directly using existing Rails is the most realistic path. Therefore, the question isn't "Will cards disappear?" The question is whether Agentic Payment will remain at this level. If the agent simply clicks "checkout" for someone, it can indeed continue to use bank cards. But if the agent starts entering a more open task network to call APIs, purchase data, payment model services, settle computing power, unlock content, and transact with other agents, then what it needs is not just a smarter payment button, but a new payment protocol stack. This is why I believe the future is more likely to see a stratification of payment systems than a "bank card vs. stablecoin" dynamic. In human consumption and established merchant networks, bank cards, credit cards, wallets, and bank accounts will remain mainstream. Traditional payment rails will continue to play a role in scenarios where agents help people complete shopping, ticket bookings, hotel reservations, and SaaS renewals. Agents simply enter existing commerce flows to help users complete transactions more automatically. However, in more machine-native scenarios such as APIs, data, models, computing power, content, on-chain services, and agent-to-agent transactions, stablecoins and blockchains will be more likely to emerge. This is because the payment objects here are not traditional merchants, but digital resources; transaction amounts may be small, but the frequency may be high; service providers may come from different platforms, countries, and systems; and the entire process should ideally be automatically understood, paid for, and verified by machines. In short: bank cards solved the payment problem of the human consumption era, while stablecoins and blockchain are more like solving the problems of settlement language and verifiable execution environment in the machine economy era. Of course, this doesn't mean stablecoins and blockchain are ready. Today's on-chain experience remains complex, wallet management is still not user-friendly, stablecoin regulations are still evolving, and liquidity between different chains is highly fragmented. More importantly, allowing agents to directly control funds is inherently dangerous. Without access control, limit control, risk control mechanisms, manual review, and auditing systems, Agentic Payment can easily go from "automation" to "automatic mishaps." Therefore, the true realization of Agentic Payment will not involve agents freely spending money indiscriminately. It's more likely to be a gradual evolution: first, it will integrate into existing payment systems to help users complete more automated checkouts; then, it will gain more granular authorization capabilities, such as budgets, whitelists, usage scope, time limits, and risk levels; next, 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 alone. It's more like the entire payment system being forced to dismantle and reorganize in the face of the new entity, the AI ​​Agent. In the past, payment systems defaulted to serving individuals and companies. In the future, payment systems may also need to serve a new type of entity: authorized software agents. It's not a person in the legal sense, nor a traditional corporate account, but it initiates requests, compares prices, calls services, consumes resources, triggers payments, and leaves records. When such entities begin to appear in large numbers, the payment system must answer new questions: Who is it, who does it represent, what is it allowed to do, how much can it spend, what did it buy, has it overstepped its authority, and who is responsible if problems arise? These questions cannot be solved by a simple payment button. So, returning to the initial question: Will the AI ​​Agent use bank cards? Yes. But it won't only use bank cards. Bank cards will continue to handle checkouts, stablecoins will begin to handle small-amount instant settlements native to machines, blockchain will provide some verifiable state and execution environment, and protocols like AP2, x402, L402, and T402 will attempt to connect authorization, payment requests, and resource access. This is the most noteworthy aspect of Agentic Payment. It's not just about giving AI an additional payment function. It's about forcing us to rethink: what kind of payment system does the internet truly need when machines begin to participate in economic activities?