Coinbase lleva x402 hacia una posición neutral, Stripe continúa apostando en ambos lados fuera de MPP

autor: Charlie, responsable de OSL para América, Venture Partner en Generative Ventures. Anteriormente fue vicepresidente de la cripto- unicornio Strike (participó en el proyecto de ley de Bitcoin de El Salvador y se encargó de los negocios de la red de Lightning de Bitcoin en LATAM y pagos con stablecoins), analista macro y monetario en Franklin Templeton, un fondo de escala billonaria, y miembro temprano del gigante global de pagos Adyen.

El artículo es una opinión personal del autor y no representa la postura de las empresas relacionadas.

Cada vez hay más amigos que recientemente están prestando atención al agentic commerce, pero toda clase de protocolos y jugadores también hacen que cada vez sea más difícil para todos entender el panorama.

Especialmente la semana pasada: todos seguían ocupados en conocer el MPP de Stripe / Tempo, y de pronto resulta que Stripe se unió al x402 Foundation del competidor Coinbase.

Además, Cloudflare ahora también admite ambos. Google también está metido en el asunto, pero por su parte tiene AP2 y UCP.

Visa y Mastercard también han llegado, pero obviamente no han venido a respaldar stablecoins.

Linux Foundation define públicamente x402 como un “campo base” neutral, de gobernanza compartida por la industria; mientras que Cloudflare, de manera explícita, mete tanto x402 como MPP en su Agents SDK, y Stripe también ha escrito públicamente que admite tanto MPP como x402.

Entonces, ¿quién está compitiendo con quién y, por otra parte, quién se superpone con quién?

Pero estos días, cuanto más lo miro, más me da la impresión de que este “desorden” no es porque el mercado no tenga dirección, sino porque el mercado ya está muy claro, y además, como antes con x402, probablemente todos entendimos mal el significado original que se mencionaba: desde el primer día, esta cuestión no se unificará con un solo protocolo.

Se parece más a una situación muy común en la infraestructura de internet: distintas capas crecen al mismo tiempo, distintas compañías apuestan en distintas capas y, al final, todo se pone a funcionar primero gracias a la interoperabilidad.

La historia estratégica real es quién define la capa de control predeterminada para el paid machine access en el agentic web; y los actores clave, claramente, hacen multi-home, porque todos aún apuestan a que el verdadero cuello de botella futuro caerá en la autorización, la distribución o el settlement.

I. Por qué Coinbase soltó x402 y entregó el fondo a Linux?

Si x402 fuera solo un protocolo de Coinbase, le sería difícil convertirse en la opción predeterminada de la industria.

Esto no es una frase de corrección política, sino una lógica de estandarización muy realista.

La formulación de Linux Foundation en esta ocasión es muy clara: enfatiza que es neutral el servicio, la gobernanza comunitaria, la infraestructura compartida; no es “una compañía lanzó una nueva función de producto”.

Más importante aún: la página de x402 Foundation todavía escribe que el proyecto está en fase de construcción, y que los mecanismos de gobernanza y el consejo de administración aún se están montando.

Dicho de otro modo: esta acción no es primero un anuncio de “el producto ya está maduro”, sino un anuncio de “vamos a darle a este protocolo un hogar neutral”.

El mensaje implícito detrás de esto, en realidad, es muy sencillo.

Si x402 siguiera creciendo con una “cara de función de producto” de Coinbase (por ejemplo, Base en este momento), entonces proveedores de nube, empresas de pagos, organizaciones de tarjetas y jugadores tipo plataforma, aunque técnicamente quieran conectarse, políticamente dudarían.

Nadie quiere entregar la capa futura de paid access a una sola plataforma. Ponerlo bajo Linux Foundation no es porque Coinbase no quiera controlarlo; es justo porque quiere que x402 sea adoptado ampliamente, y por lo tanto primero debe quitarse la carga de “esto es un protocolo de Coinbase”.

