Coinbase positions x402 as neutral, while Stripe continues to bet on both sides outside of MPP.

Author: Charlie, OSL Americas lead, Venture Partner @ Generative Ventures. Previously Vice President at the crypto unicorn Strike (involved in the Bitcoin bill in El Salvador, and responsible for Latin America’s Bitcoin Lightning Network and stablecoin payments business), macro and currency analyst at Franklin Templeton, a trillion-level fund, and an early member of the global payments giant Adyen.

The article reflects the author’s personal views and does not represent the stance of any related company.

More and more friends have been paying attention to agentic commerce lately, but all kinds of protocols and players are also increasingly making it hard for everyone to keep track.

Especially last week—everyone was still busy learning about Stripe / Tempo’s MPP, and in the blink of an eye, Stripe joined the rival Coinbase’s x402 Foundation.

And now Cloudflare supports both. Google is also in this mix, but it has its own AP2 and UCP.

Visa and Mastercard are also here, but obviously they’re not here to endorse stablecoins.

Linux Foundation has publicly defined x402 as a neutral, industry-governed “home base,” while Cloudflare has explicitly put both x402 and MPP into its Agents SDK. Stripe has also publicly written that it supports both MPP and x402.

So who is competing with whom, and who is overlapping with whom?

But the more I’ve looked these past few days, the more I feel that this “mess” isn’t because the market lacks direction—it’s because the market is already very clear. And it’s also possible that, like what I previously misunderstood about x402, we may have gotten the original intent wrong: from day one, this won’t be unified by a single protocol all at once.

It’s more like a situation that’s very common in internet infrastructure—different layers are evolving at the same time, different companies are betting on different layers, and in the end the whole thing starts running first thanks to interoperability.

The real strategic story is: who defines the default control layer for paid machine access on the agentic web. And key players are clearly multi-homing, because everyone is still betting on where the real bottleneck of the future will land—authorization, distribution, or settlement.

I. Why did Coinbase let go and hand the x402 Foundation to Linux?

If x402 were only Coinbase’s protocol, it would be difficult for it to become the industry default option.

This isn’t a politically correct statement—it’s a very real standardization logic.

Linux Foundation’s wording this time is very clear: it emphasizes provider neutrality, community governance, and shared infrastructure, not “a certain company released a product new feature.”

More importantly, the x402 Foundation page now says the project is in the building phase, with governance mechanisms and the board of directors still being set up.

That means this move isn’t first about announcing “the product is mature,” but about announcing “we’re giving this protocol a neutral home.”

The underlying implication is actually very simple.

If x402 has always grown with a Coinbase product-like face (for example, Base at present), then even if cloud providers, payment companies, card networks, and platform players are technically willing to integrate, they will hesitate politically.

No one wants to hand the future paid access layer to a single platform. Putting it under the Linux Foundation isn’t because Coinbase doesn’t want to control it—quite the opposite: it wants x402 to be widely adopted so badly that it has to remove the burden of “this is Coinbase’s protocol” first.

This actually matters, because many people tend to treat foundation-style actions as just PR or an open-source posture.

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

Especially when a standard is still early and hasn’t yet achieved absolute network effects, the so-called “neutral trust” isn’t less important than technical elegance.

Conversely, if x402 really becomes a kind of HTTP-native paid access baseline in the future, it may not be because its code is the prettiest, but because it has earlier lowered political costs compared with other approaches.

In other words, governance here isn’t a supporting character—governance itself is a growth engine.

II. What is Stripe actually doing with its cross-fighting on both sides?

The player most worth watching this time is definitely Stripe, because Stripe’s moves are the easiest to confuse people.

On one hand, it boldly launched MPP on March 18, packaging it as an open standard for machine payments.

On the other hand, it is also a founding contributor of the x402 Foundation, and its own documentation supports x402 machine payments.

Cloudflare’s documentation is even more direct, explicitly stating that: the core payment flow of MPP with respect to x402 is backward-compatible, and an MPP client can directly consume existing x402 services.

If you look only through the “protocol competition” framework, Stripe looks like it’s hedging both ways.

But if you lift the perspective a bit higher, this approach actually has more business logic.

Because what Stripe truly wants to protect might not be 402 handshake itself.

What it wants to protect is the layers above the handshake: credentials, compliance, risk, reporting, tax, refunds, and merchant integration.

Stripe doesn’t look like a true believer in a single protocol. It looks more like it’s ensuring that no matter which handshake standard wins in the end, Stripe remains the default abstraction layer for agent payments.

Supporting x402 is to avoid being absent from the open ecosystem; pushing MPP is to participate in defining the underlying semantics; pushing ACP and Shared Payment Tokens above that is to safeguard the thicker value layer of workflows and payment credentials.

So Stripe’s most “weird” part this time is actually also its most honest part.

It hasn’t pretended that the future will quickly be left with only one protocol. It’s using action to tell you: at least in this phase, no one should bet exclusively on one side.

III. This is really a B2B infrastructure story

