Resumen

  • En enero de 1997, RFC 2068 incorporó 402 Payment Required a HTTP/1.1 y lo dejó con una sola regla: «reservado para uso futuro».
  • RFC 2616, RFC 7231 y RFC 9110 conservaron esa reserva. HTTP nunca añadió para el 402 un precio común, un reto de pago ni reglas de liquidación.

Un letrero sin caja registradora

RFC 1945 presentó los códigos de estado como resultados legibles por máquinas y publicó los valores reconocidos por HTTP/1.0. En la lista de errores de cliente, 401 Unauthorized daba paso a 403 Forbidden; 402 no aparecía. El documento sí permitía códigos de extensión, así que un número no listado podía usarse como extensión. Lo que faltaba era una definición propia dentro del catálogo publicado. RFC 1945 §§6.1.1–6.1.2

La especificación HTTP/1.1 de enero de 1997 puso 402 en la gramática de códigos de estado y le asignó la sección 10.4.3. El texto completo de la regla era una frase: «This code is reserved for future use.» El nombre apuntaba a una condición económica; la norma no describía la operación que debía seguir. RFC 2068 §§6.1.2, 10.4.3

Un código puede marcar el resultado de una solicitud. Por sí solo no comunica cuánto se debe, en qué moneda, a quién, qué prueba acepta el servidor, cómo se confirma el pago ni cómo se resuelve una disputa. La respuesta puede explicar las condiciones propias de un servicio, pero HTTP no las vuelve intercambiables entre aplicaciones.

A 401 le dieron instrucciones; a 402, una sala de espera

El 401 vecino ofrece un ejemplo de interacción concreta. RFC 9110 exige que una respuesta 401 incluya WWW-Authenticate con al menos un desafío aplicable. El cliente puede leer el mecanismo y saber qué credenciales debe presentar. La sección 15.5.3 no ofrece un equivalente para 402: repite que queda reservado y termina ahí. RFC 9110 §§15.5.2–15.5.3

La tarea pendiente cae sobre la aplicación. Si un servicio condiciona el acceso a un pago, sus desarrolladores tienen que definir qué se cobra, cómo demuestra el comprador que pagó, quién recibe el dinero y qué ocurre si la prueba falla o la liquidación no llega. HTTP pone el letrero; el servicio aún debe montar el mostrador, el recibo y el trámite de salida.

El futuro se prorrogó de versión en versión

RFC 2616, publicada en junio de 1999, repitió la misma reserva en la sección 10.4.3. RFC 7231 hizo lo mismo en 2014. RFC 9110 volvió a hacerlo en 2022. Cambió el número de sección; no cambió el texto. Cada revisión actualizó la semántica de HTTP y trasladó el espacio vacío del pago a la siguiente edición. RFC 2616 §10.4.3 · RFC 7231 §6.5.2

Las RFC no identifican el sistema de pago que tenían en mente sus autores. Una nota de diseño fechada que lo nombrara cambiaría esa explicación histórica. Los estándares publicados dan nombre al código y mantienen su reserva; no cuentan qué propuesta esperaba ocuparla.

En la página consultada para este artículo, actualizada el 15 de septiembre de 2025, el registro de la IANA aún anota 402 como «Payment Required» y remite a la RFC 9110, § 15.5.3. Registro de códigos de estado HTTP de IANA

El coste vuelve a la mesa de desarrollo

Aquí aparece la economía de una interfaz para desarrolladores. Un protocolo compartido puede evitar que cada equipo negocie de nuevo las mismas mecánicas en una guía privada. El 402 de HTTP no consigue ese ahorro. El servidor y el cliente del comprador necesitan acordar, a nivel de aplicación, el precio, la prueba, las credenciales, los reintentos y el cierre del pago. Los equipos de software cargan con la integración y el mantenimiento, mientras cada servicio conserva el control de sus condiciones.

Por eso 402 es un nombre para una situación, no una interfaz de pago. Le indica al cliente que el servidor condiciona el acceso a un pago. No le da una forma común de satisfacerlo. En HTTP, la caja registradora sigue siendo una política local con número estándar.

Fuentes