Will AI Agents use bank cards? Why can't Agentic Payment avoid stablecoins and blockchain?

Author: Yokiiiya

Last week at the Web3 Festival in Hong Kong, one obvious feeling was that almost every forum and panel could not avoid discussing AI.

Regardless of whether the original topics were payments, stablecoins, RWA, wallets, exchanges, compliance, or infrastructure, they almost always returned to the same question: When AI is no longer just generating content but starts executing tasks, calling services, making decisions, and even handling cash flows, are the existing financial and payment systems still sufficient?

In one of the panels I attended, someone directly posed the question: Is Web3 just riding the AI wave? I don't think so. Of course, there will be projects that ride the trend. But if we only understand AI × Web3 as a narrative collage, we might miss a deeper 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 are undergoing a reallocation of roles.

The Financial Secretary of Hong Kong, Paul Chan, also mentioned in his speech at the Web3 Festival 2026 that AI agents will analyze information and take action at machine speed while fully utilizing blockchain infrastructure in the background, thereby improving transaction efficiency and reshaping scenarios such as finance, trade, wealth management, supply chains, and logistics. When AI starts to act, the question is not just about the "intelligence" itself, but how these actions are authorized, settled, recorded, and held accountable.

Among them, Agentic Payment is an increasingly hard-to-ignore topic. But I initially had a very simple question: Why is it that whenever people talk about Agentic Payment or Agentic Commerce, it seems to be assumed that it must be tied to Crypto, Stablecoin, or Blockchain?

Can't AI Agents use bank cards? Can't they use credit cards? Can't they use Apple Pay, Visa, Mastercard, or PayPal?

If an Agent is just helping me buy a plane ticket, book a hotel, or renew a SaaS subscription, theoretically it can completely utilize the existing payment system. The user authorizes once, and the Agent executes the payment within the limits and rules, using bank cards, virtual cards, corporate accounts, or third-party payment wallets; it doesn't sound unreasonable.

So the question is not "Can bank cards be used?" Of course they can. The real question is: Which part of Agentic Payment can bank cards and credit cards effectively address, and which part can they not? Will AI Agents use bank cards? And why, as Agentic Payment develops to a certain stage, is it almost inevitable to involve stablecoins and blockchain?

1. Bank cards solve checkout, not the Agent Economy

If Agentic Payment is just about having AI Agents complete the final step of payment, such as buying a plane ticket, booking a hotel, or renewing a SaaS subscription, using bank cards, credit cards, virtual cards, Apple Pay, Stripe, or PayPal, there are no essential barriers. Bank cards can certainly be used, and credit cards can also be used.

Users authorize in advance, and the Agent executes the payment within the limits and rules. This is not hard to understand; it is essentially like 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 does not solely rely on stablecoins but 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 payment, traditional payments and stablecoins are more likely to coexist rather than one immediately replacing the other. But this only addresses one part of Agentic Commerce: checkout.

The premise of checkout is that products, merchants, orders, payment buttons, refund processes, and dispute handling processes already exist. The Agent simply stands beside the user, helping them complete a purchase more automatically.

The real issue arises in another type of scenario: Agents are no longer just entering a pre-built shopping cart but are continuously calling resources, combining services, and completing tasks in an open network.

For example, an AI research agent may need to call multiple databases, purchase several paid materials, access different model APIs, invoke a web scraping service, pay for chart generation tools, and even purchase an analysis result from another Agent to complete an industry report. There may not be a traditional "store" involved. There may not even be a complete checkout page. It may be dealing with APIs, data interfaces, model services, computing nodes, content resources, automated tools, or even another Agent.

I recently encountered a very specific example myself. I wanted to create a traffic analysis assistant that could automatically call data sources like Semrush when needed to help me analyze a website's traffic, keywords, competitors, and market trends. But when I started organizing the plan, I found that the issue was not "Can AI analyze?" but rather "How does it obtain the data?" Many commercial data sources are not designed for "one-time calls, one-time payments, instant returns." Taking Semrush as an 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 to have corresponding API access or purchase an API unit package; although the Trends API can be purchased separately, it is still based on API units to request data.

