Table of Contents

1. Agentic Commerce vs. E-commerce: A Structural Shift in Transaction Models

2. Why Existing Payment Rails Break Under Agentic Workflows

3. Stablecoins as Execution Rails: A Scenario-Based Analysis

4. Limitations of Stablecoin Payment Infrastructure

5. Conclusion: Payment as Composition, Not Selection

News around “AI agents handling tasks on behalf of humans” has accelerated since last year. Scheduling meetings, drafting emails, and even writing code are no longer unfamiliar. Pushing the concept one step further, consider the moment a user instructs an agent, “Buy me running shoes at the lowest price within this week.” The agent scans dozens of marketplaces, applies coupons, checks inventory, and executes the payment autonomously. Human input is reduced to a single instruction. This is agentic commerce.

As this paradigm moves from concept to production, payment infrastructure faces a fundamentally different set of requirements. Agents do not click a payment button; they execute hundreds of transactions programmatically. The question is not whether payments can be executed, but whether existing rails can support this execution model without breaking. Can card networks and banking systems absorb this shift as they are, or is a new settlement layer required? Visa signaled its direction in April 2025 by announcing payment infrastructure dedicated to AI agents. Stripe followed in May by expanding stablecoin-based settlement, a blockchain-native payment mechanism pegged to fiat value, across 101 countries. Movement from global payment incumbents suggests that the answer is already being operationalized.

If legacy rails such as cards and bank transfers are evolving to support agent-based payments, the next question becomes clear: why are stablecoins still necessary? The answer lies not in surface-level capability, but in structural limitations. A proper evaluation requires understanding how far existing payment rails can extend, and at what point stablecoins become structurally more advantageous.

This article addresses that question in three parts: (1) how agentic commerce differs from traditional e-commerce, (2) how those differences translate into new requirements for payment rails, and (3) where domestic bank transfers, cards, SWIFT, and stablecoins each exhibit strengths and limitations across different segments.

1. Agentic Commerce vs. E-commerce: A Structural Shift in Transaction Models

Understanding agentic commerce as simply an “automated version” of e-commerce misses the core of the payment problem. The distinction is not about automation, but about the underlying economic structure in which transactions operate.

Traditional e-commerce aligns closely with an Attention Economy, where systems are designed to capture and monetize user attention. Platforms rely on advertisements, recommendations, and UI optimization to guide users toward conversion. Payment, in this context, functions as a single, terminal event that confirms the user’s final decision. Once the cart is reviewed, the price acknowledged, and the payment authorized, the transaction is complete.

Agentic commerce, by contrast, aligns with an Intention Economy, where user intent is executed directly. A user specifies a goal, such as “buy shoes at the lowest price,” and the agent handles search, comparison, payment, and settlement end-to-end. Payment is no longer an isolated checkpoint; it operates as one execution step within a broader workflow.

The implications surface across three dimensions.

First, transaction frequency and unit economics shift. In e-commerce, multiple product comparisons still result in a single payment event. In agentic commerce, a single objective triggers a sequence of API calls and service interactions, each potentially tied to a payment. A shoe-purchasing agent, for instance, may perform coupon queries, price discovery, inventory checks, and order execution; each step can incur costs in the range of $0.01 to $0.05.

Second, payment outcomes act as branching logic for subsequent execution. In traditional e-commerce, post-payment processes remain loosely coupled. Shipping and refunds are handled asynchronously, often with human intervention. In agentic commerce, payment results directly determine the next action. A failed payment triggers alternative sourcing; delays initiate retries; confirmation immediately activates downstream APIs such as fulfillment. Payment latency, in this structure, is not a UX issue but a control variable that can halt the entire workflow.

Third, payment itself becomes condition-aware by design. In traditional e-commerce, payment is executed first, with refunds or compensation handled through separate processes. A delayed shipment, for example, requires a manual refund request. In agentic commerce, conditional logic is embedded directly into the payment flow. Funds are released only if predefined conditions are met, such as delivery within a specified timeframe; otherwise, refunds are executed automatically. Execution occurs at the code level, not through manual intervention. Payment therefore shifts from a simple transfer of value to a mechanism coupled with conditional execution logic.

Taken together, these differences impose new requirements on payment rails. The baseline is no longer the ability to process a payment. What is required is repeatable execution at ultra-low cost, predictable finality within bounded timeframes, and native support for conditional settlement logic.

2. Why Existing Payment Rails Break Under Agentic Workflows

Payment rails in traditional e-commerce (Attention Economy) are designed to process discrete, one-off events. That design conflicts directly with the requirements of agentic commerce (Intention Economy): repetition, conditional execution, and immediate finality. The mismatch surfaces across three structural limitations.

2-1. Domestic Bank Transfers

For KRW-denominated domestic payments, bank transfers remain highly effective. Korea’s open banking infrastructure operates close to 24/7 outside of maintenance windows, with API fees at approximately 40–50 KRW per transaction for institutional users. In the context of simple domestic payments, stablecoins are not strictly necessary.

Limitations remain clear.

