AI Agents Are Starting to Pay With Crypto: What x402, Visa TAP, and EIP-7702 Actually Solve

AI agents paying with crypto is not one technology. It is a stack of separate problems, and x402, Visa Trusted Agent Protocol, and EIP-7702 each solve a different layer of it.

AI agents are starting to pay with crypto, and x402, Visa Trusted Agent Protocol, and EIP-7702 are the three mechanisms most often named when people try to explain how. The problem is that most coverage blends them into one story, as if a single breakthrough now lets software spend money on its own. That blending is where the confusion starts. These are not competing answers to the same question. They sit at different layers of the same emerging stack, and each one leaves large parts of the problem unsolved.

At Blockready, we treat agentic payments the way we treat most frontier topics: as a set of mechanisms to separate clearly before deciding what is real. This article maps the stack so you can tell which layer a given claim is actually describing. For the broader argument about why machine payments and crypto rails keep coming up together, you can read the broader infrastructure thesis connecting AI and crypto. Here, the focus is narrower: what x402, Visa TAP, and EIP-7702 each handle, and what none of them handles.

Why AI agents break ordinary payment assumptions

Web payments were built around humans. A person logs in, holds an account, enters card details, and clicks a button. Card networks, subscriptions, API keys, and one-time passwords all assume a human is present somewhere in the loop. An autonomous agent breaks several of those assumptions at once. It may need to pay a service it has never used before, at machine speed, hundreds of times an hour, for amounts too small for a card fee to make sense.

That mismatch is what the three mechanisms in this article are reacting to. An agent that calls a paid data feed once per second cannot stop to create an account and pass a checkout flow each time. A merchant receiving a purchase request from software needs some way to tell a legitimate shopping agent apart from a scraper or a fraud script. And an agent that holds spending power needs that power to be limited, because a piece of automation with unlimited access to a wallet is a very different risk from a human who pauses before each purchase.

The three-layer stack at a glance

The clearest way to understand AI-agent payments is to stop asking "which protocol does this" and start asking "which layer does this." Payment settlement, agent trust, and wallet authorization are distinct problems, and the three mechanisms below map onto them almost one to one.

Understanding which layer you are looking at is not academic. It changes how you read every announcement in this space. A headline about Visa enabling agent checkout is describing the trust layer. A post about an agent paying for an API is describing the payment layer. A wallet update about session keys and spending caps is describing the authorization layer. When those get collapsed into one "AI agents pay with crypto now" story, readers end up believing the whole problem is solved when only one slice of it has a working mechanism.

x402: the payment request and settlement layer

x402 is an open payment protocol, first released by Coinbase in 2025, that revives the dormant HTTP 402 status code so software can pay for a web resource directly over HTTP. The status code itself is old. According to MDN's HTTP 402 reference, 402 Payment Required has sat reserved for future use for decades, with no single agreed convention for how to use it. x402's idea is to give that status code a job: a server can answer a request with a 402 and machine-readable payment instructions, and the client can pay and try again.

Coinbase's x402 documentation frames the protocol as a way for human and machine clients to pay without accounts, sessions, or API-key billing, with stablecoins as the common settlement asset. Cloudflare's x402 documentation adds an important detail about the facilitator, the optional service that verifies and settles payments. Cloudflare describes the facilitator as a component that abstracts the blockchain work and does not hold user funds. That distinction matters, because it means the facilitator is a convenience layer, not a custodian.

The protocol is also moving out of any single company's hands. The Linux Foundation launched the x402 Foundation on April 2, 2026, taking stewardship of the protocol Coinbase contributed, with a broad set of payments, cloud, and crypto participants signing on as members. You can confirm the governance details in the Linux Foundation announcement. Neutral governance does not prove adoption, but it does signal that x402 is being treated as shared infrastructure rather than a proprietary feature.

Where x402 fits most cleanly today is paid APIs, tools, datasets, and machine-to-machine services, the cases where a programmatic client needs to pay for one discrete thing without a human checkout. It settles in stablecoins rather than through a bank or card network, which is a different rail entirely. If that settlement distinction is new to you, it is worth understanding why stablecoins and bank-native digital money sit on different rails, because the choice of rail shapes speed, cost, reversibility, and who is liable when something goes wrong.

