Coinbase lleva x402 a una posición neutral, Stripe apuesta en ambos lados fuera de MPP

Autor: Charlie Liu, socio de Generative Ventures

Cada vez hay más gente que sigue de cerca el agentic commerce, pero toda clase de protocolos y actores también hacen que a todos les cueste cada vez más aclararse.

En particular, la semana pasada, todos seguían ocupados en entender el MPP de Stripe / Tempo; y de repente Stripe incluso se ha unido a la x402 Foundation, de su competidor Coinbase.

Además, Cloudflare ahora es compatible con ambos. Google también está metido en este asunto, pero por su cuenta maneja AP2 y UCP.

Visa y Mastercard también han llegado, pero evidentemente no vienen a respaldar los stablecoins.

Linux Foundation ha definido públicamente x402 como un “campo base” neutral y gobernado de forma conjunta por la industria; mientras tanto, Cloudflare ha incluido explícitamente tanto x402 como MPP en su Agents SDK, y Stripe también ha publicado que es compatible con MPP y con x402.

Entonces, ¿quién compite con quién y, además, quién se superpone con quién?

Pero cuanto más miro estos días, más me convenzo de que este “desorden” no es porque el mercado no tenga dirección, sino porque el mercado ya lo tiene muy claro y, como ya mencioné antes: desde el primer día, esto no lo unificará un solo protocolo de una vez.

Se parece más a un escenario muy común en la infraestructura de Internet: distintas capas creciendo a la vez, distintas compañías apostando en capas diferentes, y al final haciendo que todo funcione primero gracias a la interoperabilidad.

La historia estratégica real es quién va a definir la capa de control predeterminada para paid machine access en la web agentic; y los jugadores clave, claramente, también están multi-home, porque todos siguen apostando a que el cuello de botella real del futuro estará en autorización, distribución o liquidación.

Uno. ¿Por qué Coinbase dejó ir la x402 Foundation y se la entregó a Linux?

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

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

La formulación de Linux Foundation esta vez es muy clara: enfatiza la neutralidad del proveedor de servicios, el gobierno comunitario y la infraestructura compartida, en lugar de “una empresa publicó una nueva funcionalidad de producto”.

Y lo más clave es que en la página de x402 Foundation todavía se lee que el proyecto está en fase de establecimiento, y que los mecanismos de gobernanza y la junta directiva aún están en construcción.

Es decir: la acción de esta vez no está anunciando primero que “el producto ya está maduro”, sino que “queremos darle un hogar neutral a este protocolo”.

El mensaje subyacente detrás es bastante sencillo.

Si x402 siempre estuviera creciendo con la cara de una funcionalidad de producto de Coinbase (por ejemplo, Base ahora), entonces los proveedores de nube, las empresas de pagos, las organizaciones de tarjetas y los actores tipo plataforma, incluso si técnicamente estuvieran dispuestos a integrarlo, dudarían políticamente.

Nadie quiere entregar la futura capa de paid access a una sola plataforma. Ponerla bajo Linux Foundation no es porque Coinbase no quiera controlar; es, al contrario, porque Coinbase quiere que x402 se adopte ampliamente y por eso debe quitar primero la carga de “esto es el protocolo de Coinbase”.

Esto es importante, porque mucha gente, al ver acciones como las de fundaciones, tiende a interpretarlas solo como PR o como postura de código abierto.

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

Especialmente cuando un estándar aún está en etapas tempranas y todavía no tiene efectos de red absolutos, la supuesta “confianza neutral” no es menos importante que la elegancia técnica.

Dicho al revés: si en el futuro x402 realmente se convirtiera en algún baseline de paid access nativo de HTTP, probablemente no sería porque su código sea el más bonito, sino porque ha reducido antes los costos políticos frente a otras soluciones.

En otras palabras, aquí la gobernanza no es un papel secundario; la gobernanza misma es el motor de crecimiento.

Dos. ¿Qué están haciendo realmente los choques cruzados de Stripe?

El actor más digno de vigilar esta vez es, sin duda, Stripe, porque las acciones de Stripe son las más fáciles de confundir.

Por un lado, el 18 de marzo lanzó de forma muy destacada el MPP, y lo enmarcó como un estándar abierto para los machine payments.

Por otro lado, también es founding contributor de x402 Foundation, y su propia documentación también da soporte a x402 machine payments.

