Written by: Charlie Little Sun

The article represents the author's personal views and does not reflect the stance of related companies.

Recently, more and more friends have been paying attention to agentic commerce, but the various protocols and players are becoming increasingly confusing.

Especially last week, while everyone was busy understanding Stripe / Tempo's MPP, Stripe unexpectedly joined its competitor Coinbase's x402 Foundation.

Moreover, Cloudflare now supports both sets. Google is also involved but has its own AP2 and UCP.

Visa and Mastercard have also joined, but they are clearly not here to support stablecoins.

The Linux Foundation publicly defines x402 as a neutral, industry co-governance "base camp," while Cloudflare explicitly includes x402 and MPP in its own Agents SDK, and Stripe has also stated its support for both MPP and x402.

Who is competing with whom, and who is cooperating with whom?

However, the more I look into it these days, the more I feel this "chaos" is not because the market lacks direction, but because the market is already very clear, and just like I mentioned with x402 before, we may have misunderstood its original intention: from day one, this matter would not be unified by a single protocol.

It resembles a situation commonly seen in internet infrastructure—different layers evolving simultaneously, different companies betting on different layers, ultimately relying on interoperability to get things running.

The real strategic story is about who will define the default control layer for paid machine access on the agentic web; and key players are clearly multi-homing, as everyone is still betting on where the real bottlenecks will fall—authorization, distribution, or settlement.

1. Why did Coinbase hand over the x402 foundation to Linux?

If x402 were merely Coinbase's protocol, it would struggle to become the industry default option.

This is not just a politically correct statement, but a realistic standardization logic.

The Linux Foundation's statement is very clear; it emphasizes service provider neutrality, community governance, and shared infrastructure, rather than "a certain company has released a new product feature."

More importantly, the x402 Foundation page currently states that the project is in its establishment phase, with governance mechanisms and a board still being set up.

In other words, this move is not primarily announcing "the product is mature," but rather "we want to give this protocol a neutral home."

The underlying implication is quite simple.

If x402 continues to wear the face of a Coinbase product feature (like the current Base), then cloud providers, payment companies, card organizations, and platform players may technically be willing to connect, but will hesitate politically.

No one wants to hand over the future paid access layer to a single platform. Placing it under the Linux Foundation is not because Coinbase does not want to control it; rather, it is precisely because it strives for x402 to be widely adopted, so it must first shed the burden of "this is Coinbase's protocol."

This point is quite important because many people see the action of the foundation and easily interpret it as just PR or a stance of open source.

But in the protocol war, governance is part of the product.

Especially when a standard is still in its early stages and does not yet have absolute network effects, the so-called "neutrality and trustworthiness" is not less important than elegant technology.

Conversely, if x402 can truly become some form of HTTP-native paid access baseline in the future, it is likely not because its code is the prettiest, but rather because it reduced political costs faster than other solutions.

In other words, governance here is not a supporting role; governance itself is the growth engine.

2. What is Stripe's dual strategy all about?

The player most worth watching this time is undoubtedly Stripe, as its actions are the easiest to confuse.

On one hand, they grandly launched MPP on March 18, branding it as an open standard for machine payments.

On the other hand, they are a founding contributor of the x402 Foundation and also support x402 machine payments in their documentation.

Cloudflare's documentation is more direct, even explicitly stating: MPP is backward-compatible with the core payment process of x402, allowing the MPP client to directly consume existing x402 services.

If we only look at it through the lens of "protocol competition," Stripe seems to be playing both sides.

However, if you elevate your perspective slightly, this approach actually has the most business logic.

What Stripe truly wants to safeguard is not just the 402 handshake itself.

What they really want to protect are the layers above the handshake: credentials, compliance, risk, reporting, tax, refunds, and merchant integration.

Stripe does not appear to be a genuine believer in a single protocol; rather, it looks like they are ensuring that no matter which handshake standard wins in the end, Stripe remains the default abstraction layer for agent payments.

Supporting x402 is to stay relevant in the open ecosystem; pushing MPP is to participate in defining the underlying semantics; further pushing ACP and Shared Payment Tokens is to retain stronger value for workflows and payment credentials.

Therefore, the most "strange" aspect of Stripe this time is actually the most honest aspect.

They are not pretending that the future will quickly boil down to one protocol. They are using action to tell you: at least at this stage, no one should bet on only one side.

3. This is ultimately a B2B infrastructure story

I increasingly feel that many media outlets are missing the point of this matter.

When agent payments are mentioned, the easiest thing to think of is retail: AI helps you book flights, hotel reservations, make orders, and checkout.

However, if you look at the scenes that have truly gone public and are beginning to have a sense of infrastructure, the first to take off is not retail checkout, but rather the more mundane and more real B2B paid access: paid APIs, paid data, paid tools, paid browser sessions, paid agent workflows.

