Introduction
When two hyperscalers ship the same payment primitive at the edge of their networks within weeks of each other, the interesting question is not which product wins. It is what the underlying protocol assumes, and who ends up sitting in the middle when the traffic starts flowing.
That is the position x402 occupies as of mid-2026. The protocol repurposes the long-dormant HTTP 402 status code — reserved in HTTP/1.1 in 1997 and never standardized for real use — into a machine-to-machine payment handshake settled primarily in USDC on Base and Solana. Coinbase authored it, contributed it to the Linux Foundation as the x402 Foundation in April 2026, and continues to operate the only production facilitator that every major deployment currently depends on. AWS CloudFront now enforces x402 at the edge as a generally available feature. Cloudflare’s Monetization Gateway is on a waitlist. Anthropic, Circle, Stripe and 20+ other members sit on the foundation.
Meanwhile the card networks have not been idle. Visa announced a strategic collaboration with OpenAI on 10 June 2026 to embed tokenized Visa credentials into agent-driven commerce. Google donated its Agent Payments Protocol (AP2) to the FIDO Alliance and, together with Mastercard, contributed a tamper-proof audit-log standard called Verifiable Intent. Two payment tracks are now clearly visible: one that settles in stablecoins at the HTTP layer, and one that authorizes agents on top of existing card rails.
We think the more useful framing is not “who wins” but where each stack’s trust assumptions sit, what breaks first as volume grows, and whether the two tracks converge, stratify, or displace each other. What follows is a mechanism-level walkthrough of x402, an honest account of its centralization and settlement problems, and a comparison against the card-network answer.
Background: what “agentic payments” actually means
Before the protocol details, it is worth naming the problem. An agentic payment is a transaction initiated by software acting on behalf of a user, without a human at the checkout page and often without a fixed merchant relationship established in advance. An LLM-powered research agent that pays per API call for a data feed. A crawler that pays a publisher for the right to ingest a page. A code assistant that provisions a cloud resource on demand.
Traditional payment stacks assume a human clicking, an account provisioned ahead of time, an API key issued out-of-band, or a subscription. Agents break all four assumptions. They arrive without accounts, without pre-registered payment methods, without patience for a checkout flow, and often with very low per-transaction values where card interchange (~1.5–3%) is prohibitive.
The traffic mix has already shifted. Cloudflare reported that AI training accounted for 52% of its crawler traffic as of June 2026, up from 22% in spring 2025. The publisher-side ad and subscription economy was not designed for readers that never see an ad and never sign up. That is the demand-side pressure behind x402.
Two design choices define the space:
- Where does authorization live? In a user’s wallet (x402), or in a card-network policy layer with spending limits, merchant category controls, and approval rules (Visa Intelligent Commerce, AP2)?
- Where does settlement happen? On a public blockchain per request, batched off-chain and settled later, or across existing card and bank rails?
x402 initially chose wallet-held authorization and per-request on-chain settlement in USDC. It is now proposing a deferred scheme that relaxes the second choice. The card-network stacks chose network-held authorization with existing rails. The trade-offs cascade from there.
The x402 flow, hop by hop
The core protocol is deliberately spare. As documented in Cloudflare’s launch post and Coinbase’s developer documentation, an x402 payment resolves in five steps:
- Request. A client — typically an agent with an embedded wallet — issues an ordinary HTTP request to a resource URL.
- 402 response. The server responds with HTTP 402 and a JSON payload describing acceptable payment schemes, accepted networks (e.g. Base, Polygon, Arbitrum, World, Solana), accepted assets (USDC, EURC via EIP-3009, or arbitrary ERC-20s via Permit2), the price, and the recipient address.
- Retry with payment authorization. The client re-issues the request with an
X-PAYMENTheader carrying a signed payment authorization — for EIP-3009, this is atransferWithAuthorizationsignature that lets a third party pull the specified amount from the client’s wallet. - Facilitator verification and settlement. The server forwards the authorization to a facilitator, which verifies the signature, checks the client’s on-chain balance, and submits the transfer to the target chain. In every documented production deployment, this facilitator is Coinbase’s CDP.
- Resource delivery. On confirmation, the server returns the resource with an
X-PAYMENT-RESPONSEheader carrying the settlement receipt.
Each hop has a distinct trust assumption, and it is worth naming them precisely.
Where the trust actually sits
The client wallet is the root of custody. Whoever holds the signing key can drain it up to the balance. For an autonomous agent, this key must live somewhere accessible to the agent runtime — a fundamentally weaker security posture than a user-held hardware key. Wallet-level spending limits (via smart-contract wallets or session keys) are the primary defense, but the design and enforcement of those limits is not part of x402 itself; it is delegated to the wallet stack.
The facilitator is trusted to verify signatures honestly, to submit the transaction to the correct chain within a reasonable window, and to report settlement truthfully to both sides. It is not trusted with custody — the EIP-3009 signature is scoped to a single transfer amount and recipient — but it is trusted with liveness and with the accuracy of its report to the merchant. If the facilitator lies about settlement status, the merchant can independently verify on-chain, but only after the fact.
The chain provides settlement finality. Base and Solana both offer sub-second block times and effective finality within seconds for USDC-denominated amounts small enough that reorg risk is negligible. This is materially different from Bitcoin-Lightning-era micropayment schemes.
The server is trusted to actually deliver the resource once payment settles. There is no on-chain enforcement of delivery, and — critically — no chargeback or refund path if the resource turns out to be junk. USDC transfers are irreversible by default.
What happens when the facilitator is unavailable
None of the documented deployments describe a fallback path. If Coinbase’s CDP facilitator returns errors, both the AWS CloudFront and Cloudflare Monetization Gateway integrations lose their ability to verify payment. The protocol specification allows any facilitator to exist, but the operational reality in mid-2026 is that only one does at production scale. We return to this below because it is the sharpest structural risk in the stack.
The facilitator problem
The x402 specification is open. Anyone can, in principle, stand up a facilitator. The Coinbase CDP facilitator publishes its interface, supports Base, Polygon, Arbitrum, World, and Solana, and prices at 1,000 transactions per month free with $0.001 per transaction thereafter. Sellers do not need to run blockchain infrastructure — the facilitator abstracts it.
In practice, across every deployment documented in the source material — AWS CloudFront, Cloudflare’s Monetization Gateway, and the Coinbase-hosted SDK integrations — the facilitator in production is Coinbase’s. No independent facilitator is documented as operational. The reasons are not mysterious:
- Balance sheet. A facilitator carries settlement risk in the window between signature verification and on-chain confirmation. Small operators struggle to price this risk.
- Chain coverage. Supporting five chains at low latency requires nodes, indexers, and monitoring across each.
- Roadmap features. Optional KYC attestations and geographic restrictions — items on Coinbase’s stated roadmap — are exactly the features that regulated buyers will require, and building them credibly requires legal infrastructure that most crypto teams do not have.
- Integration lock-in. Once AWS and Cloudflare validated against a single facilitator, the switching cost for a merchant to migrate is nontrivial, even if the interface is standard.
The consequence is that a protocol marketed as permissionless HTTP-level payments has, at the plumbing layer, exactly one commercial gatekeeper. That gatekeeper can adjust pricing, impose compliance conditions, restrict geographies, and — under legal pressure — deplatform specific merchants or wallets. This is not a hypothetical: Coinbase already operates under a US regulatory regime that could impose exactly these controls.
The Linux Foundation governance model is intended to prevent proprietary capture of the specification. It does not prevent operational concentration in the facilitator market. Those are different problems. The specification being open matters less than whether a second facilitator with meaningful traffic actually emerges. As of mid-2026, none is documented.
Deferred settlement: the enterprise-viable path
Cloudflare’s September 2025 launch post described a variant it calls the deferred payment scheme. It is worth walking through carefully because it changes the trust model materially and is arguably the more consequential proposal in the specification.
In the immediate scheme, every HTTP request that clears a paywall triggers an on-chain transfer. At Base or Solana costs this is defensible for medium-value transactions, but at Cloudflare’s reported volume of over one billion HTTP 402 responses per day against bot and crawler traffic, per-request settlement is prohibitively wasteful — and pointless if the same buyer will make a thousand requests to the same publisher in an hour.
The deferred scheme separates the cryptographic handshake from settlement. Instead of an EIP-3009 signature per request, the client presents an HTTP Message Signature using a JWK public key, establishing identity. The server allows the request. Settlement is aggregated — daily, weekly, or per subscription — and can happen off-chain entirely, including via credit card. Cloudflare’s pay-per-crawl private beta uses exactly this: HTTP signature per request, end-of-day credit card settlement.
Two things are true about this at once. It solves the fee-economics and throughput problems that would otherwise cap x402 at genuinely high-value calls. And it partly dissolves the protocol’s original crypto-native settlement thesis. If the settlement layer is credit cards batched end-of-day, x402 is no longer competing with card rails on economics — it is competing on the HTTP-native identity and authorization surface, with card rails doing the actual money movement.
The deferred scheme also introduces new trust assumptions. The server now extends credit to the buyer between the signed request and settlement. In the immediate scheme, the merchant knew settlement was final within seconds. In the deferred scheme, the merchant relies on the identity behind the HTTP signature being both solvent and non-repudiating. That is a different risk model, closer to a corporate net-30 relationship than to a stablecoin payment.
The specification is careful to note this is a proposal, not a ratified feature, and there is no security audit of the HTTP Message Signature construction referenced in the source material. It is likely, but not certain, that this is the scheme most enterprises actually adopt.
The competing stacks
x402 is not the only proposal, and the alternatives are not superficial. The card networks have converged on a different architecture that preserves their existing rails while adding an agent-authorization layer above them.
Visa Intelligent Commerce and the OpenAI collaboration
Visa’s 10 June 2026 announcement with OpenAI positions Visa as the tokenization, network, and risk layer, with OpenAI providing the agent interface. Transactions use tokenized Visa credentials with real-time authorization and fraud monitoring. Spending limits, merchant category controls, and required approvals are configured per user — the same primitives that Visa has offered on commercial cards for years, now exposed as constraints an agent must operate within.
The technical architecture is not disclosed in the press release. What is disclosed is the value proposition: trust, fraud liability, chargeback rights, and regulatory settled-ness. None of these are things x402 currently offers. Visa is not competing on cost or programmability. It is competing on the entire operational apparatus that surrounds a card payment — the parts of “payments” that are not the transfer itself.
AP2, FIDO, and Verifiable Intent
Google’s approach with AP2 is different again. By donating AP2 to the FIDO Alliance, Google is trying to establish it as a platform-agnostic authentication and authorization standard for agent-initiated payments — governed by an alliance whose existing mandate (WebAuthn, passkeys) already covers the identity layer that regulated finance recognizes. The AP2 v0.2 release introduced the concept of Human Not Present payments, where agents execute transactions autonomously against pre-authorized user instructions.
The companion standard, Verifiable Intent, is a tamper-proof audit log of user-authorized agent actions, co-developed with Mastercard and also donated to FIDO. This is the piece x402 currently lacks: a cryptographically enforceable record of what the user actually authorized the agent to do, which any downstream party — merchant, network, regulator, court — can inspect to resolve disputes.
Notably, AP2 is described as compatible with existing payment rails, not a replacement. It is a policy and audit layer that can sit above cards, bank transfers, or in principle stablecoin transfers. Whether AP2 and x402 stratify (AP2 as authorization, x402 as settlement) or compete (AP2 with its own settlement) is not clarified in the source material.
Mastercard Agent Pay exists in the topic angle but is not documented technically in our sources. We flag this as a gap rather than guess at its architecture.
The honest comparison
| Dimension | x402 (immediate) | x402 (deferred) | Visa Intelligent Commerce | AP2 + FIDO |
|---|---|---|---|---|
| Settlement rail | USDC on-chain | Off-chain, incl. cards | Visa card rails | Rail-agnostic |
| Per-transaction cost | ~fraction of a cent | Amortized | Card interchange | Depends on rail |
| Fraud liability | Undefined | Undefined | Card network model | Not specified |
| Refunds/chargebacks | None | None | Existing card rights | Depends on rail |
| Mandate authorization | Wallet-level | Wallet-level | Network policy layer | Verifiable Intent log |
| Regulatory posture | Emerging | Emerging | Settled | Settled (via rail) |
| Governance | Linux Foundation | Linux Foundation | Proprietary | FIDO Alliance |
The false-equivalence trap here is treating these as directly substitutable. They are not. x402 excels at machine-to-machine calls where the buyer is definitely a bot, the resource is definitely digital, and the value is definitely small. Card-network stacks excel where fraud, refunds, and regulatory clarity dominate the buyer’s risk calculus. The interesting empirical question over the next 12–24 months is whether the middle collapses toward one side or splits cleanly along use case.
Where the system breaks first
Assume x402 volume continues to grow. Coinbase reports 169 million payments, 590,000 buyers, and 100,000 sellers in the protocol’s first year — figures that are unaudited self-reports and should be treated as directional rather than defensible. The annualized dollar-volume estimate that has circulated (~$600M) does not appear in our sourced material and we decline to quote it as fact. Coinbase has not clarified whether a “payment” includes retries, deferred-scheme signed commitments, or only settled on-chain transfers, which makes the top-line figure difficult to compare against any card-network baseline.
Even taking the growth at face value, several failure modes are visible.
Facilitator centralization
The most immediate. Both hyperscaler deployments funnel to Coinbase’s facilitator. If it degrades, the paywalls fail open (traffic passes through unpaid) or fail closed (traffic is refused) — neither is desirable at edge scale. Beyond availability, pricing power is unconstrained. The current $0.001-per-transaction rate is attractive against card interchange but there is no contractual protection against upward revisions once dependency is entrenched.
Mandate fraud and the human-not-present problem
x402’s authorization model relies on the wallet enforcing spending limits. If an agent runtime is compromised — via prompt injection, supply-chain attack on the model, or a bug in the agent framework — it can execute any payment the wallet’s limits allow. The wallet cannot distinguish a legitimate agent action from a hijacked one, because both are signed by the same key.
AP2’s Verifiable Intent is the direct answer to this: a cryptographic log of what the user authorized, verifiable independently of the agent’s runtime state. x402 has no equivalent. Whether wallet-level session keys and smart-contract spending policies are sufficient without an audit log is an open question, and one that regulated enterprises are likely to answer conservatively.
VAT, invoicing, and tax jurisdiction
Neither AWS nor Cloudflare has addressed how an anonymous stablecoin payment from an agent generates a compliant EU VAT invoice. Under EU rules, the seller must identify the buyer’s jurisdiction, apply the correct VAT rate, and issue an invoice with specific fields. An x402 payment provides an on-chain address, not a buyer identity or jurisdiction. This is not a small problem for European enterprises, and it is not solved in the current specification.
Refund and dispute semantics
USDC transfers are irreversible. If an agent pays for a resource and the resource is malformed, missing, or misrepresented, x402 provides no protocol-level path to redress. Merchants can voluntarily refund, but there is no equivalent of the card-network chargeback that shifts liability and forces the merchant to defend the delivery. For contested transactions — anything where quality is subjective — x402 is structurally unsuited without an out-of-band dispute layer.
Fee economics at scale
The $0.001-per-transaction facilitator fee looks favorable against 1.5–3% card interchange. It stops looking favorable at very high volumes if it is a flat fee on high-value transactions, and stops looking favorable at very low volumes if the underlying chain fees (even on Base or Solana) start to dominate. The deferred scheme dissolves this tension by amortizing settlement, but at the cost of introducing credit relationships that reintroduce the card-network’s operational complexity.
The bootstrapping problem
Bots can ignore payment gates and use free endpoints or synthetic data. Enforcement requires that enough high-value content actually sits behind paid edges — a chicken-and-egg problem that historical micropayment schemes (Flattr, Bitcoin Lightning) failed to solve. The structural bet x402 makes is that the buyer being a non-human agent removes the UX friction that killed prior attempts. That is plausible but not proven; if enterprise risk controls impose the same authorization friction on agent wallets that killed human micropayments, the bet weakens.
Implications and open questions
The most defensible reading of the current state is that x402 has solved the least-important half of the agent payments problem — the transfer of value — and has barely addressed the harder half: authorization, audit, refund, and regulatory fit. The card-network stacks have the harder half largely solved and are grafting agent authorization onto it. Whether the two tracks converge, stratify, or one displaces the other depends on questions we cannot yet answer:
- Does an independent facilitator market emerge? If a second facilitator with meaningful traffic does not exist by mid-2027, the “open protocol” framing is functionally hollow. If two or three do, the centralization critique softens materially.
- Does the deferred scheme become the primary settlement mode? If it does, x402 evolves into an HTTP-native identity and authorization protocol for payments, with the settlement rail negotiable. That is a materially different — and arguably more durable — product than pure stablecoin micropayments.
- Does Verifiable Intent or an x402 equivalent get standardized? Without a cryptographic audit log of user authorization, enterprise adoption of autonomous agent payments will hit governance objections independent of any technical property of the transfer.
- How is a “payment” defined? Coinbase’s reported volume numbers cannot be meaningfully compared against card-network volumes until the counting methodology is disclosed. This is not a minor accounting question; it determines whether the growth story is real.
- Where does regulatory treatment land? FinCEN, EU MiCA, and FATF travel-rule applicability to x402 stablecoin payments is not addressed in any documentation we have. Enterprise buyers will not deploy against a protocol with unsettled AML posture at scale.
What the reader should watch for over the next twelve months is not the volume numbers — those are self-reported and definitionally soft. Watch for the second facilitator. Watch for the first regulated enterprise (bank, exchange, publisher) to publish an audit-passing deployment. Watch for a formal refund or dispute mechanism in the specification. And watch whether AP2 and x402 begin explicit interoperability work through FIDO and the Linux Foundation, or whether they harden into non-overlapping stacks.
If the facilitator remains singular and the audit-log gap remains unfilled, x402 will occupy a real but bounded niche: agent-to-agent micropayments for digital resources where the operator accepts stablecoin settlement risk and neither party requires refund rights. That is a genuine market. It is not the general-purpose agentic commerce rail the launch materials imply. Card networks would then not be disintermediated so much as complemented, with the rails stratifying cleanly by transaction type.
The alternative outcome — where deferred settlement matures, independent facilitators emerge, and a Verifiable-Intent-equivalent gets bolted onto the specification — leaves x402 as a legitimate HTTP-layer competitor to the card-network stacks for a much wider set of use cases. Neither outcome is currently more likely than the other from what the sources support. The next twelve months should resolve most of the ambiguity.
References
- InfoQ, Cloudflare and AWS Embed x402 Agent Payments at the Edge, July 2026.
- Visa, Visa Partners with OpenAI to Power the Next Generation of AI Commerce, 10 June 2026.
- Google, Donating Agent Payments Protocol to the FIDO Alliance.
- Cloudflare, Launching the x402 Foundation with Coinbase, 23 September 2025.
- Coinbase Developer Platform, x402 Overview.
서론
두 거대 클라우드 사업자가 몇 주 간격으로 동일한 결제 프리미티브를 엣지 네트워크에 탑재했을 때, 흥미로운 질문은 어느 제품이 이기느냐가 아니다. 핵심은 기저 프로토콜이 어떤 신뢰 가정 위에 서 있는지, 그리고 트래픽이 본격적으로 흐르기 시작할 때 누가 중간에 앉아 있느냐다.
2026년 중반 현재, 그 자리를 차지하고 있는 것이 바로 x402다. 이 프로토콜은 1997년 HTTP/1.1에서 예약됐지만 실제로 표준화된 적 없는 HTTP 402 상태 코드를 재활용해, 주로 Base와 Solana 위에서 USDC로 결제가 완결되는 머신-투-머신 결제 핸드셰이크로 탈바꿈시켰다. Coinbase가 설계하고 2026년 4월 x402 Foundation이라는 이름으로 Linux Foundation에 기증했으며, 현재 모든 주요 배포가 의존하는 유일한 프로덕션 퍼실리테이터를 계속 운영하고 있다. AWS CloudFront는 x402를 정식 출시 기능으로 엣지에서 강제 적용하고 있고, Cloudflare의 Monetization Gateway는 웨이팅 리스트 단계다. Anthropic, Circle, Stripe 등 20개 이상의 기관이 재단 멤버로 이름을 올리고 있다.
그러나 카드 네트워크도 가만히 있지 않았다. Visa는 2026년 6월 10일 OpenAI와의 전략적 협력을 발표하며 토큰화된 Visa 자격증명을 에이전트 기반 커머스에 내장하겠다고 밝혔다. Google은 자사의 **Agent Payments Protocol(AP2)**을 FIDO Alliance에 기증했고, Mastercard와 함께 Verifiable Intent라는 위변조 방지 감사 로그 표준을 공동 개발해 역시 기증했다. 이제 두 개의 결제 트랙이 뚜렷하게 모습을 드러내고 있다. 하나는 HTTP 레이어에서 스테이블코인으로 결제를 완결하는 트랙이고, 다른 하나는 기존 카드 인프라 위에서 에이전트를 인가하는 트랙이다.
우리는 “누가 이기느냐”보다 각 스택의 신뢰 가정이 어디에 놓여 있는지, 볼륨이 커질수록 무엇이 먼저 깨지는지, 그리고 두 트랙이 수렴할지·계층화될지·서로를 대체할지를 묻는 편이 훨씬 생산적이라고 본다. 이어지는 내용은 x402의 메커니즘을 단계별로 해부하고, 중앙화 및 결제 완결 문제를 솔직하게 짚은 뒤, 카드 네트워크의 대응 방식과 비교하는 순서로 전개된다.
배경: “에이전트 결제”가 실제로 의미하는 것
프로토콜 세부 사항에 앞서 문제를 명확히 정의할 필요가 있다. 에이전트 결제란 결제 페이지 앞에 사람이 없는 상태에서, 종종 사전에 맺어진 특정 가맹점 관계도 없이, 소프트웨어가 사용자를 대신해 개시하는 거래다. 데이터 피드를 API 호출당 과금으로 이용하는 LLM 기반 리서치 에이전트, 페이지 수집 권한을 지불하는 크롤러, 온디맨드로 클라우드 리소스를 프로비저닝하는 코드 어시스턴트가 그 예다.
전통적인 결제 스택은 클릭하는 인간, 사전에 개설된 계정, 별도 채널로 발급된 API 키, 또는 구독 관계를 전제한다. 에이전트는 이 네 가지 전제를 모두 깨뜨린다. 계정도, 사전 등록된 결제 수단도, 결제 플로우를 기다릴 인내심도 없이 나타나며, 카드 수수료(~1.5~3%)가 부담스러울 만큼 건당 금액이 낮은 경우도 많다.
트래픽 구성은 이미 변하고 있다. Cloudflare는 2026년 6월 기준 AI 학습이 자사 크롤러 트래픽의 **52%**를 차지한다고 보고했다. 2025년 봄의 22%에서 크게 오른 수치다. 퍼블리셔 측의 광고·구독 경제는 광고를 보지도 않고 가입도 하지 않는 독자를 위해 설계된 것이 아니다. x402의 수요 측 압력이 여기서 나온다.
이 공간을 정의하는 두 가지 설계 선택이 있다.
- 인가는 어디에 있는가? 사용자의 지갑(x402)에 있는가, 아니면 지출 한도·가맹점 카테고리 제어·승인 규칙을 갖춘 카드 네트워크 정책 레이어(Visa Intelligent Commerce, AP2)에 있는가?
- 결제는 어디서 완결되는가? 요청마다 퍼블릭 블록체인에서, 오프체인으로 묶어서 나중에 정산하는 방식으로, 아니면 기존 카드·은행 인프라를 통해?
x402는 초기에 지갑 보유 인가와 USDC 온체인 건별 결제를 선택했다. 그리고 현재 두 번째 선택을 완화하는 지연 결제 방식을 제안 중이다. 카드 네트워크 스택은 기존 인프라를 활용하는 네트워크 보유 인가를 선택했다. 모든 트레이드오프는 이 지점에서 파생된다.
x402 흐름, 단계별 분석
핵심 프로토콜은 의도적으로 단순하게 설계되어 있다. Cloudflare의 출시 포스트와 Coinbase의 개발자 문서에 따르면, x402 결제는 다섯 단계로 완결된다.
- 요청. 임베디드 지갑을 보유한 에이전트 같은 클라이언트가 리소스 URL에 일반 HTTP 요청을 보낸다.
- 402 응답. 서버는 HTTP 402와 함께 허용 가능한 결제 방식, 수락 네트워크(예: Base, Polygon, Arbitrum, World, Solana), 수락 자산(USDC, EIP-3009 기반 EURC, 또는 Permit2 기반 임의 ERC-20), 가격, 수신자 주소를 담은 JSON 페이로드로 응답한다.
- 결제 인가와 함께 재요청. 클라이언트는 서명된 결제 인가를 담은
X-PAYMENT헤더와 함께 요청을 재전송한다. EIP-3009의 경우 제3자가 클라이언트 지갑에서 지정 금액을 인출할 수 있도록 허용하는transferWithAuthorization서명이다. - 퍼실리테이터 검증 및 결제 완결. 서버는 인가를 퍼실리테이터에 전달하고, 퍼실리테이터는 서명을 검증하고 클라이언트의 온체인 잔액을 확인한 뒤 대상 체인에 전송을 제출한다. 문서화된 모든 프로덕션 배포에서 이 퍼실리테이터는 Coinbase의 CDP다.
- 리소스 전달. 확인이 완료되면 서버는 정산 영수증을 담은
X-PAYMENT-RESPONSE헤더와 함께 리소스를 반환한다.
각 단계마다 별개의 신뢰 가정이 있으며, 이를 정확히 짚을 필요가 있다.
신뢰가 실제로 위치하는 곳
클라이언트 지갑이 자산 보관의 근원이다. 서명 키를 보유한 자는 잔액 한도 내에서 지갑을 소진할 수 있다. 자율 에이전트에서 이 키는 에이전트 런타임이 접근 가능한 곳에 있어야 하므로, 사용자가 하드웨어 키를 직접 보유하는 것보다 근본적으로 보안이 취약하다. 지갑 수준의 지출 한도(스마트 컨트랙트 지갑이나 세션 키를 통한)가 주요 방어 수단이지만, 그 설계와 집행은 x402 자체의 범위 밖이며 지갑 스택에 위임된다.
퍼실리테이터는 서명을 정직하게 검증하고, 합리적인 시간 내에 올바른 체인에 트랜잭션을 제출하며, 양측에 정산 결과를 정확히 보고할 것으로 신뢰된다. 자산 보관은 신뢰 대상이 아니다. EIP-3009 서명은 단일 전송 금액과 수신자에 한정된다. 그러나 가용성과 가맹점에 대한 보고의 정확성은 신뢰 대상이다. 퍼실리테이터가 정산 상태를 허위로 보고할 경우, 가맹점은 온체인에서 독립적으로 검증할 수 있지만 사후에만 가능하다.
체인은 결제 완결성을 제공한다. Base와 Solana 모두 서브세컨드 블록 타임을 제공하며, 리오그 리스크가 무시할 수 있을 만큼 소액인 USDC 거래의 경우 수 초 내에 사실상 완결성을 달성한다. 이는 비트코인 라이트닝 시대의 소액결제 방식과 실질적으로 다른 점이다.
서버는 결제 완결 후 실제로 리소스를 전달할 것으로 신뢰된다. 전달에 대한 온체인 강제 메커니즘은 없으며, 결정적으로 리소스가 불량하다고 판명될 경우 환불이나 취소 경로도 없다. USDC 전송은 기본적으로 되돌릴 수 없다.
퍼실리테이터가 불가용할 때 일어나는 일
문서화된 배포 중 대체 경로를 기술한 사례는 없다. Coinbase의 CDP 퍼실리테이터가 오류를 반환하면, AWS CloudFront와 Cloudflare Monetization Gateway 통합 모두 결제 검증 능력을 잃는다. 프로토콜 명세는 누구든 퍼실리테이터를 운영할 수 있다고 허용하지만, 2026년 중반의 운영 현실은 프로덕션 규모에서 단 하나만 존재한다는 것이다. 이 문제는 스택에서 가장 날카로운 구조적 리스크이므로 아래에서 다시 다룬다.
퍼실리테이터 문제
x402 명세는 개방되어 있다. 원칙적으로 누구든 퍼실리테이터를 구축할 수 있다. Coinbase CDP 퍼실리테이터는 인터페이스를 공개하고, Base·Polygon·Arbitrum·World·Solana를 지원하며, 월 1,000건까지 무료, 이후 건당 $0.001로 가격을 책정하고 있다. 판매자는 블록체인 인프라를 직접 운영하지 않아도 된다. 퍼실리테이터가 이를 추상화하기 때문이다.
그러나 실제로, 소스 자료에 문서화된 모든 배포—AWS CloudFront, Cloudflare의 Monetization Gateway, Coinbase 호스팅 SDK 통합—에서 프로덕션 퍼실리테이터는 Coinbase의 것이다. 독립 퍼실리테이터가 운영 중이라고 문서화된 사례는 없다. 그 이유는 딱히 미스터리가 아니다.
- 재무 여력. 퍼실리테이터는 서명 검증과 온체인 확인 사이의 창에서 정산 리스크를 부담한다. 소규모 운영자는 이 리스크를 가격에 반영하기 어렵다.
- 체인 커버리지. 다섯 개 체인을 저지연으로 지원하려면 각 체인별로 노드, 인덱서, 모니터링이 필요하다.
- 로드맵 기능. 선택적 KYC 증명과 지리적 제한—Coinbase의 명시적 로드맵 항목—은 규제 적용을 받는 구매자가 반드시 요구할 기능이며, 이를 신뢰할 수 있는 방식으로 구축하려면 대부분의 크립토 팀이 갖추지 못한 법적 인프라가 필요하다.
- 통합 고착. AWS와 Cloudflare가 단일 퍼실리테이터를 기준으로 검증하고 나면, 가맹점이 인터페이스가 표준화돼 있더라도 마이그레이션하는 데 드는 전환 비용은 만만치 않다.
그 결과, 퍼미션리스 HTTP 레이어 결제로 마케팅된 프로토콜이 배관 레이어에서는 단 하나의 상업적 게이트키퍼를 두고 있다. 그 게이트키퍼는 가격을 조정하고, 컴플라이언스 조건을 부과하고, 특정 지역을 제한하며, 법적 압박 하에 특정 가맹점이나 지갑을 차단할 수 있다. 이는 가설이 아니다. Coinbase는 이미 정확히 이런 통제를 부과할 수 있는 미국 규제 체계 하에서 운영되고 있다.
Linux Foundation의 거버넌스 모델은 명세의 독점적 포획을 방지하기 위한 것이다. 퍼실리테이터 시장의 운영 집중을 막는 것이 아니다. 이 둘은 다른 문제다. 명세가 개방되어 있다는 사실은 의미 있는 트래픽을 보유한 두 번째 퍼실리테이터가 실제로 등장하느냐보다 덜 중요하다. 2026년 중반 현재, 그런 사례는 문서화되어 있지 않다.
지연 결제: 기업 친화적 경로
Cloudflare의 2025년 9월 출시 포스트는 **지연 결제 방식(deferred payment scheme)**이라 부르는 변형을 소개했다. 이 방식은 신뢰 모델을 실질적으로 바꾸며 명세에서 더 중요한 제안일 수 있기 때문에 꼼꼼히 살펴볼 필요가 있다.
즉시 방식에서는 페이월을 통과하는 모든 HTTP 요청이 온체인 전송을 트리거한다. Base나 Solana 비용으로는 중간 가치 거래에서 방어할 수 있지만, Cloudflare가 보고한 하루 10억 건 이상의 HTTP 402 응답 볼륨에서 요청별 정산은 낭비가 심할 뿐 아니라, 동일한 구매자가 한 시간에 같은 퍼블리셔에 수천 건의 요청을 보낼 경우에는 아무 의미가 없다.
지연 방식은 암호화 핸드셰이크와 정산을 분리한다. 요청마다 EIP-3009 서명을 붙이는 대신, 클라이언트는 JWK 공개 키를 사용한 HTTP Message Signature를 제시해 신원을 증명한다. 서버는 요청을 허용한다. 정산은 일별, 주별, 또는 구독 단위로 집계되며 신용카드를 포함한 오프체인에서 이루어질 수 있다. Cloudflare의 비공개 베타 방식인 pay-per-crawl이 바로 이 방식을 사용한다. 요청마다 HTTP 서명, 결제는 하루 마감 시점에 신용카드로.
이에 대해 두 가지 사실이 동시에 참이다. 이 방식은 그렇지 않을 경우 x402를 진정한 고가 호출에만 묶어 두었을 수수료 경제학 및 처리량 문제를 해결한다. 그리고 이 프로토콜 고유의 크립토 네이티브 정산 테제를 어느 정도 희석한다. 정산 레이어가 하루 마감 신용카드 정산이라면, x402는 더 이상 경제성에서 카드 인프라와 경쟁하는 것이 아니다. HTTP 네이티브 신원·인가 레이어에서 경쟁하는 것이며, 실제 자금 이동은 카드 인프라가 담당한다.
지연 방식은 새로운 신뢰 가정도 도입한다. 이제 서버는 서명된 요청과 정산 사이에 구매자에게 신용을 제공한다. 즉시 방식에서 가맹점은 정산이 수 초 내에 완결된다는 것을 알았다. 지연 방식에서 가맹점은 HTTP 서명 뒤의 신원이 지급 능력이 있고 부인을 하지 않는다는 것을 믿어야 한다. 이는 스테이블코인 결제보다 기업 간 30일 외상 거래에 가까운 다른 리스크 모델이다.
명세는 이것이 비준된 기능이 아닌 제안임을 명시하고 있으며, 소스 자료에 언급된 HTTP Message Signature 구성에 대한 보안 감사는 없다. 대부분의 기업이 실제로 채택하는 방식이 이 지연 방식일 가능성은 높지만 확실하지는 않다.
경쟁 스택
x402가 유일한 제안은 아니며, 대안들이 피상적인 수준에 머물러 있지도 않다. 카드 네트워크는 기존 인프라를 유지하면서 에이전트 인가 레이어를 그 위에 추가하는 다른 아키텍처로 수렴하고 있다.
Visa Intelligent Commerce와 OpenAI 협력
Visa의 2026년 6월 10일 OpenAI와의 발표는 Visa를 토큰화·네트워크·리스크 레이어로, OpenAI를 에이전트 인터페이스로 위치시킨다. 거래는 실시간 인가 및 사기 모니터링을 갖춘 토큰화된 Visa 자격증명을 사용한다. 지출 한도, 가맹점 카테고리 제어, 필수 승인 사항은 사용자별로 설정된다. Visa가 수년간 법인 카드에서 제공해 온 것과 동일한 프리미티브를 에이전트가 준수해야 하는 제약으로 노출하는 방식이다.
기술 아키텍처는 보도자료에 공개되어 있지 않다. 공개된 것은 가치 제안이다. 신뢰, 사기 책임, 차지백 권한, 규제 안정성. 이 중 어느 것도 x402가 현재 제공하지 않는다. Visa는 비용이나 프로그래밍 가능성에서 경쟁하는 것이 아니다. 실제 자금 이동이 아닌 결제를 둘러싼 전체 운영 장치에서 경쟁하고 있다.
AP2, FIDO, Verifiable Intent
Google의 AP2 접근법은 또 다르다. AP2를 FIDO Alliance에 기증함으로써 Google은 에이전트가 개시하는 결제를 위한 플랫폼 불가지론적 인증·인가 표준을 확립하려 한다. 규제 금융이 인정하는 신원 레이어를 이미 관할하고 있는 WebAuthn, 패스키 등의 기존 임무를 가진 얼라이언스가 이를 거버닝하도록 한 것이다. AP2 v0.2 릴리스는 에이전트가 사전 인가된 사용자 지시에 따라 자율적으로 거래를 실행하는 Human Not Present 결제 개념을 도입했다.
보완 표준인 Verifiable Intent는 Mastercard와 공동 개발하고 역시 FIDO에 기증한, 사용자 인가 에이전트 행동의 위변조 방지 감사 로그다. 이것이 x402가 현재 가지고 있지 않은 부분이다. 사용자가 실제로 에이전트에게 무엇을 하도록 인가했는지에 대한 암호학적으로 집행 가능한 기록으로, 가맹점, 네트워크, 규제 기관, 법원 등 어떤 하위 당사자도 분쟁 해결을 위해 검사할 수 있다.
주목할 점은 AP2가 기존 결제 인프라의 대체가 아닌 호환 가능한 것으로 기술되어 있다는 것이다. 카드, 은행 이체, 원칙적으로 스테이블코인 전송 위에 놓일 수 있는 정책·감사 레이어다. AP2와 x402가 계층화될지(AP2가 인가, x402가 정산)·경쟁할지(AP2가 자체 정산 포함)는 소스 자료에서 명확히 하지 않는다.
Mastercard Agent Pay는 주제 범위에 있으나 우리 소스에서 기술적으로 문서화되지 않았다. 아키텍처를 추측하기보다 이를 공백으로 표시한다.
솔직한 비교
| 차원 | x402 (즉시) | x402 (지연) | Visa Intelligent Commerce | AP2 + FIDO |
|---|---|---|---|---|
| 정산 인프라 | USDC 온체인 | 오프체인, 카드 포함 | Visa 카드 인프라 | 인프라 불가지론 |
| 건당 비용 | ~분의 일 센트 | 분할 상각 | 카드 수수료 | 인프라에 따라 상이 |
| 사기 책임 | 미정의 | 미정의 | 카드 네트워크 모델 | 미명시 |
| 환불/차지백 | 없음 | 없음 | 기존 카드 권한 | 인프라에 따라 상이 |
| 위임 인가 | 지갑 수준 | 지갑 수준 | 네트워크 정책 레이어 | Verifiable Intent 로그 |
| 규제 포지션 | 신규 | 신규 | 안정적 | 안정적 (인프라 경유) |
| 거버넌스 | Linux Foundation | Linux Foundation | 독점 | FIDO Alliance |
여기서 빠지기 쉬운 함정은 이것들을 직접 대체 가능한 것으로 취급하는 것이다. 그렇지 않다. x402는 구매자가 명확히 봇이고, 리소스가 명확히 디지털이며, 가치가 명확히 소액인 머신-투-머신 호출에서 탁월하다. 카드 네트워크 스택은 사기, 환불, 규제 명확성이 구매자의 리스크 계산을 지배하는 곳에서 탁월하다. 향후 12~24개월에 걸친 흥미로운 경험적 질문은 중간 영역이 한쪽으로 붕괴할지, 아니면 사용 사례에 따라 깔끔하게 분화할지다.
시스템이 먼저 깨지는 지점
x402 볼륨이 계속 성장한다고 가정하자. Coinbase는 프로토콜 첫 해에 1억 6,900만 건의 결제, 59만 명의 구매자, 10만 명의 판매자를 보고하고 있다. 이 수치는 감사되지 않은 자체 보고이며 방향성 지표로만 봐야 한다. 회자되고 있는 연간 환산 달러 볼륨 추정치(~$6억)는 우리 소스 자료에 등장하지 않으며 사실로 인용하지 않겠다. Coinbase는 “결제” 집계에 재시도, 지연 방식 서명 약정, 또는 온체인 완결된 전송만을 포함하는지를 명확히 하지 않았으며, 이는 카드 네트워크 기준치와 최상단 수치를 비교하기 어렵게 만든다.
성장을 액면 그대로 받아들이더라도 여러 실패 양태가 보인다.
퍼실리테이터 중앙화
가장 즉각적인 문제다. 두 하이퍼스케일러 배포 모두 Coinbase의 퍼실리테이터로 트래픽이 집중된다. 퍼실리테이터가 저하되면 페이월이 열린 채로 실패하거나(트래픽이 무료로 통과) 닫힌 채로 실패하는데(트래픽 거부), 엣지 규모에서는 어느 쪽도 바람직하지 않다. 가용성을 넘어 가격 결정권도 제약이 없다. 현재의 건당 $0.001 요율은 카드 수수료 대비 매력적이지만, 의존성이 고착된 후 상향 조정을 막는 계약적 보호 장치는 없다.
위임 사기와 사람 없는 결제 문제
x402의 인가 모델은 지갑이 지출 한도를 집행하는 것에 의존한다. 에이전트 런타임이 침해되면—프롬프트 인젝션, 모델 공급망 공격, 에이전트 프레임워크 버그를 통해—지갑 한도가 허용하는 모든 결제를 실행할 수 있다. 지갑은 정당한 에이전트 행동과 탈취된 행동을 구별할 수 없다. 둘 다 동일한 키로 서명되기 때문이다.
AP2의 Verifiable Intent가 이에 대한 직접적인 답이다. 에이전트 런타임 상태와 독립적으로 검증 가능한, 사용자가 인가한 내용의 암호학적 로그. x402에는 이에 해당하는 것이 없다. 지갑 수준의 세션 키와 스마트 컨트랙트 지출 정책이 감사 로그 없이 충분한지는 미결 질문이며, 규제 대상 기업들은 이를 보수적으로 판단할 가능성이 높다.
부가세, 인보이싱, 세금 관할권
AWS도 Cloudflare도 에이전트의 익명 스테이블코인 결제가 어떻게 EU 부가세 적합 인보이스를 생성하는지 다루지 않았다. EU 규정에 따르면 판매자는 구매자의 관할권을 확인하고, 올바른 부가세율을 적용하며, 특정 필드가 포함된 인보이스를 발행해야 한다. x402 결제는 구매자 신원이나 관할권이 아닌 온체인 주소를 제공한다. 유럽 기업에게 이것은 소소한 문제가 아니며, 현재 명세에서 해결되지 않았다.
환불 및 분쟁 의미론
USDC 전송은 되돌릴 수 없다. 에이전트가 리소스에 대금을 지불했는데 리소스가 불량하거나, 누락되거나, 잘못 표현된 경우, x402는 프로토콜 레이어에서 구제 경로를 제공하지 않는다. 가맹점이 자발적으로 환불할 수는 있지만, 책임을 이전하고 가맹점이 전달을 방어하도록 강제하는 카드 네트워크 차지백에 해당하는 것이 없다. 품질이 주관적인 분쟁 거래의 경우, x402는 별도 채널의 분쟁 레이어 없이는 구조적으로 적합하지 않다.
규모에 따른 수수료 경제학
건당 $0.001의 퍼실리테이터 수수료는 1.5~3% 카드 수수료 대비 유리해 보인다. 고가 거래에 대한 정액 수수료일 경우 매우 높은 볼륨에서 불리해지고, 기반 체인 수수료(Base나 Solana에서도)가 지배적이 될 만큼 소액 거래에서도 불리해진다. 지연 방식은 정산을 분할 상각해 이 긴장을 해소하지만, 카드 네트워크의 운영 복잡성을 재도입하는 신용 관계라는 비용을 치른다.
부트스트래핑 문제
봇은 결제 게이트를 무시하고 무료 엔드포인트나 합성 데이터를 사용할 수 있다. 집행은 충분히 많은 고가 콘텐츠가 실제로 유료 엣지 뒤에 위치하는 것을 요구하는데, 이는 과거 소액결제 방식(Flattr, Bitcoin Lightning)이 해결하지 못한 닭-달걀 문제다. x402가 거는 구조적 도박은 구매자가 비인간 에이전트라는 사실이 이전 시도를 죽인 UX 마찰을 제거한다는 것이다. 그럴듯하지만 증명되지 않았다. 기업 리스크 통제가 에이전트 지갑에 인간 소액결제를 죽인 것과 동일한 인가 마찰을 부과한다면, 이 도박은 약해진다.
시사점과 미결 질문
현 상태에 대한 가장 방어하기 쉬운 해석은 x402가 에이전트 결제 문제의 덜 중요한 절반—가치 이전—을 해결했고, 더 어려운 절반인 인가, 감사, 환불, 규제 적합성은 거의 다루지 못했다는 것이다. 카드 네트워크 스택은 어려운 절반을 대체로 해결했으며 에이전트 인가를 그 위에 접목하고 있다. 두 트랙이 수렴할지·계층화될지·하나가 다른 하나를 대체할지는 아직 답할 수 없는 질문들에 달려 있다.
- 독립 퍼실리테이터 시장이 등장하는가? 2027년 중반까지 의미 있는 트래픽을 보유한 두 번째 퍼실리테이터가 등장하지 않는다면, “개방 프로토콜” 프레이밍은 기능적으로 공허하다. 두세 개가 등장한다면 중앙화 비판은 실질적으로 완화된다.
- 지연 방식이 주요 정산 모드가 되는가? 그렇다면 x402는 HTTP 네이티브 신원·인가 프로토콜로 발전하며 정산 인프라는 협상 가능해진다. 이는 순수 스테이블코인 소액결제보다 실질적으로 다르고, 어쩌면 더 지속 가능한 제품이다.
- Verifiable Intent 또는 x402 동등물이 표준화되는가? 사용자 인가의 암호학적 감사 로그 없이는, 자율 에이전트 결제의 기업 채택이 전송의 기술적 특성과 무관한 거버넌스 이의에 부딪힐 것이다.
- “결제”를 어떻게 정의하는가? 집계 방법론이 공개되기 전까지 Coinbase의 보고 볼륨 수치는 카드 네트워크 볼륨과 의미 있게 비교할 수 없다. 이는 사소한 회계 질문이 아니다. 성장 스토리가 실재하는지를 결정한다.
- 규제 취급이 어떻게 결정되는가? x402 스테이블코인 결제에 대한 FinCEN, EU MiCA, FATF 여행 규칙 적용 가능성은 우리가 보유한 어떤 문서에서도 다루어지지 않는다. 기업 구매자는 규모에서 AML 포지션이 불확실한 프로토콜에 배포하지 않을 것이다.
향후 12개월간 주목해야 할 것은 자체 보고된 수치가 정의상 무르기 때문에 볼륨 수치가 아니다. 두 번째 퍼실리테이터를 주목하라. 규제 대상 기업(은행, 거래소, 퍼블리셔)이 감사를 통과한 배포를 최초로 공개하는 것을 주목하라. 명세에서 공식 환불 또는 분쟁 메커니즘을 주목하라. 그리고 AP2와 x402가 FIDO와 Linux Foundation을 통해 명시적 상호운용성 작업을 시작하는지, 아니면 겹치지 않는 스택으로 굳어지는지를 주목하라.
퍼실리테이터가 단일로 남고 감사 로그 공백이 채워지지 않으면, x402는 실재하지만 한정적인 틈새를 차지할 것이다. 운영자가 스테이블코인 정산 리스크를 수용하고 어느 쪽도 환불 권한을 요구하지 않는 디지털 리소스에 대한 에이전트-투-에이전트 소액결제. 이는 실제 시장이다. 출시 자료가 암시하는 범용 에이전트 커머스 인프라는 아니다. 카드 네트워크는 그때 중개 제거되기보다는 보완되며, 거래 유형에 따라 인프라가 깔끔하게 계층화될 것이다.
대안적 결과—지연 방식이 성숙하고, 독립 퍼실리테이터가 등장하며, Verifiable Intent 동등물이 명세에 추가되는—는 x402를 훨씬 광범위한 사용 사례에서 카드 네트워크 스택의 HTTP 레이어 경쟁자로 만든다. 소스가 뒷받침하는 내용으로는 현재 어느 결과가 더 가능성 높다고 할 수 없다. 향후 12개월이 대부분의 모호성을 해소할 것이다.
참고문헌
- InfoQ, Cloudflare and AWS Embed x402 Agent Payments at the Edge, July 2026.
- Visa, Visa Partners with OpenAI to Power the Next Generation of AI Commerce, 10 June 2026.
- Google, Donating Agent Payments Protocol to the FIDO Alliance.
- Cloudflare, Launching the x402 Foundation with Coinbase, 23 September 2025.
- Coinbase Developer Platform, x402 Overview.
はじめに
2社のハイパースケーラーが数週間のうちに同一の決済プリミティブをネットワークエッジに実装したとき、注目すべき問いは「どちらの製品が勝つか」ではない。根底にあるプロトコルが何を前提としているか、そしてトラフィックが流れはじめたとき、誰が間に座り続けるのか、だ。
2026年半ば現在、その座を占めているのが x402 である。このプロトコルは、1997年に HTTP/1.1 で予約されながら実用化されることなく眠り続けた HTTP 402 ステータスコードを、マシン間決済のハンドシェイクとして再活用するものだ。決済は主に Base および Solana 上の USDC で行われる。Coinbase が設計し、2026年4月に x402 Foundation として Linux Foundation へ寄贈した。現在、すべての主要デプロイメントが依存する唯一の本番ファシリテーターを引き続き運営しているのも Coinbase だ。AWS CloudFront はすでに x402 をエッジで一般提供機能として実施している。Cloudflare の Monetization Gateway はウェイティングリスト段階にある。Anthropic、Circle、Stripe をはじめ20社以上がファウンデーションのメンバーに名を連ねる。
一方、カードネットワーク各社も動いている。Visa は2026年6月10日、エージェント主導型コマースにトークン化された Visa クレデンシャルを組み込む戦略的提携を OpenAI と発表した。Google は Agent Payments Protocol（AP2） を FIDO アライアンスに寄贈し、Mastercard と共同で Verifiable Intent と呼ぶ改ざん防止型の監査ログ標準を開発して同アライアンスに提出した。いまや2つの決済トラックが明確に見えている。1つは HTTP レイヤーでステーブルコインを使って決済するトラック、もう1つは既存のカードレール上でエージェントを承認するトラックだ。
「どちらが勝つか」を問うよりも、各スタックのトラスト前提がどこに置かれているか、ボリュームが増大したときに何が最初に壊れるか、そして2つのトラックが収束するのか、層化するのか、それとも一方が他方を駆逐するのかを問う方がずっと実りある。以下では x402 のメカニズムを順を追って解説し、その中央集権化と決済の問題点を率直に論じたうえで、カードネットワーク側の回答と比較する。
背景：「エージェンティック決済」が実際に意味すること
プロトコルの詳細に入る前に、解決すべき問題を明確にしておく必要がある。エージェンティック決済とは、ユーザーに代わってソフトウェアが起こす取引であり、チェックアウトページに人間がいない場合がほとんどで、事前に確立された固定の加盟店関係もないことが多い。具体的には、データフィードの API 呼び出しごとに支払いを行う LLM 搭載のリサーチエージェント、パブリッシャーのページをインジェストする権利を支払うクローラー、オンデマンドでクラウドリソースをプロビジョニングするコードアシスタントなどが挙げられる。
従来の決済スタックは、人間がクリックすること、事前にプロビジョニングされたアカウント、帯域外で発行された API キー、あるいはサブスクリプションを前提に設計されている。エージェントはこの4つの前提をすべて破壊する。エージェントはアカウントなし、事前登録された決済手段なし、チェックアウトフローを待つ余裕もなく現れ、しかも1件あたりの取引額は非常に小さいためカードのインターチェンジ（~1.5〜3%）が割に合わない。
トラフィックの構成はすでに変化している。Cloudflare の報告によれば、2026年6月時点で AI トレーニングがクローラートラフィックの 52% を占めており、2025年春時点の22%から急上昇している。パブリッシャー側の広告・サブスクリプション経済は、広告を一切見ず、登録もしない「読者」を想定して設計されていない。これが x402 を後押しする需要側の圧力だ。
この問題空間を規定する設計上の選択肢は2つある。
- 認可はどこに置くか？ ユーザーのウォレット（x402）に置くか、支出制限・加盟店カテゴリ制御・承認ルールを備えたカードネットワークのポリシーレイヤー（Visa Intelligent Commerce、AP2）に置くか？
- 決済はどこで行うか？ リクエストごとにパブリックブロックチェーン上で行うか、オフチェーンでまとめて後から決済するか、それとも既存のカード・銀行レール上で行うか？
x402 は当初、ウォレット内蔵の認可とリクエストごとの USDC オンチェーン決済を選択した。現在は2番目の選択肢を緩和する遅延決済スキームを提案している。カードネットワーク側のスタックはネットワーク内蔵の認可と既存レールを選んだ。ここから始まるトレードオフが全体に波及していく。
x402 のフロー：ホップごとの解説
コアプロトコルは意図的にシンプルに作られている。Cloudflare のローンチポストと Coinbase のデベロッパードキュメントに記載されているとおり、x402 の決済は5つのステップで完結する。
- リクエスト。 クライアント（通常はウォレットを内蔵したエージェント）がリソース URL に対して通常の HTTP リクエストを送信する。
- 402 レスポンス。 サーバーは HTTP 402 と、受け入れ可能な決済スキーム、対応ネットワーク（Base、Polygon、Arbitrum、World、Solana など）、対応アセット（EIP-3009 による USDC・EURC、または Permit2 による任意の ERC-20）、価格、および受取アドレスを記述した JSON ペイロードを返す。
- 決済承認付きリトライ。 クライアントは
X-PAYMENTヘッダーに署名済みの決済承認を含めてリクエストを再送する。EIP-3009 の場合、これはサードパーティがクライアントのウォレットから指定額を引き出せるtransferWithAuthorization署名だ。 - ファシリテーターによる検証と決済。 サーバーは承認をファシリテーターに転送し、ファシリテーターは署名を検証してクライアントのオンチェーン残高を確認後、対象チェーンに送金を送信する。ドキュメント化されているすべての本番デプロイメントにおいて、このファシリテーターは Coinbase の CDP だ。
- リソース配信。 確認が取れると、サーバーは決済レシートを含む
X-PAYMENT-RESPONSEヘッダーとともにリソースを返す。
各ホップには固有のトラスト前提があり、それを正確に整理しておく価値がある。
トラストが実際に置かれている場所
クライアントウォレットはカストディの起点だ。署名鍵を保持する者は残高の上限まで引き出せる。自律型エージェントの場合、この鍵はエージェントランタイムがアクセスできる場所に置かなければならず、ユーザー保有のハードウェアキーに比べてセキュリティ上の前提が本質的に弱くなる。スマートコントラクトウォレットやセッションキーによるウォレットレベルの支出制限が主な防御手段だが、その設計と執行は x402 自体の守備範囲ではなく、ウォレットスタックに委ねられている。
ファシリテーターは、署名を誠実に検証し、合理的な時間内に正しいチェーンへ取引を送信し、決済結果を両者に正確に報告することを信頼される存在だ。EIP-3009 署名は単一の送金額と受取人にスコープされているため、カストディは信頼されていないが、ライブネスと加盟店への報告の正確性については信頼されている。ファシリテーターが決済ステータスについて虚偽の報告をした場合、加盟店はオンチェーンで独自に検証できるが、それは事後になる。
チェーンは決済のファイナリティを提供する。Base と Solana はいずれもサブ秒のブロックタイムを持ち、USDC 建ての少額取引においてはリオーグリスクが無視できる範囲でほぼ数秒内にファイナリティが確定する。これは Bitcoin Lightning 時代のマイクロペイメントスキームとは本質的に異なる点だ。
サーバーは決済が確定した後に実際にリソースを配信することを信頼される。配信のオンチェーン強制手段はなく、決定的なことに、リソースが不良であった場合のチャージバックや払い戻しのパスも存在しない。USDC 送金はデフォルトで不可逆だ。
ファシリテーターが利用不能になったとき
ドキュメント化されているデプロイメントのいずれも、フォールバックパスを記述していない。Coinbase の CDP ファシリテーターがエラーを返した場合、AWS CloudFront と Cloudflare Monetization Gateway のどちらの統合も決済の検証能力を失う。プロトコル仕様は任意のファシリテーターの存在を許容しているが、2026年半ばの実態では本番スケールで稼働しているのは1社のみだ。この点については後述する。これがスタック全体で最も深刻な構造的リスクだからだ。
ファシリテーター問題
x402 の仕様はオープンだ。原則として誰でもファシリテーターを立ち上げられる。Coinbase の CDP ファシリテーターはそのインターフェースを公開しており、Base、Polygon、Arbitrum、World、Solana に対応し、月1,000トランザクションまで無料、以降は1トランザクションあたり$0.001で提供している。加盟店はブロックチェーンインフラを自前で運営する必要がなく、ファシリテーターがそれを抽象化してくれる。
しかし実態としては、ソース資料に記載されているすべてのデプロイメント — AWS CloudFront、Cloudflare の Monetization Gateway、Coinbase ホスト型 SDK の統合 — において、本番環境のファシリテーターは Coinbase のものだ。独立したファシリテーターが稼働しているという記録は存在しない。その理由は難しくない。
- バランスシート。 ファシリテーターは署名検証からオンチェーン確認までの窓口に決済リスクを負う。小規模な事業者にはこのリスクを適切に価格設定することが難しい。
- チェーンカバレッジ。 低レイテンシで5チェーンに対応するには、各チェーンのノード、インデクサー、モニタリングが必要だ。
- ロードマップ機能。 オプションの KYC 証明や地域制限 — Coinbase が言及しているロードマップ項目 — は規制対象の買い手が要求する機能そのものであり、それを信頼性をもって構築するには、多くの暗号資産チームが持ち合わせていない法的インフラが必要だ。
- 統合のロックイン。 AWS と Cloudflare が単一のファシリテーターを基準に検証を行った以上、インターフェースが標準化されていても、加盟店が移行するコストは小さくない。
結果として、パーミッションレスな HTTP レベル決済として売り出されたプロトコルが、配管レイヤーではただ1社の商業的ゲートキーパーを持つ構造になっている。そのゲートキーパーは価格を変更し、コンプライアンス条件を課し、地域を制限し、そして法的圧力の下で特定の加盟店やウォレットを排除することができる。これは仮定の話ではない。Coinbase はすでに米国の規制体制の下で運営しており、そこではまさにこうした制御が課される可能性がある。
Linux Foundation のガバナンスモデルは仕様の独占的な取り込みを防ぐことを意図している。しかし、ファシリテーター市場における運営の集中を防ぐことはできない。これらは別の問題だ。仕様がオープンであることは、実際のトラフィックを持つ第2のファシリテーターが登場するかどうかよりも重要ではない。2026年半ば現在、その記録はどこにもない。
遅延決済：エンタープライズ対応への道
Cloudflare の2025年9月のローンチポストには、遅延決済スキームと呼ばれる変形版が記述されている。これを丁寧に読み解く価値がある。トラストモデルを大きく変えるものであり、おそらく仕様の中でより重大な提案だからだ。
即時スキームでは、有料コンテンツを通過するすべての HTTP リクエストがオンチェーン送金を引き起こす。Base や Solana のコストを前提にすれば中程度の価値を持つ取引には耐えられるが、Cloudflare が報告するボットとクローラーのトラフィックに対する1日あたり10億件超の HTTP 402 レスポンスというボリュームを前提にすると、リクエストごとの決済は無駄が多すぎて現実的でない。同一の買い手が1時間に同一パブリッシャーへ1,000回リクエストを送るなら、なおのことだ。
遅延スキームは暗号ハンドシェイクと決済を分離する。リクエストごとの EIP-3009 署名の代わりに、クライアントは JWK 公開鍵を用いた HTTP Message Signature を提示してアイデンティティを証明する。サーバーはリクエストを通す。決済は日次・週次・サブスクリプション単位で集約され、クレジットカードを含む完全なオフチェーン決済も可能だ。Cloudflare の pay-per-crawl プライベートベータはまさにこれを採用している。リクエストごとに HTTP 署名を行い、日次でクレジットカード決済する方式だ。
これについて2つのことが同時に言える。一方では、費用対効果とスループットの問題が解決され、x402 が本当に高価値の呼び出しに上限を設けてしまう問題が回避される。もう一方では、プロトコルが元来持っていたクリプトネイティブな決済の命題が部分的に溶解する。決済レイヤーが日次バッチ処理のクレジットカードになるなら、x402 はもはや経済的にカードレールと競合しているのではなく、HTTP ネイティブなアイデンティティと認可の表面で競合しており、実際のお金の移動はカードレールが担うことになる。
遅延スキームは新たなトラスト前提も導入する。サーバーは署名済みリクエストから決済までの間、買い手に信用を供与することになる。即時スキームでは加盟店は決済が数秒で確定することを知っていた。遅延スキームでは、加盟店は HTTP 署名の背後にあるアイデンティティが支払い能力を持ちかつ否認しないことに依拠する。これはステーブルコイン決済よりも、企業間の30日ネット払いに近いリスクモデルだ。
仕様はこれが確定した機能ではなく提案であることを明記しており、ソース資料に言及されている HTTP Message Signature の実装についてセキュリティ監査は行われていない。ほぼ確実ではあるが、エンタープライズが実際に採用するのはこのスキームになると思われる。
競合するスタック
x402 は唯一の提案ではなく、代替案は表面的なものでもない。カードネットワーク各社は、既存レールを維持しつつその上にエージェント認可レイヤーを追加する別アーキテクチャへと収束しつつある。
Visa Intelligent Commerce と OpenAI の提携
Visa の2026年6月10日の OpenAI との発表は、Visa がトークン化・ネットワーク・リスクのレイヤーを担い、OpenAI がエージェントインターフェースを提供するポジショニングだ。取引にはトークン化された Visa クレデンシャルが使われ、リアルタイムの承認と不正監視が行われる。支出制限、加盟店カテゴリ制御、必要な承認はユーザーごとに設定される。これは Visa がコーポレートカードで長年提供してきたプリミティブそのものであり、今それがエージェントの行動制約として公開されている。
技術的なアーキテクチャはプレスリリースに開示されていない。開示されているのはその価値提案だ。信頼、詐欺責任、チャージバック権、規制面での確立性。これらは現在の x402 が提供していないものだ。Visa はコストや設定可能性で競争しているのではない。カード決済を取り巻く運営上の装置全体 — 送金そのものではない「決済」の部分 — で競争している。
AP2、FIDO、Verifiable Intent
Google の AP2 へのアプローチはさらに異なる。AP2 を FIDO アライアンスに寄贈することで、Google はエージェント主導型決済のための、プラットフォーム非依存の認証・認可標準として確立しようとしている。FIDO アライアンスは、規制金融が認識するアイデンティティレイヤーをすでにカバーする既存の活動（WebAuthn、パスキー）を持つアライアンスだ。AP2 v0.2 リリースでは、エージェントが事前認可されたユーザーの指示に従って自律的に取引を実行する Human Not Present 決済の概念が導入された。
付随する標準 Verifiable Intent は、ユーザーが認可したエージェントのアクションを記録する改ざん防止型の監査ログであり、Mastercard と共同開発され FIDO に寄贈された。これは x402 が現在持っていないものだ。ユーザーが実際にエージェントに何を認可したかを暗号学的に証明できる記録であり、加盟店・ネットワーク・規制当局・裁判所など下流のあらゆる当事者が紛争解決のために参照できる。
注目すべきは、AP2 が既存の決済レールの代替ではなく、それらと互換性があると説明されている点だ。カード、銀行振込、原理的にはステーブルコイン送金の上にも置けるポリシー・監査レイヤーだ。AP2 と x402 が層化する（AP2 が認可、x402 が決済）のか、それとも競合する（AP2 が独自の決済も持つ）のかは、ソース資料では明確にされていない。
Mastercard Agent Pay はトピックに含まれているが、ソース資料に技術的な文書がない。推測するのではなく、これはギャップとして明示しておく。
率直な比較
| 比較軸 | x402（即時） | x402（遅延） | Visa Intelligent Commerce | AP2 + FIDO |
|---|---|---|---|---|
| 決済レール | オンチェーン USDC | オフチェーン（カード含む） | Visa カードレール | レール非依存 |
| 1取引あたりコスト | ~数分の1セント | 償却 | カードインターチェンジ | レール次第 |
| 詐欺責任 | 未定義 | 未定義 | カードネットワークモデル | 未規定 |
| 払い戻し・チャージバック | なし | なし | 既存カード権利 | レール次第 |
| 委任認可 | ウォレットレベル | ウォレットレベル | ネットワークポリシーレイヤー | Verifiable Intent ログ |
| 規制上の位置づけ | 発展途上 | 発展途上 | 確立済み | 確立済み（レール経由） |
| ガバナンス | Linux Foundation | Linux Foundation | 独占的 | FIDO アライアンス |
ここで陥りやすい誤りは、これらを直接置き換え可能なものとして扱うことだ。そうではない。x402 は、買い手が確実にボットであり、リソースが確実にデジタルであり、金額が確実に少額であるマシン間呼び出しに優れている。カードネットワーク型スタックは、詐欺・払い戻し・規制の明確性が買い手のリスク計算を支配する場面に優れている。今後12〜24ヶ月で興味深い実証的問いは、中間地帯がどちら側かへ崩壊するのか、それともユースケースによって明確に分かれるのかだ。
システムが最初に壊れる場所
x402 のボリュームが引き続き成長すると仮定しよう。Coinbase はプロトコル初年度に1億6,900万件の決済、59万人の買い手、10万人の売り手を報告しているが、これらは監査を受けていない自己申告であり、方向性を示すものとして扱うべきで、確かな根拠のある数字として扱うべきではない。流通していた年間ドルボリュームの試算（~$600M）は今回参照したソース資料には記載がなく、事実として引用することは控える。Coinbase は「決済」にリトライ、遅延スキームの署名コミットメント、オンチェーン確定済みの送金のいずれが含まれるかを明確にしておらず、表面上の数字をいかなるカードネットワークのベースラインとも比較することが困難だ。
それでも成長を額面どおりに受け取ったとして、いくつかの障害シナリオが見えてくる。
ファシリテーターの集中化
最も直近の問題だ。両ハイパースケーラーのデプロイメントが Coinbase のファシリテーターに集中している。これが劣化すれば、ペイウォールはフェイルオープン（トラフィックが無課金で通過）またはフェイルクローズ（トラフィックが拒否される）になる。エッジスケールではどちらも望ましくない。可用性の問題に加え、価格支配力も無制約だ。現在の1取引あたり$0.001という料率はカードインターチェンジと比べて魅力的だが、依存関係が固まった後に値上げを防ぐ契約上の保護はどこにもない。
委任詐欺とヒューマン・ノット・プレゼント問題
x402 の認可モデルは、支出制限の執行をウォレットに依拠している。エージェントランタイムが侵害された場合 — プロンプトインジェクション、モデルへのサプライチェーン攻撃、エージェントフレームワークのバグなどによって — ウォレットの制限が許す範囲で任意の決済を実行できてしまう。ウォレットは正規のエージェント行動と乗っ取られた行動を区別できない。どちらも同じ鍵で署名されるからだ。
AP2 の Verifiable Intent はこれへの直接の答えだ。ユーザーが何を認可したかを記録する暗号学的ログを、エージェントのランタイム状態から独立して検証できる。x402 には同等のものがない。監査ログなしにウォレットレベルのセッションキーとスマートコントラクトの支出ポリシーで十分かどうかは未解決の問いであり、規制対象エンタープライズはこれを保守的に判断する可能性が高い。
消費税（VAT）、インボイス、税務管轄
AWS も Cloudflare も、エージェントからの匿名のステーブルコイン決済がいかにして EU の適格 VAT インボイスを生成するかを説明していない。EU の規則では、売り手は買い手の管轄を特定し、正しい VAT 税率を適用し、特定のフィールドを持つインボイスを発行しなければならない。x402 の決済が提供するのはオンチェーンアドレスであり、買い手のアイデンティティや管轄ではない。欧州のエンタープライズにとってこれは小さな問題ではなく、現在の仕様では解決されていない。
払い戻し・紛争のセマンティクス
USDC 送金は不可逆だ。エージェントがリソースに対して支払いを行い、そのリソースが不正、欠落、または誇大広告だった場合、x402 はプロトコルレベルでの救済パスを提供しない。加盟店が自発的に返金することはできるが、責任を転嫁して加盟店に配信の証明を求めるカードネットワークのチャージバックに相当するものはない。品質に主観の余地がある競合取引 — そのあらゆる場面 — において、x402 は帯域外の紛争レイヤーなしには構造的に不向きだ。
スケールにおける手数料の経済性
ファシリテーター手数料1取引あたり$0.001はカードインターチェンジの1.5〜3%と比べて有利に見える。しかし高価値取引でフラットフィーになれば有利ではなくなるし、基礎チェーンのコスト（Base や Solana ですら）が支配的になりはじめるほど超少額取引では有利ではなくなる。遅延スキームは決済を償却することでこの緊張を解消するが、その代償としてカードネットワークの運営上の複雑さを再導入する信用関係が生じる。
ブートストラップ問題
ボットはペイウォールを無視して無料のエンドポイントや合成データを使うことができる。執行には十分な高価値コンテンツが有料エッジの背後に実際に置かれることが必要だ。これは歴史的なマイクロペイメントスキーム（Flattr、Bitcoin Lightning）が解決できなかった鶏と卵の問題だ。x402 の構造的な賭けは、買い手が人間ではないエージェントであることで、以前の試みを殺した UX の摩擦が取り除かれるというものだ。それは筋が通っているが証明されていない。エンタープライズのリスク管理がエージェントウォレットに人間のマイクロペイメントを殺したのと同じ認可の摩擦を課すなら、この賭けは弱くなる。
示唆と未解決の問い
現状についての最も堅固な読み方は、x402 がエージェント決済問題の「あまり重要でない半分」 — 価値の移転 — は解決し、「より困難な半分」 — 認可、監査、払い戻し、規制適合 — にはほとんど手をつけていないというものだ。カードネットワーク側のスタックは困難な半分をほぼ解決しており、その上にエージェント認可を接ぎ木しつつある。2つのトラックが収束するか、層化するか、一方が他方を駆逐するかは、現時点ではまだ答えられない問いにかかっている。
- 独立したファシリテーター市場は出現するか？ 2027年半ばまでに実際のトラフィックを持つ第2のファシリテーターが登場しなければ、「オープンプロトコル」という位置づけは機能的に空洞だ。2〜3社登場すれば、中央集権化への批判は大きく和らぐ。
- 遅延スキームが主要な決済モードになるか？ そうなれば、x402 は決済のための HTTP ネイティブなアイデンティティ・認可プロトコルへと進化し、決済レールは交渉可能なものになる。それは純粋なステーブルコインマイクロペイメントとは本質的に異なる — そして、より耐久性のある — プロダクトだ。
- Verifiable Intent または x402 の同等物が標準化されるか？ ユーザー認可の暗号監査ログなしに、自律型エージェント決済のエンタープライズ採用は、送金のいかなる技術的特性とも無関係にガバナンス上の異議に直面する。
- 「決済」はどう定義されるか？ Coinbase の報告ボリューム数は、集計方法論が公開されるまでカードネットワークのボリュームと意味のある比較ができない。これは小さな会計上の問いではない。成長のストーリーが本物かどうかを決定する問いだ。
- 規制上の取り扱いはどこに落ち着くか？ FinCEN、EU MiCA、x402 ステーブルコイン決済への FATF トラベルルールの適用可能性は、いずれのドキュメントにも記載がない。エンタープライズ側の買い手は、AML のスタンスが未確定なプロトコルに大規模展開しないだろう。
今後12ヶ月で読者が注目すべきなのはボリューム数ではない — それらは自己申告であり、定義上ソフトな数字だ。第2のファシリテーターを注視せよ。仕様への正式な払い戻し・紛争メカニズムの追加を注視せよ。初の規制対象エンタープライズ（銀行、取引所、パブリッシャー）が監査合格のデプロイメントを公表する瞬間を注視せよ。そして AP2 と x402 が FIDO と Linux Foundation を通じて明示的な相互運用作業を開始するか、それとも重複しないスタックへと固まっていくかを注視せよ。
ファシリテーターが単一のままであり監査ログのギャップが埋まらないなら、x402 は本物だが限定的なニッチを占め続けるだろう。ステーブルコイン決済リスクを受け入れ、どちらの当事者も払い戻し権利を必要としない、デジタルリソースに対するエージェント間マイクロペイメントだ。それは確かな市場だ。しかしローンチ資料が示唆する汎用エージェントコマースレールではない。カードネットワークはその場合、中抜きされるというよりも補完されることになり、レールは取引タイプによってきれいに層化する。
代替の結果 — 遅延決済が成熟し、独立したファシリテーターが登場し、Verifiable Intent の同等物が仕様に組み込まれる未来 — では、x402 はより広いユースケースのセットでカードネットワーク型スタックへの正当な HTTP レイヤーの競合相手として立つ。どちらの結果が現在より有力かは、ソースの支持する根拠からは判断できない。次の12ヶ月でほとんどの曖昧さは解消されるだろう。
参考文献
- InfoQ, Cloudflare and AWS Embed x402 Agent Payments at the Edge, July 2026.
- Visa, Visa Partners with OpenAI to Power the Next Generation of AI Commerce, 10 June 2026.
- Google, Donating Agent Payments Protocol to the FIDO Alliance.
- Cloudflare, Launching the x402 Foundation with Coinbase, 23 September 2025.
- Coinbase Developer Platform, x402 Overview.
引言
当两家超大规模云服务商在数周内相继在各自网络边缘推出同一支付原语时，真正值得关注的问题并非哪款产品会胜出，而是这个底层协议做了哪些信任假设，以及当流量真正涌入时，谁会坐在中间那个位置。
这正是 x402 在 2026 年中的处境。该协议将长期休眠的 HTTP 402 状态码——1997 年在 HTTP/1.1 中预留、始终未经标准化落地——改造为一套机器间支付握手机制，结算主要通过 USDC 在 Base 和 Solana 上完成。Coinbase 起草了这套协议，并于 2026 年 4 月将其捐献给 Linux 基金会，成立了 x402 基金会；与此同时，Coinbase 仍是目前所有主要部署实际依赖的唯一生产级协调者（facilitator）。AWS CloudFront 已将 x402 作为正式发布（GA）功能部署在边缘节点，Cloudflare 的 Monetization Gateway 则处于候补名单阶段。Anthropic、Circle、Stripe 等 20 余家机构已加入基金会成为成员。
与此同时，卡组织并未袖手旁观。2026 年 6 月 10 日，Visa 宣布与 OpenAI 达成战略合作，将代币化 Visa 凭证嵌入由智能体驱动的商业场景。Google 将其 Agent Payments Protocol（AP2） 捐赠给 FIDO 联盟，并联合 Mastercard 贡献了一套名为 Verifiable Intent 的防篡改审计日志标准。两条支付路径由此清晰呈现：一条在 HTTP 层以稳定币结算，另一条在现有卡轨之上为智能体授权。
我们认为，更有价值的分析框架不是”谁会赢”，而是：各套架构的信任假设分别落在哪里，随着交易量增长哪里会率先出现问题，以及这两条路径最终会走向融合、分层，还是相互取代。以下内容将逐层剖析 x402 的机制，如实呈现其中心化与结算问题，并与卡组织的应对方案进行比较。
背景：「智能体支付」究竟意味着什么
在进入协议细节之前，有必要先把问题本身说清楚。智能体支付是指由软件代表用户发起的交易——没有人坐在结账页面前，通常也没有提前建立固定的商家关系。比如：由大语言模型驱动的调研智能体按 API 调用次数付费购买数据源；爬虫向出版商支付内容抓取权限；代码助手按需申请云资源。
传统支付架构假定有人在点击、有预先开通的账户、有带外（out-of-band）签发的 API 密钥，或者有订阅关系。智能体把这四个假设全部打破了。它们没有账户、没有预注册的支付方式、无法等待一套结账流程，而且单笔交易金额往往极低——卡组织收取的 ~1.5–3% 手续费在此场景下根本行不通。
流量结构已经发生了切实的变化。Cloudflare 报告显示，截至 2026 年 6 月，AI 训练爬虫流量占其爬虫总流量的 52%，而 2025 年春季这一比例仅为 22%。面向从不看广告、从不注册账号的”读者”，基于广告和订阅的出版经济模式根本无从发挥作用。这正是 x402 背后的需求侧压力。
这一领域有两个关键设计选择：
- 授权逻辑落在哪里？ 是在用户的钱包中（x402），还是在卡组织的策略层——带有消费限额、商家类别管控和审批规则（Visa Intelligent Commerce、AP2）？
- 结算发生在哪里？ 是每笔请求都在公链上结算，还是链下批量聚合后再结算，抑或是走现有的卡和银行轨道？
x402 最初选择了钱包持有授权加上每笔请求在链上以 USDC 结算。它现在正在提出一套延迟结算方案，放宽了对第二个选择的约束。卡组织方案则选择了网络层持有授权加上现有轨道。后续所有的权衡取舍都由此生发。
x402 支付流程，逐跳拆解
核心协议刻意设计得极为精简。根据 Cloudflare 发布博文和 Coinbase 开发者文档的记录，一笔 x402 支付分五步完成：
- 发起请求。 客户端——通常是嵌入了钱包的智能体——向资源 URL 发送一个普通 HTTP 请求。
- 返回 402 响应。 服务器以 HTTP 402 响应，并附带一个 JSON 载荷，描述可接受的支付方案、支持的网络（如 Base、Polygon、Arbitrum、World、Solana）、可接受的资产（通过 EIP-3009 的 USDC、EURC，或通过 Permit2 的任意 ERC-20 代币）、价格以及收款地址。
- 携带支付授权重新请求。 客户端重新发送请求，在
X-PAYMENT请求头中附上签名的支付授权——对于 EIP-3009，这是一个transferWithAuthorization签名，允许第三方从客户端钱包中划转指定金额。 - 协调者验证与结算。 服务器将授权转发给协调者（facilitator），协调者验证签名、检查客户端的链上余额，并将转账提交至目标链。在所有有据可查的生产部署中，该协调者均为 Coinbase 的 CDP。
- 资源交付。 链上确认后，服务器返回资源，并在
X-PAYMENT-RESPONSE响应头中附上结算收据。
每一跳都有其独特的信任假设，有必要逐一明确。
信任究竟落在哪里
客户端钱包是托管的根。无论谁持有签名密钥，都能在余额范围内随意划转资金。对于自主运行的智能体而言，这把密钥必须存放在智能体运行时可访问的地方——这在安全态势上天然弱于由用户持有的硬件密钥。钱包层面的消费限额（通过智能合约钱包或 session key 实现）是主要防线，但这些限额的设计与执行并不属于 x402 协议本身，而是委托给钱包协议栈处理。
协调者被信任为：诚实地验证签名、在合理时间窗口内将交易提交至正确的链，以及如实向双方汇报结算情况。它不被信任托管资金——EIP-3009 签名的作用域仅限于单笔特定金额和特定收款方——但它被信任于保持服务可用，以及向商家如实报告结算状态。若协调者谎报结算状态，商家可在链上独立核实，但只能是事后核查。
链提供结算最终性。Base 和 Solana 均具备亚秒级出块时间，对于金额足够小、链重组风险可忽略不计的 USDC 交易，数秒内即可达到有效最终性。这与比特币闪电网络时代的微支付方案有本质区别。
服务器被信任在支付结算后确实交付资源。链上并无对交付行为的强制约束，更关键的是——若资源质量低劣、内容缺失或存在虚假描述，协议层面也没有退款或撤单路径。USDC 转账默认不可逆。
协调者不可用时会发生什么
所有有文档记录的部署均未描述降级回退路径。若 Coinbase 的 CDP 协调者出现故障，AWS CloudFront 和 Cloudflare Monetization Gateway 的集成将无法完成支付验证。协议规范允许任何人部署协调者，但 2026 年中的实际情况是：生产规模下只有一个协调者在运行。我们将在下文进一步探讨这一问题，因为这是整个架构中最尖锐的结构性风险。
协调者问题
x402 规范是开放的。任何人原则上都可以搭建一个协调者。Coinbase 的 CDP 协调者公开了接口，支持 Base、Polygon、Arbitrum、World 和 Solana，定价为每月 1,000 笔免费，超出后每笔 $0.001。卖方无需自行运行区块链基础设施——协调者将这些复杂性抽象掉了。
然而，从所有有据可查的部署来看——AWS CloudFront、Cloudflare Monetization Gateway，以及 Coinbase 托管 SDK 的集成——生产环境中的协调者均为 Coinbase 的。没有任何独立协调者被记录为已投入运营。原因并不难理解：
- 资产负债表压力。 协调者在签名验证与链上确认之间的时间窗口内承担结算风险，小型运营商难以对这一风险进行合理定价。
- 多链覆盖要求。 以低延迟支持五条链需要在每条链上维护节点、索引器和监控系统。
- 路线图功能壁垒。 可选的 KYC 认证和地理限制——这些都在 Coinbase 明确表示的路线图上——恰恰是受监管买方所必须的功能，而要可靠地构建这些功能，需要大多数加密团队并不具备的合规法律基础设施。
- 集成锁定效应。 一旦 AWS 和 Cloudflare 以单一协调者为基准完成验证，商家迁移至其他协调者的切换成本便不容小觑，即便接口是标准化的。
由此产生的后果是：一个以”无许可 HTTP 层支付”为卖点的协议，在底层管道层面，实际上只有一个商业守门人。这个守门人可以调整定价、施加合规条件、限制地域，并在法律压力下将特定商家或钱包下线。这并非假设——Coinbase 已在美国监管框架下运营，而该框架完全有可能对其施加上述管控。
Linux 基金会的治理模式旨在防止规范被专有化，但它并不能阻止协调者市场的运营集中化。这是两个不同的问题。规范开放的意义，远不及是否真正出现一个拥有显著流量的第二家协调者。截至 2026 年中，尚无此类案例有据可查。
延迟结算：通向企业级可用性的路径
Cloudflare 在 2025 年 9 月的发布博文中描述了一种它称为延迟支付方案的变体。这一方案值得仔细研读，因为它在实质上改变了信任模型，也可以说是规范中更具深远影响的提案。
在即时结算方案中，每一个通过付费墙的 HTTP 请求都会触发一笔链上转账。以 Base 或 Solana 的成本来看，对于中等价值的交易这尚可接受，但 Cloudflare 报告的日均 HTTP 402 响应量超过十亿次——面向机器人和爬虫流量——逐笔结算的浪费将大得令人咋舌，况且若同一买家在一小时内向同一出版商发出数千次请求，这种做法更是毫无意义。
延迟方案将密码学握手与结算分离。客户端不再为每笔请求提供 EIP-3009 签名，而是出示使用 JWK 公钥的 HTTP Message Signature 来建立身份认证，服务器放行请求，结算则按日、按周或按订阅周期聚合进行，可以完全在链下完成，包括通过信用卡结算。Cloudflare 的按爬取量付费私测版就是如此运作的：每笔请求一个 HTTP 签名，当日结束时通过信用卡结算。
这里同时存在两个事实。延迟方案解决了费用经济性和吞吐量问题——这些问题若不解决，将把 x402 限制在真正高价值的调用场景中。但与此同时，它也在一定程度上消解了该协议最初的加密原生结算主张。如果结算层是按日批量走信用卡，那么 x402 已不再在经济性上与卡轨竞争——它竞争的是 HTTP 原生的身份识别与授权层面，实际的资金流动仍由卡轨完成。
延迟方案还引入了新的信任假设。服务器现在需要在签名请求与结算之间向买方垫资。即时方案中，商家知道结算在数秒内即告最终确认；延迟方案中，商家依赖 HTTP 签名背后的身份方既有足够偿付能力，又不会否认交易。这是一种不同的风险模型，更接近企业间 net-30 账期的信用关系，而非稳定币支付。
规范明确指出这仍是一项提案，尚未经过正式批准；参考资料中提及的 HTTP Message Signature 构建方式也未经过安全审计。这一方案很可能（但不确定）是大多数企业实际采用的方式。
竞争架构
x402 并非唯一的方案，其他替代方案也绝非表面文章。卡组织已在不同的架构路径上形成合力——在现有轨道之上增加智能体授权层，而非替换底层轨道。
Visa Intelligent Commerce 与 OpenAI 合作
Visa 在 2026 年 6 月 10 日与 OpenAI 联合发布的公告，将 Visa 定位为代币化、网络与风险管理层，OpenAI 则提供智能体交互界面。交易使用代币化 Visa 凭证，配备实时授权和欺诈监测。消费限额、商家类别管控和审批要求均可按用户进行配置——这套原语正是 Visa 多年来在商业卡上一直提供的能力，如今以智能体必须遵守的约束规则的形式对外开放。
技术架构在新闻稿中未予披露。公开的是其价值主张：信任背书、欺诈责任、退单权以及成熟的监管合规性——这些都是 x402 目前无从提供的。Visa 竞争的不是成本或可编程性，而是围绕一笔卡交易的整套运营体系——也就是”支付”中不属于资金划转本身的那部分。
AP2、FIDO 与 Verifiable Intent
Google 对 AP2 的处理方式又有所不同。通过将 AP2 捐赠给 FIDO 联盟，Google 试图将其确立为智能体发起支付的与平台无关的认证与授权标准——而 FIDO 联盟现有使命（WebAuthn、passkeys）已覆盖受监管金融所认可的身份层。AP2 v0.2 版本引入了 Human Not Present（无人在场）支付的概念，即智能体依据用户预授权的指令自主执行交易。
配套标准 Verifiable Intent 是与 Mastercard 共同开发、同样捐赠给 FIDO 的防篡改审计日志，记录用户授权智能体执行的操作，供任何下游参与方——商家、支付网络、监管机构、法庭——调取核查以解决争议。这恰恰是 x402 目前所缺乏的：一份可以密码学方式证明的记录，证明用户实际上授权智能体做了什么。
值得注意的是，AP2 被描述为与现有支付轨道兼容而非取而代之。它是一个策略与审计层，可以叠加在卡支付、银行转账之上，原则上也可叠加在稳定币转账之上。AP2 与 x402 究竟会形成分层关系（AP2 负责授权，x402 负责结算），还是直接竞争（AP2 自带结算能力），在现有资料中并无明确说明。
Mastercard Agent Pay 在话题背景中有所提及，但我们的资料来源中未对其技术细节进行记录，我们在此标注这一信息缺口，不作架构层面的猜测。
客观比较
| 维度 | x402（即时结算） | x402（延迟结算） | Visa Intelligent Commerce | AP2 + FIDO |
|---|---|---|---|---|
| 结算轨道 | USDC 链上 | 链下，含卡支付 | Visa 卡轨 | 与轨道无关 |
| 单笔成本 | ~分之一美分 | 摊销 | 卡组织手续费 | 取决于轨道 |
| 欺诈责任 | 未定义 | 未定义 | 卡网络模式 | 未规定 |
| 退款/退单 | 无 | 无 | 现有卡权利 | 取决于轨道 |
| 授权管控 | 钱包层面 | 钱包层面 | 网络策略层 | Verifiable Intent 日志 |
| 监管态势 | 尚待明确 | 尚待明确 | 成熟 | 成熟（依轨道而定） |
| 治理 | Linux 基金会 | Linux 基金会 | 专有 | FIDO 联盟 |
此处的认知陷阱在于将这些方案视为可直接替代的选项——实则并非如此。x402 在以下场景中表现最佳：买方明确是机器人、资源明确是数字内容、交易金额明确极小。卡组织方案在以下场景中表现最佳：欺诈风险、退款需求和监管合规主导买方的风险考量。未来 12–24 个月最值得关注的实证问题是：中间地带会向某一端坍缩，还是会沿用例清晰地分裂？
系统最先在哪里崩溃
假设 x402 的交易量持续增长。Coinbase 报告协议上线第一年共处理 1.69 亿笔支付、59 万名买家、10 万名卖家——这些数字均为未经审计的自我披露，应作为方向性参考，而非可供核实的事实。坊间流传的年化交易额估算（~$6 亿）并未出现在我们的资料来源中，我们拒绝将其作为事实引用。Coinbase 也未说明”一笔支付”是否包含重试请求、延迟方案的签名承诺，或仅限已在链上结算的转账——这使得总量数字难以与任何卡组织基准进行比较。
即便接受这一增长数字的大致方向，若干潜在失效模式已清晰可见。
协调者中心化
这是最迫在眉睫的问题。两大超规模云服务商的部署均汇聚至 Coinbase 的协调者。若其出现故障，付费墙将要么失效开放（流量未付费直接通过），要么失效关闭（流量被拒绝）——两者在边缘节点规模下都不可接受。此外，定价权完全不受约束。目前每笔 $0.001 的费率相较卡组织手续费颇具吸引力，但一旦依赖关系根深蒂固，协议中并无任何条款可防止费率上调。
授权欺诈与”无人在场”问题
x402 的授权模型依赖钱包执行消费限额。若智能体运行时遭到入侵——通过提示词注入、模型供应链攻击或智能体框架的漏洞——攻击者即可在钱包限额允许的范围内执行任意支付操作。钱包无法区分合法的智能体行为与被劫持的行为，因为两者均由同一密钥签名。
AP2 的 Verifiable Intent 正是对此的直接回应：一份可独立于智能体运行时状态核查的、关于用户实际授权内容的密码学记录。x402 没有等价机制。钱包层面的 session key 和智能合约消费策略，在没有审计日志的情况下是否已足够——这是一个悬而未决的问题，而受监管的企业很可能会给出保守的答案。
增值税、发票与税务管辖
AWS 和 Cloudflare 均未说明，来自智能体的匿名稳定币支付如何生成符合欧盟增值税要求的合规发票。根据欧盟规定，卖方必须识别买方的税务管辖地、适用正确的增值税税率，并开具包含特定字段的发票。一笔 x402 支付提供的是链上地址，而非买方身份或所在司法管辖区。对于欧洲企业而言，这绝非小问题，且在现有规范中没有解决方案。
退款与争议语义
USDC 转账不可逆。若智能体为某资源付款后，该资源存在格式错误、内容缺失或虚假描述，x402 协议层面不提供任何救济路径。商家可以自愿退款，但不存在类似卡组织退单机制那样的机制——能够转移责任并强制要求商家举证交付。对于有争议的交易——任何质量存在主观性的场景——x402 在结构上缺乏适当性，除非引入带外（out-of-band）争议解决层。
规模化下的费用经济性
协调者每笔 $0.001 的费率相较 1.5–3% 的卡组织手续费看似优越。但在极高交易量下，若这是针对高价值交易的固定费用，这一优势便不再成立；在极低交易量下，若底层链费用（即便是 Base 或 Solana）开始占主导，也是如此。延迟方案通过聚合结算消解了这一矛盾，但代价是引入了信用关系，从而重新带入卡组织运营模式的复杂性。
冷启动问题
机器人可以绕开付费墙，转而使用免费端点或合成数据。要真正执行付费，前提是足够多的高价值内容实际位于付费边缘之后——这是一个”先有鸡还是先有蛋”的问题，历史上的微支付方案（Flattr、比特币闪电网络）均未能解决。x402 押注的逻辑是：买方是非人类智能体，移除了此前扼杀人类微支付的用户体验摩擦。这一逻辑有其可能性，但尚未得到验证；若企业风控体系对智能体钱包施加了与此前人类微支付同等的授权摩擦，这一押注就会大打折扣。
启示与待解问题
对当前状态最站得住脚的解读是：x402 解决了智能体支付问题中较容易的那一半——价值的转移——而对更难的那一半几乎毫无建树：授权、审计、退款与监管合规性。卡组织方案已基本解决了较难的那一半，并正在其上嫁接智能体授权能力。两条路径是融合、分层，还是其一取代另一，取决于目前尚无法回答的若干问题：
- 独立协调者市场能否形成？ 若到 2027 年中仍未出现第二家拥有显著流量的协调者，“开放协议”的叙事在功能上便是空洞的。若出现两三家，中心化的批评则会大为弱化。
- 延迟结算方案会成为主要结算模式吗？ 若果真如此，x402 将演变为 HTTP 原生的支付身份识别与授权协议，结算轨道可以协商。这是一个在本质上截然不同——也可以说更为持久——的产品，而非纯粹的稳定币微支付工具。
- Verifiable Intent 或其 x402 等价物能否完成标准化？ 没有用户授权的密码学审计日志，企业对自主智能体支付的采用将遭遇治理层面的阻力，这与支付转移的技术属性无关。
- “一笔支付”如何定义？ 在统计方法论公开披露之前，Coinbase 报告的交易量数字无法与卡组织的交易量进行有意义的比较。这不是细枝末节的会计问题；它决定了增长故事是否真实。
- 监管定性将落于何处？ FinCEN、欧盟 MiCA 以及 FATF 旅行规则对 x402 稳定币支付的适用性，在我们接触到的任何文档中均未涉及。企业买方不会在 AML 态势尚不明朗的协议上规模化部署。
未来十二个月，读者应当关注的不是交易量数字——那些是自我披露的，天然缺乏硬度。要关注：第二家协调者何时出现；第一家受监管的企业（银行、交易所、出版商）何时发布通过审计的部署报告；规范中何时出现正式的退款或争议机制；以及 AP2 与 x402 是否会通过 FIDO 和 Linux 基金会启动明确的互操作性合作，还是硬化为互不重叠的平行架构。
若协调者始终单一、审计日志的缺口始终未填，x402 将占据一个真实但有限的细分市场：数字资源的智能体间微支付，适用于运营方能够接受稳定币结算风险、且双方均不需要退款权利的场景。这是一个真实存在的市场，但并非发布材料所暗示的通用智能体商业轨道。届时，卡组织非但未被颠覆，反而将与 x402 形成互补，各条轨道按交易类型清晰分层。
另一种可能的结局是：延迟结算逐渐成熟，独立协调者相继涌现，Verifiable Intent 的等价机制被加入规范——届时 x402 将成为 HTTP 层上对卡组织方案的真正竞争者，覆盖更广泛的用例。基于现有资料，两种结局目前并无高下之分。未来十二个月应能消除大部分的不确定性。
参考资料
- InfoQ, Cloudflare and AWS Embed x402 Agent Payments at the Edge, July 2026.
- Visa, Visa Partners with OpenAI to Power the Next Generation of AI Commerce, 10 June 2026.
- Google, Donating Agent Payments Protocol to the FIDO Alliance.
- Cloudflare, Launching the x402 Foundation with Coinbase, 23 September 2025.
- Coinbase Developer Platform, x402 Overview.
Introducción
Cuando dos hyperscalers lanzan el mismo primitivo de pago en el extremo de sus redes con pocas semanas de diferencia, la pregunta interesante no es cuál producto gana. La pregunta es qué asume el protocolo subyacente, y quién termina sentado en el medio cuando el tráfico comienza a fluir.
Esa es la posición que ocupa x402 a mediados de 2026. El protocolo repropone el código de estado HTTP 402 —reservado en HTTP/1.1 en 1997 y nunca estandarizado para uso real— como un handshake de pago máquina a máquina liquidado principalmente en USDC sobre Base y Solana. Coinbase lo redactó, lo donó a la Linux Foundation como la x402 Foundation en abril de 2026, y sigue operando el único facilitador en producción del que depende toda implementación relevante. AWS CloudFront ahora aplica x402 en el edge como una funcionalidad de disponibilidad general. El Monetization Gateway de Cloudflare está en lista de espera. Anthropic, Circle, Stripe y más de 20 miembros adicionales forman parte de la fundación.
Mientras tanto, las redes de tarjetas no han estado ociosas. Visa anunció una colaboración estratégica con OpenAI el 10 de junio de 2026 para incrustar credenciales Visa tokenizadas en el comercio impulsado por agentes. Google donó su Agent Payments Protocol (AP2) a la alianza FIDO y, junto con Mastercard, contribuyó un estándar de registro de auditoría a prueba de manipulaciones llamado Verifiable Intent. Ahora son claramente visibles dos vías de pago: una que liquida en stablecoins en la capa HTTP, y otra que autoriza agentes sobre los rieles de tarjetas existentes.
Creemos que el encuadre más útil no es “quién gana”, sino dónde residen los supuestos de confianza de cada stack, qué falla primero a medida que crece el volumen, y si las dos vías convergen, se estratifican o se desplazan mutuamente. Lo que sigue es un análisis a nivel de mecanismo de x402, una evaluación honesta de sus problemas de centralización y liquidación, y una comparación frente a la respuesta de las redes de tarjetas.
Contexto: qué significa realmente “pagos agénticos”
Antes de los detalles del protocolo, vale la pena nombrar el problema. Un pago agéntico es una transacción iniciada por software que actúa en nombre de un usuario, sin un humano en la página de pago y a menudo sin una relación de comerciante establecida de antemano. Un agente de investigación impulsado por LLM que paga por llamada de API por un feed de datos. Un crawler que le paga a un editor por el derecho a procesar una página. Un asistente de código que provisiona un recurso en la nube bajo demanda.
Los stacks de pago tradicionales asumen un humano haciendo clic, una cuenta provisionada de antemano, una clave de API emitida fuera de banda, o una suscripción. Los agentes rompen los cuatro supuestos. Llegan sin cuentas, sin métodos de pago preregistrados, sin paciencia para un flujo de pago, y a menudo con valores muy bajos por transacción donde el interchange de tarjetas (~1,5–3%) resulta prohibitivo.
La composición del tráfico ya ha cambiado. Cloudflare reportó que el entrenamiento de IA representó el 52% de su tráfico de crawlers en junio de 2026, frente al 22% en la primavera de 2025. La economía de publicidad y suscripciones del lado del editor no fue diseñada para lectores que nunca ven un anuncio y nunca se registran. Esa es la presión del lado de la demanda detrás de x402.
Dos decisiones de diseño definen el espacio:
- ¿Dónde reside la autorización? En la wallet de un usuario (x402), ¿o en una capa de política de red de tarjetas con límites de gasto, controles de categoría de comerciante y reglas de aprobación (Visa Intelligent Commerce, AP2)?
- ¿Dónde ocurre la liquidación? En una blockchain pública por solicitud, agregada off-chain y liquidada después, ¿o a través de los rieles de tarjetas y bancos existentes?
x402 eligió inicialmente la autorización custodiada en la wallet y la liquidación on-chain por solicitud en USDC. Ahora está proponiendo un esquema diferido que relaja la segunda elección. Los stacks de redes de tarjetas eligieron la autorización custodiada en la red con los rieles existentes. Las compensaciones se derivan de ahí.
El flujo de x402, salto a salto
El protocolo central es deliberadamente austero. Tal como está documentado en el post de lanzamiento de Cloudflare y la documentación para desarrolladores de Coinbase, un pago x402 se resuelve en cinco pasos:
- Solicitud. Un cliente —típicamente un agente con una wallet integrada— emite una solicitud HTTP ordinaria a una URL de recurso.
- Respuesta 402. El servidor responde con HTTP 402 y un payload JSON que describe los esquemas de pago aceptables, las redes aceptadas (p. ej. Base, Polygon, Arbitrum, World, Solana), los activos aceptados (USDC, EURC vía EIP-3009, o ERC-20 arbitrarios vía Permit2), el precio y la dirección del destinatario.
- Reintento con autorización de pago. El cliente reenvía la solicitud con un encabezado
X-PAYMENTque contiene una autorización de pago firmada —para EIP-3009, se trata de una firmatransferWithAuthorizationque permite a un tercero retirar el importe especificado de la wallet del cliente. - Verificación y liquidación por el facilitador. El servidor reenvía la autorización a un facilitador, que verifica la firma, comprueba el saldo on-chain del cliente y envía la transferencia a la cadena objetivo. En toda implementación en producción documentada, este facilitador es el CDP de Coinbase.
- Entrega del recurso. Tras la confirmación, el servidor devuelve el recurso con un encabezado
X-PAYMENT-RESPONSEque contiene el recibo de liquidación.
Cada salto tiene un supuesto de confianza distinto, y vale la pena nombrarlos con precisión.
Dónde reside realmente la confianza
La wallet del cliente es la raíz de la custodia. Quien tenga la clave de firma puede vaciarla hasta el saldo disponible. Para un agente autónomo, esta clave debe residir en algún lugar accesible al runtime del agente —una postura de seguridad fundamentalmente más débil que una clave hardware en manos del usuario. Los límites de gasto a nivel de wallet (a través de smart contract wallets o session keys) son la defensa principal, pero el diseño y la aplicación de esos límites no forman parte de x402 en sí; se delegan al stack de la wallet.
El facilitador es confiable para verificar firmas honestamente, enviar la transacción a la cadena correcta dentro de una ventana razonable, e informar la liquidación con veracidad a ambas partes. No tiene custodia —la firma EIP-3009 tiene alcance limitado a una sola transferencia de monto y destinatario—, pero sí se confía en su disponibilidad y en la exactitud de su reporte al comerciante. Si el facilitador miente sobre el estado de la liquidación, el comerciante puede verificarlo on-chain de forma independiente, pero solo después del hecho.
La cadena provee la finalidad de liquidación. Tanto Base como Solana ofrecen tiempos de bloque inferiores a un segundo y finalidad efectiva en cuestión de segundos para montos denominados en USDC lo suficientemente pequeños como para que el riesgo de reorganización sea negligible. Esto es materialmente diferente de los esquemas de micropagos de la era Bitcoin-Lightning.
El servidor es confiable para efectivamente entregar el recurso una vez que se liquida el pago. No hay aplicación on-chain de la entrega y —de manera crítica— tampoco existe una vía de contracargo o reembolso si el recurso resulta ser basura. Las transferencias de USDC son irreversibles por defecto.
Qué ocurre cuando el facilitador no está disponible
Ninguna de las implementaciones documentadas describe una ruta de respaldo. Si el facilitador CDP de Coinbase devuelve errores, tanto las integraciones de AWS CloudFront como las del Monetization Gateway de Cloudflare pierden su capacidad de verificar el pago. La especificación del protocolo permite que exista cualquier facilitador, pero la realidad operativa a mediados de 2026 es que solo uno opera a escala de producción. Volvemos sobre esto más adelante porque es el riesgo estructural más agudo del stack.
El problema del facilitador
La especificación de x402 es abierta. En principio, cualquiera puede levantar un facilitador. El facilitador CDP de Coinbase publica su interfaz, admite Base, Polygon, Arbitrum, World y Solana, y tiene un precio de 1.000 transacciones mensuales gratuitas con $0,001 por transacción a partir de ahí. Los vendedores no necesitan operar infraestructura blockchain —el facilitador la abstrae.
En la práctica, en cada implementación documentada en el material fuente —AWS CloudFront, el Monetization Gateway de Cloudflare y las integraciones del SDK hospedado por Coinbase— el facilitador en producción es el de Coinbase. No se documenta ningún facilitador independiente en operación. Las razones no son misteriosas:
- Balance. Un facilitador asume riesgo de liquidación en la ventana entre la verificación de la firma y la confirmación on-chain. Los operadores pequeños tienen dificultades para valorar este riesgo.
- Cobertura de cadenas. Admitir cinco cadenas con baja latencia requiere nodos, indexadores y monitoreo para cada una.
- Funcionalidades del roadmap. Las atestaciones KYC opcionales y las restricciones geográficas —elementos en el roadmap declarado de Coinbase— son exactamente las funcionalidades que los compradores regulados exigirán, y construirlas de forma creíble requiere infraestructura legal que la mayoría de los equipos de cripto no posee.
- Lock-in de integración. Una vez que AWS y Cloudflare validaron contra un único facilitador, el costo de migración para un comerciante es considerable, aunque la interfaz sea estándar.
La consecuencia es que un protocolo comercializado como pagos HTTP-nativos sin permiso tiene, en la capa de plomería, exactamente un único guardián comercial. Ese guardián puede ajustar precios, imponer condiciones de cumplimiento, restringir geografías y —bajo presión legal— dar de baja a comerciantes o wallets específicos. Esto no es hipotético: Coinbase ya opera bajo un régimen regulatorio estadounidense que podría imponer exactamente estos controles.
El modelo de gobernanza de la Linux Foundation está destinado a evitar la captura propietaria de la especificación. No evita la concentración operativa en el mercado de facilitadores. Esos son problemas distintos. Que la especificación sea abierta importa menos que si emerge un segundo facilitador con tráfico significativo. A mediados de 2026, no se documenta ninguno.
Liquidación diferida: la vía viable para empresas
El post de lanzamiento de Cloudflare de septiembre de 2025 describió una variante que denomina el esquema de pago diferido. Vale la pena analizarla con detenimiento porque cambia el modelo de confianza de manera sustancial y es, se podría argumentar, la propuesta más relevante de la especificación.
En el esquema inmediato, cada solicitud HTTP que franquea un muro de pago desencadena una transferencia on-chain. A los costos de Base o Solana esto es defensible para transacciones de valor medio, pero con el volumen reportado por Cloudflare de más de mil millones de respuestas HTTP 402 diarias contra tráfico de bots y crawlers, la liquidación por solicitud es prohibitivamente costosa —e innecesaria si el mismo comprador realizará mil solicitudes al mismo editor en una hora.
El esquema diferido separa el handshake criptográfico de la liquidación. En lugar de una firma EIP-3009 por solicitud, el cliente presenta una HTTP Message Signature usando una clave pública JWK, estableciendo identidad. El servidor permite la solicitud. La liquidación se agrega —diaria, semanal, o por suscripción— y puede ocurrir completamente off-chain, incluso mediante tarjeta de crédito. La beta privada de pago-por-crawl de Cloudflare usa exactamente esto: firma HTTP por solicitud, liquidación con tarjeta de crédito al final del día.
Dos cosas son simultáneamente ciertas sobre esto. Resuelve los problemas de economía de comisiones y rendimiento que de otro modo limitarían x402 a llamadas de alto valor genuino. Y en parte disuelve la tesis original del protocolo de liquidación cripto-nativa. Si la capa de liquidación son tarjetas de crédito agregadas al final del día, x402 ya no compite con los rieles de tarjetas en economía —compite en la superficie de identidad y autorización HTTP-nativa, con los rieles de tarjetas haciendo el movimiento real del dinero.
El esquema diferido también introduce nuevos supuestos de confianza. El servidor ahora extiende crédito al comprador entre la solicitud firmada y la liquidación. En el esquema inmediato, el comerciante sabía que la liquidación era definitiva en segundos. En el esquema diferido, el comerciante depende de que la identidad detrás de la firma HTTP sea solvente y no repudie la transacción. Ese es un modelo de riesgo diferente, más cercano a una relación corporativa a 30 días netos que a un pago en stablecoin.
La especificación aclara que esto es una propuesta, no una funcionalidad ratificada, y no existe auditoría de seguridad de la construcción de HTTP Message Signature referenciada en el material fuente. Es probable, aunque no seguro, que este sea el esquema que la mayoría de las empresas adopte en la práctica.
Los stacks competidores
x402 no es la única propuesta, y las alternativas no son superficiales. Las redes de tarjetas han convergido en una arquitectura diferente que preserva sus rieles existentes mientras agrega una capa de autorización de agentes por encima de ellos.
Visa Intelligent Commerce y la colaboración con OpenAI
El anuncio de Visa del 10 de junio de 2026 con OpenAI posiciona a Visa como la capa de tokenización, red y riesgo, con OpenAI proveyendo la interfaz del agente. Las transacciones usan credenciales Visa tokenizadas con autorización en tiempo real y monitoreo de fraude. Los límites de gasto, los controles de categoría de comerciante y las aprobaciones requeridas se configuran por usuario —los mismos primitivos que Visa ha ofrecido en tarjetas comerciales durante años, ahora expuestos como restricciones dentro de las cuales debe operar un agente.
La arquitectura técnica no se revela en el comunicado de prensa. Lo que sí se revela es la propuesta de valor: confianza, responsabilidad por fraude, derechos de contracargo y certeza regulatoria. Nada de esto lo ofrece actualmente x402. Visa no está compitiendo en costo o programabilidad. Está compitiendo en todo el aparato operativo que rodea a un pago con tarjeta —las partes de los “pagos” que no son la transferencia en sí.
AP2, FIDO y Verifiable Intent
El enfoque de Google con AP2 es distinto. Al donar AP2 a la alianza FIDO, Google intenta establecerlo como un estándar de autenticación y autorización agnóstico de plataforma para pagos iniciados por agentes —gobernado por una alianza cuyo mandato existente (WebAuthn, passkeys) ya cubre la capa de identidad que las finanzas reguladas reconocen. La versión AP2 v0.2 introdujo el concepto de pagos Human Not Present, donde los agentes ejecutan transacciones de forma autónoma contra instrucciones preautorizadas por el usuario.
El estándar complementario, Verifiable Intent, es un registro de auditoría a prueba de manipulaciones de las acciones del agente autorizadas por el usuario, codesarrollado con Mastercard y también donado a FIDO. Esta es la pieza que actualmente le falta a x402: un registro criptográficamente aplicable de lo que el usuario realmente autorizó al agente a hacer, que cualquier parte involucrada —comerciante, red, regulador, tribunal— puede inspeccionar para resolver disputas.
Cabe destacar que AP2 se describe como compatible con los rieles de pago existentes, no como un reemplazo. Es una capa de política y auditoría que puede situarse sobre tarjetas, transferencias bancarias o, en principio, transferencias en stablecoin. Si AP2 y x402 se estratifican (AP2 como autorización, x402 como liquidación) o compiten (AP2 con su propia liquidación) no queda claro en el material fuente.
Mastercard Agent Pay aparece en el ángulo del tema pero no está documentado técnicamente en nuestras fuentes. Señalamos esto como una brecha en lugar de especular sobre su arquitectura.
La comparación honesta
| Dimensión | x402 (inmediato) | x402 (diferido) | Visa Intelligent Commerce | AP2 + FIDO |
|---|---|---|---|---|
| Riel de liquidación | USDC on-chain | Off-chain, incl. tarjetas | Rieles de tarjeta Visa | Agnóstico del riel |
| Costo por transacción | ~fracción de centavo | Amortizado | Interchange de tarjeta | Depende del riel |
| Responsabilidad por fraude | No definida | No definida | Modelo de red de tarjetas | No especificada |
| Reembolsos/contracargos | Ninguno | Ninguno | Derechos de tarjeta vigentes | Depende del riel |
| Autorización de mandato | A nivel de wallet | A nivel de wallet | Capa de política de red | Registro Verifiable Intent |
| Postura regulatoria | En desarrollo | En desarrollo | Consolidada | Consolidada (vía riel) |
| Gobernanza | Linux Foundation | Linux Foundation | Propietaria | Alianza FIDO |
La trampa de la falsa equivalencia aquí es tratar estas opciones como directamente sustituibles. No lo son. x402 destaca en llamadas máquina a máquina donde el comprador es definitivamente un bot, el recurso es definitivamente digital y el valor es definitivamente pequeño. Los stacks de redes de tarjetas destacan donde el fraude, los reembolsos y la claridad regulatoria dominan el cálculo de riesgo del comprador. La pregunta empírica interesante durante los próximos 12–24 meses es si el espacio intermedio colapsa hacia un lado o se divide claramente por caso de uso.
Dónde falla primero el sistema
Supongamos que el volumen de x402 sigue creciendo. Coinbase reporta 169 millones de pagos, 590.000 compradores y 100.000 vendedores en el primer año del protocolo —cifras que son autoreportes no auditados y deben tratarse como indicativas, no como definitivas. La estimación de volumen en dólares anualizados que ha circulado (~$600M) no aparece en nuestro material de fuente y nos negamos a citarla como hecho. Coinbase no ha aclarado si un “pago” incluye reintentos, compromisos firmados bajo el esquema diferido, o solo transferencias liquidadas on-chain, lo que hace difícil comparar la cifra global con cualquier línea base de las redes de tarjetas.
Incluso aceptando el crecimiento como verdadero, varios modos de fallo son visibles.
Centralización del facilitador
El más inmediato. Ambas implementaciones de hyperscalers canalizan hacia el facilitador de Coinbase. Si este se degrada, los muros de pago fallan abiertos (el tráfico pasa sin pagar) o cerrados (el tráfico es rechazado) —ninguno es deseable a escala de edge. Más allá de la disponibilidad, el poder de fijación de precios no tiene restricciones. La tarifa actual de $0,001 por transacción es atractiva frente al interchange de tarjetas, pero no existe protección contractual contra revisiones al alza una vez que la dependencia esté consolidada.
Fraude de mandato y el problema de la ausencia humana
El modelo de autorización de x402 depende de que la wallet aplique los límites de gasto. Si un runtime de agente es comprometido —mediante inyección de prompts, un ataque a la cadena de suministro del modelo, o un error en el framework del agente— puede ejecutar cualquier pago que los límites de la wallet permitan. La wallet no puede distinguir una acción legítima del agente de una secuestrada, porque ambas están firmadas por la misma clave.
Verifiable Intent de AP2 es la respuesta directa a esto: un registro criptográfico de lo que el usuario autorizó, verificable independientemente del estado de runtime del agente. x402 no tiene equivalente. Si las session keys a nivel de wallet y las políticas de gasto en contratos inteligentes son suficientes sin un registro de auditoría es una pregunta abierta, y una que las empresas reguladas probablemente responderán de forma conservadora.
IVA, facturación y jurisdicción fiscal
Ni AWS ni Cloudflare han abordado cómo un pago anónimo en stablecoin de un agente genera una factura de IVA conforme a la normativa de la UE. Según las reglas de la UE, el vendedor debe identificar la jurisdicción del comprador, aplicar la tasa de IVA correcta y emitir una factura con campos específicos. Un pago x402 proporciona una dirección on-chain, no una identidad del comprador ni una jurisdicción. Este no es un problema menor para las empresas europeas, y no está resuelto en la especificación actual.
Semántica de reembolso y disputas
Las transferencias de USDC son irreversibles. Si un agente paga por un recurso y este resulta malformado, faltante o no responde a lo prometido, x402 no proporciona ninguna vía de remedio a nivel de protocolo. Los comerciantes pueden reembolsar voluntariamente, pero no existe el equivalente del contracargo de la red de tarjetas que desplaza la responsabilidad y obliga al comerciante a defender la entrega. Para transacciones disputadas —cualquier situación donde la calidad es subjetiva— x402 es estructuralmente inadecuado sin una capa de disputas fuera de banda.
Economía de comisiones a escala
La comisión de facilitador de $0,001 por transacción parece favorable frente al interchange de tarjetas del 1,5–3%. Deja de parecer favorable a volúmenes muy altos si es una comisión plana sobre transacciones de alto valor, y deja de parecer favorable a volúmenes muy bajos si las comisiones de cadena subyacentes (incluso en Base o Solana) comienzan a dominar. El esquema diferido disuelve esta tensión al amortizar la liquidación, pero a costa de introducir relaciones crediticias que vuelven a incorporar la complejidad operativa de las redes de tarjetas.
El problema del arranque
Los bots pueden ignorar los muros de pago y usar endpoints gratuitos o datos sintéticos. La aplicación requiere que suficiente contenido de alto valor esté efectivamente detrás de bordes pagos —un problema de huevo y gallina que los esquemas históricos de micropagos (Flattr, Bitcoin Lightning) no lograron resolver. La apuesta estructural que hace x402 es que el hecho de que el comprador sea un agente no humano elimina la fricción de UX que mató los intentos anteriores. Eso es plausible pero no está probado; si los controles de riesgo empresarial imponen a las wallets de los agentes la misma fricción de autorización que mató los micropagos humanos, la apuesta se debilita.
Implicaciones y preguntas abiertas
La lectura más defendible del estado actual es que x402 ha resuelto la mitad menos importante del problema de los pagos agénticos —la transferencia de valor— y apenas ha abordado la mitad más difícil: autorización, auditoría, reembolso y adecuación regulatoria. Los stacks de redes de tarjetas tienen la mitad más difícil en gran medida resuelta y están injertando autorización de agentes sobre ella. Si las dos vías convergen, se estratifican, o una desplaza a la otra depende de preguntas que aún no podemos responder:
- ¿Emerge un mercado de facilitadores independientes? Si un segundo facilitador con tráfico significativo no existe para mediados de 2027, el encuadre de “protocolo abierto” es funcionalmente hueco. Si emergen dos o tres, la crítica de centralización se suaviza materialmente.
- ¿Se convierte el esquema diferido en el modo de liquidación primario? Si es así, x402 evoluciona hacia un protocolo de identidad y autorización HTTP-nativo para pagos, con el riel de liquidación negociable. Eso es un producto materialmente diferente —y posiblemente más duradero— que los micropagos puros en stablecoin.
- ¿Se estandariza Verifiable Intent o un equivalente de x402? Sin un registro de auditoría criptográfico de la autorización del usuario, la adopción empresarial de pagos de agentes autónomos chocará con objeciones de gobernanza independientes de cualquier propiedad técnica de la transferencia.
- ¿Cómo se define un “pago”? Los números de volumen reportados por Coinbase no pueden compararse de manera significativa con los volúmenes de las redes de tarjetas hasta que se revele la metodología de conteo. Esta no es una cuestión contable menor; determina si la historia de crecimiento es real.
- ¿Dónde aterriza el tratamiento regulatorio? La aplicabilidad de FinCEN, la MiCA de la UE y la regla de viaje FATF a los pagos en stablecoin de x402 no está abordada en ninguna documentación que tengamos. Los compradores empresariales no implementarán contra un protocolo con postura AML no resuelta a escala.
Lo que el lector debería observar durante los próximos doce meses no son los números de volumen —son autoreportados y definitoriamente imprecisos. Hay que observar el segundo facilitador. Hay que observar la primera empresa regulada (banco, exchange, editor) que publique una implementación que supere una auditoría. Hay que observar un mecanismo formal de reembolso o disputa en la especificación. Y hay que observar si AP2 y x402 comienzan a trabajar explícitamente en interoperabilidad a través de FIDO y la Linux Foundation, o si se endurecen como stacks sin superposición.
Si el facilitador permanece singular y la brecha del registro de auditoría sigue sin llenarse, x402 ocupará un nicho real pero acotado: micropagos entre agentes para recursos digitales donde el operador acepta el riesgo de liquidación en stablecoin y ninguna de las partes requiere derechos de reembolso. Ese es un mercado genuino. No es el riel de comercio agéntico de propósito general que implican los materiales de lanzamiento. Las redes de tarjetas entonces no serían desintermediadas tanto como complementadas, con los rieles estratificándose limpiamente por tipo de transacción.
El resultado alternativo —donde la liquidación diferida madura, emergen facilitadores independientes y un equivalente de Verifiable Intent se integra a la especificación— deja a x402 como un competidor legítimo en la capa HTTP frente a los stacks de redes de tarjetas para un conjunto mucho más amplio de casos de uso. Ninguno de los dos resultados es actualmente más probable que el otro a partir de lo que las fuentes sustentan. Los próximos doce meses deberían resolver la mayor parte de la ambigüedad.
Referencias
- InfoQ, Cloudflare and AWS Embed x402 Agent Payments at the Edge, julio de 2026.
- Visa, Visa Partners with OpenAI to Power the Next Generation of AI Commerce, 10 de junio de 2026.
- Google, Donating Agent Payments Protocol to the FIDO Alliance.
- Cloudflare, Launching the x402 Foundation with Coinbase, 23 de septiembre de 2025.
- Coinbase Developer Platform, x402 Overview.
Read next다음으로 읽기次に読む继续阅读Leer a continuación
Mercados de Predicción en la Encrucijada Regulatoria
Análisis estructural y legal del caso Kalshi contra Illinois, la prerrogativa regulatoria de la CFTC, la microestructura de los CLOB frente a los AMM, y qué implica cada desenlace para los mercados de predicción onchain.
Siete días sin ser detectado: el drenaje silencioso del bridge de la red secreta
Análisis post-mortem del exploit de acuñación infinita de aproximadamente 4,67 millones de dólares en el bridge Axelar de Secret Network, y lo que el período de detección de siete días revela sobre la confianza entre cadenas.
Symbiotic Core V2 y la tesis del mercado de colateral
El Core V2 de Symbiotic reencuadra el restaking como infraestructura generalizada de colateral. Analizamos si este giro representa una novedad arquitectónica o simplemente un reposicionamiento.
Follow the next market structure breakdown 다음 시장 구조 분석 받기 次の市場構造分析をフォロー 关注下一篇市场结构分析 Sigue el próximo análisis de estructura de mercado
New Steadyrain research is published several times a week across DeFi risk, BTCFi, stablecoins, and RWA. Steadyrain은 DeFi 리스크, BTCFi, 스테이블코인, RWA 분석을 매주 여러 차례 발행합니다. SteadyrainはDeFiリスク、BTCFi、ステーブルコイン、RWAの分析を毎週公開しています。 Steadyrain 每周发布 DeFi 风险、BTCFi、稳定币和 RWA 研究。 Steadyrain publica análisis sobre riesgo DeFi, BTCFi, stablecoins y RWA varias veces por semana.