¿Qué es el protocolo x402: pagos HTTP 402 por acceso?

El protocolo X402 es un estándar de pago abierto y nativo de HTTP que utiliza la respuesta HTTP 402 "Pago Requerido" más encabezados estandarizados para hacer que un cliente pague antes de que un servidor devuelva un recurso. Convierte una llamada API normal en un flujo determinista de cotización → pago → verificación/liquidación → recibo, con servicios de terceros opcionales para manejar la verificación y liquidación a través de redes.

Conclusiones Clave

• x402 utiliza http 402 "Pago Requerido" más encabezados estandarizados para que un servidor pueda exigir el pago antes de servir unarespuesta APIo recurso web.
• El apretón de manos principal es 402 + PAYMENT-REQUIRED (cotización) → reintentar con PAYMENT-SIGNATURE (carga de pago) → verificar y liquidar → 200 + PAYMENT-RESPONSE (recibo).
• x402 se mantiene agnóstico a la red al emparejar un esquema de pago con una implementación de red específica, y puede externalizar la verificación y liquidación a un facilitador.
• Solanacomercializa x402 con estadísticas específicas de la cadena, incluyendo ~400ms de finalización, ~$0.00025 de costos de transacción, y más de 35M de transacciones x402 y más de $10M de volumen desde su lanzamiento en Solana.

X402 como un estándar de pago HTTP

El movimiento clave en lo que es el protocolo x402 es que el pago se convierte en un patrón de respuesta HTTP de primera clase, no en un sistema de facturación específico de la aplicación que se añade posteriormente. Un servidor de recursos puede responder a una solicitud no pagada con http 402 y requisitos de pago legibles por máquina, y el cliente puede responder con una carga de pago firmada en los encabezados.

Por eso, "x402 explicado" se lee menos como una presentación de producto cripto y más como una pieza faltante de la plomería web que se está completando.

Esto es importante para la economía de agentes explicada porque los agentes no quieren "registrarse" en cada punto final que tocan. La monetización tradicional de API obliga a las cuentas,Claves API, facturas y una historia de autenticación separada.

x402 invierte la secuencia: el servidor cita los términos de pago dentro del mismo flujo HTTP, y el cliente prueba la autorización de pago de la misma manera que prueba cualquier otra propiedad de la solicitud, enviando un encabezado.

x402 se especifica como un estándar abierto para "pagos nativos de internet", destinado a ser agnóstico en cuanto a red, token y moneda. El centro de gravedad de la especificación es el repositorio de la Fundación x402, que es el objetivo de compatibilidad que los desarrolladores deberían seguir.

Coinbase x402 también existe, pero su propio README lo señala como un fork de desarrollo después de que el proyecto se trasladara a la Fundación x402, que es la realidad de gobernanza práctica detrás de "coinbase x402".

Cómo se paga una solicitud x402

Entre un cliente que accede a un endpoint y el servidor que devuelve un 200 OK, x402 fuerza la interacción a una microestructura predecible: cotización, llenado, compensación, recibo. El protocolo lo hace con códigos de estado y encabezados, no con un apretón de manos de SDK personalizado.

Un flujo típico, como se documenta en la especificación de la Fundación x402, funciona así:

1. El cliente solicita un recurso a un servidor de recursos a través de HTTP. 2. El servidor de recursos devuelve una respuesta 402 Payment Required con un encabezado PAYMENT-REQUIRED que contiene un objeto PaymentRequired codificado en base64 que enumera los PaymentRequirements aceptables. 3. El cliente selecciona un PaymentRequirement y construye un PaymentPayload que coincide con el par (esquema, red) elegido. 4.

El cliente reintenta la solicitud con un encabezado PAYMENT-SIGNATURE que lleva el PaymentPayload. 5. El servidor de recursos verifica el payload ya sea localmente o enviando por POST el payload y los requisitos a un endpoint de facilitador /verify. 6. Si la verificación es válida, el servidor de recursos cumple con la solicitud, luego liquida ya sea directamente en la cadena o enviando por POST a un endpoint de facilitador /settle. 7.

Si la liquidación tiene éxito, el servidor de recursos devuelve 200 OK con el recurso en el cuerpo y un encabezado PAYMENT-RESPONSE que contiene una respuesta de liquidación codificada en base64.

Dos detalles impulsan la mayoría de los resultados de integración. Primero, los pasos 1 y 2 son opcionales si el cliente ya conoce los detalles de pago para ese recurso, que es cómo los equipos evitan un viaje adicional a gran escala.

Segundo, la especificación permite explícitamente intercambiar la velocidad de respuesta por la garantía de pago, razón por la cual "http 402 payment" no es automáticamente sinónimo de "liquidación final instantánea".

Redes, esquemas y facilitadores

La afirmación agnóstica de la cadena de x402 vive o muere en una restricción: los clientes y facilitadores deben soportar pares explícitos (esquema, red). Un esquema es una forma lógica de mover dinero, pero la implementación de ese esquema difiere según la red. "Exacto enEthereum"y "exacto en Solana" no son el mismo problema de ingeniería, incluso si la superficie HTTP parece idéntica.

El repositorio de la Fundación x402 describe esquemas que incluyen liquidación exacta, hasta y por lotes (EVM). Las distinciones son elecciones de estilo de ejecución. exact es una transferencia fija para una solicitud. upto es una autorización hasta un límite, con el vendedor liquidando el uso real hasta ese máximo.

batch-settlement (EVM) utiliza un fideicomiso y vales fuera de la cadena para que muchos cargos pequeños puedan ser canjeados en la cadena en lotes en lugar de liquidar cada solicitud HTTP individualmente.

