Can AI Agents use bank cards?
Why is Agentic Payment inextricably linked to stablecoins and blockchain?

Author: Yokiiiya

Last week at the Web3 Festival in Hong Kong, a very clear feeling was: almost every forum, every panel, can’t avoid AI.

No matter if the original discussion was about payments, stablecoins, RWA, wallets, exchanges, or compliance and infrastructure, in the end, it almost always circles back to the same question: when AI is no longer just generating content, but begins executing tasks, calling services, making decisions, and even handling funds, are the existing financial and payment systems still sufficient?

In one panel I attended, someone directly posed a question: Is Web3 just riding the AI wave? I think not. Of course, projects riding the trend will exist. But if we only see AI × Web3 as a narrative collage, we might miss a deeper, more fundamental change: AI is responsible for understanding, decision-making, and action, while Web3 provides assets, accounts, settlement, and verifiable execution environments. These are not just combined concepts but are re-dividing roles.

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

Among these, Agentic Payment is an increasingly prominent topic. But I initially had a simple question: why does everyone seem to assume that Agentic Payment or Agentic Commerce must be tied to crypto, stablecoins, or blockchain?

Can’t AI agents use bank cards? Can’t they use credit cards? Can’t they use Apple Pay, Visa, Mastercard, Stripe, PayPal?

If an agent is just helping me buy a plane ticket, book a hotel, or renew a SaaS subscription, theoretically it can call the existing payment systems. User authorizes once, the agent executes payment within limits and rules, behind the scenes it uses bank cards, virtual cards, corporate accounts, or third-party wallets—nothing unreasonable about that.

So the question isn’t “Can bank cards be used?” Of course they can. The real question is: which part of Agentic Payment are bank cards and credit cards suitable for solving, and which parts are they not? Will AI agents really use bank cards? And why, once Agentic Payment reaches a certain stage, is it almost impossible to avoid stablecoins and blockchain?

1. Bank cards solve checkout, not the Agent Economy

If Agentic Payment is just about helping AI agents complete the final payment step—like buying a ticket, booking a hotel, renewing a SaaS—then using bank cards, credit cards, virtual cards, Apple Pay, Stripe, PayPal behind the scenes is no fundamental obstacle. They can be used. Of course.

User pre-authorizes, agent executes within limits and rules. This is not hard to understand; essentially, it’s like smarter auto-deduction, corporate virtual cards, travel cards, or automated procurement systems.

Therefore, traditional players like Visa, Mastercard, Stripe won’t disappear. They might even become important entry points for early-stage Agentic Commerce.

Stripe and Tempo’s Machine Payments Protocol exemplifies this. It’s not just about stablecoins; it allows merchants to accept payments directly from agents, supporting stablecoins, cards, BNPL, and other fiat payment methods. In early agent payments, traditional payments and stablecoins are more likely to coexist rather than one immediately replacing the other. But this only addresses part of the picture: checkout.

Checkout presupposes that products, merchants, orders, payment buttons, refunds, and dispute processes already exist. The agent just stands beside the user, helping automate a purchase.

The real challenge appears in another scenario: Agents no longer just enter an existing shopping cart but continuously invoke resources, combine services, and complete tasks in an open network.

For example, an AI research agent aiming to produce an industry report might need to call multiple databases, purchase several paid resources, access different model APIs, invoke a crawler service, pay for chart generation tools, or even buy analysis results from another agent. There may be no traditional “store” in this process, nor a complete checkout page. It might face APIs, data interfaces, model services, compute nodes, content resources, automation tools, or even another agent.

Recently, I encountered a concrete example myself. I wanted to build a traffic analysis assistant that could automatically call data sources like Semrush when needed, to analyze website traffic, keywords, competitors, and market trends. But when I started planning, I realized the problem wasn’t “Can AI analyze?” but “How does it get the data?” Many commercial data sources aren’t designed for “single call, pay-per-use, instant response.” Take Semrush: its API system is more like account, package, and API units. Each API request consumes a certain number of API units; users need API access or buy API unit packages. Trends API can be purchased separately but still operates on API units.

For an agent, this model isn’t natural. If an agent only needs to call traffic data occasionally, it doesn’t need to register a SaaS account or buy a whole API unit package. It just needs to send a request like browsing a webpage: How much does this data cost? Am I authorized to buy? If within budget, pay, and get the result immediately.

This exposes a gap between Agentic Payment and traditional API business models. Today’s API charging methods are designed for “human companies purchasing software,” not for “machines on demand buying resources.”