• Currency and geographic scope are constrained. Domestic KRW transactions are efficient; once payments extend to overseas merchants or global supply chains, they fall back into traditional cross-border payment networks. SWIFT is not always used directly, but even when routed through local collection networks, payment processors, or fintech intermediaries, the same structural constraints apply.
• Programmable settlement is not supported. Bank transfers execute simple instructions such as “transfer n KRW from Account A to Account B.” Conditional settlement logic, such as paying only if goods arrive within a specified timeframe and refunding otherwise, must be implemented at the application layer.

In summary, domestic bank transfers are sufficient for simple domestic payments, but they do not natively support programmable settlement.

2-2. Card Rails

Card rails are built around the separation of authorization, capture, and settlement. This structure is highly effective for consumer protection and universal acceptance. Card networks have also incrementally incorporated automation through API-based payments, recurring billing, and delegated authentication. Agent-driven payment flows are therefore technically feasible within the existing framework. The claim that cards cannot be used in agentic commerce is no longer accurate.

The constraint lies not in feasibility, but in economic efficiency.

• Fixed costs make micropayments structurally inefficient. When a card is used, the issuing bank authorizes the transaction, and settlement is processed through an acquiring bank. Merchant fees are derived from interchange rates between issuer and acquirer. Most agent-driven payments fall under Card Not Present (CNP) debit transactions, where higher fees apply due to increased fraud risk. Public benchmarks from Visa suggest rates around 1.65%. While not a universal rate, it is sufficient to illustrate the structural burden of fixed costs in low-value transactions.
• Dispute resolution introduces extended uncertainty. Chargebacks allow consumers to cancel or dispute transactions within a defined window, creating strong consumer protection but introducing uncertainty for merchants and automated systems. Card network rules typically allow disputes up to 120 days post-transaction. For agent-executed digital services, evidencing disputes is inherently difficult; in high-frequency, low-value contexts, the cost of handling a single chargeback can exceed the transaction value.
• Programmable settlement requires external orchestration. Card systems provide a “authorization → settlement” flow, but do not natively support embedded conditional logic. Conditions such as “release funds upon delivery within 7 days, otherwise refund” must be implemented by the platform or intermediary layers rather than the card network itself.

2-3. SWIFT: Deterministic Speed, Non-Deterministic Execution

Cross-border payments traditionally operate through the correspondent banking system. Intermediary banks bridge institutions that lack direct relationships, with the number of intermediaries varying by route. Within this framework, SWIFT does not move funds; it transmits payment instructions specifying the amount to be sent. Once the sending bank issues a message, it is routed through intermediary banks to the receiving bank. The receiving bank processes the deposit based on this instruction or reflects the funds later through internal settlement procedures.

Since the introduction of SWIFT gpi in 2017, both speed and traceability have improved materially. SWIFT indicates that a large share of gpi transactions settle within 30 minutes, with nearly all completed within 24 hours. The conventional view that cross-border transfers typically take several days is therefore overstated under current conditions.

From an agentic commerce perspective, the constraint is not average speed, but the cost and complexity of handling exceptions. Most SWIFT gpi transactions settle quickly; however, delays of more than two days can still occur when transactions are subject to compliance checks or foreign exchange controls, even along identical routes.

The issue is not the delay itself, but the requirement for the system to handle it. Agents must treat the entire process as executable logic. SWIFT-based payments introduce multiple intermediate states, unclear ownership of processing, and non-deterministic completion timing. Distinguishing between completed, pending, and rejected states becomes inherently unreliable, increasing the complexity of exception-handling logic. The result is higher development overhead and operational cost. What appears as a “slightly delayed transfer” to a human becomes, for an agent, a state uncertainty problem requiring multiple branching paths.

The correspondent model also introduces fixed fees and foreign exchange costs at each intermediary step. Total cost varies significantly by corridor and transaction size, and even small payments can become disproportionately expensive when multiple intermediaries are involved. Detailed cost comparisons are provided alongside card rails in Scenario C of Section 3.

3. Stablecoins as Execution Rails: A Scenario-Based Analysis

In agentic commerce (Intention Economy), payment is not a standalone action; it is one step within an execution flow. The basis for comparison therefore shifts. The relevant question is not whether a payment message is delivered, but whether funds reach a finalized state that allows the agent to proceed without delay.

This section compares payment rails under that framework. Card fees are modeled at 1.65% plus a fixed cost of $0.15 per transaction for CNP flows, with domestic cards benchmarked at a 1.45% preferential rate ceiling. SWIFT-based cross-border payments assume a $55 fixed fee across sending, intermediary, and receiving stages, along with a 1% FX cost. Stablecoin transactions are modeled at approximately $0.0005 per transaction on the Solana network.

These figures are not intended as absolute cost benchmarks; they are simplified assumptions designed to highlight structural differences. Actual costs and settlement behavior vary by corridor, transaction size, and participating institutions.

Scenario A. Micropayments: Fixed Cost vs. Viability

Section 2 established that the constraint in card rails is not feasibility, but economics. Micropayments expose this most clearly.