La documentación de Cloudflare es incluso más directa: e incluso escribe explícitamente que el flujo de pago central de MPP para x402 es backward-compatible; que un cliente MPP puede consumir directamente los servicios existentes de x402.

Si solo lo analizas dentro del marco de “competencia de protocolos”, Stripe parece estar haciendo movimientos de ida y vuelta.

Pero si elevas un poco más la perspectiva, esta conducta, en realidad, tiene toda la lógica de negocio.

Porque lo que Stripe realmente quiere proteger quizá no sea solo el propio handshake de 402.

Lo que Stripe quiere proteger de verdad son esas capas encima del handshake: credentials, compliance, risk, reporting, tax, refunds e integración con merchants.

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

Dar soporte a x402 es para no quedar fuera del ecosistema abierto; impulsar MPP es para participar en la definición de los significados subyacentes; y empujar ACP y Shared Payment Tokens por encima, es para resguardar una capa de valor más gruesa: el flujo de trabajo y las credenciales de pago.

Por eso, lo más “extraño” de esta vez en Stripe, en realidad, es lo más honesto.

No está fingiendo que en el futuro habrá rápidamente solo un protocolo. Con acciones te está diciendo: al menos en esta fase, nadie debería apostar únicamente por un lado.

Tres. En realidad, esto es una historia de infraestructura B2B

Cada vez siento más que muchos medios le han puesto el foco en un lugar equivocado.

Cuando se habla de agent payments, lo primero que se imagina casi siempre es el retail: que la IA te compre boletos de avión, te reserve hoteles, te haga el pedido y te lleve al checkout.

Pero si miras los escenarios que ya están realmente publicados y que ya empezaron a ponerse en marcha con un “sabor” de infraestructura, lo primero que corre no es el checkout retail, sino el paid access B2B: más aburrido, pero también más real y más auténtico—API de pago, datos de pago, herramientas de pago, sesiones de navegador de pago, workflows de agentes de pago.

Cloudflare ahora da soporte públicamente para cobrar por contenido HTTP, API y herramientas de MCP usando x402 y MPP.

La ruta de adopción más fuerte de x402 está en APIs y tools pagadas de developer-to-developer, porque “no account + pay-per-request” aquí no es una moda publicitaria, sino una puesta en práctica operativa.

El cambio que hay detrás es enorme.

Antes, cuando una API se cobraba, normalmente había que pasar por un conjunto completo de procesos “amigables para humanos”: abrir una cuenta, vincular billing, emitir una API key, configurar límites, conciliación contable y luego tramitar permisos de pago.

Para las personas ya es bastante molesto; para los agentes, todavía peor.

Lo más atractivo de x402 no es que sea más crypto, ni que sea más IA, sino que intenta volver a meter el “acceso de pago” dentro del propio HTTP, haciendo que el control de acceso y la negociación de pagos ocurran como si fuera una solicitud request-response normal.

El servidor responde con 402, diciéndote cuánto vale esta solicitud; el cliente paga, y luego reintenta el mismo request usando las credenciales de pago.

Si observas este modelo desde la perspectiva de software B2B y access machine-to-machine, encaja mucho mejor que desde la perspectiva del retail.

Y cuanto más te mueves hacia el lado B2B, más claras se vuelven las ventajas de x402 y menos letales son sus carencias.

Porque en consumer commerce, reembolsos, chargebacks, merchant-of-record, consumer protection, asignación de responsabilidades: todo son problemas difíciles; pero en APIs y llamadas de herramientas B2B, la importancia de esos problemas baja de forma evidente.

En cambio, lo que es una necesidad real es “sin cuenta, pagando por llamada, obteniendo el resultado y te vas”.

El retail es más grande, más caliente y más fácil de atraer miradas; pero lo que define cómo será un protocolo, a menudo no es el escenario más ruidoso, sino el escenario que primero expone necesidades reales.

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

Cuatro. La evolución de la industria valida mi juicio previo de interoperability

En mi artículo anterior, la conclusión más central era la interoperability.

En ese entonces, esa conclusión sonaba todavía un poco a “debería ser así a nivel de arquitectura”.

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

Cloudflare no eligió bando: en vez de eso, dio soporte directamente tanto a x402 como a MPP, y además hizo mapeos de compatibilidad explícitos.

Google participa en x402 y, al mismo tiempo, sigue empujando AP2 y UCP.

Visa y Mastercard tampoco han expresado su estrategia con la postura “all in one winner”; en vez de eso, se unen a x402 por un lado y por otro intensifican agent token, autenticación, validación de instrucciones y señales de disputa.

