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 talking about 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 current financial and payment systems still sufficient?

In one panel I attended, someone directly raised a question: Is Web3 just riding the AI wave? I think not. Of course, there will be projects jumping on the hype. 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 simple overlapping concepts but are a redivision of labor.

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 unavoidable topic. But I initially had a simple question: why do discussions about Agentic Payment, or Agentic Commerce, seem to automatically assume they 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 the payment within limits and rules, behind the scenes it could be via bank card, virtual card, corporate account, or third-party wallet—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 actually 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 step of payment, like buying a ticket, booking a hotel, or 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, and they are used.

User authorizes once, agent executes within limits and rules. This is not hard to understand; essentially, it’s like smarter automatic deductions, 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 Agentic Commerce.

Stripe and Tempo’s Machine Payments Protocol exemplifies this well. 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 stages of agent payments, traditional payments and stablecoins are more likely to coexist rather than one immediately replacing the other. But this only solves 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 segments 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 create 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, requiring API access or purchasing API units; Trends API can be purchased separately but still operates on API units.

For an agent, this model isn’t natural. If an agent only occasionally needs to call traffic data, what it truly needs isn’t to register a SaaS account or buy a whole package of API units, but to make 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 still 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 wallet. It’s how, throughout the entire task chain, the machine 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 dispute resolution.

But Agent Economy faces a different set of problems: 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, without manual confirmation at each step, complete small, high-frequency, cross-platform payments? After payment, can the service provider immediately release resources? If the agent makes a mistake, exceeds authority, or gets attacked, who bears responsibility?

This is why Google, when developing AP2, didn’t focus on “which payment method” but on a more universal agent payment trust framework. Google describes AP2 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 signatures from 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, and risk rules can enable agents to transact within existing merchant systems.

Visa is also pushing in this direction. Its Intelligent Commerce and Trusted Agent Protocol essentially aim to recognize, trust, and authorize AI agents to act on behalf of consumers or enterprises within existing merchant networks. Visa’s description of the Trusted Agent Protocol states: AI agents will help users browse merchant sites, discover products, compare prices, and make choices, with the commercial journey starting even before checkout; in the past, 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, authorization, to final payment. But card networks are better at solving: how the agent enters the existing commerce flow and completes an authorized transaction. They are not inherently designed to handle: how an agent continuously initiates small payments across open networks for APIs, data, models, compute, content, or other agents.

So, bank cards aren’t useless. More precisely: they solve the checkout problem in agent commerce, but what agent economy needs is a more fundamental payment protocol.

This pushes the question to a higher 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 target is a traditional merchant, the agent can enter the existing checkout flow, paying with credit/debit cards, virtual cards, or wallets. But if the 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’s needed 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 determines 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 purchases, 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 for each data access, or go through a full human payment and procurement process for small cents or dimes. 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 an API key
• Call the 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 pricing APIs simultaneously.
• A developer agent might buy model inference, code review, or testing environments per use.
• A traffic analysis agent might just buy Semrush-like data for a single website, not a full SaaS package.

If each service requires accounts, subscriptions, API keys, plans, and manual approval, the agent’s execution ability 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, also based on HTTP 402 but combined with Bitcoin Lightning Network, macaroons (access credentials), and small-value payments. Lightning Labs defines L402 as a way to facilitate authentication and transactions for API endpoints, compute resources, etc., 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, but agents will.

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

Similarly, in the USDT/Tether ecosystem, there are explorations like Tether WDK’s x402 documentation emphasizing its importance for AI agents, because agents need programmatic resource payments; x402 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. It’s cautious to say it’s an “official Tether standard,” but rather that such protocols are emerging around USDT/Tether.

This reflects a significant trend: Agentic Payment isn’t just a product competition among companies but the formation of 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 a payment request, and how does the agent complete payment and receive the resource?
• Stablecoins and blockchain are about: What assets settle this payment, where is it verified, and how to achieve low-cost, real-time, programmable, cross-platform settlement?

So, discussing Agentic Payment alongside crypto isn’t about Web3 trying to “hype” AI. It’s more accurate to say that Agentic Payment reopens the long-unsolved “native payment” problem of the internet.

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? Why not ETH? Why not regular bank cards?

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

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.
An automated procurement agent comparing prices, ordering, and paying within a budget needs precise cost control per transaction.