But for Agents, this model is not natural enough. If an Agent only occasionally needs to call traffic data, what it really needs may not be to register a SaaS account or purchase a whole package of API units, but to initiate a request like accessing a webpage: How much does this data cost? Am I authorized to purchase it? If it is within budget, then pay and immediately receive the result.

This is the disconnect between Agentic Payment and traditional API business models. Today, many API charging methods are still designed for "human companies purchasing software," rather than for "machines purchasing resources on demand."

So, the issue with Agentic Payment is not whether the last step can deduct money, but how machines can continuously obtain authorization, initiate payments, verify delivery, and complete settlements throughout the entire task chain.

This is where the boundaries of the bank card system lie.

Not because bank cards are outdated, but because they originally serve human consumption scenarios: a person enters a merchant environment, selects products, confirms orders, completes payments, and then banks, card organizations, acquirers, and payment service providers complete authorization, clearing, risk control, and dispute handling.

But the Agent Economy faces a different set of questions: What authority does this Agent have to spend this money? How does the service provider confirm that this is not a malicious bot but an extension of the user's true intent? Can the Agent complete small, high-frequency, cross-platform payments without human confirmation at every step? After the service provider receives payment, can they immediately release the corresponding resources? If the Agent makes a mistake, exceeds authority, or is attacked, who should be held responsible?

This is also why, when Google created AP2, it did not 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 complete agent-led payments with more confidence across different payment methods. The AP2 specification also clearly states that Agents need a secure and simple way to obtain scoped permissions to act on behalf of users; the security of the protocol relies on users and merchants cryptographically signing relevant information.

So, the first layer of the issue with Agentic Payment is not: Where does the money come from? but rather: What authority does the Agent have to spend this money?

This question can be partially addressed by the bank card system. For example, virtual cards, tokenized credentials, limit management, corporate expense control, and risk control rules can allow Agents to complete transactions within the existing merchant system.

Visa is also advancing in this direction. Its Intelligent Commerce and Trusted Agent Protocol essentially allow AI Agents to be recognized, trusted, and permitted to complete transactions on behalf of consumers or businesses within the existing merchant network. Visa Developer's description of the Trusted Agent Protocol is also very direct: AI agents will help users browse merchant websites, discover products, compare prices, and make choices, while the commercial journey has already begun long before checkout; in the past, these automated accesses were often blocked by merchants, CDNs, or bot mitigation services as bots.

This indicates that traditional payment networks also see the same issue: Agentic Commerce does not only occur at the moment of payment but spans the entire chain from searching, comparing, selecting, authorizing, to final payment. However, card networks are better at solving how Agents can enter existing commerce flows and complete authorized transactions. What they do not naturally solve is how Agents can continuously initiate small payments for APIs, data, models, computing power, content, tools, and another Agent in an open network.

So, bank cards are not unfeasible. More accurately, bank cards solve the checkout issue of Agentic Commerce, but the Agent Economy requires a more fundamental payment protocol.

This pushes the question to the next level: If the transaction object is not 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 also why protocols like x402, L402, and T402 are beginning to be discussed.

2. What Agents really need is a machine-readable payment protocol

If the transaction object is a traditional merchant, Agents can certainly enter the existing checkout flow and complete payments using credit cards, debit cards, virtual cards, or wallets. But if the transaction object is not 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 is not a "payment button," but a set of payment processes that machines can understand: The Agent requests a resource. The service provider tells it: This resource requires payment, what the price is, what the receiving address is, and what payment methods are supported. The Agent determines whether this payment is within the user's authorized range. If it meets the rules, it completes the payment. After the service provider verifies the payment, it immediately releases the resource.

This process sounds simple, but it is actually filling a layer of capability that the internet has long been missing: 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; it was attached to another system: registering accounts, binding bank cards, connecting payment gateways, purchasing packages, managing API keys, and reconciling at the end of the month.

This is bearable for humans. People can register, log in, bind cards, approve, procure, and reimburse. But for Agents, this process is too cumbersome.

Agents should not have to register an account every time they call an API, nor should they have to buy a whole package every time they access data, and they should not have to go through a complete human payment and procurement process for small calls worth a few cents. This is why protocols like x402 have emerged.

