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, cannot 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 comes back to the same question: when AI is no longer just generating content, but begins to execute tasks, call services, make decisions, and even handle fund flows, are the existing 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 riding the hype. But if we only understand 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 such as finance, trade, wealth management, supply chain, and logistics. When AI begins to act, 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 important topic. But I initially had a simple question: why do discussions about Agentic Payment or Agentic Commerce seem to assume it must be tied to crypto, stablecoins, or blockchain?

Can AI agents use bank cards? Can they use credit cards? Can 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 using bank cards, virtual cards, corporate accounts, or third-party wallets. This doesn’t seem unreasonable.

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 payment step—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 not fundamentally different. They can be used, and there’s no inherent obstacle.

User authorizes once, agent executes within limits and rules. This is not hard to understand; it’s essentially smarter automatic deductions, corporate virtual cards, travel cards, or automated procurement systems.

Therefore, traditional players like Visa, Mastercard, and Stripe will not 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 as well as card, 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 one part of the checkout process.

The premise of checkout is 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 arises in another scenario: Agents no longer just enter an existing shopping cart but continuously call 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 involve 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.” For example, Semrush’s API system is more like account, package, and API units. Each API request consumes a certain number of API units, and users need API access or purchase 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.”

Thus, the core issue isn’t whether the last step can be deducted from a wallet. It’s how, throughout 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 the Agent Economy faces a different set of questions: Why does this agent have the authority to spend this money? How does the service provider confirm it’s not a malicious bot but a genuine user extension? Can an agent complete small, high-frequency, cross-platform payments without manual confirmation? Can the service provider immediately release resources after payment? If the agent makes a mistake, exceeds authority, or gets attacked, who is responsible?

This is why Google’s AP2 didn’t focus on “which payment method” but on a more general agent payment trust framework. Google describes AP2 as a payment-agnostic framework that allows users, merchants, and payment providers to complete agent-led payments with more confidence 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.

Therefore, the first question of Agentic Payment isn’t “Where does the money come from?” but “Why does the agent have the authority to spend it?”

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 advancing along this path. Its Intelligent Commerce and Trusted Agent Protocol 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 that AI agents will help users browse merchant sites, discover products, compare prices, and make choices—long before checkout; but these automated visits are often blocked as bots by merchants, CDNs, or bot mitigation services.

This indicates that traditional payment networks also see the same problem: 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 an 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 APIs, data, models, compute, content, and other agents in an open network.

So, bank cards aren’t useless. More precisely: bank cards solve the checkout problem in agent 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, and 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 machine-understandable payment process: the agent requests a resource. The service responds: this resource requires payment, what’s the price, what’s the payment address, and which 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 as an external system: register accounts, link bank cards, connect to payment gateways, buy packages, manage API keys, reconcile monthly.

This is tolerable for humans. People can register, log in, bind 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 small, cents or dime-level calls. That’s why protocols like x402 emerged.

x402 reactivates the long-standing but rarely used HTTP 402 Payment Required status code. 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 returns the API, content, or digital service.

Coinbase’s definition of x402 is straightforward: it’s an open protocol for real-time, automatic 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, but that x402 embeds payment into the request-response cycle of the internet.

Previously:

• Register account.
• Purchase package.
• Obtain API key.
• Call service.
• Reconcile monthly.

Now, with x402:

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

This is crucial for agentic payments because agents often perform many small, real-time, on-demand service calls, not just a few large purchases.

Examples:

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

If each service requires accounts, subscriptions, API keys, and manual approval, agent execution is hampered by payment and procurement bottlenecks. So, x402’s significance 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, combining HTTP 402 with Bitcoin Lightning Network, macaroons, and small-value payments. Lightning Labs describes L402 as facilitating API endpoint and compute resource authentication and transactions, enabling services to charge API endpoints and making it easier for AI agents to participate.

L402 shows that this isn’t a new invention; earlier efforts tried to combine 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.

The emergence of AI agents makes HTTP-native payment protocols suddenly meaningful.

