Agentic payments are transactions that an AI agent authorizes and executes on a user’s behalf, without per-transaction human approvals. The agent holds its own wallet, carries its own scoped permissions, and can prove to a merchant that it is acting legitimately.

Picture this: an autonomous trading agent holds $50 of USDC on Arbitrum and owes a $50 invoice to a data provider that settles on Solana. No human signs off on the individual payment. The agent presents a signed Mandate proving the user authorized this category of spending, sends the value over an HTTP-native stablecoin rail called x402, and the funds cross chains automatically before the merchant ever checks the payment header. 

And it’s no longer a thought experiment. Coinbase’s x402 protocol is clearing roughly $600 million in annualized stablecoin volume, with USDC accounting for 99.8% of settlements. Stripe and Tempo co-developed the Machine Payments Protocol with Visa, standardizing continuous micropayment streams with a ‘sessions’ primitive. AWS, Coinbase, and Stripe have jointly shipped a managed payments product for agents — AWS Bedrock AgentCore Payments — with x402 as the default rail. Google donated its agent-payments protocol to the FIDO Alliance, the standards body behind passkeys. 

The rails are real; demand is picking up. Autonomous agentic actors will soon handle most digital payments and transactions. And those who position themselves early, acquiring a deep understanding of the agent-driven payments stack to begin with, will be the ones to capitalize fully on the value the agentic economy will create. 

That’s why, in this article, we describe the agentic payments stack end-to-end: the consent layer where Google’s AP2 protocol lives, the transfer layer where x402 and the Machine Payments Protocol settle in seconds, the account-abstraction substrate that lets agents hold funds safely, and LI.FI’s intent-based cross-chain settlement infrastructure that closes the loop when the agent’s stablecoins are not on the merchant’s chain. Let’s dive in. 

Key Takeaways

• Agentic payments are payments that an AI agent authorizes and executes without per-transaction human approval. Consent is granted once, upfront, as a cryptographically signed Mandate, then the agent operates within those rails until they expire or hit their cap. 

• The stack comprises four components: consent (AP2 Mandates), order (ACP/UCP), transfer (x402), and settlement (cross-chain routing). 

• Stablecoins, not cards, are the substrate for agent-initiated payments. Sub-cent pricing, 24x7 settlement, cross-border clearing without correspondent banks, and spending limits enforced in code via ERC-4337 and EIP-7702. Card networks, however, are responding with tokenized agent credentials of their own. 

• When the agent has funds on one chain while the merchant accepts payments on another, cross-chain settlement serves as the last mile. Intent-based routing is emerging as the go-to standard in this regard, and LI.FI Intents provides the tooling for it, with payment-grade defaults.  

What agentic payments are (and how they differ from card-not-present)

Laura Furlong from Very Good Security first defined agentic payments as online payments “initiated and executed autonomously by an AI agent,” typically without direct human intervention at checkout. 

This framing introduced a new category of payments that differs from typical card-not-present transactions — where neither the debit/credit card nor the cardholder is physically present at the point of payment, such as on eCommerce sites — in three main ways: 

1. Upfront consent, not per-transaction: The user signs a single cryptographic Mandate that scopes what, where, and for how long the agent can spend. The agent then operates inside those rails until the Mandate expires or hits its cap. This pushes the authorization decision into a signed artifact that merchants can verify asynchronously, unlike card-not-present transactions, which require the issuer’s fraud engine to make a real-time call against the card-on-file at each checkout. 

2. Verifiable agentic identity: Every agent has a unique identity (ideally onchain), which can be a wallet address, a smart-account contract, or, in card-network terms, a tokenized agent credential. Rather than pretending to be a human typing card numbers into a form, the agent is a distinct entity with its own keys that merchants can know and verify. 

3. Codified spending limits: Onchain smart accounts governed by ERC-4337 or EIP-7702 can encode spending limits as contract logic, with instructions like ‘never spend more than $100 per day’ or ‘only approve merchants on this allowlist.’ These are enforced at signing time and not pattern-matched after the fact, so agentic systems don’t need to rely on ad hoc fraud rules. 

That said, while Laura’s definition still holds as a baseline, it predates AP2 and x402, which have significantly expanded the operational horizon for agentic payments. And this expanded context is where discussions on this matter are happening today. 

The agent payment stack: From consent to settlement

Agentic transactions have four interlocking aspects, and currently, there’s a working standard or production-grade solution for each. Here’s how the complete stack looks:

• Consent: Google’s Agent Payments Protocol (AP2) issues the Mandate, i.e., the cryptographically signed ‘permission slip’ that proves a user authorized the agent to make this category of payment.