x402 reactivates the long-existing but rarely used HTTP 402 Payment Required status code. It allows service providers to directly inform clients at the HTTP layer: You need to pay first to access this resource. The client can be either a human or a machine. After payment is completed, the service provider verifies the payment and then returns the corresponding API, content, or digital service. Coinbase's definition of x402 is very straightforward: it is an open protocol for instant, automated stablecoin payments via HTTP, allowing human and machine clients to programmatically pay and gain access without needing accounts, sessions, or complex authentication.

What is truly important here is not "whether to use Coinbase," nor is it "whether to use USDC." What is truly important is that x402 embeds payment back into the request-response process of the internet.

In the past, it was:

• First, register an account.

• Then, buy a package.

• Then, get an API key.

• Then, call the service.

• Reconcile at the end of the month.

x402 wants to change it to:

• Request a resource.

• Receive 402 Payment Required.

• Complete payment.

• Obtain the resource.

This is crucial for Agentic Payment. Because the transactions of Agents are not a few large purchases but potentially a large number of small, real-time, on-demand service calls.

• A writing Agent may purchase a data query for an article.

• An investment research Agent may call an on-chain analysis service for a question.

• A travel Agent may simultaneously inquire prices from multiple price APIs.

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

• A traffic analysis Agent may only want to buy Semrush-like data for a specific website, rather than purchasing a whole SaaS package first.

If every service requires an account, subscription, API key, package, and manual approval, the execution capability of the Agent will be stuck in the payment and procurement process. Therefore, the significance of x402 is not to make payments "more crypto," but to make payments more like internet protocols: requestable, returnable, verifiable, and automatically executable.

L402 is another similar route.

It also revolves around HTTP 402 but combines it with Bitcoin Lightning Network, macaroons, and small payments. Lightning Labs defines L402 as facilitating authentication and transactions for API endpoints, computing resources, and other services, allowing services to charge API endpoints and making it easier for AI agents to participate.

L402 indicates that this issue was not suddenly invented by x402. People have been trying to combine three things for a long time: HTTP access control, small payments, and digital service permissions. It was just that there was a lack of a sufficiently strong demand side.

Human users would not pay a few cents to access an API endpoint. But Agents will. Humans do not automatically call hundreds of data sources in a day. But Agents will. Humans do not combine calls, inquire prices, make payments, and verify delivery in real-time across different services to complete a task. But Agents will.

Thus, the emergence of AI Agents makes the HTTP-native payment route suddenly meaningful.

Around the USDT / Tether ecosystem, similar directions are also beginning to emerge. The x402 documentation of Tether WDK clearly states that x402 is important for AI agents because agents need to programmatically pay for resources; x402 makes payment a first-class citizen of the web stack, allowing agents to discover prices, sign payments, and obtain resources within a single request-response cycle. At the same time, the t402 project also describes itself as an open standard for internet-native payments, aiming to support various forms of value such as crypto, fiat, stablecoins, and tokens, and to be compatible with Tether WDK. Here, caution is needed: I do not recommend stating it directly as "has become the official standard of Tether"; a more stable expression is that protocols similar to x402 are emerging around the USDT / Tether ecosystem.

Behind this is actually a trend worth paying attention to: Agentic Payment is not a product competition of a single company, but is forming a new protocol stack.

• AP2 is more like answering: What authority does the Agent have to be authorized to pay?

• Protocols like x402, L402, and T402 are more like answering: 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: What assets will ultimately settle this money, where will it be verified, and how can it be low-cost, real-time, programmable, and cross-platform?

Therefore, discussing Agentic Payment alongside Crypto is not because Web3 wants to ride the AI wave. More accurately, it is because Agentic Payment has resurfaced the "native payment" issue that the internet has not solved well in the past.

Information can flow natively on the internet. But value has long been unable to. The emergence of Agents is forcing the internet to fill this layer.

This is also why protocols like x402, L402, and T402 are worth paying attention to. They are not simply saying "let AI pay with cryptocurrency," but are attempting to define a new interaction method: machines request resources, machines understand prices, machines verify authorization, machines complete payments, and machines obtain services.

If bank cards solve checkout, then these protocols solve how machines initiate a payment. Once this question is entered, stablecoins and blockchain are no longer just payment tools but will become the underlying settlement language and execution environment of Agentic Payment.

