Coinbase pushes x402 to neutral; Stripe bets on both sides outside of MPP

Author: Charlie Liu, Partner at Generative Ventures

More and more people I know are paying attention to agentic commerce, but the various protocols and players have also made it harder and harder for everyone to keep track.

Especially last week—people were still busy learning about Stripe / Tempo’s MPP, and in the blink of an eye, Stripe has joined the friendly-fellow camp with x402 Foundation from its competitor, Coinbase.

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

Visa and Mastercard have also arrived, but obviously they’re not here to back stablecoins.

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

So who is competing with who, and who is stacking on top of whom?

But the more I look these 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, just like I mentioned earlier, from day one this wouldn’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 evolve in parallel, different companies place bets at different layers, and in the end they get the whole thing running first through interoperability.

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

I. Why did Coinbase hand over the x402 foundation?

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

This isn’t a statement about political correctness. It’s a very real standardization logic.

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

More critically, the x402 Foundation page currently says the project is in the building stage, with governance mechanisms and the board of directors still being set up.

So this move isn’t first about announcing “the product is mature.” It’s about announcing “we’re giving this protocol a neutral home.”

The subtext behind it is actually simple.

If x402 has continued to grow with the face of a Coinbase product feature (for example, Base for now), then cloud providers, payments companies, card networks, and platform players— even if they technically want to integrate—will hesitate politically.

Nobody 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—if anything, it’s because it wants x402 to be widely adopted. So it must first shed the burden of “this is Coinbase’s protocol.”

This point is important, because many people tend to treat actions like forming foundations as only PR or as open-source posture.

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

Especially when a standard is still in its early stage and doesn’t yet have absolute network effects, the so-called “neutral and trustworthy” matters no less than technical elegance.

Conversely, if x402 can truly become a baseline for some HTTP-native paid access in the future, it might not be because its code is the prettiest—but because it has lowered political costs earlier than other approaches.

In other words, governance here isn’t a supporting role. Governance itself is the growth engine.

II. What on earth is Stripe doing with its back-and-forth moves?

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

On one side, it boldly launched MPP on March 18 and packaged it as an open standard for machine payments.

On the other side, it’s also a founding contributor to the x402 Foundation, and its own documentation supports x402 machine payments.

Cloudflare’s documentation is even more direct. It even explicitly states that: MPP’s core payment process for x402 is backward-compatible, and the MPP client can directly consume existing x402 services.

If you look at this only through the lens of “protocol competition,” Stripe looks like it’s hedging on both sides.

But if you raise the perspective a bit, this actually makes commercial sense.

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

What Stripe 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 any single protocol. It looks more like it’s ensuring that no matter which handshake standard ultimately wins, Stripe remains the default abstraction layer for agent payments.

Supporting x402 is so it doesn’t miss out on an open ecosystem. Pushing MPP is so it can participate in defining the underlying semantics. Pushing ACP and Shared Payment Tokens further up the stack is to protect the thicker value layer around workflows and payment credentials.

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

It hasn’t pretended there will quickly be only one protocol left. It’s using action to tell you: at least in this stage, nobody should bet only on one side.

III. This is actually a B2B infrastructure story

I’m increasingly feeling that a lot of media is putting the spotlight in the wrong place.

Whenever people talk about agent payments, the first thing people think of is usually retail: AI helps you buy flights, book hotels, place orders, and handle checkout.

But if you look at what’s truly already public and actually deployed with an infrastructure feel, the first thing running isn’t retail checkout—it’s a more boring, more real B2B paid access: paid APIs, paid data, paid tools, paid browser sessions, paid agent workflows.

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

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

The change behind this is actually huge.

In the past, if an API was going to charge, it usually had to go through a whole set of “human-friendly” processes first: create an account, attach billing, issue an API key, set rate limits, reconcile accounts, and then handle payment permissions.

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

What’s most attractive about x402 isn’t that it’s more crypto, or more AI—it’s that it tries to put “paid access” back into HTTP itself, so that access control negotiation and payment agreement happen like ordinary request-response.

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

From a B2B software and machine-to-machine access perspective, this model is much smoother than from the retail perspective.

And the more you look toward B2B, the more obvious x402’s advantages become, and the less fatal its shortcomings are.

Because in consumer commerce, refunds, chargebacks, merchant-of-record, consumer protection, and responsibility allocation are all hard problems. But in B2B API and tool calls, the importance of these issues drops significantly.

Instead, the real needs are: “no account, pay per call, get the result and move on.”

Retail is bigger, louder, and more eye-catching. But the shape of the protocols is usually defined not in the most exciting scenario, but in the earliest scenarios that expose real demand.

For today’s wave of agent payments, that scenario is very likely not a shopping cart, but paid access between more and more software—between agents and between workflows.

IV. Industry development has validated my previous interoperability judgment

The core judgment in my previous article was interoperability.

Back then, the judgment still sounded like it had a bit of “architecturally it should be this way” flavor.

Now it looks more and more like a practical constraint, because the public market is literally voting with its feet.

Cloudflare didn’t pick sides. It supports both x402 and MPP directly, and it clearly implements compatibility mapping.

On one hand, Google participates in x402, and on the other it continues pushing AP2 and UCP.

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

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

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

At least so far, x402 and MPP are closer to the paid HTTP handshake layer; they solve “how to make a request carry payment capabilities back.”

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