Este punto en realidad es importante, porque mucha gente mira acciones como las de fundaciones y tiende a verlas solo como PR o como una postura de open source.

Pero en la guerra de protocolos, la gobernanza es parte del producto.

Especialmente cuando un estándar todavía está en etapas tempranas y aún no ha logrado efectos de red absolutos, la llamada “neutralidad confiable” no es menos importante que la elegancia técnica.

Al contrario: si en el futuro x402 realmente pudiera convertirse en algún tipo de baseline de paid access native de HTTP, probablemente no sea porque su código sea el más bonito, sino porque redujo antes los costos políticos frente a otras soluciones.

En otras palabras: aquí la gobernanza no es un papel secundario; la gobernanza en sí es el motor de crecimiento.

II. ¿Qué está haciendo realmente Stripe con su “lucha de ida y vuelta”?

El jugador más digno de atención en esta ocasión, sin duda, es Stripe, porque las acciones de Stripe son las que más fácilmente confunden.

Por un lado, en marzo 18 lanzó de forma destacada MPP, y lo empaquetó como un estándar abierto para pagos de máquinas.

Por el otro, también es founding contributor de x402 Foundation, y además su propia documentación también apoya x402 machine payments.

La documentación de Cloudflare es más directa: incluso escribe con claridad que el core payment flow de MPP para x402 es backward-compatible; el cliente MPP puede consumir directamente servicios existentes de x402.

Si solo miras esto desde el marco de “competencia de protocolos”, Stripe parece estar haciendo lucha en ambos lados.

Pero si elevas un poco más el punto de vista, este enfoque tiene más lógica comercial.

Porque lo que Stripe realmente quiere proteger no es necesariamente el propio 402 handshake.

Lo que realmente quiere resguardar son las capas que están encima del handshake: credentials, compliance, risk, reporting, tax, refunds, merchant integration.

Stripe no parece ser un creyente genuino de un protocolo único; más bien parece asegurarse de que, gane cual gane el estándar de handshake final, Stripe siga siendo la capa de abstracción predeterminada para agent payments.

Admitir x402 es para no quedar fuera del ecosistema abierto; impulsar MPP es para participar en la definición de la semántica base; y empujar ACP y Shared Payment Tokens por encima es para proteger una capa de mayor valor: el flujo de trabajo y las credenciales de pago.

Así que, en realidad, el lugar “más raro” de Stripe en esta ronda es, precisamente, el más honesto.

No está fingiendo que en el futuro rápidamente quedará solo un protocolo. Está usando acciones para decirte: al menos en esta etapa, nadie debería apostar solo a un lado.

III. En realidad, es una historia de infraestructura B2B

Cada vez me convenzo más de que muchos medios están poniendo el foco en el lugar equivocado.

Cuando se habla de agent payments, lo primero que suele venir a la mente es el retail: que la IA te compre boletos de avión, te reserve hoteles, te haga el pedido y te lleve a través del checkout.

Pero si miras los casos que realmente ya están en marcha y además tienen “olor a infraestructura”, lo que primero despega no es el checkout minorista, sino un paid access B2B más aburrido y más real: APIs pagadas, datos pagados, herramientas pagadas, sesiones de navegador para agentes pagadas, y workflows pagados de agent.

Cloudflare ahora admite públicamente cobrar por contenido HTTP, API y MCP tools usando x402 y MPP.

La ruta de adopción más fuerte de x402 está en las paid APIs y tools developer-to-developer, porque “no account + pay-per-request” aquí no es un gancho, sino un despliegue realmente operable.

El cambio detrás de esto es bastante grande.

Antes, cobrar por una API normalmente requería primero pasar por todo un flujo “amigable para humanos”: abrir cuenta, vincular billing, emitir API key, configurar límites, conciliación, y luego gestionar permisos de pago.

Para las personas ya es bastante molesto; para los agentes, aún más incómodo.

