Ir al contenido
FINORA Academy
SistemaSwitch Aurora

Switch Aurora · Conceptos

ISO 8583 en palabras propias

DocumentadoIntermedio15 min

ISO 8583 es la norma internacional que define cómo se arman los mensajes de las transacciones con tarjeta: los terminales, los switches y los bancos la usan para hablar entre sí. Esta página la explica con palabras propias y a nivel de concepto.

    1. Tipo de mensaje (MTI)4 dígitos: qué es este mensaje
    2. Mapa de bitsQué campos vienen, uno por bit
    3. Campos de datos (DE)Solo los que el mapa dice, en orden

Muchas implementaciones agregan delante un prefijo de longitud (dos o cuatro bytes) para que el receptor sepa dónde termina el mensaje en la conexión TCP. A eso se le llama framing, y si el emisor y el receptor no se ponen de acuerdo en él, ninguno de los dos entiende nada.

Son cuatro dígitos y cada uno responde una pregunta:

DígitoPreguntaEjemplos
1.º¿Qué versión de la norma?0 = versión de 1987, la más extendida
2.º¿De qué clase es?1 autorización, 2 financiero, 4 reverso, 5 conciliación, 8 gestión de red
3.º¿Qué función cumple?0 solicitud, 1 respuesta, 2 aviso, 3 respuesta al aviso
4.º¿Quién lo originó?0 el adquirente, 1 el adquirente repitiendo

Así, 0200 se lee «versión 1987, financiero, solicitud, del adquirente»: una compra que pide aprobación. 0210 es su respuesta. 0420 es «reverso, aviso»: deshaz lo que te pedí. La lista de los que usa Aurora está en Tipos de mensaje.

Una regla práctica que se cumple casi siempre: la respuesta es la solicitud más 10. 0100 → 0110, 0200 → 0210, 0800 → 0810.

Un mensaje ISO 8583 no lleva todos los campos posibles, que son 128. Lleva solo los que necesita. El mapa de bits dice cuáles: 64 bits donde un 1 en la posición 4 significa «viene el campo 4». Si el primer bit está encendido, hay un segundo mapa con los campos 65 a 128.

Por eso un campo de más o de menos no es un detalle: si el receptor cree que viene un campo que no viene, o mide mal su longitud, lee corrido todo lo que sigue.

Cada campo se identifica por su número: «DE 4» (data element 4). Estos son los que aparecen en casi cualquier conversación con el switch, descritos con nuestras palabras:

CampoQué llevaPor qué importa
DE 2El número de la tarjetaEs dato sensible: nunca se guarda en claro ni se muestra completo
DE 3El código de proceso: qué operación es (compra, retiro, consulta, devolución) y de qué cuentaJunto con el MTI, decide qué tubería corre
DE 4El monto de la transacciónEn la moneda del DE 49, sin separador decimal
DE 7Fecha y hora de transmisiónAyuda a ubicar el mensaje en el tiempo
DE 11Número de secuencia del mensaje (STAN)Lo pone quien envía; sirve para emparejar solicitud y respuesta
DE 12 / 13Hora y fecha local del terminalLo que el comercio ve en su recibo
DE 22Cómo se leyó la tarjeta: chip, banda, sin contacto, digitadaCambia qué validaciones aplican
DE 32Quién adquirió la transacciónIdentifica a la institución de origen
DE 35Datos de la banda (o su equivalente del chip)Dato sensible
DE 37Número de referencia de la recuperación (RRN)Con él se encuentra la original al reversar o reclamar
DE 38Código de autorizaciónLo da el emisor cuando aprueba
DE 39Código de respuesta00 aprobada; cualquier otro, el motivo. Ver Códigos de respuesta
DE 41 / 42Terminal y comercioBase de los lotes y de los totales
DE 49MonedaFija cuántos decimales tiene el monto
DE 52El PIN, cifradoSolo el HSM lo puede abrir
DE 55Los datos del chip (EMV), incluido el criptogramaEl emisor verifica con ellos que la tarjeta es auténtica
DE 70Código de gestión de redEn los mensajes 08xx: inicio de sesión, eco, cambio de llaves
DE 90Datos del mensaje originalEn los reversos, para encontrar qué se deshace
DE 95Montos de reemplazoEn un reverso parcial: cuánto quedó cobrado de verdad

Dialectos: el mismo idioma, con acentos distintos

Sección titulada «Dialectos: el mismo idioma, con acentos distintos»

La norma deja muchas decisiones abiertas: si un campo numérico va en ASCII o en BCD, cuánto mide un campo variable, qué lleva cada campo privado. Cada red y cada banco toman esas decisiones a su manera. A ese conjunto de decisiones se le llama dialecto.

Aurora guarda el dialecto de cada contraparte como dato, no como código. Y mantiene dos descripciones separadas a propósito: lo que Aurora acepta por sus puertos y lo que Aurora emite hacia cada contraparte. Unificarlas parece limpieza, pero rompe: se pierden campos que solo declara una de las dos.

Un ejemplo real de lo que cuesta un dialecto mal declarado: un campo de moneda descrito como texto de tres caracteres cuando la contraparte lo enviaba como número en BCD, que ocupa dos bytes. Un byte de diferencia, y todos los campos siguientes se leyeron corridos.