x402 es un protocolo para pagar por recursos web a través de HTTP. Un servidor devuelve los requisitos de pago con HTTP 402; un cliente compatible autoriza el pago y lo intenta de nuevo con una carga útil de pago.
Para un agente de IA, esto puede convertir una consulta de API pagada en parte de la tarea. La billetera aún necesita permiso para gastar, y el servicio aún tiene que entregar el resultado.
HTTP 402 se convierte en una oferta de precio
HTTP 402 es el código de estado Pago Requerido (Payment Required). x402 añade un intercambio de pagos definido a su alrededor; los navegadores ordinarios no se convierten automáticamente en compradores autónomos porque un sitio web devuelva ese estado.
En el flujo actual de V2, el servidor comunica los requisitos a través de PAYMENT-REQUIRED. El cliente responde con una carga útil de pago en PAYMENT-SIGNATURE. El servidor informa el resultado de la liquidación a través de PAYMENT-RESPONSE. Los nombres de los encabezados describen pasos separados, no tres pagos. HTTP 402 y encabezados V2.
Imagina un agente de investigación comprando una observación meteorológica para una tarea de planificación de rutas. Una oferta ficticia solicita $0.001 en USDC, nombra la dirección de recepción del vendedor y especifica una red compatible y un esquema de pago exacto. El cliente de pago necesita reconocer esos términos antes de poder proceder. Este precio es ilustrativo, no una cotización de servicio real.
Una oferta de precio no es permiso para gastar. La política de la billetera o de la aplicación debe verificar que el monto, el comercio y el recurso solicitado se ajusten a la tarea. Un servidor puede cotizar un precio irrazonable de la misma manera que puede hacerlo un vendedor humano.
De una solicitud no pagada a una respuesta pagada
El agente autoriza un pago, mientras que el vendedor controla cuándo libera el recurso.
Seguir una solicitud pagada
El cliente solicita el recurso. El servidor responde con los requisitos de pago. El cliente elige una opción compatible y crea una carga útil de autorización o de pago para esa opción. Repite la solicitud del recurso con la carga útil adjunta.
El servidor comprueba el pago y gestiona la liquidación bajo el esquema y el flujo de pago seleccionados. La autorización por defecto se verifica antes del manejador de recursos y se liquida después; un flujo por adelantado liquida antes de que se ejecute el manejador. Los flujos basados en depósito (escrow) introducen saldos financiados y una captura o canje posterior. Un precio exacto por sí solo no te indica cuándo comienza el cálculo en relación con la liquidación. Descripción general del esquema y el flujo de pago.
La separación es útil para comprender un fallo. Una autorización rechazada significa que el servicio no ha aceptado el pago propuesto. Una transacción de difusión (broadcast) a la espera de confirmación significa que el dinero aún puede moverse. Un pago completado con un recurso faltante es un problema de entrega.
Una interfaz que fusiona esos estados en "pago fallido" fomenta reintentos costosos. El cliente debe preservar el identificador de la solicitud y conciliar el intento anterior antes de autorizar otra compra. El software puede repetir un proceso de pago erróneo mucho más rápido que un humano.
El facilitador gestiona la infraestructura de pago
Un facilitador puede verificar las cargas útiles de pago, enviar transacciones de liquidación e informar sobre su estado. Un servidor de recursos puede utilizar un proveedor de producción gestionado, operar su propio servicio o manejar estas funciones por sí mismo. No se debe asumir que el facilitador de inicio rápido público sea la ruta de producción para cada red. Documentación del facilitador.
El facilitador seleccionado afecta las dependencias operativas del servicio. El vendedor necesita soporte para su red, token y esquema de pago. También necesita una respuesta funcional cuando el proveedor sea lento o no esté disponible.
La verificación no custodial no hace que cada parte del negocio sea independiente. Un proveedor puede ser incapaz de enviar transacciones aunque no custodie los fondos del cliente. Una puerta de enlace API puede dejar de entregar recursos sin controlar la billetera. Estos fallos pertenecen a diferentes partes del plan de incidentes.
Antes de lanzar un punto de acceso de pago, yo probaría la ruta con el proveedor de producción y la configuración del contrato real. Un pago exitoso en la testnet establece que la integración puede funcionar en ese entorno. No establece la liquidez, el precio o la fiabilidad de producción.
El esquema determina cuándo se mueve el dinero
Un pago exacto especifica una cantidad definida. Un pago de hasta un límite autoriza un techo para el uso cuyo costo final puede ser menor. El grupo de liquidación por lotes agrupa cargos para un canje posterior en cadena, mientras que la autorización-captura admite un patrón de depósito en garantía reembolsable. Estas son diferentes opciones para un vendedor que cobra por solicitud o por unidad de trabajo. Esquemas de pago.
Una búsqueda de datos a precio fijo se ajusta a un problema de facturación diferente al de generar una respuesta cuyo costo de computación depende de la longitud de la salida. Este último necesita un máximo claro y un cargo final medible. El comprador debe saber cómo el vendedor calcula ese cargo.
En el patrón de lote documentado de EVM, el comprador aporta fondos al depósito en garantía y firma vales acumulativos. El vendedor puede reclamar más tarde y barrer los ingresos a través de una operación de liquidación separada. Eso explica cómo los cargos diferidos pueden seguir siendo cobrables, añadiendo también reglas de aportación de fondos y de canje para inspeccionar. Mecanismo de liquidación por lotes.
Es por esto por lo que un millón de solicitudes pagadas no deberían describirse automáticamente como un millón de transacciones en blockchain. El artículo sobre la economía de los micropagos sigue los costes en cada capa en lugar de utilizar el recuento de solicitudes como un indicador de los ingresos de la cadena.
Un modelo de IA no es el firmante del pago
El modelo puede decidir que un recurso es útil y enviar una solicitud de compra a una herramienta. Un servicio de billetera o un componente de firma crea la acción financiera autorizada. Esos roles deberían ser visibles en el diseño del sistema.
Darle al modelo una instrucción de tarea como "gasta con sensatez" ofrece una protección más débil que un límite de transacción impuesto. Una configuración más sólida verifica al comerciante, la moneda, la cantidad máxima y el presupuesto restante antes de que el firmante apruebe la solicitud.
También existe una diferencia entre una compra única y una autoridad continua. Un pago por un recurso no debería conceder silenciosamente a un vendedor acceso a un saldo sin restricciones. Nuestro artículo sobre billeteras de agentes explica cómo la custodia y los permisos de gasto definen ese límite.
La identidad del agente es otra cuestión aparte. Un pago demuestra una acción financiera bajo el mecanismo pertinente. No demuestra que el comprador sea un agente de IA único, competente u honesto. ERC-8004 se refiere a la identificación y las señales de confianza en torno a los agentes, en lugar de reemplazar el intercambio de pagos.
El pago y la entrega útil necesitan recibos
El servicio debe identificar claramente el recurso y la unidad de precio. "Una respuesta" puede significar un resultado de búsqueda, un conjunto de datos completo o una página de registros. Una facturación ambigua dificulta la comparación tanto para los humanos como para los agentes.
Las ofertas firmadas y los recibos pueden ayudar a vincular una compra con los términos declarados y un resultado registrado. Aún así, no demuestran que cada hecho en un conjunto de datos entregado sea correcto. Un comprador necesita una forma de evaluar la frescura, la procedencia y si la respuesta sirve para la tarea. Ofertas firmadas y recibos.
Para trabajos costosos o variables, define qué cuenta como un éxito facturable. Un resultado vacío podría ser una respuesta válida a una consulta, pero esa regla debería indicarse antes de la compra. Lo mismo se aplica a un cálculo fallido o a una fuente upstream no disponible.
El problema de distribución del vendedor persiste. Habilitar x402 no hace que un punto de conexión sea descubrible o valga la pena pagar por él. Vender datos a agentes cubre ese lado del negocio.
Qué inspeccionar en una demostración de x402
Busca una cotización visible, una autorización restringida y un resultado de liquidación distinto. Pide al equipo que reintente una solicitud después de un tiempo de espera simulado y que muestre que la compra original no se cobra dos veces. Luego, pregunta qué sucede si el pago tiene éxito pero la respuesta se pierde.
Una demostración útil finaliza la tarea del cliente bajo esas condiciones. Una captura de pantalla de un explorador de transferencias demuestra mucho menos. El software que compra un recurso necesita un intercambio comercial fiable en torno a la transacción.
Para un enfoque alternativo de protocolo e integración de comerciantes, lee x402 vs MPP. La elección comienza con el patrón de facturación del servicio y los métodos de pago que sus clientes pueden utilizar.
Un tiempo de espera necesita dos respuestas separadas
Supongamos que un vendedor aceptó el pago por una observación meteorológica, pero el cliente nunca recibió la respuesta. El siguiente paso depende de dos registros: ¿se liquidó la compra? ¿y se entregó esa observación?
Una compra liquidada con una respuesta faltante necesita una ruta de recuperación de entrega. Una autorización rechazada antes de la aceptación necesita una explicación del fallo de pago. Un pago cuyo resultado aún es desconocido necesita una conciliación antes de otra autorización.
El identificador de pago puede ayudar a conectar un reintento con la compra original cuando se implemente la extensión. El vendedor todavía necesita una regla para devolver o recuperar el recurso comprado. Extensión Payment-Identifier.