So, the core issue isn’t whether the last step can be deducted from a payment method. It’s how, in the entire task chain, machines can continuously obtain authorization, initiate payments, verify delivery, and settle.

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

It’s not because bank cards are outdated, but because they were originally designed for human consumption scenarios: a person enters a merchant environment, selects products, confirms the order, completes payment, and then banks, card organizations, acquirers, and payment service providers handle authorization, clearing, risk control, and disputes.

But Agent Economy faces a different set of questions: Why does this agent have the right to spend this money? How does the service provider confirm it’s not a malicious bot but a genuine user extension? Can the agent make small, high-frequency, cross-platform payments without manual confirmation? After payment, can the service provider immediately release resources? If the agent makes a mistake, exceeds authority, or gets attacked, who is responsible?

This is why Google, when developing AP2, didn’t focus on “which payment method” but on a more universal agent payment trust framework. Google’s official description of AP2 defines it as a payment-agnostic framework that allows users, merchants, and payment providers to complete agent-led payments more confidently across different payment methods. The AP2 specification explicitly states that agents need a secure, simple way to obtain scoped permissions to act on behalf of users; the protocol’s security depends on cryptographic signing by users and merchants.

Thus, the first question of Agentic Payment isn’t: Where does the money come from? but: Why does the agent have the authority to spend this money?

The bank card system can address part of this. For example, virtual cards, tokenized credentials, limit management, corporate expense controls, risk rules—all can enable agents to transact within existing merchant systems.

Visa is also advancing along this path. Its Intelligent Commerce and Trusted Agent Protocol essentially aim to enable AI agents to be recognized, trusted, and authorized to act on behalf of consumers or enterprises within existing merchant networks. Visa’s description of Trusted Agent Protocol states that AI agents will help users browse merchant sites, discover products, compare prices, and make choices, with the commercial journey starting even before checkout; previously, such automated visits were often blocked as bots by merchants, CDNs, or bot mitigation services.

This indicates that traditional payment networks also see the same issue: Agentic Commerce isn’t just about the moment of clicking the payment button but involves the entire chain from search, comparison, selection, authorization, to final payment. But card networks are better at solving: how does the agent enter the existing commerce flow and complete an authorized transaction? They are not inherently designed to handle: how do agents continuously initiate small payments across open networks for APIs, data, models, compute, content, or other agents?

So, bank cards aren’t impossible. More precisely: they solve the checkout problem in Agentic Commerce, but Agent Economy needs a more fundamental payment protocol.

This pushes the question to the next level: if the transaction target 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? That’s why protocols like x402, L402, T402 are being discussed.

2. What agents truly need is a machine-readable payment protocol

If the transaction is with a traditional merchant, the agent can enter the existing checkout flow, paying with credit/debit cards, virtual cards, or wallets. But if the transaction target isn’t a merchant but an API, a model, a data interface, content resource, or another agent, the problem changes.

At this point, what machines need isn’t a “pay button,” but a set of machine-understandable payment flows: the agent requests a resource. The service responds: this resource requires payment, what’s the price, what’s the payment address, what payment methods are supported. The agent assesses whether this payment is within user authorization. If yes, it completes the payment. The service verifies the payment and immediately releases the resource.

This process sounds simple but actually fills a missing layer in the internet’s past: a native payment layer. Historically, the internet naturally supported information flow—web pages can be requested, emails sent, APIs invoked, files downloaded. But “payment” was never part of the internet protocol itself; it was added on top via external systems: account registration, bank card linking, payment gateways, subscription management, API key management, monthly reconciliation.

This is tolerable for humans. People can register, log in, link cards, approve, purchase, reimburse. But for agents, this process is too heavy.

Agents shouldn’t have to register an account every time they call an API, buy a whole package of API units, or go through a full human payment and procurement process for a few cents or dimes of usage. That’s why protocols like x402 emerged.

x402 reactivates the HTTP 402 Payment Required status code, which has existed for a long time but is rarely used. It allows services to tell clients directly at the HTTP level: you need to pay before accessing this resource. The client can be human or machine. After payment, the service verifies and then returns the API, content, or digital service.

Coinbase’s definition of x402 is straightforward: it’s an open protocol for real-time, automated stablecoin payments via HTTP, enabling human and machine clients to pay programmatically and gain access without accounts, sessions, or complex authentication.

The key isn’t whether to use Coinbase or USDC specifically. The core is that x402 embeds payment into the request-response cycle of the internet.

