Resumen

  • RFC 3538 asignaba 20, 40, 60, 80 y 100 a la creación o procesamiento de sucesivos mensajes SET dentro del puente IOTP. Eran hitos de interfaz, no porcentajes del resultado comercial.
  • En 100, PRes podía señalar una autorización aprobada o una captura exitosa. CompletedOK aún podía pasar a Failed tras una cancelación; liquidación y entrega quedaban fuera de lo demostrado.

Una consola muestra una barra llena. ¿Qué puede afirmar el equipo de operaciones? ¿Se autorizó la solicitud, se capturó el cargo, se liquidaron fondos entre instituciones, salió el paquete o ya no cabe una cancelación? Las interfaces contemporáneas suelen comprimir todas esas preguntas en una sola palabra. RFC 3538, publicado en junio de 2003 como Informational, respondió de forma más limitada: el puente entre SET e IOTP había procesado el último mensaje de su mapa.

IOTP buscaba una estructura común para el comercio electrónico sin imponer un único sistema de pago. RFC 3538 explicó cómo los mensajes de Secure Electronic Transaction circularían por la Payment API de IOTP 1.0. Las fuentes congeladas no ofrecen una cifra de adopción, una transacción real ni un incidente medido. Su importancia histórica está en otra parte: el diseño no hizo que una observación local reclamara autoridad sobre toda la operación.

La sección 8.12 traza cinco escalones. Tras crear o procesar la primera SET Initiation Response, PercentComplete vale 20. PinitReq corresponde a 40; PinitRes, a 60; PReq, a 80; PRes, a 100. Consumer y Payment Handler observan creación y procesamiento desde lados distintos. La iniciación puede contener un número variable de mensajes, pero la primera respuesta sigue recibiendo 20. La escala no mide partes iguales de trabajo ni tiempo restante: enumera hitos elegidos por la interfaz.

El último hito admite dos significados. Un PRes exitoso puede contener authorizationPerformed con AuthCode aprobado, o capturePerformed con CapCode exitoso. Autorizar permite avanzar; capturar pertenece a otro momento comercial. Que ambos viajen en el mismo tipo de mensaje y terminen en el mismo 100 no los convierte en el mismo hecho. Hay que conservar el código para saber qué ocurrió.

La máquina de estados niega además una finalización absoluta. En el Payment Handler, una transacción en curso puede llegar a CompletedOK. Pero, si se cancela el pago, ChangeProcessState o CancelPayment permite la transición CompletedOK -> Failed. El estado expresa la visión de un componente en un instante. Borrar la arista histórica fabrica irrevocabilidad.

La función de recibo dibuja un límite todavía más claro. CheckPayReceipt no comprueba especialmente Payment Receipt Information; emite una respuesta general mientras la solicitud sea válida. Ese reparto de responsabilidades puede ser correcto. Lo que no sería correcto es presentar validez estructural como verificación económica. Sobre válido, recibo reconocible y afirmación corroborada son comprobantes distintos.

La entrega sigue fuera del puente de pago. Para bienes físicos, el RFC recomienda omitir IOTP Delivery Exchanges. Puede especificarse una ubicación de consulta y la comprobación de autorización entre gestores puede ocurrir fuera de IOTP. Para bienes digitales recomienda autorización en tiempo real. Haber terminado los mensajes de pago no mueve un paquete ni demuestra que el contenido haya llegado a su destinatario.

Consulta y error mantienen la misma separación. Se omite SET Inquiry Initiation; los mensajes de consulta se encapsulan en datos IOTP. Un error técnico del puente usa HardError, mientras un fallo comercial recorre otra vía. Si se pierde el origen, un rechazo bien transportado parece avería o un transporte sano parece venta lograda.

Este análisis no repite el artículo sobre RFC 3354, dueño de los requisitos IOTP v2 y de composición frente a autorización comercial. Tampoco repite RFC 3504, que trata la gramática corregida, identidad, consulta y la separación general entre pago, liquidación y entrega. RFC 3538 aporta un instrumento específico: cinco cifras, dos resultados en PRes, verificación limitada del recibo y cancelación después de “completar”.

La regla duradera consiste en dar nombre al denominador de todo progreso. Deben conservarse el mensaje exacto, quién lo creó o procesó, su completion code y las transiciones posteriores. Así, 100 es evidencia útil. Sin esa procedencia, es un símbolo que toma prestada certeza de sucesos que jamás midió.

Fuentes