In these scenarios, the agent isn’t trading or speculating; it’s completing a task. So, it needs 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, an API call costs $0.10; tomorrow, due to price swings, it might be $0.12 or $0.08. This might not matter for trading markets but complicates machine on-demand resource purchases.

That’s why stablecoins are more natural in agentic payments—they provide a more consistent, real-world-like unit of account. Today, many APIs, SaaS, data, model, and cloud services are priced in USD. If agents pay with USD-stablecoins, they can keep budgets, prices, authorizations, and billing in the same unit.

It sounds simple but is crucial for agents. Because agents aren’t just “paying,” they’re also making judgments: Is this call worth it? Is the budget enough? Do I need user confirmation? How to record task costs? And if something goes wrong, how to explain why this money was spent?

Therefore, agentic payment needs a low-volatility, machine-readable, directly callable payment asset. Stablecoins fit this need better than 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 to enable instant, automated stablecoin payments via HTTP, allowing API, digital content, and service providers to charge human and machine clients without accounts, sessions, or complex authentication. The key change is that payments can happen within a single API request, not just at checkout.

The process:

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

This flow is naturally suitable for small, high-frequency, on-demand calls—like data queries, model inferences, content unlocking, on-chain analysis, or chart generation. Tether WDK’s x402 documentation emphasizes that AI agents need to pay programmatically for resources, and x402 enables discovering prices, signing payments, and obtaining resources within 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 states that merchants can accept agent payments with both stablecoins and fiat methods.

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

The third value is that stablecoins are inherently better for cross-platform and cross-border transactions. Agents may operate across different platforms, countries, and systems—calling US data APIs, European model services, Asian content interfaces, on-chain analysis tools, and interacting with other agents. Relying on local bank accounts, acquirers, and settlement cycles at each step fragments the task chain. Stablecoins, as internet-native assets, can flow 24/7, across wallets, platforms, and applications, 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 need a settlement asset that’s always available, automatically callable, and verifiable.

This is why protocols like x402, Tether WDK’s support, and explorations 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 a word of caution: 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 they shouldn’t be seen as complete replacements for modern monetary systems.

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

Their value isn’t about “decentralization narrative,” but about 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 calls happen in open networks, stablecoins naturally appear. Agents don’t need a “credit card for machines,” 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, clearer risk controls, improved wallet permissions, and integration with protocols like AP2, x402, MPP to truly support large-scale agentic payments.

But the direction is clear: agents need stable price units, 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” more like an internet protocol component.

But stablecoins only answer one question: what money does the agent use? 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 it be Stripe, Visa, a bank, or a platform’s own accounting?

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

But the real value of agentic payments isn’t just about clicking a payment button within a closed system. 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 is responsible if something goes wrong?”

These are the questions where blockchain truly shines. Not because all transactions must be on-chain, nor because on-chain is inherently superior to banks, but because when agents start executing tasks, calling services, and handling funds in an open network, every economic action needs a verifiable record.

Humans can tolerate opacity: if a service isn’t delivered, they can contact support; if procurement goes wrong, 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 providers, and longer chains. Relying on manual post-hoc reconciliation, screenshots, emails, or customer support erodes the value of agentic payments. They need a clear responsibility chain.

For example, a user gives an agent a task: “Spend no more than $100 this week, help me with market analysis, only buy data, model calls, and chart generation services.” The agent requests a data API; the provider returns a $0.20 charge. The agent checks the budget, pays, and the provider releases data. The critical part isn’t which chain was used but whether we can answer: what authorization did the user give? What did the agent buy? 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 back?

This is why I believe that revisiting Bitcoin’s white paper when discussing agentic payments isn’t nostalgia. Satoshi Nakamoto’s core problem wasn’t “invent a tradable asset,” but “how to transfer electronic 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 payments aren’t exactly the same. It’s not just double-spending but also 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.

That’s the significance 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 protocols like AP2, x402, stablecoins, and blockchain are often discussed together—they aren’t the same thing. AP2 isn’t a decentralized protocol or blockchain; it’s an open, payment-agnostic framework that enables users, merchants, and payment providers to confidently perform agent-led payments across different methods. Its specification states that agents need a secure way to obtain scoped permissions, and the security depends on cryptographic signatures from involved parties.