Lo más atractivo de x402 no es que sea más cripto, ni que sea más IA; es que intenta reinsertar el “acceso pagado” en el HTTP mismo, haciendo que el control de acceso y la negociación de pagos ocurran como una solicitud request-response normal.

El servidor responde 402, diciéndote cuánto vale esta solicitud; el cliente paga y luego reintenta la misma solicitud usando la credencial de pago.

Este modelo, si lo miras desde la perspectiva del software B2B y el acceso machine-to-machine, encaja mucho mejor que desde la perspectiva minorista.

Y cuanto más miras hacia B2B, más claras se vuelven las ventajas de x402 y menos letales sus debilidades.

Porque en consumer commerce, reembolsos, chargebacks, merchant-of-record, protección al consumidor y asignación de responsabilidad son problemas duros; pero en APIs y llamadas de herramientas B2B, la importancia de esos problemas baja de forma evidente.

En cambio, “sin cuenta, pagar por llamada, obtener el resultado y salir” es la necesidad real.

El retail es más grande y más ruidoso, y por tanto atrae más miradas; pero definir realmente cómo es un protocolo, a menudo no ocurre en el escenario más ruidoso, sino en el escenario que expone antes necesidades reales.

Para esta ola de agent payments hoy, ese escenario probablemente no sea un carrito de compras, sino cada vez más paid access entre software, entre agentes y entre workflows.

IV. El desarrollo de la industria validó mi juicio anterior sobre interoperabilidad

En mi artículo anterior, el juicio más central era interoperability.

En ese momento, ese juicio todavía sonaba como “debería ser así desde el punto de vista de la arquitectura”.

Ahora se parece cada vez más a una restricción de la realidad, porque el mercado público ya está votando con los pies.

Cloudflare no eligió un bando; admite directamente tanto x402 como MPP, y además deja claro que hace mapeo compatible.

Por un lado, Google participa en x402 y, por otro, continúa impulsando AP2 y UCP.

Visa y Mastercard tampoco expresaron su estrategia con la postura de “all in a un único ganador”; en vez de eso, por un lado se suman a x402 y por otro continúan intensificando agent tokens, autenticación, validación de instrucciones y dispute signals.

Las apuestas multilaterales de los gigantes son una decisión racional, no hipocresía comercial.

¿Y por qué pasa esto? Porque estos protocolos, en realidad, no están en la misma capa.

Al menos hasta ahora, x402 y MPP se parecen más a la capa de paid HTTP handshake: resuelven “cómo hacer que la solicitud regrese con capacidad de pago”.

AP2 se acerca más a authorization e intención confiable, resolviendo “si este agent realmente tiene permiso para gastar ese dinero”.

UCP y ACP se parecen más a la capa de workflow: encargada de problemas de nivel superior como discovery, checkout, relación con el merchant y el intercambio de credenciales.

Muchas compañías soportan simultáneamente x402, MPP, AP2 y UCP no porque no se aclaren, sino porque la arquitectura que se gana al final probablemente cruza varias capas e incluso requiere que múltiples protocolos se compongan juntos.

Así que, si tengo que responder con una frase a mi juicio anterior, ahora estoy aún más convencido de que sin interoperability, esta ola de ecosistema simplemente no podría levantarse.

Ahora se ve que el mercado está validando activamente ese juicio.

Más allá: este juicio también es importante para B2B vs retail.

Porque en el mundo del retail, quizá al final sí sea absorbido por unos pocos grandes plataformas y unos pocos grandes workflows; pero en el mundo B2B no es así.

Las empresas ya viven en una realidad donde conviven múltiples nubes, múltiples métodos de pago, múltiples sistemas de workflow y múltiples sistemas de credenciales y permisos de identidad.

Quien intente derribar y rehacer todo el stack empresarial con un nuevo protocolo, probablemente muera primero.

Lo que realmente está dispuesto a pagar en B2B no suele ser “el único protocolo correcto”, sino la capacidad de hacer que los sistemas existentes sigan funcionando en un entorno de múltiples protocolos.