Cloudflare now openly supports charging for HTTP content, APIs, and MCP tools using x402 and MPP.

The strongest adoption path for x402 lies in developer-to-developer paid APIs and tools, because "no account + pay-per-request" here is not a gimmick, but rather a practical operational reality.

The changes underlying this are actually quite significant.

In the past, when an API required a fee, it typically involved a whole set of "human-friendly" processes: creating accounts, binding billing, issuing API keys, setting limits, reconciling, and processing payment permissions.

That’s annoying enough for humans, and even more so for agents.

The most attractive aspect of x402 is not that it is more crypto or more AI, but that it attempts to reinsert "paid access" back into HTTP itself, making entry control and payment negotiation occur like a regular request-response.

The server returns a 402, informing you of how much this request costs; once the client pays, it retries the same request using the payment credential.

If you view this model from the perspective of B2B software and machine-to-machine access, it flows much more smoothly than from a retail perspective.

Moreover, the closer you look towards B2B, the more apparent x402's advantages become, and its shortcomings are less fatal.

Because, in consumer commerce, issues like refunds, chargebacks, merchant-of-record, consumer protection, and liability are all hard problems; but in B2B API and tool calls, the importance of these issues significantly decreases.

On the contrary, "no account, pay-per-call, get the result and go" is a genuine need.

Retail is certainly larger, more vibrant, and easier to attract attention; but the scenarios that truly define what the protocol looks like are often not the noisiest ones, but those that first expose real needs.

For today's wave of agent payments, that scene is very likely not the shopping cart, but the increasing number of paid access scenarios between software, between agents, and between workflows.

4. Industry development validates my previous judgment on interoperability

The core judgment in my previous article was interoperability.

At that time, this judgment still sounded somewhat like "it should be structured this way."

Now it appears increasingly to be a realistic constraint, as the open market is already voting with its feet.

Cloudflare did not take sides, but directly supports both x402 and MPP at the same time while clearly mapping compatibility.

Google participates in x402 while continuing to promote AP2 and UCP.

Visa and Mastercard have also not expressed their strategy in an "all in one winner" manner; instead, they are joining x402 while also ramping up their focus on agent tokens, identity validation, instruction verification, and dispute signals.

The multilateral bets of giants are rational decisions, not commercial hypocrisy.

Why is this the case? Because these protocols are not even on the same layer.

At least so far, x402 and MPP are closer to the layer of paid HTTP handshake, addressing "how to ensure requests come with payment capability."

AP2 is closer to authorization and trustworthy intent, solving the question of "does this agent have the qualification to spend this money."

UCP and ACP resemble the workflow layer, tackling higher-level issues like discovery, checkout, merchant relationships, and credential transmission.

Many companies support x402, MPP, AP2, and UCP simultaneously, not because they lack clarity, but because the structure that ultimately wins is likely to span multiple layers and require multiple protocols to compose.

So, if I were to reflect on my previous judgment in a single sentence, I am now more convinced that without interoperability, this wave of ecology simply cannot arise.

Currently, the market is actively verifying this judgment.

Furthermore, this judgment is also important for B2B vs. retail.

In the retail world, perhaps only a few large platforms and workflows will eventually dominate; but the B2B world is not like that.

Businesses inherently live in a reality where multi-cloud, multiple payment methods, various workflow systems, and diverse identity permission systems coexist.

Anyone attempting to push an entire corporate stack down and rebuild it using a new protocol is likely to fail first.

B2B clients are often willing to pay for not "the only correct protocol," but for the ability to ensure that existing systems can still function in a multi-protocol environment.

This logic is precisely what makes interoperability a harder requirement in enterprise scenarios than in consumer scenarios.

5. This is not a simple protocol competition, but a competition of the layered stack

Once you understand this matter as a layered stack, many seemingly chaotic phenomena will immediately make sense.

The bottom layer is the paid access handshake.

This layer concerns how HTTP requests express "payment is required here," and how the client brings back the payment credential after paying.

x402 and MPP primarily compete here. MPP attempts to align 402 with more formal HTTP auth semantics, while x402 is more focused on platforming 402, using custom headers, facilitators, on-chain settlement abstractions, and ecological integrations to get it running first.

One is more like a standardized semantic route, while the other resembles a platform distribution path.

The next layer up is the authority to spend, which concerns "who authorized this expenditure."

This layer is crucial, and many people have yet to fully recognize it.

Machines can make payments, which is not that challenging; the real challenge is ensuring machines can be reliably authorized to make payments.

AP2 is significant precisely because it addresses not just "how to pay," but also resolves mandates, verifiable credentials, authenticity, and accountability.

The recent ramp-up in agent tokens, instruction validation, passkeys, and dispute signals by Visa and Mastercard are all fundamentally related to this layer.