I’m increasingly convinced that many media outlets have misplaced the focus of this story.

When people say agent payments, the first thing they usually think of is retail: AI helps you buy plane tickets, book hotels, place orders, and go through checkout.

But if you look at the scenarios that are actually publicly deployed right now and that really have an infrastructure feel, the first things to run aren’t retail checkouts, but a more boring—and more real—B2B paid access: paid APIs, paid data, paid tools, paid browser sessions, and paid agent workflows.

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

The strongest adoption path for x402 is on developer-to-developer paid APIs and tools, because “no account + pay-per-request” here isn’t a gimmick—it’s a truly operational reality.

The changes behind this are actually huge.

In the past, when an API charged, it usually had to go through a whole set of “human-friendly” steps first: create an account, link billing, issue an API key, set limits, reconciliation, and then handle payment permissions.

For humans, that’s already annoying. For agents, it’s even more awkward.

What makes x402 most compelling isn’t that it’s more crypto, or that it’s more AI. It’s that it tries to put “paid access” back into HTTP itself, so that access control and payment negotiation happen like a normal request-response cycle.

The server returns a 402 to tell you how much this request costs; the client pays, then retries the same request using the payment credential.

If you view this model from the angle of B2B software and machine-to-machine access, it fits better than from the retail angle.

And the more you look toward B2B, the clearer x402’s advantages become, while its shortcomings become less fatal.

In consumer commerce, refunds, chargebacks, merchant-of-record, consumer protection, and responsibility allocation are all hard problems. But in B2B API and tool calls, those issues matter much less.

Instead, the true need is “no account, pay per call, get the result and leave.”

Retail is of course bigger and noisier, and easier to attract attention; but what typically defines what a protocol should look like isn’t the most attention-grabbing scenario—it’s the scenario that exposes real needs earliest.

For today’s wave of agent payments, that scenario probably isn’t a shopping cart—it’s increasingly paid access between software, between agents, and between workflows.

IV. Industry development validated my earlier view on interoperability

In my previous article, the most core judgment was interoperability.

At the time, that judgment sounded a bit like it “should” be done that way in terms of architecture.

Now it looks more and more like a real-world constraint, because the open market is already voting with its feet.

Cloudflare didn’t choose sides—it directly supports both x402 and MPP, and it clearly does compatibility mapping.

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

Visa and Mastercard also didn’t express their strategy in the “all in one winner” posture. They added x402 while continuing to double down on agent tokens, identity verification, instruction validation, and dispute signals.

These big players’ multi-lateral bets are rational decisions, not commercial hypocrisy.

Why is that? Because these protocols aren’t even in the same layer.

At least so far, x402 and MPP are closer to the paid HTTP handshake layer, addressing “how to get the request to come back with payment capability.”

AP2 is closer to authorization and trusted intent; it addresses “whether this agent is actually qualified to spend this money in a trustworthy way.”

UCP and ACP are more like the workflow layer, dealing with higher-level problems like discovery, checkout, merchant relationships, and credential passing.

Many companies support x402, MPP, AP2, and UCP not because they can’t figure things out, but because the architecture that wins at the end is very likely to span multiple layers—possibly requiring multiple protocols working together to form the complete solution.

So if you want to look back at my earlier judgment in one sentence: I now believe even more strongly that without interoperability, this ecosystem would not have gotten off the ground at all.

Now it looks like the market is actively validating this judgment.

Further, this judgment also matters for B2B vs retail.

In the retail world, perhaps in the end, a few big platforms and a few big workflows will absorb everything. But the B2B world isn’t like that.

Enterprises already live in a reality where multiple clouds, multiple payment methods, multiple workflow systems, and multiple identity/permission systems coexist.

Anyone who tries to overturn and rebuild an entire enterprise stack with a single new protocol is very likely to die first.

What B2B customers are really willing to pay for typically isn’t “the uniquely correct protocol,” but the ability to keep existing systems working in a multi-protocol environment.

This logic is exactly why interoperability is slightly more rigid in enterprise scenarios than in consumer scenarios.

V. This isn’t just protocol competition—it’s stack competition after layering

Once you understand this as a layered stack, many previously confusing phenomena will instantly make sense.

The bottom-most layer is the paid access handshake.

This layer cares about how an HTTP request expresses “this needs to be paid,” and how the client brings the payment credential back after payment.

x402 and MPP mainly fight here. MPP is trying to bring 402 into more formal HTTP auth semantics; x402, meanwhile, is more like “platformizing” 402—making it run first by abstracting it through custom headers, facilitators, settlement layers-on-chain, and ecosystem integration.

That’s one route more like standardized semantics; the other more like a platform distribution route.

One layer above is authority to spend—i.e., “who authorized this money.”

This is the key layer that many people still haven’t fully realized.

Machines paying isn’t that hard; machines being able to pay with trustworthy authorization is the real hard part.

AP2 is important because it isn’t just about “how to pay,” but about solving mandates, verifiable credentials, authenticity, and accountability.