Similarly, in the USDT/Tether ecosystem, protocols like x402 are emerging. Tether WDK’s x402 documentation states that x402 is important for AI agents because they need programmatic resource payments; it makes payments a first-class citizen in 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.

This indicates a trend: Agentic Payment isn’t just a product from a single company but is forming a new protocol stack.

• AP2 is more about answering: Why is the agent authorized to pay?
• Protocols like x402, L402, T402 are about answering: When an agent requests a digital resource, how does the service initiate a payment request, and how does the agent complete payment and access the resource?
• Stablecoins and blockchain are about answering: What assets settle this payment, where is it verified, and how to do so efficiently, in real-time, and cross-platform?

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

Information can flow natively online, but value cannot—yet. The rise of agents is pushing the internet to fill this gap.

That’s why protocols like x402, L402, and T402 are worth watching. They aren’t just about “letting AI pay with crypto,” but about defining a new interaction model: machines request resources, understand prices, verify authorization, complete payments, and receive services.

If bank cards solve the checkout problem, these protocols address how machines initiate and complete payments. Once you consider this, stablecoins and blockchain are no longer just payment tools but become the underlying settlement language and execution environment for agentic payments.

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.

For example:

• A research agent calling a data API might spend $0.10 per call.
• A coding agent invoking a model inference might spend $0.03.
• A marketing agent buying traffic data might spend $1.
• An procurement agent automatically comparing prices, ordering, and paying needs to control each expenditure within a budget.

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

If the payment asset itself fluctuates wildly daily, budget management becomes complicated. Today, an API call might cost $0.10, but tomorrow, due to price swings, it could be $0.12 or $0.08. For human traders, this might be manageable, but for machines on demand, it adds unnecessary complexity.

This is why stablecoins naturally fit into agentic payments—they provide a more realistic, predictable unit of account.

The first value of stablecoins is offering a more practical, business-aligned unit of measure. Today, many API, SaaS, data, model, and cloud services are priced in USD. If agents buy these services on-demand, using USD stablecoins allows them to keep budgets, prices, authorizations, and billing in the same unit.

This might seem trivial, but it’s 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 do I record costs? And if something goes wrong, how do I explain why this money was spent?

Therefore, agentic payments require a low-volatility, machine-readable, programmatically accessible payment asset. Stablecoins fit this need better 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 to enable instant, automated stablecoin payments via HTTP, allowing API and digital content services to charge both humans and machines without accounts, sessions, or complex authentication. Payments can happen within a single API request.

For example:

• An agent requests a resource.
• The service responds with 402 Payment Required.
• The agent assesses price and authorization.
• The agent pays with stablecoins.
• The service verifies and releases the resource.

This process 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 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 differs from the bank card context. Bank cards are more suitable for human merchant checkout. Stablecoins are better for instant, machine-to-machine resource payments. This doesn’t mean bank cards will disappear; protocols like Stripe’s Machine Payments Protocol support both paths: on-chain crypto payments and fiat payments via cards or wallets.

4. Why stablecoins are also ideal for cross-platform and cross-border payments

Agents may operate across multiple platforms. An agent might call US-based data APIs, European model services, Asian content interfaces, and on-chain analysis tools, then transact with another agent. If each layer depends on different national banking accounts, acquirers, local payment methods, and settlement cycles, the entire task chain fragments. But stablecoins are native internet assets—they can flow 24/7, across platforms, wallets, and applications, and be directly handled by smart contracts or payment protocols. For humans, this might just mean faster settlement; for agents, it’s more significant. Their execution isn’t limited by banking hours, weekends, cross-border delays, or settlement windows.

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 like t402 are heading in the same direction: turning stablecoin payments into web stack components that machines can directly invoke, rather than forcing agents into human-designed payment pages.

However, stablecoins are not without issues.

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 native internet settlement assets to meet agentic payment needs.

Their value isn’t about “decentralization narrative,” but about meeting several conditions:

• Price stability
• Programmatic accessibility
• Cross-platform transferability
• 24/7 settlement
• Compatibility with HTTP-native payments, wallets, smart contracts, and on-chain audits

