On July 14, 2026, the Linux Foundation announced the launch of x402 Foundation operations and the completion of the x402 protocol transfer from Coinbase. This is an attempt to enable AI agents and APIs to make payments within HTTP requests and responses, without going through human screen operations. Just over three months after the initial establishment announcement in April, 40 organizations—centered around card networks and payment processors—have come together. Participation spans cloud, commerce, stablecoin issuers, and multiple blockchain camps. The focus is not on the sheer number of members, but on whether Coinbase-originated crypto asset payments can be transformed into a common specification that different payment camps can implement.
From the April Establishment Announcement to Operations Launch with 40 Organizations
This is not the first announcement about x402 Foundation. On April 2, the Linux Foundation had already announced its policy to establish a home for x402, developed by Coinbase, and was recruiting industry participants including Cloudflare and Stripe. What changed on July 14 is that the foundation began operating under formal governance, and Coinbase's contribution of the protocol was completed. It moved from concept to operation.
Looking at the participating companies, one can sense the intent not to confine x402 within the crypto asset industry alone. Premier Members include Adyen, American Express, and Fiserv, with Mastercard, Stripe, and Visa also joining. In addition to AWS and Google, Cloudflare and Shopify also participate. Beyond Circle, Coinbase, and Ripple, the Solana Foundation and Stellar Development Foundation have joined as well, bringing the total to 40 organizations: 17 Premier, 18 General, and 5 Associate. The fact that mutually competing camps—cards, payment processors, stablecoins, and blockchains—now sit at the same table is what gives value to this transfer.
However, this is not a case of the x402 specification suddenly appearing out of nowhere. Coinbase released the initial version on May 6, 2025, and launched V2 in December of the same year. The official x402 V2 announcement states that it processed over 100 million payments within roughly six months of release. The July announcement should not be taken as proof that the technology has moved past the experimental stage, but rather as an organizational change to decouple its adoption from Coinbase's single-company product strategy.
Turning 402 into a Payment Round-Trip
The name x402 derives from the HTTP status code "402 Payment Required." RFC 9110, which defines the current HTTP Semantics, merely notes that 402 is "reserved for future use," without specifying payment methods or message formats. x402 fills this gap by placing a convention that carries payment conditions, buyer signatures, and settlement results. The aim is to make it easy to integrate with existing HTTP servers and clients.
The typical flow involves two round trips. When a client calls a paid API, the server returns 402 along with a PAYMENT-REQUIRED header, conveying the amount and recipient. The available networks and payment methods are also included in the same header. The client selects the conditions, signs the payment data, places it in PAYMENT-SIGNATURE, and resends the same request. Upon successful verification and settlement, the server returns 200 OK, the requested data, and a PAYMENT-RESPONSE.
To avoid burdening every API provider with blockchain connectivity, x402 also defines a role called "facilitator." The facilitator verifies the buyer's signed data and executes on-chain settlement on behalf of the seller. Since altering the content of the buyer's signature would cause verification to fail, the design does not allow facilitators to move funds freely. Sellers can also choose to implement verification and settlement themselves without using a facilitator.
Payment methods have expanded beyond the fixed-amount exact to include upto, which finalizes actual usage within an upper limit, and batch-settlement, which aggregates multiple payments afterward. For instance, an inference API cannot know the final token count at the time of the request. With upto, the maximum amount can be approved upfront, and the actual amount can be collected after processing. What matters here is that beyond simply embedding payments into HTTP, the specification has begun to formalize payment units suited to APIs' usage-based billing.
Even with 40 Organizations Participating, Technical Decisions Start from a 3-Company TSC
"Open governance by 40 organizations" does not mean that all 40 organizations have equal authority in deciding the specification. The x402 Foundation has a Directed Fund, which handles funding and business operations, and a Technical Project, which manages code and specifications. The funding charter explicitly states that the Directed Fund's Governing Board has no authority to determine the direction of the Technical Project. This is a design that separates the entity holding the budget from technical decision-making.
On the funding side, Premier Members, who contribute $200,000 annually, each send one representative to the Governing Board. The Premier tier is capped at 20 in principle, with 17 organizations currently enrolled. General Members pay annual fees ranging from $25,000 to $75,000 depending on employee count, but the 18 organizations collectively have only one board seat. Associate Membership is limited to nonprofits and similar entities, with no membership fee.
On the technical side, decision-making is handled by the Technical Steering Committee (TSC). As of July 15, 2026, the public repository lists three TSC members: Erik Reppel of Coinbase, Rohin Lohe of Cloudflare, and Steve Kaliski of Stripe. Additional representatives can be admitted with a majority vote of the existing TSC, and changes to core principles require at least 75% approval. Compared to the funding and adoption organization that has gathered 40 organizations, technical oversight is still at the stage of expanding from the three founding companies.
Meanwhile, the technical charter stipulates that individuals or organizations meeting certain conditions can participate as Contributors or Maintainers, and TSC meetings are generally open to the public. Code is provided under the Apache License 2.0, and documentation under CC BY 4.0. It is not a system where one must pay membership fees to propose code. Going forward, whether the composition of the TSC and the maintainers of key implementations expand across payment camps will serve as a concrete indicator of neutrality.
Beyond Single Payments: Batching and Delegation
x402 V2 restructured the initial "call once, pay once" model. Payment information was moved to HTTP headers, blockchains are identified using the CAIP format, and payment networks and facilitators can now be added as plugins. The current official documentation lists implementations for seven chains, including EVM and Solana. However, actual operation requires either selecting a facilitator that handles the target network or operating one's own.
batch-settlement, introduced in May 2026, delves into the cost structure of machine payments. Buyers place funds in an escrow on EVM, and sign a cryptographic voucher recording the cumulative amount each time they call the API. Sellers verify the signature on each request and later collect multiple payments together on-chain. While this avoids bearing gas fees and confirmation waits for every single request, it also means that on-chain confirmation for each request is deferred to a later stage, requiring correct implementation of escrow, voucher expiration, and deduplication.
Another indispensable element is proof of who authorized an agent's spending. Google's Agent Payments Protocol (AP2) records the authorized sellers and spending limits in an IntentMandate, and links specific purchase content and amounts to a PaymentMandate. Google's published A2A x402 extension calls x402's crypto asset payments from this delegation and audit layer. x402 carries value, while AP2 carries human intent and spending conditions. The fact that the two are connected shows that the industry is moving not toward a single all-purpose protocol for agent payments, but toward layering specifications with different responsibilities.
If It's Going to Call Itself a "Standard," Implementation Diversity Comes Next
The Linux Foundation's announcement explains that x402 supports multiple payment methods, from cards to stablecoins. However, the current x402 FAQ does not treat fiat currency deposits/withdrawals or card funding as core functionality. Cards, ACH, SEPA, and similar methods are envisioned as connecting to the same message format via facilitators or external gateways. The participation of American Express, Mastercard, and Visa, along with Adyen, Fiserv, and Stripe, carries significant weight. Until each company's implementation and interoperability are publicly disclosed, it is necessary to distinguish between statements of participation and an actually operating payment network.
Consumer protection also doesn't end with just a signature. exact is a push payment that cannot be reversed after execution; refunds require either a separate remittance from the seller or coordinated refunds via batch-settlement. Identity verification, anti-money laundering measures, and taxation must be handled through operations specific to each country and business, and purchase authorization and dispute resolution must also be designed separately. In addition to technical discussions and service exploration, the x402 Foundation has established a working group for identity management. Tax and compliance are also treated as separate areas of consideration.
Furthermore, as of July 15, the public repository's ROADMAP.md remains at a single line stating "update coming soon." HTTP 402's usage also remains "reserved" under the RFC, and the transfer to the Linux Foundation does not imply IETF standardization. The criteria for the next evaluation are clear: whether the TSC expands beyond the three founding companies, whether multiple facilitators and card-based implementations pass interoperability tests, and whether a roadmap is published that includes refund requirements and connection requirements with delegation layers like AP2. If these conditions are met, x402 will move closer from being a convenient SDK originating from Coinbase to becoming a common layer through which agents can pay regardless of their counterparty.