• Order: Stripe and OpenAI’s Agentic Commerce Protocol (ACP), or Shopify and Google’s Universal Commerce Protocol (UCP), carries the merchant-side message about what is being bought, at what price, and with what fulfillment metadata.

• Transfer/Wire: The A2A x402 extension (or even plain x402) transports the actual value. The agent signs a stablecoin transfer, and the merchant verifies it onchain. Alternatively, Stripe/Tempo’s Machine Payments Protocol (MPP) provides a rail-agnostic wire layer.

• Routing/Settlement: The agent might not have funds on the merchant’s chain, and LLMs aren’t typically competent at deciding what’s the best route to source and deliver liquidity across chains. This is where LI.FI’s intent-based routing infrastructure comes into play, enabling agentic payers to move value without getting mired in complexities or incurring higher gas, slippage costs than the transaction itself. 

In addition to these, the agent-led payments stack also integrates with the rest of the open-agent infrastructure. AP2, for instance, extends Anthropic’s Model Context Protocol (MCP), which allows agents to access ‘tools’, and Google's Agent2Agent (A2A) protocol, which enables agent-to-agent communication. 

LI.FI’s routing solution unlocks cross-chain market and liquidity access for agents, and it publishes machine-readable specs (llms.txt, openapi.yaml, ai-plugin.json) that autonomous agents can crawl to discover routing endpoints. 

Check out the Agent Integration section of our documentation for a broader overview of our agent stack and how to unlock its full capabilities.

AP2 & why agentic payments are not card transactions

On September 16, 2025, Google launched the Agent Payments Protocol (AP2), an open-source protocol developed with 60+ payments and technology companies. 

AP2’s central primitive is the Mandate — a tamper-proof, cryptographically signed record that proves that a user authorized a specific type of transaction. It also solves the trust and authentication gap by defining three distinct mandate types, implemented as W3C Verifiable Credentials: 

• Intent Mandate: Captures the user’s high-level instructions, constraints, and spending scope (e.g., “buy running shoes under $150, size 10”), representing pre-authorization. 

• Cart Mandate: Generated once the agent assembles a specific cart, and contains the finalized transaction details (items, price, taxes, shipping). The merchant must sign this to guarantee fulfillment. 

• Payment Mandate: Authorizes the actual transfer of funds, referencing the approved Cart Mandate, and carries the user’s signature, signaling to payment networks that the agent’s action is fully authorized.

That’s how AP2-based agentic transactions are structurally different than a card transaction. Whereas a card swipe says ‘this card was used here, now’, the AP2 Mandate chain commits to ‘this human pre-authorized this agent to spend up to X during P time frame, the merchant proposed the cart Y, and the human approved the transfer of Z.’ Thus, the verifier doesn’t have to trust the agent, but only the cryptographic record.

AP2 launched with a broad partner list of 60+ companies, including Adyen, American Express, Mastercard, PayPal, Coinbase, Etsy, Intuit, Revolut, Salesforce, and ServiceNow. This shows that AP2 isn’t Google-only infrastructure. Rather, it’s positioned as an extension of A2A and MCP, the two protocols the industry was already converging on. 

Then, on April 28, 2026, Google donated AP2 to the FIDO Alliance to anchor the protocol’s long-term governance. FIDO is the standards body that took WebAuthn from idea to ubiquity. Putting AP2 inside FIDO signals that Google wants AP2 and the consent layer of agentic payments to evolve through the same process that produced passkeys. 

Moreover, with A2A x402’s release, the much-needed bridge between AP2’s signed mandate and onchain settlements is now available. This is the rail agents use to move stablecoins to the merchant — the cleanest example of how the consent and transfer layers work together.

How crypto-native payment rails are winning with x402

Coinbase launched x402 in May 2025, reviving a status code defined in the original HTTP specification but never used: 402 Payment Required. It’s thrilling to think that Tim Berners-Lee somehow envisioned a future in which payments would be built into the protocol layer. That future is here. 

The x402 mechanism is fairly straightforward, yet profound. 

The client — a browser, a script, or an AI agent — requests a resource. The server responds with HTTP 402 and a payment-requirements header specifying how much, in what asset, and to which address. Then the client signs a stablecoin transfer that matches those requirements and re-requests it with a payment header attached. The server verifies the transfer onchain and returns the resource. No accounts, no sessions, no card forms, no OAuth flow.