Previously:

• Register account
• Buy a plan
• Get API key
• Call service
• Reconcile at month’s end

x402 aims to become:

• Request resource
• Receive 402 Payment Required
• Complete payment
• Access resource

This is crucial for agentic payments, because agents’ transactions aren’t just a few large purchases but potentially many small, real-time, on-demand service calls.

• A writing agent might buy data queries once per article.
• An investment research agent might call on-chain analysis once per question.
• A travel agent might query multiple prices APIs simultaneously.
• A developer agent might buy model inference, code review, or testing environments per use.
• A traffic analysis agent might just want to buy Semrush-like data for a single website, not a whole SaaS package.

If each service requires accounts, subscriptions, API keys, plans, and manual approval, agent execution is hampered by payment and procurement bottlenecks. So, the significance of x402 isn’t to make payments “more crypto,” but to make payments more like internet protocols: requestable, returnable, verifiable, and automatable.

L402 is a similar approach, expanding on HTTP 402 but combining Bitcoin Lightning Network, macaroons (access credentials), and small-value payments. Lightning Labs describes L402 as facilitating API endpoints, compute resources, and service authentication and transactions, making it easier for AI agents to participate.

L402 shows that this isn’t a new invention; earlier efforts tried to combine three things: HTTP access control, micro-payments, and digital service permissions. But the demand was lacking.

Humans won’t pay a few cents for API access, but agents will. Humans won’t automatically call hundreds of data sources daily, but agents will. Humans won’t dynamically combine, inquire, pay, and verify across services in real-time for a task, but agents will.

Thus, the emergence of AI agents makes HTTP-native payment routes suddenly meaningful.

Similarly, in the USDT/Tether ecosystem, protocols like x402 are emerging. Tether WDK’s x402 documentation explicitly states that x402 is important for AI agents because they need programmatic resource payments; it makes payments a first-class part of the web stack, allowing agents to discover prices, sign payments, and access resources within a single request-response cycle. T402 is also described as an open standard for internet-native payments supporting crypto, fiat, stablecoins, tokens, and compatible with Tether WDK. Caution is advised: it’s not officially a Tether standard yet, but an exploration around USDT/Tether.

This reflects a significant trend: Agentic Payment isn’t just about individual company products but about forming a new protocol stack.

• AP2 is more about answering: Why is the agent authorized to pay?
• x402, L402, T402 are about: When an agent requests a digital resource, how does the service initiate payment, and how does the agent complete it and get the resource?
• Stablecoins and blockchain are about: How is the payment settled, verified, and executed in a low-cost, real-time, programmable, cross-platform manner?

So, discussing Agentic Payment alongside crypto isn’t about Web3 trying to “ride the AI wave.” It’s more about how Agentic Payment reopens the fundamental “native payment” problem that the internet has long lacked.

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

If agents truly need a machine-readable, automatically executable payment protocol, why is the most discussed solution stablecoins? Why not BTC? ETH? Or traditional bank cards?

The key isn’t “crypto assets” per se, but what kind of payment assets agents need. If an agent is just holding assets long-term, it might care about price fluctuations, yields, and risks. But if an agent is paying to complete tasks, what it needs most isn’t speculative assets but a stable unit of account.

For example, a research agent calling a data API might cost $0.10. A coding agent invoking a model inference might cost $0.03. A marketing agent buying traffic data might cost $1. A procurement agent automatically comparing prices, ordering, and paying needs to keep each expenditure within a budget.

In these scenarios, agents aren’t trading or speculating—they’re completing tasks. So, they need to know: how much does this resource cost? Will this call exceed the budget? Is this payment authorized by the user? After delivery, can the cost be accurately recorded?

If the payment asset itself fluctuates wildly daily, budget management becomes complicated. Today’s $0.10 API call might become $0.12 or $0.08 tomorrow due to price swings. This might not matter for human trading, but for machine on-demand resource purchasing, it adds unnecessary complexity.

That’s why stablecoins are more natural in agentic payments—they provide a more realistic, stable unit of account for commercial transactions. Today, many API, SaaS, data, model, and cloud services are priced in USD. Using stablecoins as the payment asset allows budgets, prices, authorizations, and billing to be expressed in the same stable unit.

This might seem trivial but is crucial for agents. Because agents aren’t just “paying,” they’re also making judgments: is this call worth it? Is the cost within the budget? Does it need user confirmation? Can the task cost be logged? If something goes wrong, can it be explained: why was this money spent?