The agent tokens, instruction validation, passkeys, and dispute signals that Visa and Mastercard have been doubling down on recently are also essentially all about this.

One layer above that is workflow and distribution.

That is, discovery, checkout, merchant relationship, credential sharing, and AI surface integration—these are closer to “who controls traffic and transaction orchestration.”

UCP and ACP are more like competing for this layer.

For B2B, this layer isn’t as exciting in the short term, but in the long term it could be very valuable.

Because if more and more enterprise software is coordinated, called, procured, and paid by agents, then whoever controls the workflow language doesn’t just control a single payment—they control the entire workflow.

Once you separate these three layers, you’ll find a very plain fact: there’s no need to expect a single protocol to cover all problems.

A more realistic path is that these three layers each grow first, and then gradually interlock through interoperability.

And because of this, multi-side bets are not vacillation—they’re rational.

VI. The real risk of x402 isn’t necessarily regulation—it’s the economics under concurrency

If we only recognize that “multiple protocols coexist,” that isn’t deep enough.

The biggest risk of x402 might not first be regulation, but rather the time-of-check/time-of-use economics introduced by splitting verify and settle into two steps.

In simple terms: if payment verification and final settlement aren’t the same thing, then in real internet conditions with high concurrency, retries, agent layers, and cache layers, there will be a window for “pay once, access multiple times.”

The x402 ecosystem is also patching holes now—for example settlement cache, an idempotency extension, and payment identifier—but that actually shows the problem isn’t just theoretical.

Why is this especially worth B2B readers caring about?

Because in the B2B world, the thing they fear most is never that a pretty demo can’t be built. It’s that there are too many edge cases, and finally when it goes into production, it starts leaking.

With API monetization, on the surface it looks like charging a few cents per request is easy. But if your product charges per call, per result, or per workflow, then whether it’s “pay once get once” or “pay once get many times” isn’t a product detail—it’s a make-or-break line.

So if in the future x402 really can run in B2B, an important prerequisite isn’t narrative, but that these default-safe mechanisms must be implemented in a sufficiently thoughtless/automatic way—otherwise enterprises won’t feel comfortable routing real traffic into it.

VII. Protocols may be free, but the tollbooths won’t disappear

One more point—I think it’s worth making explicit here.

Many open protocols eventually end up in a very familiar place: the protocol itself becomes cheaper and even free, but the real tollbooths grow up right next to it.

x402 is no exception.

The standard certainly emphasizes openness, neutrality, and 0 fees built into the standard, but that doesn’t mean value capture will vanish.

If x402 succeeds, value won’t primarily stay in the protocol. It will migrate to adjacent layers such as facilitators, wallets and key management, discovery, policy engines, and trust wrappers.

This is especially important for B2B.

Because enterprise customers won’t overhaul their entire systems at scale just for a new protocol. What they’re truly willing to pay for is whoever can help clean up those messy issues in a multi-protocol environment: orchestration, policy, risk, compliance, audit, settlement, and permission boundaries.

Put another way, the protocol will look more and more like a lower-level language, but the layer that translates those languages into “capabilities enterprises can safely deploy” is more likely to become a new platform and a new set of tollbooths.

That’s also why I think that when looking at x402 today, you shouldn’t only focus on who’s more like the “main character”—Coinbase, Cloudflare, or Stripe.

What’s really worth watching is who has the best chance to stand on those adjacent layers.

Cloudflare has edge and traffic distribution positions; Stripe has payment infrastructure and merchant relationship positions; Visa and Mastercard have positions in credentials, network tokens, and consumer trust; Google has positions in workflow and discovery surface.

Real value capture may not happen in “who defines 402.” It’s more likely to happen in “who plugs 402 into a larger enterprise system.”

VIII. Conclusion

This x402 Foundation matter isn’t declaring that x402 has already won across all agentic commerce protocols.

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

Coinbase handing x402 to the Linux Foundation is to make it feel more like a neutral public layer, not an exclusive product.

Stripe pushing MPP while also joining x402 isn’t wavering—it’s because it knows that right now you shouldn’t bet exclusively on one side.

Cloudflare supports both simultaneously because it’s closest to real traffic.

The actions by players like Google, Visa, Mastercard, and Adyen also all indicate the same thing: first make the systems interoperable, then talk about who ultimately occupies which layer.

And if you move the perspective away from retail, this conclusion becomes even smoother.

Because the first people who need these protocols might not be shopping carts, but increasingly B2B software and services charging per call, per task, and per result.

Retail is certainly bigger, but B2B often exposes real needs earlier and defines what infrastructure ultimately looks like earlier.

In my previous article, I put interoperability at the center, and I think the market’s answer now is very clear: yes—and earlier than what I thought back then.

In that sense, the x402 Foundation isn’t the end of this story.

It only helps us see earlier that the real theme was never “who will win,” but rather “this world is destined to interoperate first—and who can then occupy the most valuable layer after interoperability happens.”