Coinbase later co-founded the x402 Foundation with Cloudflare in September 2025, and Cloudflare enabled any developer running a serverless function on its edge to add a stablecoin payment gateway with a few lines of configuration. This is huge as it made the rail deployable without a dedicated payments team. 

x402 V2 shipped on December 11, 2025, with refined specs based on six months of real traffic. This iteration introduced broader support for chains beyond Base, dynamic payTo routing, and modernized payment headers. 

Since then, however, the transfer layer has also been significantly upgraded with the launch of the Machine Payments Protocol (MPP) in March 2026. Stripe and Tempo co-developed MPP, standardizing the HTTP 402 flow for both stablecoin and card payments. Unlike single-transaction flows, MPP introduces a ‘sessions’ primitive that allows agents to authorize a spending cap upfront and stream continuous micropayments. This enables pay-per-token or pay-per-kilobyte billing for onchain payments on Tempo or even card payments via Stripe’s Shared Payment Tokens.

At the time of writing, the AWS Bedrock AgentCore Payments preview is using x402 as its default rail, alongside Coinbase and Stripe Privy wallets. This hyperscaler choice is the loudest signal yet that crypto-native assets, particularly stablecoins, are the production answer for autonomous machine payments. More due to operational and structural alignment than due to ideological superiority. 

Card networks have interchange floors. Real-world economics pushes minimum viable transactions to around $0.10, which makes per-millisecond compute billing or per-data-point pricing structurally impossible. Whereas Circle’s nanopayments primitive supports transfers as small as $0.000001, six orders of magnitude below what a card network can profitably clear. 

Further, spending caps, merchant allowlists, time windows, multi-sig thresholds, and session keys that expire when a job completes — all of it is expressible in smart-account contract logic via ERC-4337 and EIP-7702. None of it is expressible in a card-on-file. 

For a more in-depth discussion on why crypto-native rails and stablecoins are the natural fit for agentic systems, read: Agentic Economy.

Account abstraction: The substrate that lets agents hold funds safely

Legacy banking and legal infrastructures have historically excluded billions of people worldwide, and now they’re doing the same with agents. If not for the lack of intent, definitely for the lack of agility. The frameworks haven’t evolved to let agents hold bank accounts, which has been a key deterrent to agentic payments over the years. 

Account abstraction fixed this to become a key enabler of autonomous agentic transactions as we see them today. With ‘smart accounts’, agents can hold funds onchain without the user needing to hand over a long-lived private key they can’t revoke. This is safer, one, but it’s also a step towards agents becoming more autonomous and more capable overall than mere LLMs holding the private keys to human-centric wallets. 

As for operational components, ERC-4337 has been live on the Ethereum mainnet since March 2023. It defined a programmable ‘smart account’ with contract-embedded validation logic. You can encode rules like ‘never spend more than $100 per day’ or ‘this delegated signing key expires in 24 hours’, which turns the wallet into a contract that decides whether to let a certain transaction through. 

Two years later, EIP-7702 arrived on the scene with Ethereum’s Pectra upgrade in May 2025. It’s functionally similar to ERC-4337, but operationally critical for agentic systems: any existing externally-owned account (EOA) can temporarily delegate its execution to a smart contract. Both the private and public (wallet address) keys remain the same, but the wallet gains smart account features for a specific ‘session’ to execute specific transactions. 

This was a breakthrough for autonomous agentic systems. Agent sessions could run on delegated smart-account profiles, giving users granular control over their rights and authority while keeping the main wallet and address secure. This safeguards against a rogue agent spending beyond its cap or paying merchants off the allowlist. Revoking delegation also takes a single onchain action, without additional key management overheads. 

EIP-7702 commanded over 11,000 authorizations within weeks of going live, with WhiteBIT, OKX, and MetaMask leading the early production deployments. And, more importantly, along with ERC-4337, it laid out the substrate that AP2’s Mandate model now assumes. 

While the Mandate handles agent authorization in protocol terms, account abstraction enforces authorization in execution terms. Smart accounts take hot wallets out of the agent’s runtime, without compromising on its ability to make payments. This turns agentic payments from ‘spicy auto-pay’ into a real, scalable authorization system. 

Solving trust, authorization, and liability with Know Your Agent (KYA)

Account abstraction is one element turning agents into payers. Agent-native identity frameworks is another. Because as autonomous agents scale, identity verification and dispute resolution present massive friction points. The need for alternatives to device fingerprints, KYC checks, or physical biometrics becomes imminent. 

The Know Your Agent (KYA) framework provides this alternative, cryptographically answering critical questions before transactions are processed: 

• Who is the agent? 

• Who is its registered operator? 