El rol del facilitador es el otro gran palanca de diseño. Un facilitador es un servidor que facilita la verificación y ejecución de pagos para una o varias redes. Concretamente, le da al servidor de recursos una superficie /verify y /settle para que el servidor no necesite implementar cada integración de cadena por sí mismo.

Esa conveniencia viene con una nueva dependencia: el facilitador se convierte en parte de la frontera de fiabilidad y confianza, incluso si el objetivo declarado del estándar es la minimización de la confianza y no permitir que los facilitadores muevan fondos fuera de la intención del cliente.

Aquí es donde las evaluaciones de “crypto protocolo x402” a menudo se equivocan. La pregunta correcta no es “¿es x402 rápido o barato?”, porque x402 es una capa de negociación y prueba. La latencia, el perfil de tarifas y las garantías de liquidación provienen del par (esquema, red) y de si la verificación y la liquidación se manejan localmente o se externalizan a un facilitador.

Por qué x402 es importante para los agentes de IA

agentes de IAcambiar la forma de la demanda porque generan muchas solicitudes pequeñas y frecuentes que son difíciles de monetizar con suscripciones y incómodas de restringir con la incorporación de cuentas. x402 está diseñado para hacer que el pago agente se sienta como un HTTP normal: el agente llama a un endpoint, obtiene una cotización 402 y puede decidir si pagar según sus propias reglas.

La página x402 de Solana enmarca esto como "pagos nativos de internet" para herramientas autónomas, y se apoya enstablecoinel asentamiento como la vía económica que hace que la fijación de precios por solicitud sea sensata.

Esa página afirma que los pagos en stablecoin en Solana superan los $11 mil millones en circulación y representan más de 200 millones de transacciones por mes, posicionando a la red como una capa de asentamiento de alto rendimiento para servicios de pago por solicitud.

El mecanismo se adapta perfectamente a los flujos de trabajo de los agentes porque elimina la necesidad de una identidad y un canal de facturación separados. Un cliente que puede hablar HTTP puede aprender a pagar leyendo encabezados estandarizados, en lugar de integrar un SDK de facturación diferente para cada API.

Esa es la característica clave para el pago de máquina a máquina: la negociación de pagos es legible para clientes genéricos, no solo para humanos que hacen clic en una página de pago.

La compensación es que "el pago es autenticación" solo funciona tan bien como lo permiten las elecciones del esquema y del facilitador. Si un agente está realizando miles de llamadas, la diferencia entre "exactamente liquidado cada vez" y "liquidación por lotes redimida más tarde" es la diferencia entre un bucle ajustado y un sistema que pasa su tiempo esperando confirmaciones.

Señales de adopción y compromisos prácticos

El punto de datos de tracción más claro en las fuentes proporcionadas es específico de la cadena: la página de x402 de Solana afirma que desde que x402 se lanzó en Solana "este verano", ha procesado más de 35 millones de transacciones y más de 10 millones de dólares en volumen a través de x402. La misma página afirma que Solana tiene una finalización de aproximadamente 400 ms y costos de transacción de aproximadamente $0.00025.

Esos son útiles como señales de adopción y rendimiento para ese despliegue, pero no son prueba de que cada integración de x402 herede esos números.

La especificación en sí misma presenta un marco más sobrio: x402 es flexible, y las implementaciones pueden intercambiar la velocidad de respuesta por garantías de pago. Por eso, afirmaciones amplias como "se liquida en aproximadamente 2 segundos" de los explicadores del ecosistema deben interpretarse como dependientes de la red y del diseño, no como una propiedad del apretón de manos HTTP.

Los desarrolladores también necesitan separar el "marketing estándar" del "marketing del ecosistema". La página de Solana afirma que plataformas importantes como Cloudflare, Google y Vercel apoyan x402, pero las fuentes proporcionadas no definen qué significa "apoyo" a nivel de producto. Sin una superficie de integración concreta, esa línea no es accionable.

La postura práctica es comenzar de manera limitada y medir. Un par (esquema, red) en producción proporciona un único camino exitoso para instrumentar de extremo a extremo. A partir de ahí, los equipos pueden agregar más esquemas o redes, y decidir si mantener la verificación y el asentamiento local o confiar en un facilitador.

Esa es la diferencia entre una demostración que funciona y una capa de pago que sobrevive a reintentos, tiempos de espera y fallos parciales en la economía de agentes.

La Opinión

He visto a equipos tratar x402 como "un muro de pago cripto" y luego sorprenderse por la parte que realmente determina la experiencia del usuario: el par (esquema, red) y dónde viven la verificación y la liquidación. El apretón de manos HTTP es determinista. La capa de compensación no lo es.

Si el /verify de un facilitador es rápido pero el /settle se detiene, el cliente lo ve como una API que se cuelga aleatoriamente, aunque los encabezados estén perfectamente estandarizados.

El modelo mental que se queda es la microestructura. 402 + PAYMENT-REQUIRED es la cotización, PAYMENT-SIGNATURE es el pedido, verificar y liquidar es la compensación, y 200 + PAYMENT-RESPONSE es el recibo. Una vez que eso hace clic, la evaluación deja de ser "¿es x402 barato?" y se convierte en "¿qué estilo de ejecución eligió este endpoint y qué dependencias introdujo?", que es exactamente la lente correcta para la economía de agentes explicada.

Fuentes

• Fundación Solana
• Fundación x402 (GitHub)
• Coinbase (GitHub)
• thirdweb