3. Why stablecoins: Agents need stable units of account, not volatile assets

If Agents really need a machine-readable, automatically executable payment protocol, then why is stablecoin the most discussed? Why not BTC? Why not ETH? Why not regular bank cards?

The key here is not the "crypto asset" itself, but what kind of payment asset Agents actually need. If an Agent is just holding assets long-term, it may care about price fluctuations, returns, and risk exposure. But if an Agent is paying to complete a task, what it needs most is not speculative assets but a stable unit of account.

A research agent calling a data API may cost $0.1. A coding agent calling a model inference may cost $0.03. A marketing agent purchasing traffic data may cost $1. A procurement agent automatically comparing prices, placing orders, and making payments may need to control each expenditure within budget.

In these scenarios, the Agent is not making transactions or speculating. It is completing tasks. Therefore, it needs to know: How much does this resource actually cost? Will this call exceed the budget? Is this payment within the user's authorized range? After service delivery, can the cost be accurately recorded?

If the payment asset itself fluctuates wildly every day, the Agent's budget management will become very strange. Today an API call is worth $0.1, but tomorrow due to price fluctuations, it becomes $0.12 or $0.08; this may 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 naturally appear more in Agentic Payment than highly volatile crypto assets.

The first layer of value of stablecoins is to provide a unit of account that is closer to the real business world. Today, many APIs, SaaS, data services, model services, and cloud services are already priced in dollars. If an Agent wants to purchase these services on demand, using dollar stablecoins as the payment asset can directly align budget, price, authorization, and billing within the same unit.

This may sound ordinary, but it is very important for Agents. Because Agents do not just "pay"; they also need to make judgments. They need to judge whether this call is worth it. They need to judge whether the budget is sufficient. They need to judge whether they need to return to the user for confirmation. They need to record task costs. They also need to explain in case of errors: Why did they spend this money?

Therefore, Agentic Payment requires a low-volatility, machine-readable, and programmatically callable payment asset. Stablecoins happen to be closer to this need than volatile assets like BTC and ETH.

The second layer of value is that stablecoins are more suitable for small, high-frequency, and instant settlements. When discussing x402 earlier, this trend was already visible. Coinbase's definition of x402 is to achieve instant, automated stablecoin payments via HTTP, allowing APIs, digital content, and services to collect payments from human and machine clients without needing accounts, sessions, or complex authentication. This statement reflects a key change: payments no longer necessarily have to occur on a complete checkout page but can happen within a single API request.

Agents request a resource. The service provider returns 402 Payment Required. The Agent assesses the price and authorization. The Agent pays with stablecoins. The service provider verifies and then releases the resource.

This set of processes is naturally suitable for small, high-frequency, on-demand calls. For example, a data query, a model call, unlocking content, an on-chain analysis, or generating a chart. The x402 documentation of Tether WDK also states this point very clearly: AI agents need to programmatically pay for resources, and x402 allows agents to discover prices, sign payments, and obtain resources within a single request-response cycle.

This is not 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 call resources. Of course, this does not mean that bank cards will disappear. The Machine Payments Protocol from Stripe and Tempo clearly supports two paths: one is direct on-chain crypto payments, and the other is fiat payments like cards and wallets. Stripe's official statement also mentions that merchants can accept payments from agents through MPP, using both stablecoins and fiat payment methods like cards and BNPL.

So a more accurate judgment is not "stablecoins replace bank cards," but rather: bank cards are suitable for existing merchant networks and checkout scenarios. Stablecoins are more suitable for on-demand payment scenarios in open networks.

The third layer of value is that stablecoins are inherently more suitable for cross-platform and cross-border transactions. Agents may not only work within one platform. An Agent may call a data API from the US, a model service from Europe, a content interface from Asia, on-chain analysis tools, and then transact with another Agent. If each layer relies on different countries' bank accounts, acquirers, 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 may just mean "faster arrival." But for Agents, it is more significant. Because the execution of Agents does not occur according to bank operating hours.

They should not have their tasks interrupted due to weekends, cross-border issues, bank clearing windows, or merchant account systems. They need a settlement asset that is always available, can be automatically called, and can be verified.