• What is the agent authorized to do? 

Several KYA and identity standards have emerged recently, as with everything else in the agentic ecosystem. Skyfire’s KYAPay uses identity-linked JSON Web Tokens (JWTs) that attach a verified agent identity directly to the transaction flow, allowing agents to log in, authenticate, and settle autonomously. ACK-ID, which comes with Catena Lab’s Agent Commerce Kit (ACK), establishes persistent, cryptographically secure agent identities using decentralized identifiers (DIDs) and verifiable credentials. 

Visa co-developed the Trusted Agent Protocol (TAP) with Cloudflare. Built on HTTP Message Signatures, TAP enables merchants to cryptographically verify agent legitimacy and authorize payment credentials at the edge. The Mastercard Agentic Tokens framework integrates agent operator identity directly into network-level tokens, allowing issuing banks to track AI-initiated transactions and enforce unique risk profiles.

Nevertheless, despite these solutions, liability remains the ultimate open challenge for agentic transactions and payments. Because existing consumer protection laws (such as Regulation E in the US) don’t apply squarely to cases where, say, an AI agent makes a ‘bad purchase’ due to prompt injection, a spoofed merchant, or an over-broad mandate. 

The hard question: Who is responsible? And as of mid-2026, payment networks have not established a formal ‘liability shift’ for agentic payments. Responsibility and liability allocations among the AI platform provider, the agent operator, the payment rail, and the merchant remain highly uncertain. 

Builders and merchants must proactively prepare for risks like key compromise, prompt-injection attacks that manipulate spending limits, and the lack of automated dispute/refund systems. Until these network-level governance rules mature, early adopters are relying on strict smart-contract spending limits and isolated escrow accounts.

Cross-chain settlements: The last mile

So far, we’ve discussed the components that make agentic payments possible. 

Now we look at the element that makes the UX smooth and viable against the backdrop of increasing liquidity and market fragmentation across hundreds of blockchains. 

Consider an agent on Arbitrum that holds USDC. The merchant settles on Solana, which x402 handles on the transfer side. But the agent’s USDC must reach Solana first, and the cross-chain leg determines whether the payment clears at the price the Mandate authorized. And this requires payment-grade routing, with the following characteristics: 

• Tight slippage: The default for a retail swap is around 0.5%. For a payments agent, 0.5% can blow past the Mandate’s cap. Any slippage higher than 0.1% risks the agent rejecting its own transaction at the merchant verifier because the delivered amount no longer matches the authorized amount. 

• Curated bridge selection: Generic routing can pick from 20+ bridges. Payment routing requires bridges that maintain the peg under load, which is especially important when an agent handles high-frequency, high-consistency flows. Some viable, new-age paths include Glacis, Mayan Swift, Mayan MCTP, and Celer. 

• Intent-based settlement (vs. bridge-picking): LLM-powered agents aren’t good at picking bridges. But they’re excellent at expressing their ‘intent’ or the outcome they want to achieve. Solvers compete to fill the intent with their own capital, collecting the spread once delivery is verified on the destination chain. The agent never has to reason about which bridge offers the best pricing or the fastest execution. 

• Hard-capped price impact: If routed trades push the price above a predefined threshold, the agent must reject the route and either reduce the fill size or take a different path. This matters particularly for stablecoin-to-stablecoin moves, where price impact must be nearly zero under normal conditions. 

• Escalating-backoff polling (vs. status tracking): Poll every 10 seconds for the first minute, then 30 seconds for the next three, then 60 seconds out to half an hour. Anything past 30 minutes is a timeout that needs supervisor review, not a silent failure.

This is the routing profile LI.FI’s stablecoin preset is built for. Setting ‘preset=stablecoin’ on a ‘/v1/quote’ call returns routes with 0.1% slippage, a 2% price-impact cap, curated mint-and-burn bridges, and intent settlement layered by default. 

Further, agents that need to submit intent orders write-side can use LI.FI’s Intents MCP Server, which is distinct from the read-only routing MCP. This completes the stack for builders working in the agentic landscape, where intents are rightly becoming the go-to design choice for cross-chain liquidity and market access. 

With AWS Bedrock AgentCore Payments scaling out of preview and AP2 settling into FIDO governance, the authorization and transfer layers are converging on stable specs. Over 30% of global eCommerce transaction value — roughly $17.5 trillion in Gross Merchandise Value (GMV) — is expected to flow through agentic systems by 2030. And intent-based settlements hold the key to fully capitalizing on this opportunity. 