UCP and ACP are more like the workflow layer, dealing with more upper-level issues such as discovery, checkout, merchant relationships, and credential passing.

Many companies support x402, MPP, AP2, and UCP at the same time—not because they can’t figure things out, but because the architecture that ultimately wins is very likely cross-layer, even requiring multiple protocols working together.

So if I want to look back at my earlier judgment in one sentence, I now believe even more strongly that without interoperability, this ecosystem simply couldn’t really take off.

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

Going further, this judgment is also important for B2B versus retail.

Because in the retail world, maybe in the end a few big platforms and a few big workflows will absorb everything—but that’s not how the B2B world works.

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

Anyone trying to use a single new protocol to tear down the entire enterprise stack and rebuild it from scratch is likely to die first.

What B2B customers really pay for is often not the “only correct protocol,” but the ability to keep existing systems working even in a multi-protocol environment.

That logic is exactly why interoperability is a bit harder in enterprise scenarios than in consumer scenarios.

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

Once you understand this as a layered stack, many previously confusing phenomena suddenly line up.

At the very bottom layer, it’s the paid access handshake.

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

x402 and MPP mainly fight here. MPP is trying to bring 402 into more formal HTTP auth semantics; while x402 is more like “platformizing” 402—by using custom headers, facilitators, on-chain settlement abstractions, and ecosystem integrations to get it running first.

One path is more like standardized semantics; the other is more like platform distribution.

One layer higher is authority to spend—who authorized this money.

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

Machines can pay, and that isn’t that hard. The truly hard part is whether machines can be trusted and authorized to pay.

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

Those agent token, instruction validation, passkeys, and dispute signals that Visa and Mastercard have been adding recently essentially all live here.

One layer above that is workflow and distribution.

That’s discovery, checkout, merchant relationships, credential sharing, and AI surface integration—things much 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 its value over the long term could be very high.

Because if more and more enterprise software is coordinated, called, purchased, and paid for by agents, then whoever controls the workflow language isn’t just managing a single payment—they’re managing 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 package all problems.

A more realistic path is that these three layers grow independently first, then gradually knit together through interoperability.

That’s also why multi-head betting isn’t indecision—it’s rationality.

VI. The real risks of x402 may not be regulation, but economics under concurrency

If we only recognize “multi-protocol coexistence,” that still isn’t deep enough.

The biggest risk of x402 may not be regulation first, but 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 environments—high concurrency, retries, agent layers, cache layers—there can be a window of “pay once, access multiple times.”

The x402 ecosystem is also plugging holes now, such as settlement cache, idempotency extension, and payment identifier. But that very fact indicates the problem isn’t theoretical.

Why is this especially worth B2B readers caring about?

Because what B2B fears most is never that a beautiful demo can’t be built. It’s that there are too many edge cases, and then once deployed into production, it starts leaking.

API monetization on the surface is “a few cents per request,” which sounds light. But if your product charges per call, per result, or per workflow, then whether it’s “pay once and get once” versus “pay once and get many times” isn’t just a product detail—it’s a line between life and death.

So if x402 truly manages to run in B2B, an important prerequisite won’t be narrative—it’s that these default-safe mechanisms must be implemented in a way that’s foolproof. Otherwise enterprises won’t feel comfortable routing real traffic in.

VII. Protocols may be free, but toll booths won’t disappear

One more thing—I think it’s worth making clear in this piece.

Many open protocols eventually end up at a familiar place: the protocol itself becomes cheaper and even free, but the real toll booths grow alongside it.

x402 is no different.

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

If x402 succeeds, the value won’t mainly remain in the protocol. It will migrate to adjacent layers—facilitators, wallets and key management, discovery, policy engines, trust wrappers, and so on.

That matters especially for B2B.

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

In other words, the protocol will increasingly resemble a low-level language, but the layer that translates those languages into “capabilities enterprises can safely deploy” will more easily become a new platform and a new set of toll booths.

That’s also why I think when looking at x402 today, you can’t just focus on whether Coinbase, Cloudflare, or Stripe looks more like the “main character.”

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

Cloudflare has the edge and traffic distribution position; Stripe has the payment infrastructure and merchant relationship position; Visa and Mastercard have the credential, network token, and consumer trust position; Google has the workflow and discovery surface position.

Real value capture doesn’t necessarily happen in “who defines 402.” It’s more likely to happen in “who plugs 402 into larger enterprise systems.”

VIII. Conclusion

The x402 Foundation initiative isn’t announcing that x402 has already won across all agentic commerce protocols.

It’s publicly acknowledging that this generation of agent payments won’t be a single-protocol world from day one.

By handing x402 to the Linux Foundation, Coinbase wants it to look more like a neutral public layer rather than an exclusive product.

Stripe pushing MPP while joining x402 isn’t hedging or wavering—it’s because it knows it shouldn’t bet on only one side right now.

Cloudflare supporting both is because it’s closest to real traffic.

The moves by players like Google, Visa, Mastercard, and Adyen are also all indicating the same thing: first make systems interoperable, and then discuss which layer whoever ultimately occupies.

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

Because what needs these protocols first might not be a shopping cart, but an increasing amount of B2B software and services that charge by call, by task, and by outcome.

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

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

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

It only helps us see sooner that the real theme has never been “who will win”—it’s that this world is destined to interoperate first, and then who can occupy the most valuable layer after interoperability takes hold.