Therefore, agentic payments require a low-volatility, machine-readable, programmatically accessible payment asset. Stablecoins better meet this need than volatile assets like BTC or ETH.

The second value is that stablecoins are better suited for small, high-frequency, real-time settlements. As discussed with x402, this trend is evident. Coinbase’s definition of x402 is enabling instant, automated stablecoin payments via HTTP, allowing API and digital content services to charge human and machine clients without accounts, sessions, or complex authentication. The key change: payments can happen within a single API request, not just at checkout.

The process:

• Agent requests a resource.
• Service responds: 402 Payment Required.
• Agent assesses price and authorization.
• Agent pays with stablecoins.
• Service verifies and releases the resource.

This flow is naturally suited for small, high-frequency, on-demand calls—like data queries, model inferences, content unlocking, on-chain analysis, or chart generation. Tether WDK’s x402 document states clearly: AI agents need to pay programmatically for resources, and x402 enables discovering prices, signing payments, and obtaining resources in a single request-response cycle.

This isn’t the same context as bank cards. Bank cards are more suited for human checkout. Stablecoins are better for instant, machine-to-machine resource payments. That doesn’t mean bank cards will disappear. Stripe and Tempo’s Machine Payments Protocol support both paths: on-chain crypto payments and fiat payments via cards or wallets. Stripe’s official documentation states that merchants can accept agent payments via MPP, using stablecoins or cards and BNPL.

So, a more accurate view isn’t “stablecoins replacing bank cards,” but that bank cards are suited for existing merchant networks and checkout scenarios. Stablecoins are more suitable for open network, machine-initiated, on-demand payments.

The third value: stablecoins are inherently better for cross-platform and cross-border payments. Agents may operate across multiple platforms—calling US-based APIs, European model services, Asian content interfaces, on-chain analysis tools, and interacting with other agents. Relying on different national bank accounts, acquirers, local payment methods, and settlement cycles would fragment the entire task chain. Stablecoins are native to the internet—they can flow 24/7, across wallets, applications, and borders, and be directly handled by smart contracts or payment protocols. For humans, it might just be “faster,” but for agents, it’s more critical: their execution isn’t bound by banking hours or borders.

They shouldn’t be interrupted by weekends, cross-border issues, bank clearing windows, or merchant account systems. They need a settlement asset that’s always available, automatically callable, and verifiable.

This is why protocols like x402, Tether WDK’s support for x402, and explorations around USDT/Tether’s ecosystem (like t402) are heading in the same direction: turning stablecoin payments into web stack components that machines can call directly, rather than forcing agents into human-designed payment pages.

But caution is needed: stablecoins aren’t perfect.

Different stablecoins vary in reserve transparency, issuance, regulation, redemption, and on-chain liquidity. BIS’s 2025 Annual Economic Report criticizes stablecoins for shortcomings in key monetary standards like singleness, elasticity, and integrity, and warns against viewing them as complete replacements for modern monetary systems.

More accurately: stablecoins aren’t perfect money, but they are among the closest native internet settlement assets to meet agentic payment needs.

Their value isn’t in “decentralized narrative,” but in meeting several conditions: relatively stable prices, programmatic usability, cross-platform transferability, 24/7 settlement, and compatibility with HTTP-native payments, wallets, smart contracts, and on-chain audits.

This explains why, when resource invocation in open networks is discussed, stablecoins naturally appear. Agents don’t need a “credit card hand,” but a form of money that software can understand and use directly.

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

Of course, this language isn’t mature yet. It needs better compliance frameworks, more stable issuance mechanisms, clearer risk controls, improved wallet permissions, and integration with protocols like AP2, x402, MPP to reach large-scale agentic payment scenarios.

But the direction is clear: agents need stable units of value, instant settlement assets, machine-readable money, and cross-platform, cross-border, cross-service payment capabilities.

That’s why stablecoins are indispensable in agentic payments—not because all payments will turn crypto, but because when the transaction target shifts from “human consumer” to “software entity,” stablecoins make “money” the first part of the internet protocol.

But stablecoins only answer one question: what money does the agent use to pay? They haven’t answered another: after the agent spends in the open network, who authorized this money, where was it spent, was there overreach, was the service delivered? This leads us to blockchain.

4. Why blockchain: not just for on-chain, but to make agent actions verifiable

Even if agents need stablecoin payments, why must it be on blockchain? Can’t it be a centralized ledger? Can’t Stripe, Visa, banks, or a platform itself keep the records?