This is also why support for x402, Tether WDK's support for x402, and the emergence of t402 explorations around 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 Agents first enter a human-designed payment page.

But here, a cold splash of water is needed. Stablecoins are not without issues.

The reserve transparency, issuing entities, regulatory status, redemption capabilities, and on-chain liquidity of different stablecoins vary. The BIS also explicitly criticized stablecoins in its 2025 Annual Economic Report, stating that they fall short on key monetary system standards such as singleness, elasticity, and integrity, and should not be simply viewed as a complete substitute for modern monetary systems.

A more accurate statement is: stablecoins are not perfect currencies, but they are currently one of the closest internet-native settlement assets to the needs of Agentic Payment.

Their value does not lie in "decentralized narratives," but in that they simultaneously meet several conditions: relatively stable prices, callable by programs, capable of cross-platform circulation, available for 24/7 settlement, and can integrate with HTTP-native payments, wallets, smart contracts, and on-chain audits.

This is why stablecoins naturally appear when discussing resource calls in Agentic Payment. Because what Agents need is not a "hand that can swipe a card," but a form of money that can be directly understood and used by 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 requires better compliance frameworks, more stable issuance mechanisms, clearer risk controls, more complete wallet permission management, and needs to integrate with protocols like AP2, x402, and MPP to truly enter scalable Agentic Payment scenarios.

But the direction is already clear: Agents need stable units of account, need instant settlement assets, need callable money, and need payment capabilities that cross platforms, borders, and services.

This is why stablecoins are indispensable in Agentic Payment. Not because all payments should become crypto payments. But because when the transaction object shifts from "human consumers" to "software entities," stablecoins make "money" more like a part of internet protocols for the first time.

But stablecoins only answer one question: What money does the Agent use to pay? It has not yet answered another question: After the Agent spends money in an open network, who authorized this money, where was it spent, was there any overreach, and was the service delivered? This question will lead us to blockchain.

4. Why blockchain is needed: not for on-chain purposes, but to make Agent's actions verifiable

Even if Agents need stablecoins for payment, why must it be blockchain? Can't it be a centralized ledger? Can't it be Stripe, Visa, banks, or a platform keeping its own accounts?

Of course, it can. If this Agent only operates within a closed platform, such as shopping only on Amazon, calling services only within a certain SaaS, or making purchases only within an internal corporate system, then a centralized ledger is completely sufficient. The platform itself knows who the user is, who the Agent is, what the permissions are, how much was spent, and whether the service was delivered.

But the truly interesting aspect of Agentic Payment is not that the Agent helps you click the payment button within a closed platform, but that it may cross platforms, services, wallets, countries, and even different Agents to complete a task. At this stage, the question is no longer just "Can the money be paid out?" but rather why this money was paid, who authorized it, whether the Agent overstepped, whether the service provider delivered, and where responsibility should lie if something goes wrong.

These questions are where blockchain truly adds value in Agentic Payment. It is not because all transactions must go on-chain, nor because on-chain is necessarily superior to banks, but because when Agents start executing tasks, calling services, and handling cash flows on behalf of people, every economic action they take needs to leave a verifiable record.

Humans can tolerate a lot of opacity when making payments. If a service is purchased but not received, they can contact customer service; if there are issues with company procurement, they can refer to contracts, consult finance, check emails, or hold meetings to argue; if a bank card is charged incorrectly, they can contact the bank to dispute it. These mechanisms are clumsy, but human society has long operated this way.

Agents are different. The transaction frequency of Agents may be higher, the amounts may be smaller, the service providers may be more numerous, and the execution chains may be longer. If every transaction relies on manual post-checks, screenshots, email comparisons, and customer service inquiries, 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 help me do a market analysis, only purchasing data, model calls, and chart generation services. Then the Agent requests a data API, and the service provider returns that this query costs $0.2. The Agent assesses that this amount is within budget, completes the payment, and the service provider releases the data after receiving the money. In this process, what is truly important is not "which chain was used," but whether we can answer several questions afterward: What authorization did the user provide at the time, what did the Agent purchase, did this money exceed the budget, did the service provider actually return the data, and if it is later discovered that the Agent was induced by prompt injection to buy something it should not have, can it be traced back?