More precisely, AP2 is an authorization and trust layer for agentic payments, defining user intent, scope, and responsibility boundaries. x402, L402, T402 are about payment request layers—how services initiate payment requests when an agent asks for a resource, and how the agent completes payment and gets the resource. Stablecoins are the settlement assets, and blockchain is the verifiable state layer—tracking transaction records, settlement status, and post-settlement verification.

These layers aren’t identical but form a comprehensive infrastructure for true agentic payments. Without this, it risks being just a fancy payment button for agents, not a trustworthy, verifiable, open system.

Of course, this isn’t without risks. On-chain payments aren’t risk-free; disputes, freezes, and reversals are harder. Once a transaction is on-chain, it’s often final. If an agent is attacked, over-privileged, or if a malicious site tricks it into paying, the consequences are serious.

Therefore, agentic payments aren’t about just giving agents a wallet and saying “go spend.” They require a full control system: limits, whitelists, blacklists, scope, risk levels, manual confirmation, pause switches, audit logs. Small, low-risk, machine-native calls can be automated; large, high-risk, real-world commitments should still involve human oversight.

In this sense, I see blockchain’s role in agentic payments as providing a verifiable foundation—not to make payments “more crypto,” but to ensure that when AI agents spend in open networks, their actions are authorized, recorded, traceable, and accountable.

This is the real position of blockchain in this context. Not faith, not narrative, not “AI + Web3” hype, but because as 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 points in this direction.

5. Not about replacing bank cards, but about layered payment systems

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’s too coarse and too easily contradicted by reality. For a long time, bank cards, credit cards, Apple Pay, Visa, Mastercard, Stripe, PayPal will still exist, handling a large portion of real-world consumer payments—buying on e-commerce sites, booking hotels, flights, offline shopping, enterprise procurement. These scenarios 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 acquiring, banks and card organizations have risk and dispute systems. For “AI helps me make a purchase,” sticking to existing rails is the most practical approach.

The question isn’t “Will cards disappear?”

The question is: will agentic payments only stay at this level? If an agent is just helping click checkout, it can keep using 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 need more than a smarter payment button. They need a new payment protocol stack.

That’s 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 still dominate. Agents will just help users automate existing flows—shopping, booking, SaaS renewal.

But in API, data, model, compute, content, on-chain services, and agent-to-agent scenarios—more machine-native—the combination of stablecoins and blockchain will be more natural. Because the target isn’t a traditional merchant but digital resources; transactions are small and frequent; service providers are across different platforms and countries; the entire process benefits from machine automation and verification.

In summary:

• Bank cards solve human payment at checkout.
• Stablecoins and blockchain are more about the settlement language and verifiable execution environment for the machine economy.

This doesn’t mean stablecoins and blockchain are ready today. On-chain experiences are still complex, wallets are not user-friendly enough, stablecoin regulation is evolving, and liquidity across chains is fragmented. More critically, giving agents direct control over funds is risky. Without permission management, limits, risk controls, manual review, and audit systems, agentic payments can easily turn into uncontrolled spending.

So, agentic payment isn’t just about giving agents a wallet and saying “go spend.” It’s a gradual evolution:

• First, integrate into existing payment rails for more automation.
• Then, enable finer-grained authorizations—budgets, whitelists, scope, time limits, risk levels.
• Next, support machine-readable payment requests for API, data, model, and content services.
• Finally, stablecoins become a settlement asset in small, high-frequency, cross-platform, cross-border digital resource calls.

From this perspective, agentic payment isn’t a product of a single company, chain, stablecoin, or protocol. It’s a reorganization of the entire payment infrastructure to accommodate 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, call services, consume resources, trigger payments, and leave records. As these entities proliferate, the payment system must answer new questions:

• Who are they?
• Who do they represent?
• What are they authorized to do?
• How much can they spend?
• What did they buy?
• Did they overreach?
• Who is 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 machine-native small, instant settlements; blockchain will provide verifiable states and execution environments; protocols like AP2, x402, L402, T402 will connect authorization, payment requests, and resource access.

This is the most important aspect of agentic payment. It’s not about making AI pay more “crypto,” but about rethinking what kind of payment system is needed when machines participate in economic activities.