LI.FI Intents is now live! Built alongside the Open Intents Framework, it shapes the future of cross-chain routing with an open, customizable, and agent-ready infrastructure. Check out the official documentation and start building on LI.FI.

Frequently Asked Questions (FAQs)

What are agentic payments?

Agentic payments are transactions authorized and executed by AI agents on behalf of users without per-transaction human approval. The user signs a one-time Mandate via protocols such as Google’s AP2, specifying what the agent can spend, with whom, and over what period. The agent then completes payments, typically via stablecoin rails such as Coinbase’s x402, until the Mandate’s limits are reached or it expires. 

What is the Agent Payments Protocol (AP2)?

AP2 is an open protocol launched by Google on September 16, 2025, with 60+ partners, including Adyen, American Express, Coinbase, Mastercard, and PayPal. Its central primitive is the Mandate, a cryptographically signed permission slip from the user that the agent presents at the time of payment. AP2 extends Anthropic’s MCP and Google’s A2A protocol, and in April 2026, Google donated it to the FIDO Alliance for long-term governance. 

What is the difference between AP2, x402, and ACP?

They sit at different layers of the same payment. AP2 (Google) is the consent layer that proves the user authorized the agent to spend. ACP (Stripe and OpenAI) is the order layer that carries the merchant-side message about what is being bought and at what price. x402 (Coinbase) is the transfer layer that handles the actual stablecoin transfer onchain. Underneath these, a cross-chain routing infrastructure (LI.FI) handles liquidity access when the agent’s assets and the merchant are on different chains. 

What are the three AP2 mandate types?

Under the AP2 protocol, spending authorization is divided into three distinct, cryptographically signed mandate types: 

1. Intent Mandate: The initial scope and constraints (e.g., ‘buy running shoes under $150’), pre-authorized by the user. 

2. Cart Mandate: The finalized merchant-signed checkout details (items, prices, tax), approved by the user (or the autonomous agent) once the cart is built. 

3. Payment Mandate: The cryptographic authorization referencing the Cart Mandate that triggers the transfer of funds.

What is Know Your Agent (KYA), and why is it needed?

KYA is an emerging identity framework designed for autonomous agents. Traditional payment fraud systems rely on human biometrics and device fingerprints. Because AI agents lack these and execute payments at machine speed, KYA protocols (such as Skyfire KYAPay, Catena Labs ACK-ID, and Visa TAP) supply a cryptographically verifiable agent identity, ensuring merchants can verify legitimacy before settling. 

Who is liable when an AI agent makes a wrong or fraudulent payment?

Liability remains the biggest unresolved challenge in agentic commerce as of mid-2026. Credit card networks have not implemented a formal ‘liability shift’ for agentic payments, so liability is disputed when an agent executes an unauthorized transaction due to prompt injection, a key compromise, or an overbroad mandate. Early builders are mitigating these risks by using strict smart-contract spending limits (ERC-4337/EIP-7702) and isolated wallets rather than open-ended billing agreements. 

What is account abstraction, and why do agents need it?

Account abstraction makes a wallet programmable. Validation logic lives in a contract rather than a single private key. ERC-4337 (live since March 1, 2023) defines a smart account that can encode rules such as daily caps or merchant allowlists, and EIP-7702 (live with Pectra on May 7, 2025) allows a normal wallet to temporarily delegate execution to such a contract. Agents need this so they can safely hold funds under constrained, revocable authority, and don’t need a long-lived hot key. Account abstraction is the substrate that enforces an AP2 Mandate at execution time. 

Do agentic payments use stablecoins?

Increasingly, yes. AWS Bedrock AgentCore Payments (preview, April 2026) uses x402 stablecoin rails as its default, built with Coinbase and Stripe. Card networks still handle most consumer volume, but stablecoins dominate cross-border, micropayment, and 24x7 agent flows because they settle onchain in seconds at fractions of a cent. 

How do agents pay across blockchains?

When an agent holds stablecoins on one chain (say, Arbitrum) while the merchant accepts payments on another (say, Solana), a cross-chain routing layer moves the value before x402 settles the transfer. Production agents use intent-based settlement, in which solvers compete to deliver value with payment-grade slippage. LI.FI Intents provides the infrastructure for cross-chain liquidity access and payment settlements, freeing agents from the overhead of choosing bridges, moving funds, and more. 

Building a payment agent that has to settle stablecoins across chains? Get an agent-ready routing profile by default: minimal slippage, single API call across 60+ chains, and above all, intent-based settlement. Build it on LI.FI. Start here: https://docs.li.fi/lifi-intents/introduction.