As AI-native transactions move from concept to implementation, agentic commerce is forcing a fundamental rethink of how digital payments and settlement infrastructure work.
From human-centric payments to AI-native rails
Between September 2025 and March 2026, every major player in global payments moved on AI-driven commerce. OpenAI and Stripe launched the Agentic Commerce Protocol, while Google unveiled the Universal Commerce Protocol to more than 30 retail and fintech partners.
Over the same period, Visa and Mastercard released agent-focused payment frameworks. Coinbase advanced its x402 standard, clearing more than 15 million transactions on Base. Moreover, Stripe and Tempo co-authored the Machine Payments Protocol and submitted it for IETF standardisation.
The timing is not accidental. Payment infrastructure of the past three decades was built for humans sitting at browsers, filling forms and passing stepwise verification. AI agents, however, need programmatic interfaces, near-instant authorisation and settlement that can handle transactions at fractions of a cent.
The existing stack was never designed for that environment, and the industry recognises the mismatch. What is emerging instead is a two-layer architecture: an upper orchestration layer for discovery and initiation, and a lower settlement layer for value transfer. These will evolve on separate tracks, driven by different incentives.
Commercial orchestration: how agent transactions come together
The orchestration layer defines how an agent finds a service, manages a session, and hands off to payment. Two distinct categories of use case have appeared, and conflating them risks misunderstanding the market structure.
1.1 Agents acting on behalf of consumers
For agents buying on behalf of humans, the primary problem today is not payment mechanics but access. Most e-commerce platforms are optimised for human navigation. However, an agent should not scroll product pages, interpret banners, or click an “add to cart” button.
Merchants instead need structured, machine-readable endpoints. These are still rare, which limits native agent interactions. The first wave of protocols in this segment comes from OpenAI, Stripe and Google, each with a different approach to control and openness.
OpenAI and Stripe launched the Agentic Commerce Protocol (ACP) in September 2025. The protocol centres 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 scoped to merchant and cart total.
This token is delivered to the merchant via API, who keeps full Merchant of Record status and processes payment through existing Stripe infrastructure. Stripe’s SPT is, as of this writing, the first live implementation of this delegation design and is compatible with OpenAI’s Delegated Payment Spec. Other PSPs can implement the spec, making ACP open at the payment layer.
ChatGPT Instant Checkout launched in September 2025 for U.S. users but was shut down in March 2026 after near-zero conversion. OpenAI has since shifted to discovery: ChatGPT now surfaces products and redirects users to merchant sites or apps for checkout. ACP survives in a narrower role, powering dedicated in-ChatGPT apps for a small set of large retailers.
Merchants must apply to participate, and OpenAI controls which appear and in what ranking. That said, this curated model gives OpenAI end-to-end control of 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 co-developed with Shopify, Etsy, Wayfair, Target, and Walmart, and endorsed by more than 20 partners including Adyen, American Express, Best Buy, Mastercard, Visa, Stripe, and The Home Depot.
UCP is explicitly 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 attempt to occupy the high ground for indexing and access. Google Pay serves as the default payment method, with PayPal announced as an upcoming 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, specifying transport methods, checkout capabilities and supported payment handlers. Agents read these manifests directly without intermediaries.
The architecture reflects Google’s strategic priorities. Google has little interest in brokering transactions, which would invite margin pressure, liability and regulatory scrutiny. Instead, it wants full visibility into the commerce web. UCP positions Gemini as the primary discovery layer for agent shopping while remaining mostly invisible at settlement.
The contrast with ACP is sharp. ACP is a curated environment where OpenAI acts as gatekeeper, merchants must apply, and the flow is optimised within ChatGPT. UCP functions as an open catalogue: merchants self-publish, any compatible agent can consume 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 hand-holding. In effect, ACP trades openness for control, while UCP trades control for index breadth and protocol-level standardisation.
1.2 Agents transacting with other agents
The second major category is structurally different: both sides of the transaction are autonomous agents, and no human merchant participates. In this environment, traditional trust anchors disappear, leaving few familiar protections.
There are no consumer protection statutes or card chargeback rights to rely on. Moreover, the parties may have never interacted before, and yet must exchange value safely. This is the problem that new Ethereum standards are attempting to address.
Proposed on March 10, 2026 by the Ethereum Foundation‘s dAI team together with Virtuals Protocol, ERC-8183 structures each transaction as a three-party job. A Client commissions work, a Provider delivers it, and an Evaluator certifies completion.
Funds are held in smart-contract escrow and released only when the Evaluator signs off. Neither Client nor Provider needs to assess the other’s trustworthiness; the contract enforces the outcome mechanically. In parallel, ERC-8004 defines the identity layer that underpins this mechanism.
Under ERC-8004, agents register on-chain and build a reputation score from transaction history. This creates a portable credibility signal that persists across interactions. The design is robust in theory; however, bootstrapping adoption at scale remains the practical bottleneck.
Today, most real usage is concentrated inside the Virtuals Protocol platform. An orchestrator agent called Butler decomposes complex tasks into sub-jobs and routes them to specialist agents. The broader developer community has not yet engaged at comparable scale. ERC-8183 is effectively an attempt to make this pattern open and permissionless.
One structural point follows directly. Retail e-commerce can comfortably operate on card rails, because human buyers remain in the loop. Pure agent-to-agent commerce, by contrast, is likely to require stablecoin settlement, as card fees become uneconomic at very small ticket sizes and high frequencies.
Settlement protocols: who actually moves the money
If orchestration decides what and where to transact, the settlement layer determines whether value actually moves. Five major protocols are now competing here, each tuned 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 authorises an agent, Stripe provisions an SPT that the agent stores. At transaction time, the agent presents this time-limited, amount-capped token to the merchant.
Settlement then runs through Stripe’s existing card stack. On the back end, Stripe connects to Visa Intelligent Commerce and Mastercard Agent Pay, which issues agentic network tokens. Merchants see a single integration surface regardless of which card network is underneath.
This model is well-suited to standard retail purchases and many high-value agent-to-agent payments, where chargebacks and other consumer protections remain desirable. However, it is a poor fit for high-frequency, micro-value patterns like machine-to-machine streaming payments.
In those scenarios, transaction amounts are often fractions of a cent, and volumes can reach thousands of operations per minute. The economics of card fees and authorisation overhead become quickly unsustainable, even if technically feasible.
2.2 Visa Intelligent Commerce and Mastercard agentic tokens
Both Visa and Mastercard have refactored their tokenisation layers to handle agent-initiated payments. Real card numbers are replaced with dynamic encrypted tokens that embed metadata about the authorising agent, from identity to spend limits and validity windows.
Permitted merchants are also specified within the token metadata, allowing fine-grained controls on where agents can pay. Settlement itself remains on legacy card rails, which keeps integration paths familiar and avoids entirely new infrastructure.
Both networks have moved well beyond proof-of-concept. Mastercard processed the first fully identified agent transaction in September 2025, working with Commonwealth Bank in Australia. Visa completed initial deployments across European markets via its Agentic Ready programme.
The infrastructure appears capable, but the fee floor is a structural limitation. Neither network can efficiently support sub-dollar payments at the density that future agent commerce may demand. Moreover, regulatory and compliance layers further constrain experimentation at the very small-ticket end of the spectrum.
2.3 x402 (Coinbase)
x402, by contrast, starts from HTTP rather than cards. It builds on status code 402 “Payment Required”, which has been in the HTTP spec since 1997 but barely used. When an agent requests a paid resource, the server replies with a 402 containing payment parameters.
The agent signs an authorisation, and a Facilitator completes atomic on-chain settlement in USDC or other supported tokens, typically within about two seconds. There is no account setup, no API key distribution and no KYC enforcement at the protocol level. Governance resides with the x402 Foundation, established by Coinbase and Cloudflare.
By the end of 2025, x402 had processed more than 100 million transactions across Base, Solana and Polygon. However, analysts at Artemis, writing in February 2026, estimated that much of this volume reflects self-dealing and infrastructure testing rather than genuine commerce.
The protocol’s annualised payment volume stands at around $600 million, but concentration and quality-of-volume issues are material. That said, x402 faces no structural fee floor; it was explicitly designed for micropayments. The key gap is depth of adoption and density of real-world commerce, not technical design.
2.4 Nanopayments (Circle)
Circle’s Nanopayments protocol is intentionally compatible with x402, using HTTP 402 as the trigger while adding a batched settlement layer. Rather than 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 cost across many payments, making transfers as small as $0.000001 economically viable. Gas is effectively paid once at deposit rather than per payment, a crucial optimisation for ultra-high-frequency use cases.
The trade-off is that both counterparties must deposit into Circle Gateway, creating a semi-closed network in the current architecture. Nanopayments launched on testnet in March 2026 across 12 supported chains. Moreover, the fee model is compelling for intensive micro-payment flows if Circle can reduce onboarding friction.
2.5 MPP Machine Payments Protocol (Tempo and Stripe)
MPP, co-authored by Tempo and Stripe, is the most ambitious of the five settlement designs. It uses HTTP 402 as the trigger and allows merchants and agents to choose among multiple settlement rails within a unified framework.
Developers no longer need to hard-wire either stablecoin or fiat infrastructure at build time. Instead, the agent can decide at runtime which rail to use based on transaction needs. Available options include Tempo stablecoin settlement, Stripe SPT payments, card network tokens, and Lightspark-powered Bitcoin Lightning payments.
Crucially, MPP introduces a “session” primitive similar to OAuth. An agent authorises once and pre-funds an account, then enjoys 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. At launch on March 18, 2026, the mainnet Payment Directory already integrated more than 100 services. However, adoption patterns are still in early stages.
Stripe’s dual role is strategically important. It co-authored the protocol and also appears as one of the payment options inside it, capturing value whether developers choose MPP primarily for flexibility or specifically for card capabilities.
Market reality: protocols ahead of deployment
3.1 Where the market stands
Despite rapid protocol launches over the past six months, commercial traction remains limited. On settlement, x402 leads in transaction count, but real daily commerce volume hovers near $28,000. On orchestration, ACP’s Instant Checkout was shuttered after negligible conversions.
New standards like ERC-8183 and MPP show a similar pattern: narrative outpaces actual deployment. The industry has reached an inflection point where much of the protocol architecture exists, yet scaled commercial application has not begun.
The central bottleneck is fragmentation at the orchestration layer. Merchants face multiple independent standards, each with distinct SDKs, authentication flows and compliance rules. However, this increases integration costs and discourages experimentation.
Historically, such fragmentation is resolved by an aggregation layer that unifies access across competing standards. This cycle may be different. Platforms with meaningful agent traffic, including OpenAI, Google and Microsoft, are incentivised to maintain closed surfaces rather than hand off users elsewhere.
This same logic is unfolding regionally. China, Southeast Asia, Korea and Japan are each developing closed-loop ecosystems anchored by super-apps or dominant platforms. The more likely outcome is a set of parallel regional closed systems rather than a single open global standard.
The aggregation layer merchants want is therefore more likely to come from third-party infrastructure providers that serve merchants directly, not from the platforms competing to own agent traffic. Incentives for openness and cross-platform reach simply do not align at the platform layer.
3.2 Where the near-term opportunities lie
Two distinct opportunity sets emerge from this landscape: settlement infrastructure and application-layer agent-to-agent services. The former looks like the most certain near-term business, while the latter is the least developed but potentially most transformative.
On settlement, fragmentation at orchestration contrasts sharply with consolidation pressure at the payment layer. Every agent, regardless of platform, ultimately faces the same problem: how to pay counterparties efficiently across rails.
Developers cannot realistically maintain separate payment integrations for every surface where their agents might operate. As platforms multiply, the economic pressure intensifies toward a single, unified payment integration that abstracts away underlying rail complexity.
This defines a concrete product requirement for a multi rail wallet for agents. Card rails such as SPT, Visa agentic tokens and Mastercard agentic tokens will continue to support traditional merchant commerce. Stablecoin rails like x402 and MPP session payments will anchor on-chain APIs and agent-to-agent transfers.
Both categories are already live and will not converge onto a single rail in the near term. The flexibility burden sits on the agent side, not the merchant side. Merchants pick which rails they support, a relatively stable, controllable decision.
Enterprises then provision their agents with stablecoins and delegated cards. The agent pays using whichever rail the counterparty accepts. A wallet that seamlessly handles both, within one integration, becomes the enabling layer for general-purpose agents operating across diverse ecosystems.
That integration value compounds with every transaction and every new platform, creating infrastructure depth that is hard to displace once established. Moreover, it positions the wallet provider as a neutral clearing layer between fragmented orchestration environments.
Agent-to-agent commerce: the underdeveloped opportunity
The second opportunity sits at the application layer of agent to agent commerce. Today, most A2A activity remains confined to crypto-native workflows: agents querying on-chain data, interacting with DeFi protocols and executing blockchain transactions.
The market has not yet expanded into broad, real-world services. Yet, from a protocol standpoint, agents could already commission tasks such as data analysis, content generation, legal research or code review, paying on a per-call basis.
The missing piece is the developer ecosystem. Service builders are not yet packaging offerings as agent-payable APIs with fine-grained, usage-based pricing. That is the real gap, and currently it is one of the least contested areas in the stack.
This space is constrained by a cold-start problem. Identity systems like ERC-8004 require significant transaction density to generate credible trust scores. Agents without history lack reputational weight, which limits counterparties willing to transact with them.
Microsoft has projected around 1.3 billion active AI agents by 2028. Today’s installed base is orders of magnitude smaller. The gap will not close automatically; it is precisely what keeps near-term competition low and makes early position-taking attractive.
The implications extend beyond payments into business models. The internet’s dominant models, advertising and subscriptions, assume human buyers. Agents are neither persuadable via ads nor in need of monthly access bundles; they pay for the outcome of specific calls.
In that context, http 402 payments create a different economic primitive. Providers sell results rather than access, charge heavy users in proportion to actual consumption, and stop subsidising light users or over-provisioning for rare peak loads.
Whether the A2A economy expands beyond crypto and whether HTTP 402 becomes a general pricing layer for software are effectively the same question. Both depend on agents becoming routine economic actors, transacting at scale against rich, per-call service directories.
Conclusion: a two-layer stack and the missing primitives
Looking ahead, agent commerce will continue to develop on two separate tracks. Consumer-facing agents that buy goods for humans will mostly rely on card rails, advancing at the pace of enterprise authorisation frameworks and user trust in new payment surfaces.
In parallel, the agentic commerce protocol stack for software-to-software payments is already technically viable on stablecoin rails. It now waits for the deployment of agents and services that require high-frequency, programmatic settlement at scale.
The likely end state is a two-layer stack evolving in parallel: orchestration governing discovery and initiation, and settlement governing value transfer. For builders, breadth of integration across both layers is the strategic priority.
Infrastructure that can route any agent transaction through whichever protocol a counterparty requires, while hiding this complexity from applications, will occupy a structurally strong position as the market scales. This layer will be invisible to end users but compounding in importance.
The trigger for commercial scale is not better protocols. It is the moment enterprises delegate spending authority to agents with auditable trails, budget controls and clear liability for misdirected purchases. When that threshold is crossed, two infrastructure positions become critical.
First, a multi-rail agent wallet that supports both stablecoin and card payments in a single integration. Second, an accessible per-call service directory that lets developers with no crypto background expose APIs to agent buyers. Both are open opportunities today, and both become essential once spending agents operate at scale.