This is also why I believe that revisiting the Bitcoin white paper when discussing Agentic Payment is not for nostalgia. The core problem that Satoshi Nakamoto aimed to solve was not "inventing a tradable asset," but rather how to allow the transfer of electronic cash to be verified, ordered, and recorded by the network without a trusted third party. The white paper clearly states: The network will write transactions into a continuously growing proof-of-work chain through hashing, forming a record that cannot be changed without redoing the work.

The issues faced by Agentic Payment are not entirely the same. It is not just about double-spending, but also about the Agent's authorization, overreach, delivery, and responsibility. But they share a common point: once economic behavior occurs in an open network, verifiable transaction records are no longer accessories but the infrastructure itself.

This is the significance of blockchain. It does not make payments esoteric, but rather transforms a portion of the state that was originally hidden in platform databases into a state that can be externally verified. At least ideally, payment records, authorization credentials, service access, refund conditions, and budget consumption can be recorded and verified in a more standardized manner. For human users, this may just mean "clearer accounts"; but for Agents, this may be the basis for whether they can be trusted.

Because Agents are not human. They cannot explain their actions by saying, "I remember I thought this way at that time." They need a set of externally verifiable evidence chains.

This is also why AP2, x402, stablecoins, and blockchain are often discussed together, but they are not the same thing. AP2 itself is not a decentralized protocol, nor is it a blockchain protocol. Google's positioning of AP2 is as a payment-agnostic open framework that allows users, merchants, and payment service providers to complete agent-led payments with more confidence across different payment methods; the AP2 specification also defines it as an open protocol that enables AI agents to safely 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, authorization scope, and boundaries of responsibility. x402, L402, and T402 are more like the payment request layer, solving how service providers initiate payment requests when an Agent requests a resource. Stablecoins are the settlement asset, solving what stable unit the Agent uses to pay. Blockchain is the verifiable state layer, solving whether transaction records, settlement states, and subsequent executions can be externally verified.

These layers are not the same, but when combined, they resemble a true infrastructure for Agentic Payment. Otherwise, it would become an awkward situation: Agents are intelligent and can help you find services, compare prices, and make decisions, but when it comes to payment, they revert to the human world’s processes: registering accounts, binding cards, buying packages, checking bills, contacting customer service, and going through reimbursements. Then it is not Agentic Payment; it is just a browser assistant that can click buttons better.

Of course, we should not be overly optimistic here. Allowing Agents to access on-chain payments is not without risks, and the risks may be more direct. In traditional payments, many transactions can still be disputed, frozen, or reversed. Once an on-chain transaction is sent, it is often not easy to retrieve. If an Agent is attacked, if the user’s authorization scope is too broad, if the service provider takes the money without delivering, if a malicious website induces the Agent to pay, or if an Agent spends the entire budget in one night, these are not small issues.

Therefore, Agentic Payment is not simply about letting Agents take a wallet and say, "Go ahead, spend money." That is too dangerous. What is truly needed is a complete set of control mechanisms: limits, whitelists, blacklists, authorization scopes, risk levels, manual confirmations, pause switches, and audit records. Small, low-risk, machine-native calls can be automated; large, high-risk transactions involving real-world performance should still return to human confirmation.

So I prefer to understand the role of blockchain in Agentic Payment as: it is not used to prove that Web3 is superior to traditional finance, but to provide a verifiable foundation for the economic actions of Agents. Agentic Payment needs blockchain not because all payments should go on-chain, but because when AI Agents start spending money in open networks, we need a way to prove that the money they spent was authorized, that what they bought can be recorded, that their actions are traceable, and that the problems they cause can be held accountable.

This is the true position of blockchain in this issue. It is not about faith, not about narrative, and not about a hard push of "AI + Web3," but rather when machines begin to participate in economic activities, the original account systems and platform databases may no longer be sufficient. We need a layer of economic state that is more open, standardized, and easier for machines to read and verify, and blockchain at least provides a direction.

5. Not replacing bank cards, but the payment system is beginning to stratify