Las apuestas multilaterales de los gigantes son decisiones racionales, no hipocresía comercial.

¿Por qué pasa esto? Porque estos protocolos ni siquiera están en el mismo nivel.

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 traiga capacidades de pago de vuelta”.

AP2 se parece más a authority to spend y a la intención confiable: resuelve “si este agent realmente tiene autorización para gastar este dinero”.

UCP y ACP se parecen más a una capa de workflow: para resolver problemas más arriba, como discovery, checkout, relación con merchants y transmisión de credenciales.

Muchas compañías soportan x402, MPP, AP2 y UCP al mismo tiempo no porque no tengan claro lo que hacen, sino porque ganar al final probablemente significa una arquitectura que cruza múltiples capas e incluso necesita que varios protocolos se compongan juntos.

Así que, si volvemos a mirar mi juicio anterior con una sola frase, ahora estoy más convencido de que sin interoperability, esta ola de ecosistemas ni siquiera podría levantarse.

Ahora, el mercado está validando activamente esa conclusión.

Más aún: esta conclusión también es importante para B2B vs retail.

Porque en el mundo retail quizá termine absorbiéndolo un puñado de grandes plataformas y unos pocos grandes workflows; pero en el mundo B2B no es así.

Las empresas viven de hecho en una realidad de múltiples nubes, múltiples métodos de pago, múltiples sistemas de workflows y múltiples sistemas de identidades/permisos.

Quien intente derribar y rehacer toda la pila de una empresa con un solo protocolo nuevo, probablemente muera primero.

Los clientes B2B que de verdad están dispuestos a pagar, normalmente no compran “el protocolo único correcto”, sino la capacidad de “hacer que los sistemas existentes sigan funcionando en un entorno con múltiples protocolos”.

Esta lógica es precisamente la razón por la que interoperability es un poco más fuerte en escenarios empresariales que en los consumer.

Cinco. Esto no es solo competencia de protocolos; es competencia de stack después de capas

Si entiendes este asunto como una competencia de stack por capas, muchos fenómenos que antes parecían caóticos encajan de inmediato.

La capa más baja es el paid access handshake.

Aquí se pregunta: cómo expresa la solicitud HTTP “esto requiere pago”, y cómo el cliente trae de vuelta las credenciales de pago después de pagarlo.

x402 y MPP compiten principalmente aquí. MPP intenta llevar el 402 hacia semánticas de auth de HTTP más formales; y x402, por su parte, parece “plataformizar” el 402: mediante headers personalizados, facilitators, abstracciones de liquidación on-chain e integraciones de ecosistema, para que pueda empezar a funcionar.

Uno sigue una ruta más de semántica estandarizada; el otro, una ruta más de distribución tipo plataforma.

La siguiente capa es authority to spend, es decir, “quién autorizó este dinero”.

Esta capa es clave y mucha gente todavía no lo ha entendido del todo.

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

AP2 es importante precisamente porque no solo resuelve “cómo pagar”, sino que está resolviendo mandates, verifiable credentials, autenticidad y accountability.

Los agent token, validación de instrucciones, passkeys y dispute signals con los que Visa y Mastercard han reforzado últimamente también, en esencia, están resolviendo aquí.

Un nivel por encima está workflow y distribution.

Es decir: discovery, checkout, relación con merchants, compartir credenciales, integración en la superficie para IA; todo esto está más cerca de “quién controla el flujo y la orquestación de transacciones”.

UCP y ACP se parecen más a una disputa por esa capa.

Para B2B esta capa puede no ser tan emocionante a corto plazo, pero a largo plazo el valor podría ser muy alto.

Porque si en el futuro cada vez más software empresarial lo coordinan agent, llaman, compran y pagan, entonces quien controle el language del workflow no solo controla un pago: controla todo el workflow.

Una vez separas estas tres capas, descubres un hecho bastante obvio: no hay necesidad de esperar que un protocolo lo cubra todo.

La ruta más realista es que estas tres capas crezcan por su cuenta primero y luego se vayan acoplando lentamente mediante interoperabilidad.

Por eso, apostar en varios frentes no es indecisión; es racionalidad.

Seis. El riesgo real de x402 no es necesariamente la regulación, sino la economía del tiempo en concurrencia

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

El mayor riesgo de x402 puede no ser primero la regulación, sino la economía de time-of-check/time-of-use que proviene de separar verificación y liquidación en dos pasos.

