As AI-native transactions transition from theory to reality, agentic commerce is causing a fundamental reevaluation of how digital payments and settlement infrastructure function.
Transitioning from Human-Centric Payments to AI-Native Rails
Between September 2025 and March 2026, the major players in global payments embraced AI-driven commerce. OpenAI and Stripe introduced the Agentic Commerce Protocol, while Google unveiled the Universal Commerce Protocol to over 30 retail and fintech partners.
During the same timeframe, Visa and Mastercard launched agent-focused payment frameworks. Coinbase progressed with its x402 standard, processing over 15 million transactions on Base. Additionally, Stripe and Tempo collaborated on the Machine Payments Protocol and presented it for IETF standardisation.
The timing was intentional. The payment infrastructure developed over the past three decades catered to humans interacting with browsers, filling out forms, and undergoing stepwise verification. AI agents, on the other hand, require programmatic interfaces, immediate authorization, and settlement capabilities that can handle transactions at fractions of a cent.
The existing infrastructure was not designed for this environment, and the industry acknowledges the mismatch. What is emerging is a two-layer architecture: an upper orchestration layer for discovery and initiation, and a lower settlement layer for value transfer. These layers will evolve separately, driven by different incentives.
Commercial Orchestration: How Agent Transactions are Facilitated
The orchestration layer defines how an agent discovers a service, manages a session, and initiates payment. Two distinct categories of use cases have emerged, and conflating them risks misunderstanding the market structure.
1.1 Agents Acting on Behalf of Consumers
For agents making purchases on behalf of humans, the primary challenge is not payment mechanics but access. Most e-commerce platforms are optimized for human interaction. However, an agent should not have to navigate product pages, interpret banners, or click “add to cart” buttons.
Merchants need structured, machine-readable endpoints. These are still scarce, limiting native agent interactions. The initial protocols in this segment come from OpenAI, Stripe, and Google, each with a unique approach to control and openness.
OpenAI and Stripe introduced the Agentic Commerce Protocol (ACP) in September 2025. The protocol focuses on secure payment delegation at checkout: a user’s payment method is stored in ChatGPT, and upon purchase confirmation, Stripe issues a Shared Payment Token (SPT), a single-use credential limited to the merchant and cart total.
This token is sent to the merchant via API, who retains full Merchant of Record status and processes the payment through existing Stripe infrastructure. Stripe’s SPT, currently the first live implementation of this delegation design, is compatible with OpenAI’s Delegated Payment Spec. Other PSPs can adopt the spec, making ACP open at the payment layer.
ChatGPT Instant Checkout was launched in September 2025 for U.S. users but was discontinued in March 2026 due to minimal conversions. OpenAI has since shifted focus to discovery: ChatGPT now showcases products and directs users to merchant sites or apps for checkout. ACP continues in a narrower role, powering dedicated in-ChatGPT apps for a select group of large retailers.
Merchants must apply for participation, and OpenAI determines which merchants appear and in what order. This curated model provides OpenAI with full control over the in-assistant experience while delegating settlement to third-party processors like Stripe.
Google’s Universal Commerce Protocol (UCP) represents a contrasting strategy. Announced by Sundar Pichai at the NRF Conference on January 11, 2026, UCP was developed with Shopify, Etsy, Wayfair, Target, and Walmart, and endorsed by over 20 partners including Adyen, American Express, Best Buy, Mastercard, Visa, Stripe, and The Home Depot.
UCP is specifically aligned with Google’s own agent payments protocol (AP2), the Agent2Agent (A2A) standard, and the Model Context Protocol (MCP). This interoperability push is a deliberate effort to dominate indexing and access. Google Pay serves as the default payment method, with PayPal set to be introduced as an option.
Technically, UCP operates through a capability manifest known as a UCP profile. Merchants publish a structured JSON document at /.well-known/ucp under their domain, detailing transport methods, checkout capabilities, and supported payment handlers. Agents directly read these manifests without intermediaries.
The architecture reflects Google’s strategic priorities. Google is not interested in mediating transactions, which could lead to margin pressure, liability, and regulatory scrutiny. Instead, it aims for complete visibility into the commerce landscape. UCP positions Gemini as the primary discovery layer for agent shopping while maintaining minimal visibility in settlement.
The contrast with ACP is stark. ACP is a curated environment where OpenAI acts as the gatekeeper, merchants must apply, and the flow is optimized within ChatGPT. UCP functions as an open catalog: merchants self-publish, any compatible agent can access profiles, and Google controls the discovery surface but not the payment itself.
Onboarding friction is lower, and potential reach is broader under UCP, but merchants receive less direct guidance. Essentially, ACP sacrifices openness for control, while UCP sacrifices control for index breadth and protocol-level standardization.
1.2 Agents Engaging with Other Agents
The second major category is structurally distinct: both sides of the transaction involve autonomous agents, with no human merchant in the mix. In this scenario, traditional trust mechanisms disappear, leaving few familiar safeguards.
There are no consumer protection regulations or card chargeback rights to rely on. Additionally, the parties may have never interacted before and yet must securely exchange value. This is where new Ethereum standards aim to make a difference.
Introduced on March 10, 2026 by the Ethereum Foundation‘s dAI team in collaboration with Virtuals Protocol, ERC-8183 structures each transaction as a three-party process. A Client requests work, a Provider delivers it, and an Evaluator certifies completion.
Funds are held in smart-contract escrow and released only upon certification by the Evaluator. Neither the Client nor the Provider need to assess each other’s trustworthiness; the contract enforces the outcome mechanically. In parallel, ERC-8004 establishes the identity layer that supports this mechanism.
Under ERC-8004, agents register on-chain and build a reputation score based on transaction history. This creates a portable credibility signal that persists across interactions. The design is theoretically sound, but scaling adoption remains a practical challenge.
Currently, most real-world usage is concentrated within the Virtuals Protocol platform. An orchestrator agent named Butler breaks down complex tasks into sub-jobs and directs them to specialized agents. The broader developer community has yet to engage on a comparable scale. ERC-8183 essentially aims to make this pattern open and permissionless.
One key observation follows naturally. Retail e-commerce can operate smoothly on card rails because human buyers remain active participants. In contrast, pure agent-to-agent commerce is likely to necessitate stablecoin settlement, as card fees become economically unviable for very small transactions and high frequencies.
Settlement Protocols: Handling the Movement of Funds
While orchestration determines what and where transactions occur, the settlement layer determines if value actually transfers. Five major protocols are currently competing in this space, each tailored to different use cases and economic constraints.
2.1 Delegated Payment Spec and SPT (Stripe)
Stripe’s Delegated Payment Spec extends card infrastructure rather than replacing it. When a customer authorizes an agent, Stripe generates an SPT that the agent retains. At the time of the transaction, the agent presents this time-limited, amount-capped token to the merchant.
Settlement then flows through Stripe’s existing card infrastructure. Behind the scenes, Stripe connects to Visa Intelligent Commerce and Mastercard Agent Pay, which issues agentic network tokens. Merchants experience a unified integration surface regardless of the card network used.
This model works well for standard retail purchases and many high-value agent-to-agent payments, where consumer protections like chargebacks remain desirable. However, it is less suitable for high-frequency, micro-value scenarios like machine-to-machine streaming payments.
In such cases, transaction amounts are often fractions of a cent, with volumes reaching thousands of operations per minute. The economics of card fees and authorization overhead quickly become unsustainable, even if technically feasible.
2.2 Visa Intelligent Commerce and Mastercard Agentic Tokens
Visa and Mastercard have revamped their tokenization layers to accommodate agent-initiated payments. Real card numbers are replaced with dynamic encrypted tokens containing metadata about the authorizing agent, from identity to spending limits and validity periods.
Permitted merchants are also specified within the token data, allowing precise controls on where agents can make payments. Settlement continues on traditional card networks, ensuring familiarity in integration paths and avoiding the need for entirely new infrastructure.
Both networks have progressed beyond the proof-of-concept stage. Mastercard executed the first fully identified agent transaction in September 2025, collaborating with Commonwealth Bank in Australia. Visa completed initial deployments across European markets via its Agentic Ready program.
The infrastructure appears capable, but a fee floor poses a structural constraint. Neither network can efficiently support sub-dollar payments at the density that future agent commerce may demand. Additionally, regulatory and compliance layers further restrict experimentation at the lower end of the transaction spectrum.
2.3 x402 (Coinbase)
x402 takes a different approach, starting from HTTP rather than cards. It builds on the HTTP status code 402 “Payment Required,” a feature in the HTTP specification since 1997 but underutilized. When an agent requests a paid resource, the server responds with a 402 containing payment parameters.
The agent provides authorization, and a Facilitator completes atomic on-chain settlement in USDC or other supported tokens, typically within about two seconds. There is no account setup, API key distribution, or KYC enforcement at the protocol level. Governance is vested in the x402 Foundation, established by Coinbase and Cloudflare.
By the close of 2025, x402 had processed over 100 million transactions across Base, Solana, and Polygon. However, analysts at Artemis, in a February 2026 report, estimated that much of this volume stemmed from internal activities and infrastructure testing rather than genuine commerce.
The protocol’s annualized payment volume stands at approximately $600 million, but concentration and quality of volume present challenges. Nevertheless, x402 faces no structural fee floor; it was explicitly designed for micropayments. The primary gap lies in adoption depth and real-world commerce density, not technical design.
2.4 Nanopayments (Circle)
Circle’s Nanopayments protocol aligns with x402, using HTTP 402 as the trigger while adding a batched settlement layer. Instead of settling each payment on-chain individually, buyers pre-fund a Circle Gateway account and sign EIP-3009 off-chain messages for each transaction.
Periodic batched settlement to the blockchain spreads gas costs across many payments, enabling transfers as small as $0.000001 to be economically viable. Gas is paid once at deposit rather than per payment, a critical optimization for ultra-high-frequency use cases.
The trade-off is that both parties must deposit into the Circle Gateway, creating a semi-closed network within the current structure. Nanopayments launched on testnet in March 2026 across 12 supported chains. Furthermore, the fee model presents advantages for intensive micro-payment flows if Circle can reduce onboarding friction.
2.5 MPP Machine Payments Protocol (Tempo and Stripe)
MPP, co-developed by Tempo and Stripe, represents the most ambitious of the five settlement designs. It utilizes HTTP 402 as the trigger and enables merchants and agents to select from multiple settlement rails within a unified framework.
Developers no longer need to hard-code either stablecoin or fiat infrastructure during development. Instead, the agent can dynamically decide at runtime which rail to use based on transaction requirements. Available options include Tempo stablecoin settlement, Stripe SPT payments, card network tokens, and Lightspark-powered Bitcoin Lightning payments.
Crucially, MPP introduces a “session” primitive akin to OAuth. An agent authorizes once and pre-funds an account, subsequently benefiting from real-time automated settlement for subsequent interactions without an on-chain transaction per payment.
The core spec has been submitted to the IETF as the reference implementation of HTTP 402. Upon its launch on March 18, 2026, the mainnet Payment Directory had already integrated over 100 services. However, adoption patterns are still in the early stages.
Stripe’s dual role is strategically significant. It collaborated on the protocol’s development and also appears as one of the payment options within it, capturing value whether developers opt for MPP for its flexibility or specifically for card capabilities.
Market Reality: Protocols Ahead of Deployment
3.1 Current Market Status
Despite the rapid launch of protocols in the past six months, commercial adoption remains limited. In terms of settlement, x402 leads in transaction volume, but actual daily commerce volume remains around $28,000. On the orchestration front, ACP’s Instant Checkout was discontinued due to minimal conversions.
New standards like ERC-8183 and MPP display a similar trend: the narrative surpasses actual implementation. The industry has reached a turning point where much of the protocol architecture is in place, yet widespread commercial application has yet to commence.
The primary hindrance is fragmentation at the orchestration layer. Merchants encounter multiple independent standards, each with unique SDKs, authentication processes, and compliance regulations. This raises integration costs and discourages experimentation.
Historically, such fragmentation is resolved by an aggregation layer that consolidates access across competing standards. However, this cycle may differ. Platforms with substantial agent traffic, including OpenAI, Google, and Microsoft, are motivated to maintain closed ecosystems rather than redirecting users elsewhere.
A similar trend is unfolding regionally. China, Southeast Asia, Korea, and Japan are each constructing closed-loop ecosystems anchored by super-apps or dominant platforms. The probable outcome is a series of parallel closed systems regionally rather than a single open global standard.
Consequently, the aggregation layer merchants seek is more likely to emerge from third-party infrastructure providers that directly serve merchants, not from platforms vying to control agent traffic. The incentives for openness and cross-platform reach are simply not aligned at the platform level.
3.2 Near-Term Opportunities
Distinct opportunity sets emerge from this landscape: settlement infrastructure and application-layer agent-to-agent services. The former appears to be the most immediate business opportunity, while the latter is underdeveloped but potentially transformative.
Regarding settlement, the contrast between fragmentation at orchestration and consolidation at the payment layer is stark. Every agent, regardless of the platform, ultimately faces the same challenge: how to efficiently pay counterparties across various rails.
Developers cannot feasibly maintain separate payment integrations for each platform where their agents operate. As platforms proliferate, the economic pressure intensifies toward a unified payment integration that abstracts underlying rail complexities.
This underscores a concrete need for a multi-rail agent wallet. Traditional card rails like SPT, Visa agentic tokens, and Mastercard agentic tokens will continue to support standard merchant transactions. Stablecoin rails like x402 and MPP session payments will underpin on-chain APIs and agent-to-agent transfers.
Both categories are operational and unlikely to converge onto a single rail in the near term. The onus of flexibility falls on the agent’s side, not the merchant’s. Merchants select the rails they support, a relatively stable and manageable decision.
Enterprises then equip their agents with stablecoins and delegated cards. The agent pays using the rail accepted by the counterparty. A wallet that seamlessly handles both, within a single integration, becomes the enabling layer for versatile agents navigating diverse ecosystems.
The value of this integration grows with each transaction and each new platform, establishing infrastructure depth that is challenging to displace once established. Furthermore, it positions the wallet provider as a neutral clearing layer between fragmented orchestration environments.
Agent-to-Agent Commerce: The Untapped Opportunity
The second opportunity lies in the application layer of agent-to-agent commerce. Presently, most agent-to-agent activity remains confined to crypto-centric workflows: agents querying on-chain data, engaging with DeFi protocols, and executing blockchain transactions.
The market has yet to expand into broad, real-world services. However, from a protocol perspective, agents could already commission tasks such as data analysis, content creation, legal research, or code review, remunerating on a per-call basis.
The missing piece is the developer ecosystem. Service providers have yet to package offerings as agent-payable APIs featuring fine-grained, usage-based pricing. This represents the true gap, and currently, it is one of the least contested areas in the stack.
This domain faces a cold-start obstacle. Identity systems like ERC-8004 require substantial transaction density to establish credible trust scores. Agents lacking transaction history lack reputational weight, limiting potential transaction partners.
Microsoft projects around 1.3 billion active AI agents by 2028. The current installed base is significantly smaller. The disparity will not naturally close; it is precisely what keeps immediate competition low and makes early positioning appealing.