So in conclusion, I do not believe that Agentic Payment will simply lead to a conclusion: stablecoins replacing bank cards, and blockchain replacing traditional payment networks.

This judgment is too simplistic and too easily contradicted by reality. At least for a long time, bank cards, credit cards, Apple Pay, Visa, Mastercard, Stripe, PayPal, and these systems will still exist and will continue to serve as payment gateways in many real-world consumption scenarios. Humans buying things on e-commerce sites, booking hotels, buying plane tickets, offline consumption, and corporate procurement will not suddenly disappear because of the emergence of Agents.

Even in the early stages of Agentic Commerce, Agents are likely to first connect to these existing payment systems. Because the existing merchant networks are already very mature, consumers already have cards and wallets, merchants have already set up acquiring, and banks and card organizations already have mature risk control, dispute handling, refunds, compliance, and identity systems. For the scenario of "AI helping me complete a purchase," directly using existing rails is the most realistic path.

So the question is not "Will cards disappear?"

The question is whether Agentic Payment will only remain at this level. If Agents are just helping people click checkout, then they can indeed continue to use bank cards. But if Agents start entering a more open task network to call APIs, purchase data, pay for model services, settle computing power, unlock content, and transact with another Agent, then what they need is not a smarter payment button but a new payment protocol stack.

This is also why I believe that what is more likely to emerge in the future is not "bank cards vs. stablecoins," but rather the payment system beginning to stratify.

In human consumption and mature merchant networks, bank cards, credit cards, wallets, and bank accounts will still be mainstream. In scenarios where Agents help people complete shopping, booking tickets, booking hotels, and renewing SaaS subscriptions, traditional payment rails will continue to play a role. Agents simply enter existing commerce flows, helping users complete transactions more automatically.

But in more machine-native scenarios involving APIs, data, models, computing power, content, on-chain services, and Agent-to-Agent transactions, stablecoins and blockchain will be more likely to emerge. Because the payment objects here are not traditional merchants but digital resources; the transaction amounts may be small, and the frequency may be high; service providers may come from different platforms, countries, and systems; the entire process is best understood, paid for, and verified automatically by machines.

In summary: bank cards solve the payment issues of the human consumption era, while stablecoins and blockchain are more about solving the settlement language and verifiable execution environment issues of the machine economy era.

Of course, this does not mean that stablecoins and blockchain are ready. Today's on-chain experiences are still complex, wallet management is still not user-friendly, stablecoin regulation is still changing, and liquidity between different chains is also very fragmented. More critically, allowing Agents to directly control funds is inherently risky. Without permission management, limit controls, risk control mechanisms, manual reviews, and auditing systems, Agentic Payment can easily shift from "automation" to "automatically causing trouble."

Therefore, the true implementation of Agentic Payment will not be about letting Agents take wallets and spend money everywhere.

It is more likely to be a gradually evolving process: first entering existing payment systems to help users complete more automated checkouts; then gaining more granular authorization capabilities, such as budgets, whitelists, usage scopes, 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 later, stablecoins will become settlement assets in some machine-native scenarios, especially for small, high-frequency, cross-platform, and cross-border digital service calls.

From this perspective, Agentic Payment is not something that can be accomplished by a single company, a single chain, a single stablecoin, or a single protocol. It is more like the entire payment system being forced to re-split and reorganize in response to this new entity of AI Agents.

In the past, the payment system defaulted to serving humans and companies. In the future, the payment system may also need to serve a new entity: authorized software agents.

They are not legal persons, nor are they traditional corporate accounts, but they will initiate requests, compare prices, call services, consume resources, trigger payments, and leave records. When such entities begin to appear in large numbers, the payment system must answer new questions: Who are they, who do they represent, what are they allowed to do, how much can they spend, what did they buy, did they overreach, and who is responsible if something goes wrong.

These questions can no longer be solved by a simple payment button.

So returning to the initial question of the article: Will AI Agents use bank cards?

Yes.

But they will not only use bank cards.

Bank cards will continue to solve checkout, stablecoins will begin to solve machine-native small instant settlements, blockchain will provide some verifiable states and execution environments, 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 is not just about giving AI another payment function. It is forcing us to rethink: When machines begin to participate in economic activities, what kind of payment system does the internet really need?