It is worth being precise about where this is likely to matter first. The most credible early use case for x402 is probably not an AI assistant filling a shopping cart at a consumer store. It is the quieter machine-to-machine economy: an agent paying a few cents to call a data feed, a model paying for compute, or one service paying another for a tool, hundreds of times an hour. Those are exactly the payments that traditional card fees and account-onboarding flows handle badly. Consumer checkout, by contrast, is where card networks already have trust, dispute resolution, and merchant relationships, which is part of why Visa is building a recognition layer there rather than a crypto settlement rail. Keeping that distinction in mind prevents a common error: assuming that because a payment protocol exists, it is competing for the same transactions that cards already serve well.

Visa Trusted Agent Protocol: the trusted-agent recognition layer

Visa Trusted Agent Protocol, introduced in October 2025, solves a different problem from x402: it helps a merchant decide whether an AI agent showing up at checkout is a legitimate, authorized buyer rather than a bot, scraper, or fraud script. It is not a crypto settlement protocol. It is an agent-recognition and trust framework built on existing web infrastructure, and treating it as "Visa adopting crypto" gets the mechanism wrong.

According to Visa's Trusted Agent Protocol documentation, the protocol uses agent-specific cryptographic signatures so a merchant can verify that a request comes from a recognized agent acting on a consumer's behalf. The signatures are bound to a specific merchant and operation and include timestamps and a unique identifier, so an old request cannot be captured and replayed elsewhere. In practical terms, TAP is Visa adapting card-network trust logic for a world where the buyer might be software, not a person clicking a button.

This is why TAP and x402 are easy to confuse but should not be merged. x402 answers "how does the agent pay." TAP answers "should the merchant trust this agent at all." Visa has said it is working on interoperability with x402, which only makes sense if you accept that the two operate at different layers. A payment rail still needs a trust signal, and a trust signal still needs a payment rail. Neither replaces the other.

EIP-7702: the wallet authorization layer

EIP-7702 is the layer people most often misname and least often understand. It is not a payment protocol and it is not an AI feature. It is an Ethereum account change that lets an ordinary externally owned account temporarily take on smart-contract behavior. It went live on Ethereum mainnet on May 7, 2025 as part of the Pectra upgrade, and the official specification is published in the EIP-7702 standard.

One naming point first. The correct term is EIP-7702. You may see it searched and written as ERC-7702, but that is not the official name of the proposal. The mechanism works by adding a new transaction type that lets an account sign an authorization pointing to deployed contract code, so the account keeps its address and key but gains capabilities such as batching multiple actions, sponsoring gas, and granting scoped, time-limited permissions.

For AI agents, that last part is the point. An agent that can spend money should never hold a raw seed phrase with unlimited access. It needs authority that is limited, auditable, and revocable, scoped by amount, time, counterparty, or purpose. EIP-7702 and smart-account patterns are part of how a wallet can offer that kind of controlled delegation. At Blockready, our Wallets module covers custodial versus non-custodial storage, seed phrases, private keys, and hardware-wallet security as separate learning steps, because the difference between holding keys and granting limited authority is exactly the distinction that agent wallets depend on.

EIP-7702 sits inside the larger account-abstraction story, and this article deliberately stays at the surface of it. If you want the full picture of how ERC-4337 and EIP-7702 work together in account abstraction, that companion article covers the architecture in depth. The key idea to carry forward here is narrow: EIP-7702 can give a wallet programmable controls, but it does not decide who the agent is, whether a merchant should accept the payment, or who is liable if the purchase was a mistake.

What none of these three actually solves

This is the part most coverage skips. Even if x402 settles the payment, TAP recognizes the agent, and EIP-7702 scopes the wallet, several hard problems remain entirely outside what these mechanisms define. Treating any one of them as the finished solution is how the gaps get hidden.

Identity and compliance do not disappear because the payer is software. When regulated entities such as exchanges, custodians, or stablecoin issuers sit anywhere in the flow, customer-identification and transfer-information obligations still apply, and a stablecoin transfer does not exempt a regulated party from them. "Autonomous" is not a synonym for "compliance-free." This is one of the most common misreadings of crypto payments in general, and it gets worse when an agent is added, because people assume software is somehow outside the rules that apply to the humans and businesses behind it.

User intent is a separate question from settlement, and it may be the hardest one. A signed payment proves that a transaction happened. It does not prove that a person or business actually authorized that specific purchase, at that price, from that seller. An agent can be correct about the mechanics of paying and still be wrong about whether it should have paid at all. That is why agent-trust frameworks and wallet-level spend policies exist alongside the payment rail rather than inside it. The payment protocol is not the place where authorization is decided.