En términos sencillos: si verificar el pago y liquidar finalmente no son lo mismo, entonces en entornos reales de Internet como alta concurrencia, reintentos, capa de agentes y capa de caché, aparece una ventana de “paga una vez, accede múltiples veces”.

El ecosistema x402 también está rellenando huecos: settlement cache, idempotency extension y payment identifier; pero justamente eso demuestra que el problema no es meramente teórico.

¿Por qué vale especialmente la pena que los lectores B2B se preocupen por esto?

Porque lo que B2B más teme nunca es “no poder hacer demos bonitas”, sino que haya demasiados edge cases y luego, al llegar a producción, se empiece a filtrar por todas partes.

Monetización de API, en apariencia, es “unos centavos por request”, algo ligero; pero si tu producto cobra por llamada, por resultados o por workflow, entonces si “pagas una vez y obtienes una vez” o si “pagas una vez y obtienes muchas veces” deja de ser un detalle del producto y se convierte en una línea de vida o muerte.

Así que, si en el futuro x402 realmente logra correr en B2B, un requisito importante no es el narrative, sino que estos mecanismos default-safe se implementen de forma suficientemente “sin dolor”, es decir, automática y sin fricciones; de lo contrario, las empresas no se sentirán cómodas conectando tráfico real.

Siete. Los protocolos pueden ser gratis, pero los puestos de peaje no desaparecerán

Hay otra cosa que creo que vale la pena dejar clara en este artículo.

Muchos protocolos abiertos terminan yendo a un lugar bastante familiar: el protocolo en sí se vuelve cada vez más barato, incluso gratis; pero los puestos de peaje donde realmente se cobra crecen a un lado.

x402 es igual.

El estándar en sí, por supuesto, enfatiza apertura, neutralidad y 0 fees integradas en el estándar; pero eso no significa que el value capture vaya a desaparecer.

Si x402 tiene éxito, el valor no se quedará principalmente en el protocolo, sino que se moverá a capas vecinas: facilitators, wallet y key management, discovery, policy engine, trust wrapper y similares.

Para B2B esto es especialmente importante.

Porque los clientes empresariales no van a pagar para que un protocolo nuevo les obligue a rediseñar masivamente toda su pila; lo que realmente están dispuestos a pagar es que alguien pueda ayudarles a arreglar esos dolores de cabeza—orchestration, policy, risk, compliance, audit, settlement, y límites de permisos—en un entorno multi-protocolo.

Dicho de otra manera: el protocolo se parecerá cada vez más a un lenguaje de bajo nivel; pero la capacidad de traducir esos lenguajes a “habilidades listas para que la empresa las publique con tranquilidad” será más fácil de convertirse en una plataforma nueva y en nuevos puestos de peaje de cobro.

Por eso es que yo creo que, al mirar x402 hoy, no se puede solo fijarse en quién se parece más a “el protagonista”: Coinbase, Cloudflare o Stripe.

Lo realmente digno de vigilar es quién tiene más oportunidad de posicionarse en esas capas vecinas.

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

La captura de valor real no tiene por qué ocurrir donde “quien define el 402”, sino más probablemente donde “quien conecta el 402 dentro de un sistema empresarial más grande”.

Ocho. Conclusión

Este asunto de x402 Foundation no está anunciando que x402 ya haya ganado en todos los protocolos de agentic commerce.

Está reconociendo abiertamente que esta generación de agent payments, desde el primer día, no será un mundo de un único protocolo.

Que Coinbase entregue x402 a Linux Foundation es para hacerlo más como una capa pública neutral, y no como un producto exclusivo.

Que Stripe, por un lado, impulse MPP y por otro se una a x402 no es indecisión: es porque sabe que ahora no debería apostar solo por un lado.

Que Cloudflare soporte las dos cosas es porque está más cerca del tráfico real.

Las acciones de estos jugadores—Google, Visa, Mastercard, Adyen—también están diciendo lo mismo: primero hacer que los sistemas sean interoperables y luego discutir quién se quedará con qué capa al final.

Y si apartas la mirada del retail, esta conclusión encaja aún mejor.

Porque quienes primero necesitan estos protocolos quizá no sean los carros de compra, sino cada vez más software y servicios B2B que cobran por llamada, por tarea, y por resultado.

El retail es más grande, sin duda, pero B2B suele revelar necesidades reales antes y define antes cómo debe ser la infraestructura final.

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

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

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