Y esa lógica hace que, en escenarios empresariales, interoperability sea más fuerte que en consumer.

V. Esto no es solo competencia de protocolos; es competencia de stack después de la segmentación por capas

En cuanto entiendes el asunto como un stack por capas, muchos fenómenos que antes se veían desordenados se alinean de inmediato.

La capa más baja es paid access handshake.

A esta capa le importa: cómo expresar en HTTP “aquí se requiere pago”, y cómo traer de vuelta las credenciales de pago después de que el cliente pague.

Aquí pelean principalmente x402 y MPP. MPP intenta “capturar” el 402 hacia semánticas más formales de HTTP auth; mientras que x402 parece “platformizar” el 402, mediante header personalizado, facilitators, abstracción de settlement on-chain e integración con ecosistemas, para que pueda ponerse en marcha primero.

Un camino más parecido a semántica estandarizada, y otro más parecido a distribución de plataforma.

La capa superior es authority to spend, es decir: “quién autorizó ese dinero”.

Esta capa es clave, y mucha gente todavía no lo tiene completamente claro.

Que las máquinas paguen no es lo difícil; lo difícil es que las máquinas puedan ser autorizadas de manera confiable para pagar ese dinero.

AP2 es importante precisamente porque no trata solo de “cómo pagar”, sino de resolver mandates, verifiable credentials, authenticity y accountability.

Los agent tokens, instruction validation, passkeys y dispute signals que Visa y Mastercard han reforzado recientemente, en esencia también están aquí.

La capa siguiente es workflow y distribution.

Es decir: discovery, checkout, relación con merchants, compartir credenciales, integración de la superficie de AI: todo lo que se acerca más a “quién controla el flujo y la orquestación de transacciones”.

UCP y ACP parecen estar compitiendo por esta capa.

En B2B, a corto plazo esta capa no es tan llamativa, pero a largo plazo el valor podría ser muy alto.

Porque si, en el futuro, cada vez más software empresarial está coordinado, llamado, abastecido y pagado por agentes, entonces quien controle el language de workflow no solo controla un pago, sino que controla el workflow completo.

Una vez que separas estas tres capas, aparece un hecho muy sencillo: no hay necesidad de esperar que un protocolo cubra todos los problemas.

El camino más realista es que estas tres capas crezcan primero por separado y luego se vayan encajando lentamente gracias a la interoperabilidad.

Y por eso, las apuestas por varios frentes no son indecisión; son racionalidad.

VI. El riesgo real de x402: quizá no es la regulación, sino la economía bajo concurrencia

Si solo reconocemos “convivencia de múltiples protocolos”, eso aún no es suficiente.

El mayor riesgo de x402 quizá no sea primero la regulación, sino la economía de verify–settle en dos pasos, es decir, el time-of-check/time-of-use que surge por dividir verificación y settlement.

En simple: si verificar el pago y liquidar el settlement final no son lo mismo, entonces en entornos reales de internet con alta concurrencia, reintentos, capas de agente y capas de caché, aparecerá una ventana de “paga una vez, accede múltiples veces”.

El ecosistema x402 ahora también está parcheando huecos: settlement cache, idempotency extension, payment identifier, pero precisamente eso demuestra que el problema no es teórico.

¿Por qué esto vale la pena que los lectores B2B lo consideren especialmente?

Porque en B2B el mayor miedo no es que no se pueda hacer un demo bonito; es que haya demasiados edge cases y al momento de llevarlo a producción empiece a “separarse” y fallar con fugas.

Monetización de APIs, a simple vista, parece que es solo pagar unos céntimos por cada solicitud; pero si tu producto cobra por llamada, por resultado o por workflow, entonces “pagar una vez y obtener una vez” vs “pagar una vez y obtener muchas veces” ya no es un detalle del producto, sino una línea de vida o muerte.

