- ISO 8583 es el estándar de intercambio de mensajes en tiempo real entre redes de tarjetas de crédito
- Este estándar define los mensajes que ocurren cuando se toca una tarjeta en un dispositivo de punto de venta o se hace clic en "comprar" en línea
- Al principio, un POS o ATM generaba directamente los mensajes, pero hoy en día se usa principalmente un enfoque en el que primero se convierten a un formato de alto nivel como JSON y luego se transforman a ISO 8583
- La estructura del mensaje es simple, pero la implementación detallada es compleja y tiene flexibilidad para permitir la compatibilidad entre redes
Formato básico del mensaje
Indicador de tipo de mensaje (Message Type Indicator)
- Un código de 4 dígitos indica el tipo de mensaje (por ejemplo,
0100 es una solicitud de autorización)
- Ayuda al receptor a identificar qué campos debe esperar
- La forma de serialización puede variar según la red (BCD, ASCII, etc.)
Bitmap
- Indica la presencia o ausencia de campos
- 1 indica que el campo está presente y 0 indica que el campo no está presente
- Tiene un tamaño de 8 bytes y puede representar hasta 64 campos
Elementos de datos (Data Elements)
- Los campos se serializan después del bitmap
- Los campos de longitud fija siempre tienen el mismo tamaño, mientras que los de longitud variable incluyen información de longitud
- Para la codificación de campos se usan ASCII, BCD, binario y otros formatos
Estructura de mensajes anidados
- El estándar ISO 8583 permite que las redes incluyan datos personalizados específicos de la red
- Los mensajes anidados pueden implementarse con tablas, bitmaps y formato TLV (Tag-Length-Value)
Tablas
- Todos los campos se incluyen con longitud fija
- Para reducir el desperdicio de espacio, también se admiten subcampos de longitud variable
Mensajes con bitmap
- La presencia de cada subcampo se indica mediante un bitmap
- Evita desperdiciar espacio cuando no hay un campo presente
Mensajes TLV
- Los campos se serializan como tuplas de etiqueta, longitud y valor
- Se pueden extender sin depender del orden
Diseño del parser
- Un parser de ISO 8583 comienza con el análisis del bitmap y la definición de serialización de cada campo
- Debe considerar el manejo de mensajes anidados y las diferencias de implementación entre redes
- Se usa el sistema de tipos Sorbet de Ruby para definir clases de mensajes seguras
- Se pueden configurar campos de longitud fija y variable, manejo de padding y más
Manejo de errores
- Si falla el parseo de un campo, debe diseñarse para que aún sea posible parsear los siguientes campos
- Se procesan errores parciales manteniendo la serialización del mensaje
- Si ocurre un error crítico, se detiene el procesamiento del mensaje
Conclusión
- El estándar ISO 8583 ha seguido evolucionando desde que fue definido en 1987 para satisfacer las necesidades de diversas redes
- Increase ayuda a procesar mensajes ISO 8583 para que puedas concentrarte en desarrollar productos para usuarios
- Puedes consultar la documentación de la API o contactar al equipo de Increase
1 comentarios
Comentarios de Hacker News
Visa y Mastercard no implementan ISO 8583 de una forma estandarizada. Cada empresa publica miles de páginas de documentación para explicar cómo usar los campos estándar y cómo incluir datos propietarios en los mensajes. La mayoría de las plataformas de administración/emisión de tarjetas abstraen bien esto. La transición a ISO 20022 es una mejora positiva, pero es poco probable que cumpla con el criterio de ROI.
El tipo de protocolo (tipo de mensaje, bitmap de definición de campos, conjuntos de valores de longitud fija y variable) era común en la época en que se desarrolló. El receptor debe validar las longitudes dinámicas de los campos y tener cuidado de no leer más allá del final del mensaje. Sin embargo, estos problemas ahora se entienden bien.
Es desconcertante que el estándar ISO 8583 no especifique cómo codificar los campos o los tipos de mensaje. Esto hace posible que el receptor reciba un conjunto aleatorio de bytes que no pueda entender.
Últimamente ha habido mucha discusión sobre pagos y patio11 ofrece contenido excelente. Hace 25 años no existían sitios web con explicaciones visuales como este. Como mencionó otro comentario sobre EBCDIC, la conversión entre endianness es compleja. Fue interesante haber trabajado con Discover a principios de los 2000 para agregar un campo GUID a la especificación ISO8583.
Los sistemas financieros son uno de los frentes de batalla del cambio. Mucha gente no está consciente de estos cambios. Las grandes tecnológicas poseen sus propios ecosistemas de pagos, así que hay que darles perspectiva a quienes no se han dado cuenta. Algunos países están siguiendo esta tendencia.
Charles Stross se volvió un poco loco por culpa del estándar ISO 8583, y eso pudo haber sido una de las causas de que escribiera Accelerando. Es probable que este estándar haya sido uno nuevo para reemplazar los protocolos vagos de los años 70.
Este es un gran artículo que explica por qué ISO20022 debería reemplazar a 8583, especialmente en regiones donde no dominan las redes propietarias de M/V. Las tarjetas de crédito podrían implementarse en los nuevos sistemas de pago junto con cuentas de crédito ofrecidas por los bancos. Serían posibles los pagos instantáneos entre cuentas y las transacciones de bajo costo con precio fijo.
Fue interesante ver las distintas formas de sortear las limitaciones de ISO 8583. Últimamente se usa mucho pasar información adicional fuera de la transacción de pago mediante llamadas API antes/después del mensaje ISO. Eso acelera el time-to-market, pero puede introducir nuevos modos de falla.
Este formato fue interesante. Al analizar mensajes ISO-8583, se podía ver desplegarse la historia. Los mensajes que analicé eran BCD, no EBCDIC. Pero un campo contenía XML, y el XML contenía JSON. Cada vez que se extendía el mensaje, reflejaba la moda del año.
A diferencia de Visa y Mastercard, las alertas de transacciones de AMEX llegan casi de inmediato. Es casi mágico que aparezca una notificación en el teléfono o reloj apenas pasas la tarjeta. Parece que las capas que tienen V/MC no existen en AMEX.
He tenido mucho éxito con iso8583 usando la biblioteca de Go.
Fue divertido revisar la lógica de enmascaramiento de datos de tarjetas de crédito ISO 8583 codificados en base64 en los logs del sistema (o codificados en base64 y luego en EBCDIC).