Consider an agent paying $0.05 per API call for inventory queries. The fixed fee per card transaction ($0.15) is three times the transaction value ($0.05). Fees exceed principal; the transaction is economically invalid. Card networks will not support this pricing structure.

Stablecoins change the equation. At approximately $0.0005 per transaction, fees represent ~1% of a $0.05 payment. A transaction that fails to exist on card rails becomes viable on-chain.

Scenario B. High-Frequency Settlement: Scaling Cost Divergence

The constraint is not limited to sub-fee transactions. Even when individual payments are viable, scale introduces structural inefficiency. Assume a model where a platform settles each $1 transaction in real time. 

Under Visa CNP pricing (1.65% + $0.15), the fee per transaction is $0.1665. At 100,000 transactions per day, total volume reaches $100,000, while fees reach $16,650. Effective cost: 16.65% of gross volume.

Under the same conditions, stablecoins incur ~$0.0005 per transaction, or ~$50 per day. Effective cost: 0.05% of volume.

The divergence is not incremental; it is structural: 16.65% vs 0.05%. The gap scales linearly with transaction frequency, collapsing the unit economics of real-time settlement at $1 transaction sizes. On card rails, this model is not inefficient; it is non-viable by design.

Both scenarios converge on the same conclusion. Cards are not unusable in agentic commerce. The constraint is more fundamental: using them renders the business model invalid at inception.

Scenario C. Cross-Border Settlement: Eliminating Execution Uncertainty

As established in Section 2, the core issue with SWIFT is not average speed, but the cost of handling exceptions; this is most clearly exposed in agent-executed cross-border B2B settlement.

Consider an agent executing a $10,000 cross-border supplier payment and triggering shipment immediately upon confirmation. Under SWIFT gpi, most transactions settle quickly. Delays still occur when transactions are flagged for compliance checks or FX controls; even identical routes can extend beyond two days.

To a human, this is a delay. To an agent, it is a blocking state.

The agent must encode the entire process in logic. SWIFT introduces multiple intermediate states, unclear ownership of processing, and non-deterministic settlement timing. Distinguishing between completed, pending, and rejected states becomes unreliable, increasing the complexity of branching logic and exception handling.

On-chain settlement removes this category of risk. Finality occurs within seconds to minutes, eliminating intermediate uncertainty states. The agent no longer needs to model or handle indeterminate execution windows. Cost improves as well, declining from approximately $155 (1.55%) under SWIFT to ~$30 (0.30%) including on/off-ramps. Cost reduction matters; however, the more critical shift is structural: exception states are removed from the agent’s execution flow.

4. Limitations of Stablecoin Payment Infrastructure

Section 3 established that stablecoins offer clear advantages in cost and speed where traditional rails fail. Structural advantage, however, does not imply a risk-free infrastructure.

First, issuer risk remains. Centralized stablecoins allow issuers to freeze addresses or restrict asset transfers in response to legal or regulatory actions. The Financial Action Task Force (FATF) explicitly frames its guidance on the assumption that issuers can implement functions such as freeze, burn, and withdraw at the protocol level.

Second, compliance burden shifts to the application layer. Card and banking rails embed AML/CFT, transaction monitoring, and regulatory reporting within the network and financial institutions. On-chain payments externalize these functions. Platforms must implement address screening, Travel Rule compliance, and policies for unhosted wallets directly, materially increasing system design complexity.

Third, consumer protection is not native. Card systems provide an integrated stack including authorization, settlement, chargebacks, and dispute resolution. Stablecoin payments, by design, execute asset transfers only. Refunds, escrow, and dispute handling are not part of the payment layer and must be implemented separately at the service or protocol level.

Fourth, infrastructure risk exists at the chain level. On-chain payments inherit the operational risks of blockchain networks, including congestion, downtime, bridge vulnerabilities, and smart contract exploits. For example, the economic finality of Ethereum is approximately 12.8 minutes under the current design. In practice, confirmation policy becomes a trade-off: earlier acceptance for latency, or stronger finality for risk reduction.

5. Conclusion: Payment as Composition, Not Selection

Sections 3 and 4 lead to a consistent conclusion. Stablecoins dominate in segments where traditional rails break down, but they do not replace the embedded guarantees of those rails—consumer protection, compliance integration, and dispute resolution remain external. The design question therefore shifts. The objective is not choosing between stablecoins and traditional rails, but segmenting workflows according to where each rail’s strengths are required.

The table below outlines recommended rails by transaction type and their corresponding rationale.

The compositional model is already materializing in production systems. x402 defines a micropayment layer where agents pay for API calls in stablecoins at execution time. Stripe is extending its API abstraction layer, historically built around cards and bank rails, to incorporate stablecoin-based payment and settlement, enabling multi-rail orchestration within a unified interface.

In agentic commerce, the core problem is not selecting a payment method. The objective is to design a payment architecture that allows agents to execute without interruption. As on-chain infrastructure evolves toward embedding compliance primitives, the baseline for that architecture will continue to shift.