Así que si en el futuro x402 realmente logra funcionar en B2B, un requisito importante no es la narrativa, sino que estos mecanismos default-safe se implementen de forma lo suficientemente “a prueba de tontos”; de lo contrario, las empresas no se atreverán a confiar en conectar tráfico real.

VII. Los protocolos pueden ser gratuitos, pero los peajes no van a desaparecer

Otro punto que me parece importante aclarar aquí.

Muchos protocolos abiertos terminan llegando a un lugar muy conocido: el protocolo mismo se vuelve cada vez más barato, incluso gratis; pero el peaje de cobro aparece al lado.

x402 también es igual.

El estándar, por supuesto, subraya que sea abierto, neutral y con 0 fees incluidos en el estándar, pero eso no significa que vaya a desaparecer el value capture.

Si x402 tiene éxito, el valor no se quedará principalmente en el protocolo, sino que migrará a capas vecinas: facilitators, wallets y gestión de claves, discovery, policy engine, trust wrapper, etc.

Esto es especialmente importante para B2B.

Porque los clientes empresariales no van a remodelar masivamente todo su sistema solo por un nuevo protocolo; lo que realmente están dispuestos a pagar es por quién pueda ayudarlos a resolver y gestionar, en un entorno multi-protocolo, la orquestación, policy, risk, compliance, audit, settlement y los límites de permisos.

En otras palabras: el protocolo se parecerá cada vez más a un lenguaje de bajo nivel, pero la capacidad de traducir esos lenguajes en “habilidad para que la empresa se sienta segura al desplegarlo” en esa capa, al contrario, será más fácil que se convierta en una nueva plataforma y un nuevo peaje de cobro.

Por eso siento que, al mirar x402 hoy, no deberíamos fijarnos solo en quién se parece más a “el protagonista”: Coinbase, Cloudflare o Stripe.

Lo verdaderamente relevante es quién tiene más oportunidad de estar de pie en esas capas adyacentes.

Cloudflare tiene la ubicación de edge y distribución de tráfico; Stripe tiene infraestructura de pagos y posición en la relación con merchants; Visa y Mastercard tienen posiciones en credenciales, network tokens y consumer trust; Google tiene la posición de workflow y discovery surface.

La captura de valor real no necesariamente ocurre en “quién define 402”; es más probable que ocurra en “quién conecta 402 dentro de un sistema empresarial más grande”.

VIII. Conclusión

El tema de x402 Foundation no es anunciar que x402 ya ha ganado en todos los protocolos de agentic commerce.

Es un reconocimiento público: esta generación de agent payments no será un mundo de un solo protocolo desde el primer día.

Que Coinbase haya entregado x402 a Linux Foundation es para que se parezca más a una capa pública neutral, en lugar de un producto exclusivo.

Que Stripe impulse MPP a la vez que se una a x402 no es vacilación, sino porque sabe que ahora no debería apostar solo a un lado.

Que Cloudflare soporte ambos al mismo tiempo es porque es el más cercano al tráfico real.

Las acciones de Google, Visa, Mastercard, Adyen y otros jugadores también están mostrando lo mismo: primero hacer que el sistema sea interoperable; después, discutir en qué capa se terminará quedando cada quien.

Y si cambias la perspectiva desde el retail, este juicio también encaja mejor.

Porque quienes necesitan primero estos protocolos quizá no sea el carrito de compras, sino cada vez más software y servicios B2B que cobran por llamada, por tarea y por resultado.

El retail es, claro, más grande; pero B2B suele exponer antes necesidades reales y define antes cómo debe verse el final de la infraestructura.

En mi artículo anterior puse interoperability en el centro, y ahora creo que la respuesta que da el mercado es bastante clara: sí, y además más pronto de lo que yo pensaba entonces.

En ese sentido, x402 Foundation no es el final de esta historia.

Solo nos hace ver antes que el tema real nunca fue “quién va a ganar”, sino “este mundo está destinado a ser interoperable primero, y quién podrá quedarse con la capa que más valor tiene después de que se logre la interoperabilidad”.