Of course. If the agent operates only within a closed platform—shopping on Amazon, calling services within a SaaS, or internal enterprise procurement—centralized ledgers suffice. The platform knows who the user is, who the agent is, what permissions it has, how much was spent, and whether services were delivered.

But the real value of agentic payments isn’t just about clicking a payment button in a closed environment. It’s about cross-platform, cross-service, cross-wallet, cross-country, and even cross-agent tasks. At this stage, the questions aren’t just “Can the money be paid?” but “Why was it paid? Who authorized it? Did the agent overreach? Was the service delivered? Who’s responsible if something goes wrong?”

These are the questions where blockchain truly adds value. Not because all transactions must be on-chain, or because on-chain is inherently better than banks. But because, as agents start executing tasks, calling services, and handling funds in open networks, every economic action needs a verifiable record.

Humans can tolerate opacity—if a service isn’t delivered, they can contact customer support; if procurement fails, they can review contracts, consult finance, check emails, or hold meetings; if a bank transaction is disputed, they can file disputes. These mechanisms are slow but long-standing.

Agents, however, often operate at higher frequency, smaller amounts, more service endpoints, and longer chains. Relying on manual post-hoc reconciliation, screenshots, emails, or customer service defeats automation. Agentic Payment needs a clearer responsibility chain.

For example, a user tasks an agent: “Spend no more than $100 this week, do a market analysis, only buy data, model calls, and charting services.” The agent requests a data API; the service returns a $0.20 fee. The agent checks the budget, pays, and the service releases data. The critical part isn’t which chain was used but whether we can answer afterward: what authorization was given? What was bought? Did it stay within budget? Was the service delivered? If the agent was tricked by prompt injection into buying something it shouldn’t, can we trace it?

This is why, when revisiting Bitcoin’s white paper in the context of agentic payments, it’s not about nostalgia. Satoshi Nakamoto’s core problem wasn’t “invent a tradable asset,” but “how to transfer digital cash without trusted third parties, verified and ordered by the network.” The white paper states clearly: transactions are hashed into a proof-of-work chain, forming an immutable record.

Agentic Payment’s challenge isn’t just double-spending; it’s about authorization, overreach, delivery, and responsibility. But they share a common point: once economic actions occur on an open network, verifiable transaction records become infrastructure, not just an afterthought.

This is the essence of blockchain. It’s not about making payments “more mystical,” but about turning some states hidden in platform databases into externally verifiable states. Ideally, payment records, authorizations, service access, refund conditions, and budget consumption can be more standardized and validated. For humans, it might just mean “more transparent accounting”; for agents, it’s the foundation of trust.

Because agents aren’t humans. They can’t justify actions with “I remember I thought this way.” They need an external, verifiable chain of evidence.

This is why AP2, x402, stablecoins, and blockchain are often discussed together, but they aren’t the same. AP2 isn’t a decentralized protocol or blockchain; it’s an open, payment-agnostic framework enabling users, merchants, and payment providers to confidently perform agent-led payments across different methods. The AP2 spec explicitly states that agents need a secure, simple way to obtain scoped permissions to act on behalf of users, with cryptographic signatures ensuring security.

More precisely, AP2 is an authorization and trust layer for agentic payments—defining user intent, scope, and responsibility. x402, L402, T402 are payment request layers—how services initiate payment requests when an agent asks for a resource. Stablecoins are settlement assets—what the agent pays with. Blockchain is a verifiable state layer—tracking transaction records, settlement status, and enabling external validation.

These layers aren’t identical but form a comprehensive infrastructure for true agentic payments. Without this, it risks being a disjointed mess: smart agents that can find services, compare prices, make decisions, but when it comes to payment, revert to human-like processes—register accounts, link cards, buy plans, reconcile bills, contact support. That’s not agentic payment; that’s just a more button-clicking browser assistant.

Of course, this isn’t utopia. Connecting agents directly to on-chain payments carries risks—disputes, freezes, reversals are harder. Once a transaction is on-chain, it’s often final. If an agent is attacked, over-authorized, or the service is not delivered, responsibility is murky.

Therefore, agentic payment isn’t just about giving agents a wallet and saying “spend freely.” It requires a comprehensive control system: limits, whitelists, blacklists, scope, risk levels, manual approvals, pause switches, audit logs. Small, low-risk, machine-native calls can be automated; large, high-risk, real-world commitments should still require human oversight.