The layer above is workflow and distribution.

This involves discovery, checkout, merchant relationships, credential sharing, and AI surface integration, which are closer to "who controls traffic and transaction orchestration."

UCP and ACP seem to be competing at this layer.

For B2B, this layer may not be as lively in the short term, but its long-term value could be very high.

Because if more and more business software is coordinated, called, procured, and paid for by agents in the future, then whoever masters the workflow language won't just be managing one payment, but the entire workflow.

Once you separate these three layers, you will realize a simple fact: there is no need to expect one protocol to solve all problems.

A more realistic path is for these three layers to evolve separately and then slowly converge through interoperability.

For this reason, multi-headed bets are not wavering, but rather rational.

6. The real risk of x402 is not necessarily regulation, but economics under concurrency

If we simply realize "multi-protocol co-existence," it is still not deep enough.

The biggest risk of x402 may not primarily be regulation, but the economics created by the two-step verification-settlement process—time-of-check/time-of-use.

Simply put, if verifying payment and final settlement are not the same thing, then in high concurrency, retries, agent layers, and caching layers within real internet environments, a "pay once, access multiple times" window could emerge.

The x402 ecosystem is currently addressing these gaps, such as settlement cache, idempotency extension, and payment identifiers, which highlights that the issues are not merely theoretical.

Why is this particularly significant for B2B readers?

Because what B2B worlds fear most is never that they cannot produce a pretty demo; rather, it is that having too many edge cases leads to leaks once they go into production.

API monetization may superficially seem like charging a few cents per request, which feels light; but once your product charges per call, per result, or per workflow, then whether "pay once get once" or "pay once get many times" is no longer a product detail, but a matter of life and death.

Therefore, if x402 can indeed take off in B2B, an important prerequisite is not just about the narrative, but the need for these default-safe mechanisms to be designed to be as straightforward as possible; otherwise, enterprises will not be willing to confidently connect real traffic.

7. Protocols may be free, but toll booths will not disappear

There is one more point that I think deserves thorough discussion in this article.

Many open protocols ultimately arrive at a very familiar place: the protocol itself becomes increasingly cheap, even free, but the actual toll booths emerge alongside.

x402 is no different.

The standard itself certainly emphasizes openness, neutrality, and 0 fees built into the standard, but that does not mean that value capture will disappear.

If x402 succeeds, the value will not primarily remain within the protocol, but will transfer to facilitators, wallets and key management, discovery, policy engines, and trust wrappers in neighboring layers.

This is especially important for B2B.

Enterprise customers will not overhaul their entire system for a new protocol; what they are truly willing to pay for is who can help them sort out the troublesome matters of orchestration, policies, risk, compliance, auditing, settlement, and permission boundaries in a multi-protocol environment.

In other words, protocols will increasingly resemble foundational languages, but the ability to translate these languages into something "enterprises can feel comfortable rolling out" could ultimately become the new platform and toll booths.

This is also why I feel that when looking at x402 today, we should not just focus on who is more like the "protagonist" among Coinbase, Cloudflare, and Stripe.

What is truly worth watching is who has the best chance of standing on these neighboring layers.

Cloudflare has the positioning of edge and traffic distribution; Stripe has the positioning of payment infrastructure and merchant relationships; Visa and Mastercard have positions in credentials, network tokens, and consumer trust; Google has positions in workflow and discovery surfaces.

True value capture is not necessarily happening in "who defined 402," but more likely in "who brought 402 into larger enterprise systems."

8. Conclusion

The x402 Foundation is not announcing that x402 has emerged victorious among all agentic commerce protocols.

It is publicly acknowledging that this generation of agent payments will not be a single protocol world from day one.

Coinbase handing x402 to the Linux Foundation aims to make it more like a neutral public layer rather than an exclusive product.

Stripe pushing MPP while joining x402 is not waffling; it is because they know that now is not the time to bet on just one side.

Cloudflare supporting both sets is because it is closest to real traffic.

The actions of players like Google, Visa, Mastercard, and Adyen also reiterate the same message: first, ensure the systems can interoperate, then discuss who ultimately occupies which layer.

And if you shift the perspective away from retail, this judgment becomes more coherent.

Because the ones that need these protocols first are not necessarily shopping carts, but increasingly more B2B software and services that charge based on calls, tasks, or results.

Retail certainly is larger, but B2B often exposes real demands earlier and better defines what the infrastructure will ultimately look like.

In my previous article, I placed interoperability at the center, and I believe the market now provides a clear answer: yes, and even earlier than I thought at that time.

In this sense, the x402 Foundation is not the end of this story.

It just allows us to see earlier that the real theme has always not been "who will win," but "given that this world is destined to interconnect first, who can occupy the most valuable layer thereafter."

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。