This explains why, when resource calling in open networks is discussed, stablecoins naturally appear. Agents don’t need a “credit card hand,” but a software-understandable, usable form of money.

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, and MPP to reach large-scale agentic payment scenarios.

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.

This is why stablecoins are indispensable in agentic payments—not because all payments will turn crypto, but because, as transactions shift from “human consumers” to “software entities,” stablecoins make money more like an internet protocol component.

Yet, stablecoins only answer one question: What money does the agent use to pay? They don’t answer the other: After the agent spends in the open network, who authorized this, where did the money go, was there overreach, and was the service delivered? That’s where blockchain comes in.

5. Why blockchain is needed: not for on-chain, but for verifiable agent actions

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 keep the books?

Sure. If an agent operates only within a closed platform—shopping on Amazon, calling services within a SaaS, or doing procurement inside a single enterprise—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, and who is responsible if something goes wrong?”

These are the questions where blockchain’s value truly lies. Not because all transactions must be on-chain, nor because on-chain is inherently better than 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 contact customer support; if procurement fails, they check contracts or emails; if a bank transaction is wrong, they dispute it. 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 support would destroy the point of automation. Therefore, agents need a clear responsibility chain.

For example, a user tasks an agent: “Spend no more than $100 this week to do market analysis, only buying data, model calls, and charting services.” The agent requests a data API; the service responds: “This query costs $0.20.” 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:

• What authorization did the user give?
• What exactly did the agent buy?
• Did the payment stay within budget?
• Was the service delivered?
• If the agent was tricked or overstepped, can we trace back?

This is why revisiting Bitcoin’s white paper isn’t about nostalgia. Satoshi Nakamoto’s core problem wasn’t “invent a tradable asset,” but “how to transfer digital cash without trusted third parties, with network verification, ordering, and recording.” The white paper states that transactions are hashed into a proof-of-work chain, creating an immutable record.

Agentic payments aren’t exactly the same—they involve authorization, overreach, delivery, and responsibility. But they share a key point: once economic actions happen on an open network, verifiable transaction records become infrastructure, not just an afterthought.

That’s the real significance of blockchain. It’s not about making payments “more mystical,” but about turning some state—previously hidden in platform databases—into externally verifiable data. Ideally, payment records, authorizations, service access, refunds, and budgets can be standardized and validated. For humans, this might mean “clearer books”; 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 evidence chain.

This is why protocols like AP2, x402, stablecoins, and blockchain are often discussed together. But they aren’t the same:

• AP2 is an authorization and trust framework for agent payments, not a blockchain protocol.
• x402, L402, T402 are payment request protocols—how services initiate payments when an agent requests a resource.
• Stablecoins are settlement assets—what money is used.
• Blockchain is the verifiable state layer—records of transactions, settlement status, and post-facto validation.

These layers aren’t identical but form a comprehensive infrastructure for agentic payments. Without this, you risk a scenario where agents are smart, decision-making, and capable of service discovery, but still rely on traditional, opaque, manual payment flows: register, bind card, buy, reconcile, dispute.

In essence, the future of agentic payments involves a gradual evolution:

• First, integrate into existing payment systems for more automated checkout.
• Then, enable finer-grained authorizations—budgets, whitelists, scope, time limits, risk controls.
• Next, support machine-readable payment requests for API, data, model, and content purchases.
• Finally, stablecoins become the native settlement medium for small, high-frequency, cross-platform, cross-border digital resource calls.

From this perspective, agentic payment isn’t a product from a single company or protocol but a restructuring of the entire payment ecosystem to accommodate AI agents as new economic actors.

Historically, payment systems served humans and companies. In the future, they’ll also serve software agents—not legal persons or traditional corporate accounts, but entities that initiate requests, compare prices, call services, consume resources, trigger payments, and record transactions. When such entities proliferate, the system must answer:

• 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.

So, 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 a verifiable state and execution environment. Protocols like AP2, x402, L402, and T402 will connect authorization, payment requests, and resource access.

This is the most important insight about agentic payments: it’s not about making AI do more crypto payments. It’s about rethinking what kind of payment system is needed when machines participate in economic activities.