In this sense, blockchain’s role isn’t to prove Web3 is “better” than traditional finance but to provide a verifiable foundation for agent actions. When AI agents spend in open networks, we need a way to verify that spending is authorized, that purchases are recorded, that actions are traceable, and responsibilities are assignable.

This is the real position of blockchain in this context. Not faith, not narrative, not “AI + Web3” forced together. It’s about when machines participate in economic activities, the existing account systems and platform databases may no longer suffice. We need a more open, standardized, machine-readable, verifiable layer of economic state, and blockchain at least points in this direction.

5. Not replacing bank cards, but the payment system starting to layer

So, in the end, I don’t believe agentic payments will simply lead to the conclusion: stablecoins replace bank cards, blockchain replaces traditional payment networks.

That judgment is too coarse and too easily challenged by reality. For a long time, bank cards, credit cards, Apple Pay, Visa, Mastercard, Stripe, PayPal will still exist, continuing to serve as the main entry points for many real-world payments. Human shopping, hotel booking, airline tickets, offline consumption, enterprise procurement—these won’t vanish just because agents appear.

Even in early agentic commerce, agents will likely first integrate with existing payment systems. Because the current merchant networks are mature, consumers already have cards and wallets, merchants have payment acceptance, banks and card organizations have established risk and dispute systems. For “AI helps me make a purchase,” sticking to existing rails is the most practical approach.

So, the question isn’t “Will cards disappear?”

The real question is: will agentic payments only stay at this level? If an agent is just helping click checkout, it can still use bank cards. But if agents start entering a more open task network—calling APIs, buying data, paying for models, settling compute, unlocking content, trading with other agents—they’ll need more than a smarter payment button. They’ll need a new payment protocol stack.

This is why I believe the future isn’t “bank cards vs stablecoins,” but a layered payment system.

In human commerce and mature merchant networks, bank cards, credit cards, wallets, and bank accounts will remain dominant. For scenarios like agents helping with shopping, booking, SaaS renewal, traditional rails will still be relevant. Agents just plug into existing flows, automating transactions for users.

But in API, data, model, compute, content, on-chain services, and agent-to-agent transactions—more machine-native environments—stablecoins and blockchain will be more natural. Because the transaction targets aren’t traditional merchants but digital resources; amounts are small, frequency high; service providers are across different platforms, countries, systems; and the entire process benefits from machine automation, instant payments, and verification.

In summary: bank cards solve payments for human consumption; stablecoins and blockchain are more about providing a native settlement language and verifiable environment for the machine economy.

Of course, stablecoins aren’t perfect yet. On-chain experience is still complex, wallets are not user-friendly enough, regulation is evolving, liquidity across chains is fragmented. More critically, letting agents directly control funds is risky. Without permission management, limit controls, risk protocols, manual review, and audit systems, agentic payments could easily turn into uncontrolled spending.

Therefore, agentic payment won’t be just about giving agents a wallet and saying “spend freely.” It’s a gradual evolution: first integrating into existing payment rails, helping automate checkout; then enabling finer-grained permissions—budgets, whitelists, scope, time limits, risk levels; then supporting machine-readable payment requests for API, data, models, and content; and eventually, stablecoins becoming the settlement asset in small, high-frequency, cross-platform, cross-border digital service calls.

From this perspective, agentic payment isn’t something a single company, chain, stablecoin, or protocol can do alone. It’s a reorganization of the entire payment infrastructure in response to AI agents as new economic actors.

In the past, payment systems primarily served humans and companies. In the future, they’ll also serve a new entity: authorized software agents.

They aren’t legal persons or traditional corporate accounts, but they can initiate requests, compare prices, invoke services, consume resources, trigger payments, and leave records. As such entities proliferate, the payment system must answer new questions: Who are they? Whose behalf do they act? What are their permissions? How much can they spend? What did they buy? Did they overreach? Who’s responsible if something goes wrong?

These aren’t questions a simple payment button can solve.

Returning to the initial question: will AI agents use bank cards?

Yes.

But they won’t only use bank cards.

Bank cards will continue to handle checkout. Stablecoins will start to handle native, small, instant, cross-platform payments. Blockchain will provide verifiable states and execution environments. Protocols like AP2, x402, L402, T402 will connect authorization, payment requests, and resource access.

This is what makes agentic payment most compelling. It’s not about giving AI an extra payment function. It’s about rethinking: when machines participate in economic activity, what kind of payment system does the internet need?