Refunds and liability are different again. A confirmed on-chain payment is generally final, with no built-in chargeback, while card rails carry decades of dispute and liability rules. If an agent buys the wrong thing, the answer to "who reverses this" depends entirely on which rail was used and which intermediaries were involved. The facilitator in an x402 flow adds another assumption worth naming. It abstracts verification and settlement, and according to Cloudflare's documentation it does not hold funds, but a client still relies on it behaving correctly, and that reliance is a trust relationship the payment syntax alone does not guarantee.

Privacy is the last gap, and it is easy to miss. A payment request can carry descriptive metadata about what was bought, from where, and why, and that context can travel to a payment server or facilitator before any settlement happens, even when the on-chain transfer itself looks pseudonymous. Pseudonymous is not the same as private when the surrounding request describes the business in plain text.

The failure modes worth understanding

The risks in agent payments are not evenly distributed, and the most serious ones share a pattern: high severity combined with low user control after the mistake has already happened. The matrix below maps the failure modes that security researchers and protocol teams are actively examining.

Some of these are not hypothetical. Researchers have published preprint analyses of x402 identifying issues such as payment replay when a server does not record a payment identity before releasing a resource, and gaps in atomicity between payment and service delivery, in work like the Five Attacks on x402 preprint. A separate preprint on hardening x402 focuses on the privacy angle, noting that descriptive metadata fields travel in plaintext to the payment server and facilitator before any settlement happens. These are early-stage academic findings rather than confirmed, industry-wide incidents, so the honest framing is that researchers are actively probing these designs, not that the protocols have failed.

On the wallet side, the official Ethereum guidance is unusually direct about the risk. The Ethereum Foundation's EIP-7702 guidelines describe the delegated code as a security boundary, because code an account delegates to can act as that account, including approving and moving tokens. That is the technical reason why "an AI has a wallet" and "an AI can spend safely" are not the same statement.

That gap is also where a common and very human mistake lives. It is easy to assume that once an agent has a funded wallet, the safety problem is handled, the same way many people once assumed a smart wallet was automatically a safer wallet. It is not. Giving software spending power is the moment risk goes up, not down, unless the authority is deliberately constrained. Understanding that before any real money is involved is the same kind of foundational literacy that underpins the fundamentals of crypto wallet security, where the weakest link, not the strongest feature, usually decides the outcome.

What has shipped versus what is still early

A fair reading of this space separates what is documented and live from what is still pilot-stage or projected. The table below uses dated wording so it stays honest as things change.

Hype versus what is actually delivered

The gap between the headlines and the mechanisms is where most readers get misled. A few corrections are worth holding onto.

How to read the next AI-payment claim you see

Once you hold the stack in your head, evaluating new claims gets much easier. The first move is to separate the layer from the headline. When an agentic-payment announcement crosses your feed, decide whether it is really about settlement, agent trust, or wallet authorization, because most overstatements come from a claim about one layer being presented as if it solved all three. A demo where an agent buys something is impressive, but it usually proves that one path works in one setup, not that the surrounding problems of identity, intent, and liability are handled.

From there, a few more questions do most of the work. Ask whether a claim points to documentation, a pilot, a demo, or a forecast, because those are very different levels of evidence. Ask whether any adoption numbers are dated and sourced, since transaction counts and member lists in this space change quickly and stale figures get repeated long after they stop being true. Ask which entities are involved, because a flow that touches a regulated exchange or stablecoin issuer carries compliance weight that a pure peer-to-peer demo does not. And ask what the mechanism explicitly does not do, because in agentic payments the unsolved parts are usually more revealing than the working ones.

Our view, based on how we sequence this material in our curriculum, is that the most useful mental model here is restraint rather than excitement. We do not recommend treating any single one of these mechanisms as "the" answer to AI-agent payments, because each one is a partial answer that depends on the others and on unsolved problems like identity, liability, and privacy. The honest position in mid-2026 is that the plumbing is being built in the open, some of it works for narrow cases, and the harder questions of who is accountable when an agent pays wrongly are still being worked out. That is a more accurate, and more useful, picture than either hype or dismissal. It is also worth separating this topic cleanly from a related one: whether software should be allowed to spend is a different question from whether software can invest well, and AI trading is a separate risk question with its own failure modes. If you want to place all of this inside a structured progression, you can also see how wallets, stablecoins, and crypto infrastructure fit into a structured learning path rather than picking it up in fragments.

Frequently Asked Questions