En resumen: el servidor dice "debes pagar antes de que este recurso esté disponible".
HTTP 402 Payment Required es uno de los códigos de estado más misteriosos y menos utilizados en la especificación HTTP. A diferencia de sus hermanos conocidos como 404 (Not Found) o 401 (Unauthorized), el 402 fue diseñado con la visión de permitir mecanismos de pago nativos directamente en la web.
Cuando un servidor devuelve una respuesta 402, está enviando un mensaje claro: "Este recurso existe y sus credenciales pueden ser correctas, pero se requiere un pago para acceder a él". Esto es fundamentalmente diferente de otros códigos de error de cliente 4xx que generalmente indican problemas de autenticación o autorización.
El código de estado 402 tiene una historia fascinante que refleja el optimismo inicial sobre el comercio web desde sus comienzos.
HTTP 402 se incluyó en la primera especificación HTTP/1.1 (RFC 2068) publicada en 1997, con una nota explícita que indicaba que estaba "reservado para uso futuro". En aquel momento, se pensaba que a medida que el comercio electrónico evolucionara, sería esencial contar con una forma estandarizada de solicitar pagos. Los arquitectos de HTTP previeron un futuro donde los micro-pagos digitales serían algo común.
A pesar de formar parte de la especificación durante más de dos décadas, el código 402 permaneció prácticamente sin uso. La falta de sistemas de pago digital estandarizados y la complejidad de implementar flujos de pago entre plataformas llevaron a los sitios web a desarrollar sus propios flujos de pago propietarios.
Con la llegada de las criptomonedas, las stablecoins como USDC y protocolos como x402, el código de estado 402 finalmente ha encontrado su propósito. La tecnología blockchain moderna proporciona la pieza que faltaba en el rompecabezas: una capa de pago estandarizada y programable que puede funcionar sin problemas con HTTP.
Comprender las diferencias entre estos códigos de estado es crucial para un desarrollo web y un diseño de API adecuados.
| Estado | Significado | Escenario común | Acción requerida del usuario |
|---|---|---|---|
| 401 Unauthorized | Autenticación requerida | No ha iniciado sesión, token expirado | Iniciar sesión o actualizar credenciales |
| 403 Forbidden | Autenticado pero no permitido | La cuenta carece de permisos | Solicitar acceso al administrador |
| 402 Payment Required | Se requiere pago | Pago por visión, micro-pagos | Completar la transacción de pago |
| 404 Not Found | Recurso no encontrado | Enlace roto, contenido eliminado | Verificar URL o contactar soporte |
A pesar de formar parte de la especificación HTTP desde 1997, la adopción del 402 ha sido extremadamente baja debido a varios factores:
La especificación HTTP definió el código de estado, pero nunca prescribió cómo debía realizarse el pago. Sin encabezados de pago estandarizados, formatos de solicitud o estructuras de respuesta, cada implementación era incompatible con las demás.
Los pagos con tarjeta de crédito requieren integraciones complejas con procesadores de pago, cumplimiento de normas PCI, lógica de facturación recurrente y sistemas de prevención de fraude. Esta sobrecarga hacía que usar el 402 para pequeñas transacciones fuera poco práctico.
Los sistemas de pago tradicionales tienen tarifas de transacción mínimas, lo que hace que los micro-pagos (menos de $1) sean económicamente inviables. Si una transacción cuesta $0.30, cobrar $0.05 por el acceso a un artículo no tiene sentido.
Las empresas desarrollaron soluciones alternativas: modelos de suscripción, contenido basado en publicidad, tokens de acceso basados en OAuth o muros de pago personalizados que devuelven respuestas 200 OK con controles de acceso basados en JavaScript.
Según el RFC 9110 (la especificación HTTP actual), el código de estado 402 se define de la siguiente manera:
Aunque no están estandarizados oficialmente, las implementaciones comunes incluyen:
X-Payment-Required: Información sobre el pago necesario.X-Price: El monto a pagar.X-Currency: La moneda del pago (USD, USDC, etc.).X-Payment-Address: La dirección a donde enviar el pago.El protocolo x402 estandariza estos encabezados a través de un sistema integral de negociación de pagos. Cuando usted recibe una respuesta 402 de un servidor compatible con x402, la respuesta contiene toda la información necesaria para completar el pago de forma automática.
El código de estado 402 es especialmente adecuado para varios casos de uso emergentes:
Cobrar por cada llamada a una API utilizando el código 402. Pague solo por lo que usa para servicios de IA, APIs de datos o funciones premium sin necesidad de una suscripción.
Desbloquee artículos de noticias, documentos de investigación o contenido premium con un pequeño pago. Sin suscripciones, solo pague por el contenido individual.
Permita que agentes autónomos o bots accedan a recursos de pago y realicen pagos sin intervención humana. La respuesta 402 proporciona todo lo necesario para el procesamiento de pagos automatizado.
Las aplicaciones Web3 pueden utilizar el 402 para restringir el acceso a recursos descentralizados, con pagos liquidados on-chain utilizando USDC u otras stablecoins.
Desbloquee compras dentro del juego, activos digitales o funciones premium con pagos instantáneos activados por una respuesta 402.
Todos los navegadores modernos reconocen el 402 como un código de estado HTTP válido, pero no poseen funciones de manejo integradas.
| Plataforma | Estado | Notas |
|---|---|---|
| Chrome/Edge | ✅ Reconocido | Se muestra como un error de cliente |
| Firefox | ✅ Reconocido | Se muestra como un error de cliente |
| Safari | ✅ Reconocido | Se muestra como un error de cliente |
| Node.js/fetch | ✅ Soporte Completo | Se puede manejar mediante programación |
| cURL | ✅ Soporte Completo | Devuelve el código de estado 402 |
Aunque los navegadores no manejan automáticamente los pagos 402, las librerías cliente o las extensiones de navegador pueden interceptar las respuestas 402 para activar flujos de pago.
Eso es exactamente lo que resuelve x402: convertir la señal de "pago requerido" en una experiencia de checkout automática y sin interrupciones.
Todo el proceso toma segundos y a menudo no requiere intervención del usuario. Esta es la visión original que se tenía para HTTP 402, finalmente hecha realidad por la infraestructura criptográfica moderna.
Para los desarrolladores que buscan implementar el 402 en sus aplicaciones, aquí tienen un resumen rápido:
// Ejemplo en Express.js
app.get('/contenido-premium', (req, res) => {
if (!isPaid(req)) {
return res.status(402).json({
error: 'Se requiere pago',
price: '0.10',
currency: 'USDC',
paymentAddress: '0x...'
});
}
res.json({ contenido: 'Aquí está su contenido premium' });
});// Ejemplo en JavaScript
const response = await fetch('/contenido-premium');
if (response.status === 402) {
const paymentInfo = await response.json();
// Activar flujo de pago
await processPayment(paymentInfo);
// Reintentar con el comprobante de pago
return fetch('/contenido-premium', {
headers: { 'X-Payment-Proof': proof }
});
}El futuro de HTTP 402 es prometedor gracias a protocolos como x402.
La visión de pago nativa que la web siempre debió tener finalmente se está convirtiendo en realidad, y HTTP 402 está en el centro de esa transformación.