DESARROLLO DE GATEWAY ISO8583

INSTITUTO POLITÉCNICO NACIONAL
UNIDAD PROFESIONAL ZACATENCO
DESARROLLO DE GATEWAY
CORRESPONSAL BANCARIO
ISO8583
REPORTE MEMORIA
QUE PARA OBTENER EL GRADO DE
INGENIERO EN COMUNICACIONES Y ELECTRÓNICA PRESENTA:
PABLO BENJAMIN NIETO MERCADO
ASESOR : DR. RABINDRANATH RESÉNDIZ VÁZQUEZ
MÉXICO D.F.
SEPTIEMBRE 2015
Dedicatoria
Dedicatoria
A mi Madre María Gricela Mercado Maceda, por su gran valentía
y amoroso apoyo incondicional.
A mi Padre Enrique Nieto Flores, por su amor y protección.
A mi hermano Irving Enrique Nieto Mercado, por su gran cariño,
complicidad y resistencia.
A mis ancestros, por lo que me forma.
A mis maestros y amigos, por sus enseñanzas y amistad.
A la vida.
II
Índice
Índice
Dedicatoria
II
Índice de Figuras y Tablas
VI
Introducción
IX
Objetivo
XI
Justificación
XII
Capitulo 1.- Corresponsalía bancaria modelo de inclusión financiera en México
1
Capitulo 2.- Gateway ISO8583 sistema de corresponsalía bancaria
4
2.1.- Responsabilidades a cargo dentro del proyecto
6
2.2.- Objetivos a perseguir en el desarrollo del proyecto
7
2.3.- Observaciones
7
Capitulo 3.- Fundamentos para el desarrollo de un sistema informático
8
transaccional de corresponsalía bancaria
3.1.- Lenguaje de programación, Visual Basic. Net
9
3.2.- Corresponsal Bancario
10
3.2.1.- Requisitos para ser corresponsal
11
3.2.2.- Actividades que pueden realizar los corresponsales
12
3.2.3.- Actividades que no pueden realizar los corresponsales
13
3.2.4.- Esquema de operación con cargo al corresponsal
14
3.2.5.- Resumen de requerimientos por tipo de operación
15
3.3.- Estándar ISO8583
17
3.4.- Arquitectura de software
19
3.4.1.- Programación por capas
20
3.4.2.- Capas o niveles
21
3.4.3.- Modelos o vistas
23
Capitulo 4. Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
25
4.1.- Análisis de especificaciones del proyecto
27
4.2.- Diseño de arquitectura del sistema Gateway ISO8583
39
III
Índice
4.3.- Diagrama de arquitectura
43
4.4.- Casos de uso del sistema
44
4.5.- Actores del sistema
45
4.6.- Flujo Caso de Uso Depósito
47
4.7.- Flujo Caso de Uso Reverso
51
4.8. Diagramas de Proceso
54
4.8.1 Diagrama de Proceso Depósito
55
4.8.2 Diagrama de Proceso Reverso
56
4.9. Vistas de la Arquitectura
60
4.9.1- Vista Lógica
60
4.9.2.- Vista Paquetes
61
4.9.3.- Vista de Componentes
63
4.10.- Mensajería ISO8583 Corresponsal Bancario
65
4.10.1.- Definición de mensajería de corresponsalía bancaria
67
4.10.2.- Servicio de autorización
68
4.10.3.- Servicio de reverso
69
4.10.4.- Servicio de echos
70
4.10.5.- Estructura de mensajes ISO8583
71
4.10.5.1.- Longitud del mensaje
72
4.10.5.2.- Header del mensaje
73
4.10.5.3.- Mapas de Bits (Bitmaps)
73
4.10.5.4.- Campos de mensajería ISO8583
74
4.10.6.- Definición de campos de mensajería ISO8583
75
4.10.7.- Estructura de mensajes ISO8583 de corresponsalía bancaria
78
4.10.8.- Ejemplos de tramas ISO8583
79
4.10.8.1.- Ejemplo Trama Depósito
80
4.10.8.2.- Ejemplo Trama Reverso
81
4.10.8.3.- Ejemplo Trama Echo
82
4.11.- Programación de Gateway ISO8583
83
4.12.- Probando el funcionamiento de Gateway ISO8583
85
4.12.1.- Pruebas de comunicación hacia Tiendas X y Banco Y
IV
86
Índice
4.12.2.- Pruebas para validar recepción, contenido y estructura
88
de los mensajes de Tiendas X
4.12.3.- Pruebas de envío de mensajes de Gateway ISO8583 hacia Banco Y
91
4.12.4.- Pruebas para validar recepción, contenido y estructura
92
de los mensajes de Banco .
4.12.5.- Pruebas de envío de mensajes de respuesta de
95
Gateway ISO8583 hacia Tiendas X
4.12.6.- Pruebas masivas de envío y recepción de transacciones
95
4.12.7.- Pruebas en ambiente real
96
4.12.7.1 Ejemplo de una transacción
96
4.12.7.2 Ejemplo una transacción de Reverso
101
Conclusiones
106
Bibliografía
107
V
Índice de Figuras y Tablas
Índice de Figuras y Tablas
Figura Descripción
Pagina
3.1.
Principales Actores
10
3.2.4
Esquema de operación con cargo al corresponsal
14
3.3
Estructura de un mensaje ISO8583
18
3.4.1
Distribución física de un sistema de tres capas
20
4.6
Flujo de información entre entidades
32
4.7
Conectividad a nivel protocolo entre Tiendas X y Gateway ISO8583
33
4.8
Conectividad a nivel protocolo entre Gateway ISO8583 y Banco Y
34
4.9
Canal SSL entre Gateway ISO8583 y Banco Y
35
4.10
Mensajería ISO8583 entre "Tiendas X" y Gateway ISO8583
36
4.11
Mensajería ISO8583 entre Gateway ISO8583 y Banco Y
37
4.15
Diagrama de Arquitectura de tres capas Gateway ISO8583
43
4.18
Actores y Casos de Uso del sistema
46
4.19
Diagrama de flujo del caso de uso Depósito
50
4.20
Diagrama de flujo del caso de uso Reverso
53
4.22
Diagrama de proceso Depósito
55
4.23
Diagrama de Validaciones Depósito
56
4.25
Diagrama de proceso Reverso
58
4.26
Diagrama de Validaciones Reversos
59
4.27
Vista lógica de paquetes Gateway ISO8583
60
4.28
Flujo de intercambio, validación y traducción de mensajes entre entidades
66
4.30
Flujo Servicio de Autorización
68
4.31
Flujo Servicio de Reversos
69
4.32
Flujo Servicio de Echos
70
4.46
Conectividad y flujo de información entre Tiendas X y Banco Y
86
4.53
Flujo Depósito
96
4.58
Flujo Reverso
101
VI
Índice de Figuras y Tablas
Tabla Descripción
Pagina
3.2.1
Requisitos para ser corresponsal bancario
11
3.2.2
Actividades que pueden realizar los corresponsales
12
3.2.3
Actividades que no pueden realizar los corresponsales
13
3.2.5
Requerimientos Tecnológicos
15
4.1
Etapas y responsables del proyecto
26
4.2
Resumen de especificaciones del sistema de Tiendas X
28
4.3
Resumen de especificaciones del sistema de Banco Y
29
4.4
Limitantes de Comunicación entre Tiendas X y Banco Y
30
4.5
Roles de comunicación de entidades
31
4.12
Esbozo de la arquitectura del sistema
39
4.13
Descripción y responsabilidades de capas del sistema
40
4.14
Descripción y responsabilidades de los nodos del sistema
42
4.16
Descripción de Casos de uso del sistema
45
4.17
Descripción de Actores del sistema
45
4.21
Validaciones transacción de Depósito
54
4.24
Validaciones transacción de Reverso
57
4.29
Servicios disponibles para Tiendas X y Banco Y
67
4.33
Estructura de mensaje ISO8583
70
4.34
Componentes del header del mensaje
72
4.35
Ejemplos de Bitmaps y detalle
73
4.36
Tipos de datos de los campos ISO8583
74
4.37
Indicadores de longitud de los campos ISO8583
74
4.38
Definiciones de campos ISO8583 corresponsalía bancaria
75
4.39
Estructura de mensajes entre Tiendas X y Gateway ISO8583
78
4.40
Estructura de mensajes entre Gateway ISO8583 y Banco Y
79
4.41
Ejemplo Trama 0200 Depósito
80
4.42
Ejemplo Trama 0420 Reverso
81
4.43
Ejemplo Trama 0800 Echo
82
4.44
Archivos resultado de la compilación del sistema Gateway ISO8583
83
4.45
Paquetes codificados por capa
84
VII
Índice de Figuras y Tablas
Tabla Descripción
Pagina
4.47
Transacción de deposito estructura completa
89
4.48
Transacción de deposito estructura incompleta
90
4.49
Transacción de deposito tipo de dato incorrecto
91
4.50
Transacción de deposito estructura completa
92
4.51
Transacción de deposito estructura incompleta
93
4.52
Transacción de deposito tipo de dato incorrecto
94
4.54
Mensaje de Depósito de Tiendas X a Gateway ISO8583
97
4.55
Mensaje de Depósito de Gateway ISO8583 a Banco Y
98
4.56
Mensaje de respuesta de Depósito de Banco Y a Gateway ISO8583
99
4.57
Mensaje de respuesta de Depósito de Gateway ISO8583 a Tiendas X
100
4.59
Mensaje de Reverso de Tiendas X a Gateway ISO8583
102
4.60
Mensaje de Reverso de Gateway ISO8583 a Banco Y
103
4.61
Mensaje de respuesta de Reverso de Banco Y a Gateway ISO8583
104
4.62
Mensaje de respuesta de Reverso de Gateway ISO8583 a Tiendas X.
105
VIII
Introducción
Introducción
Desde que la humanidad empezó a ser productiva, cazando e implementando técnicas de
agricultura y artesanía, se ha implementado el comercio e intercambio para conseguir algo
que uno mismo no produce pero que alguien más sí. Desde hace 100,000 años, la
humanidad ha creado diferentes tipos de economía y conforme ha pasado el tiempo se ha
hecho más práctica y especializada, hoy en día se define como un medio admitido por un
sistema económico. Puede ser monedas, billetes bancarios y otras formas diversas cuya
característica principal es la de ser un instrumento de cambio y una medida de valor.
La evolución de los medios de pago desde el siglo XIX hasta hoy ha sido enorme, desde un
punto de vista practico y de control, especialmente a partir de la década de los años 60,
haciendo uso de las tecnologías de la información y al desarrollo de la actividad financiera
que vertiginosamente se ha acelerado en los últimos años, se ha permitido la incorporación
de una diversidad de medios de pago, como los medios de pago electrónico, ceros y unos
circulando por redes de comunicación, almacenados en medios físicos electrónicos en los
cuales ahora creemos y respaldamos con la idea, sustitutivos de la moneda y billetes de
curso legal que hasta hace algunos años tenían un respaldo o equivalente en minerales
como el oro y la plata.
Los medios de pago electrónicos más usuales son las tarjetas de crédito, débito y las tarjetas
prepagadas. Con la tarjeta de crédito compras primero y pagas después al banco en la fecha
pactada. Funciona como un préstamo que recibes del Banco que pagas días después y si te
demoras pagas intereses. En cambio, con la tarjeta de débito pagas con el dinero que tienes
en tu cuenta bancaria. Cuando se registra el pago que hiciste con tu tarjeta de débito, el
banco te lo resta inmediatamente a tu cuenta. Con la tarjeta prepagada pagas antes de usar
el servicio: por ejemplo, compras crédito para tu celular y después lo utilizas
IX
Introducción
En el año 2010 en México la Comisión Nacional Bancaria y de Valores CNBV publicó la
regulación que permite operar corresponsales bancarios1, término que hace referencia a un
tercero que establece relaciones o vínculos de negocio con una institución de crédito con
objeto de ofrecer, a nombre y por cuenta de ésta, servicios financieros a sus clientes. Al
permitir este nuevo canal de distribución, el Gobierno Federal busca facilitar el acceso a
servicios financieros, a través del incremento de puntos de distribución de servicios
financieros, reduciendo los costos de transacción para los demandantes y oferentes.
Para que los corresponsales bancarios funcionen como un verdadero canal que promueva la
Inclusión Financiera, y no sólo como un canal que brinde mayor conveniencia a los clientes
de los bancos; es necesario que represente una reducción real de los costos, para que
logren penetrar en las localidades desatendidas, constituidas en su mayoría por municipios
rurales, en transición y semi-urbanos.
En el futuro próximo el impacto de los medios de pago electrónicos va a seguir aumentando,
al crecer su uso en todo tipo de transacciones. Seguramente todavía nos queda mucho por
ver en la evolución que sigan el dinero y las formas de pago electrónico.
1
Comisión Nacional Bancaria y de Valores, CMBV, Modelos de Negocio para la Inclusión Financiera
(2010)
X
Objetivo
Objetivo
Documentar los procesos llevados a cabo en el diseño de la arquitectura lógica de un
programa Gateway Corresponsal Bancario ISO8583. El cual tiene como objetivo comunicar
una entidad Bancaria con las terminales punto de venta de una cadena de tiendas de
autoservicio, para recibir en ellas transacciones de deposito a tarjeta de crédito y debito,
bajo la figura de corresponsal bancario.
Objetivos específicos
• Documentar diseño de la arquitectura lógica del sistema Gateway Corresponsal
Bancario ISO8583.
• Comunicar transacciones electrónicas de corresponsalía bancaria con formato
ISO8583, entre un Banco y una cadena de Tiendas de autoservicio.
XI
Justificación
Justificación
En la actualidad en México, los medios de pago electrónico están presentes en el cotidiano
de muchas maneras. Tarjetas prepagadas para el consumo de servicios digitales, tarjetas
para viajar en metro, metrobús o bicicleta, recargas de saldo de telefonía celular sin rascar
tarjetas, vales de despensa de programas sociales, tarjetas bancarias de debito y crédito. Si
a este fenómeno le aunamos al crecimiento exponencial de sucursales de tiendas de
autoservicio, que aparecen día a día en las esquinas de cada colonia, tenemos por resultado
el escenario perfecto para establecer un modelo de negocios redituablemente lucrativo,
donde los puntos de venta de dichos comercios pueden volverse receptores de
transacciones electrónicas de múltiples tipos, entre ellas, las transacciones bancarias de
deposito y retiro de efectivo, logrando de esta manera acercar dichos servicios bancarios a
regiones donde las sucursales bancarias anteriormente no llegaban.
Este tema es de gran interés para comprender la importancia que tiene la formación de
ingenieros, enfocados en el desarrollo de tecnologías de información, al servicio de la
sociedad de consumo. ¿Podremos aprender de lo que hemos desarrollado y aplicarlo en el
desarrollo de modelos económicos y sociales, donde los beneficios sean para la sociedad y
no para los intermediarios de los flujos de información?.
XII
CAPITULO 1
Corresponsalía bancaria, modelo de
inclusión financiera en México
1
Corresponsalía bancaria, modelo de inclusión financiera en México
En los últimos años, el Gobierno Federal ha diseñado políticas públicas encaminadas a
promover la Inclusión Financiera. La introducción de la figura de corresponsales bancarios es
un claro ejemplo de una reciente adecuación a la Regulación para promover el acceso a
servicios financieros. Desde su implementación en diciembre de 2009, 12 cadenas
comerciales ya actúan como corresponsales bancarios proporcionando más de 15 mil
nuevos puntos de acceso al sistema financiero.
Debido al enorme potencial del modelo de corresponsales en México, la Comisión Nacional
Bancaria y de Valores CNBV elaboró un análisis con el objetivo de valorar la posibilidad de
utilizar las Redes de Distribución de productos para habilitar comercios independientes como
distribuidores de servicios financieros (corresponsales bancarios), y así facilitar a los
oferentes la manera de llegar a las poblaciones con menor acceso a servicios financieros en
el país.
De acuerdo con la interacción que exista entre la Institución Bancaria y sus corresponsales,
el modelo de negocio puede realizarse de forma directa o indirecta, es decir, existe la
posibilidad de que el Banco delegue a una entidad gestora la administración de sus agentes
(corresponsales). Si las instituciones optan por hacerlo de manera indirecta la
reglamentación permite la figura del Administrador de Corresponsales.2
Un Administrador de Corresponsales facilita el crecimiento de la red de corresponsales y
disminuye los costos asociados a la instalación; al mismo tiempo, permite la homologación
de los sistemas operativos y tecnológicos, entre otras ventajas.
Un Administrador de Corresponsales puede realizar varias de las actividades involucradas en
2
V. Comisión Nacional Bancaria y de Valores, CMBV, Modelos de Negocio para la Inclusión
Financiera, Pág. 15 (2010)
2
Corresponsalía bancaria, modelo de inclusión financiera en México
el modelo de negocios; estas funciones van desde las relacionadas con la apertura de un
corresponsal, como son la selección de corresponsales o la capacitación; hasta aquellas
actividades destinadas a mejorar el rendimiento de los mismos, como el desarrollo de
esquemas de incentivos o la asesoría en mercadotecnia. También realizan actividades que
aseguren la sustentabilidad del modelo; como son la solución de problemas técnicos, el
control de riesgos, así como garantizar las necesidades líquidas de los corresponsales.
En mi experiencia profesional he laborado con empresas desarrollando Switches
transaccionales, nuevos medios de pago electrónico y con otras que fungen el rol de
intermediarios administradores de transacciones Administrador de Corresponsales. Bajo mi
responsabilidad ha estado la conceptualización de proyectos, diseño de arquitectura lógica y
de comunicaciones, generación de especificaciones técnicas, desarrollo de sistemas
informáticos y canales de comunicación para medios de pago y de consumo electrónico,
especialmente en sistemas encargados del intercambio de transacciones electrónicas entre
corresponsales
bancarios,
cajeros
automáticos,
comercio
electrónico
por
Internet,
proveedores de servicios, venta de tiempo aire de telefonía celular, programas sociales,
estaciones gasolineras, bancos y marcas de tarjetas como VISA, MasterCard y American
Express.
3
CAPITULO 2
Gateway ISO8583,
sistema informático transaccional de
corresponsalía bancaria
4
Gateway ISO8583 Sistema Informático Transaccional de Corresponsalía Bancaria
Hemos visto en el capitulo anterior las ventajas practicas que ofrece a comercios, bancos y
usuarios del sistema financiero la implementación de corresponsales bancarios haciendo uso
de la infraestructura de comunicaciones y puntos de ventas de cadenas comerciales.
En esta memoria expondré mi trabajo realizado en una empresa que cumple el rol de
Administrador de Corresponsales, donde desarrolle el análisis y diseño de la arquitectura
lógica de un sistema Gateway ISO8583 encargado de comunicar, validar y traducir
transacciones electrónicas de corresponsalía bancaria entre una cadena comercial que para
fines ilustrativos del reporte llamaremos Tiendas X y un Banco al cual nombrare Banco Y.3
Tiendas X es una cadena comercial de tiendas de autoservicio que extiende su red de puntos
de venta a nivel nacional operando las 24 horas del día, tomando en cuenta los horarios bajo
los cuales operan actualmente las sucursales bancarias de Banco Y (9 a.m. – 4 p.m.),
implementar un modelo de corresponsalía bancaria haciendo uso de la red de puntos de
venta e infraestructura de Tiendas X ofrece una gran ventaja para los usuarios de Banco Y
que por razones de tiempo o ubicación no pueden acceder de forma sencilla a una sucursal
bancaria dentro de su localidad.
Por su lado Banco Y abre la oportunidad a comercios y cadenas comerciales para captar
operaciones de corresponsalía bancaria, haciendo usos de su infraestructura y puntos de
venta, obteniendo el comercio intermediario una comisión por cada transacción la cual es
pagada directamente por el usuario del servicio.
3
Tiendas X y Banco Y, serán referencias usadas a lo largo del reporte.
5
Gateway ISO8583 Sistema Informático Transaccional de Corresponsalía Bancaria
Como requisito para que Tiendas X y otros comercios puedan captar transacciones de
corresponsalía bancaria se hace necesario que estos cumplan con los estándares y normas
de comunicación establecidas por Banco Y. Siendo esta tarea muchas veces difícil de
resolver por los comercios, entra la figura de Administrador de Corresponsales, el cual es un
intermediario tecnológico y comercial encargado de establecer canales de comunicación
adecuados entre comercios y bancos cumpliendo con los estándares y normas propios de
cada entidad.
Tiendas X actualmente cuenta con un sistema informático para el switcheo de transacciones
electrónicas con formato ISO8583 pero este no cumple con las especificaciones establecidas
por Banco Y, por lo que Tiendas X estableció un vinculo de comunicación mediante un
Administrador de Corresponsales donde yo colabore en el análisis y desarrollo del proyecto
Gateway ISO8583, una interfaz de comunicación de transacciones electrónicas de
corresponsalía bancaria entre Tiendas X y Banco Y.
2.1.- Responsabilidades a cargo dentro del proyecto
En el desarrollo del proyecto Gateway ISO8583 estuvieron bajo mi cargo las siguientes
responsabilidad.
• Análisis de requerimientos técnicos para comunicar a Tiendas X con Banco Y.
• Apoyo en el desarrollo de las aplicaciones que cumplan con los requisitos estipulados.
• Realizar pruebas locales antes de pasar al proceso de certificación.
• Realizar proceso de certificación de la aplicación con Banco Y.
6
Gateway ISO8583 Sistema Informático Transaccional de Corresponsalía Bancaria
2.2.- Objetivos a perseguir en el desarrollo del proyecto
Dentro de las responsabilidades a cargo los objetivos específicos a perseguir fueron.
• Diseñar la arquitectura lógica del sistema.
• Diseñar y desarrollar capa de vista.
• Diseñar y desarrollar clases ISO8583 para capa de control.
• Diseñar y desarrollar clases de conectividad de sockets cliente - servidor.
2.3.- Observaciones
Los desarrollos e implementaciones se realizarán siguiendo los siguientes estándares del
Administrador de Corresponsales:
• Realización de la programación del software usando el lenguaje de programación
Visual Basic.Net.
• Utilización del estándar ISO8583 para la comunicación de transacciones.
Veamos ahora algunos antecedentes teóricos que nos permiten tener un mayor
entendimiento del proyecto, comencemos con el lenguaje de programación utilizado para el
desarrollo del sistema.
7
CAPITULO 3
Fundamentos para el desarrollo de un
sistema informático transaccional de
corresponsalía bancaria
8
Fundamentos para el desarrollo de un
sistema informático transaccional de corresponsalía bancaria
3.1.- Lenguaje de programación, Visual Basic. Net
En el desarrollo del proyecto el lenguaje de programación utilizado por preferencia del
Administrador de Corresponsales fue Visual Basic .NET.
Visual Basic .NET (VB.NET) es un lenguaje de programación orientado a objetos que se
puede considerar una evolución de Visual Basic implementada sobre el framework .NET. Su
introducción resultó muy controvertida, ya que debido a cambios significativos en el lenguaje
VB.NET no es retrocompatible con Visual Basic, pero el manejo de las instrucciones es
similar a versiones anteriores de Visual Basic, facilitando así el desarrollo de aplicaciones
más avanzadas con herramientas modernas.
Visual Basic .NET ofrece numerosas características nuevas y mejoradas, como herencia,
interfaces y sobrecarga, que lo convierten en un eficaz lenguaje de programación orientado a
objetos. Como desarrollador de Visual Basic, ahora puede crear aplicaciones multiproceso y
escalables utilizando subprocesamiento múltiple explícito. Otra característica nueva de Visual
Basic .NET incluye el control estructurado de excepciones, atributos personalizados y
compatibilidad con CLS (Common Language Specification, Especificación de lenguajes
Comunes).También se incluyen el control estructurado de excepciones, delegados y varios
tipos de datos nuevos.
Veamos mas acerca de los Corresponsales Bancarios y Administradores de Corresponsales.
9
Fundamentos para el desarrollo de un
sistema informático transaccional de corresponsalía bancaria
3.2.- Qué es un corresponsal bancario
El corresponsal bancario es un tercero que establece relaciones o vínculos de negocio con
una institución de crédito con objeto de ofrecer, a nombre y por cuenta de ésta, servicios
financieros a sus clientes. Un ejemplo son los establecimientos comerciales habilitados para
prestar servicios financieros ofrecidos por un banco. La Figura 3.1 muestra los principales
actores que intervienen en el proceso.
Fuente : CNBV
Figura 3.1. Principales Actores.
10
Fundamentos para el desarrollo de un
sistema informático transaccional de corresponsalía bancaria
3.2.1.- Requisitos para ser corresponsal
Puede habilitarse como corresponsal bancario cualquier persona que, por medio de la
institución financiera, acredite ante el órgano regulador su experiencia y capacidad técnica
cumpliendo con los requisitos que se muestran en la Tabla 3.2.1.
Tabla 3.2.1 Requisitos para ser corresponsal bancario.
¿Quienes pueden ser corresponsales?
•
Personas Morales o físicas con actividad empresarial:
•
Con un establecimiento permanente
•
Que acrediten un giro de negocio propio
•
Con infraestructura necesaria para realizar operaciones
•
Con personal capacitado para operar los dispositivos tecnológicos
•
Con buen historial crediticio y de negocios
•
Que no hayan sido condenados por sentencia (delitos dolosos o patrimoniales)
Fuente : CNBV
11
Fundamentos para el desarrollo de un
sistema informático transaccional de corresponsalía bancaria
3.2.2.- Actividades que pueden realizar los corresponsales
Los corresponsales bancarios funcionan como una ventanilla entre la institución financiera y
el cliente; sin embargo, las transacciones se realizan Cliente-Corresponsal CorresponsalBanco mediante operaciones de cargo y abono en las cuentas correspondientes, de acuerdo
a la operación que se esté llevando a cabo. Es importante destacar que, en todo momento, la
institución financiera es la responsable ante el cliente de todas las operaciones realizadas a
través de sus corresponsales. En la Tabla 3.2.2 se muestra las actividades que tiene
permitidas un corresponsal, y las cataloga de acuerdo a si son operaciones con cargo o con
abono al corresponsal; así mismo distingue aquellas operaciones en las que no existe
afectación a la cuenta del corresponsal.
Tabla 3.2.2 Actividades que pueden realizar los corresponsales.
Operaciones con Cargo al
Operaciones con Abono
Corresponsal
al Corresponsal
•
Pago de servicios en
efectivo con tarjetas, o
con cheques de la
institución
•
Depósitos en efectivo o
con cheques de la
institución
•
Pago de créditos en
efectivo, con tarjetas o
con cheques de cualquier
institución.
Otras Operaciones
•
Retiro de efectivo
•
Consulta de
saldos y
movimientos
•
Pago de cheques
del mismo banco
•
Remesas
Circulación de medios de
pago
Fuente : CNBV
•
12
Fundamentos para el desarrollo de un
sistema informático transaccional de corresponsalía bancaria
3.2.3.- Actividades que no pueden realizar los corresponsales
La Tabla 3.2.3 muestra las actividades que no tiene permitidas un corresponsal. La
regulación vigente restringe la actividad del corresponsal, para evitar prácticas monopólicas;
así como para garantizar, en todo momento, que se cumplan los estándares de protección al
cliente y se proteja la estabilidad del sistema financiero
Tabla 3.2.3 Actividades que no pueden realizar los corresponsales.
¿Qué NO pueden hacer los Corresponsales?
•
Cobrar a los clientes o usuarios tarifas no autorizadas
•
Condicionar alguna venta de otro producto o servicio a la realización de
alguna operación (Ventas Atadas)
•
Publicitarse o promocionarse en los comprobantes de operación
•
Ceder el contrato total o parcialmente a terceros
•
Pactar exclusividad en el pago de servicios no bancarios así como en el
pago de tarjetas de crédito
•
Prestar servicios financieros por cuenta propia
•
Realizar cualquier operación de forma distinta a la pactada con la
institución
Fuente : CNBV
13
Fundamentos para el desarrollo de un
sistema informático transaccional de corresponsalía bancaria
3.2.4.- Esquema de operación con cargo al corresponsal
El la Figura 3.2.4 se muestra un ejemplo de cómo es el proceso para realizar una operación
con cargo al corresponsal.
Figura 3.2.4.Esquema de operación con cargo al corresponsal.
14
Fundamentos para el desarrollo de un
sistema informático transaccional de corresponsalía bancaria
3.2.5.- Resumen de requerimientos por tipo de operación
Todas las operaciones deberán llevarse a cabo en tiempo real y contar con mecanismos de
identificación que permitan verificar, tanto la autenticidad del cliente, como la del operador y
del equipo. Se deberá generar, además de un registro electrónico de todas las operaciones,
un comprobante para el cliente. En la Tabla 3.2.5 se muestra, en forma resumida, los
requerimientos que exige la regulación para la realización de cada una de las operaciones
bancarias permitidas.
Tabla 3.2.5 Requerimientos Tecnológicos.
15
Fundamentos para el desarrollo de un
sistema informático transaccional de corresponsalía bancaria
La institución financiera y el corresponsal deberán firmar un contrato de comisión mercantil,
el cuál debe contener, por lo menos, los siguientes puntos: las actividades permitidas y
prohibidas para el corresponsal, los procedimientos para la identificación del corresponsal y
del cliente, la aceptación del corresponsal para recibir visitas de inspección por parte de la
Comisión Nacional Bancaria y de Valores, los límites de las operaciones (individuales y
agregados), los requisitos operativo y técnicos, la responsabilidad del corresponsal ante la
institución de créditos, y por último, los procedimientos para rescindir o suspender el contrato
en caso de incumplimiento.
16
Fundamentos para el desarrollo de un
sistema informático transaccional de corresponsalía bancaria
3.3.- Estándar ISO8583
ISO8583 define un estándar de intercambio y un flujo de comunicación para que diferentes
sistemas puedan intercambiar transacciones electrónicas. La mayoría de las operaciones
realizadas en ATM usan ISO8583 en algunos puntos de la cadena de comunicación, así
como también las transacciones que realiza un cliente que usa una tarjeta para hacer un
pago en un local. En particular, todas las redes de tarjetas basan sus transacciones en el
estándar ISO8583.
Las transacciones incluyen compras, extracciones, depósitos, reintegros, reversos, consultas
de saldo, pagos y transferencias entre cuentas. ISO8583 también define mensajes entre
sistemas para intercambios seguros de claves, conciliación de totales y otros propósitos
administrativos. Aunque el ISO8583 define un estándar común, no se usa normalmente en
forma directa por sistemas o redes. En lugar de eso cada red adapta el estándar para su
propio uso con campos adaptados a sus necesidades particulares.
Para entender que es ISO8583 en una forma práctica y simple, un mensaje ISO8583 es una
cadena de caracteres conformada por los elementos mostrados en la Figura 3.3.
17
Fundamentos para el desarrollo de un
sistema informático transaccional de corresponsalía bancaria
Figura 3.3 Estructura de un mensaje ISO8583.
Longitud
•
Header
MTI
Bitmap(s)
Campos del Mensaje
ETX
Longitud del mensaje; Normalmente se usan 2 bytes para indicar la longitud total del
mensaje.
•
Header; Puede ser opcional y es usado para enviar datos propios del dueño de la
mensajería.
•
MTI; Indica el origen y tipo mensaje
•
Bitmap(s); Son usados para enumerar los campos contenidos en el mensaje.
•
Campos del mensaje; Contienen los datos de la transacción.
•
ETX; Es opcional y es usado para indicar el fin de una transacción, se usa un byte.
Para cada campo (también llamado bit), existe una definición única y específica de su uso.
Algunos campos son de largo fijo y otros de largo variable, estos últimos comienzan con un
indicador de longitud. Un conjunto de definiciones de campos (128 máximo) forma una
definición de ISO8583.
Es importante tener en cuenta que un mensaje ISO8583 sólo funcionará contra su propia
definición. Existe una definición estándar de ISO8583, pero en el uso real, muchas empresas
la modifican y generan su propia definición de ISO8583. Por lo tanto, un mensaje ISO8583
puede ser válido para una definición pero inválida para otra.
18
Fundamentos para el desarrollo de un
sistema informático transaccional de corresponsalía bancaria
3.4.- Arquitectura de software
Una Arquitectura Software, también denominada Arquitectura lógica, consiste en un conjunto
de patrones y abstracciones coherentes que proporcionan el marco de referencia necesario
para guiar la construcción del software para un sistema de información.4
Una arquitectura software se selecciona y diseña con base en unos objetivos y restricciones.
Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los
de tipo funcional, también otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e
interacción con otros sistemas de información. Las restricciones son aquellas limitaciones
derivadas de las tecnologías disponibles para implementar sistemas de información. Unas
arquitecturas son más recomendables de implementar con ciertas tecnologías mientras que
otras tecnologías no son aptas para determinadas arquitecturas.
La arquitectura software define, de manera abstracta, los componentes que llevan a cabo
alguna tarea de computación, sus interfaces y la comunicación entre ellos. Toda arquitectura
software debe ser implementable en una arquitectura física, que consiste simplemente en
determinar qué computadora tendrá asignada cada tarea.
La arquitectura de software, tiene que ver con el diseño y la implementación de estructuras
de software de alto nivel. Es el resultado de ensamblar un cierto número de elementos
arquitectónicos de forma adecuada para satisfacer la mayor funcionalidad y requerimientos
de desempeño de un sistema, así como requerimientos no funcionales, como la confiabilidad,
escalabilidad, portabilidad, y disponibilidad.5
4
Booch, Grady. Object-Oriented Analysis and Design. Second Edition. Benjamin/Cummings,
Redwood: 1994
5
Kruchten, Philippe. "Architectural Blueprints--The 4+1 View Model of Software Architecture". IEEE
Software, Institute of Electrical and Electronics Engineers. November 1995, pp. 42-50.
19
Fundamentos para el desarrollo de un
sistema informático transaccional de corresponsalía bancaria
3.4.1.- Programación por capas
La programación por capas es un estilo de programación en la que el objetivo primordial es la
separación de la lógica de negocios de la lógica de diseño, un ejemplo básico de esto es
separar la capa de datos de la capa de presentación al usuario, la Figura 3.4.1 muestra la
distribución a nivel infraestructura de un sistema estructurado en 3 capas, capa de vista,
capa de negocios y capa de datos.
Figura 3.4.1 Distribución física de un sistema de tres capas.
La ventaja principal de este estilo, es que el desarrollo se puede llevar a cabo en varios
niveles y en caso de algún cambio sólo se ataca al nivel requerido sin tener que revisar entre
código mezclado.
20
Fundamentos para el desarrollo de un
sistema informático transaccional de corresponsalía bancaria
En la actualidad en el diseño de sistemas informáticos se usa las arquitecturas multinivel o
programación por capas. En dichas arquitecturas a cada nivel se le confía una misión simple,
lo que permite el diseño de arquitecturas escalables (que pueden ampliarse con facilidad en
caso de que las necesidades aumenten)
3.4.2.- Capas o niveles
El término "capa" hace referencia a la forma como una solución informática es segmentada
desde el punto de vista lógico. Por ejemplo: Presentación / Lógica de Negocio/ Datos.
En cambio, el término "nivel", corresponde a la forma en que las capas lógicas se encuentran
distribuidas de forma física. Por ejemplo:
• Una solución de tres capas (presentación, lógica, datos) que residen en un sólo
ordenador (Presentación+lógica+datos). Se dice, que la arquitectura de la solución es
de tres capas y un nivel.
• Una solución de tres capas (presentación, lógica, datos) que residen en dos
ordenadores (presentación+lógica, lógica+datos). Se dice que la arquitectura de la
solución es de tres capas y dos niveles.
• Una solución de tres capas (presentación, lógica, datos) que residen en tres
ordenadores (presentación, lógica, datos). La arquitectura que la define es: solución
de tres capas y tres niveles.
21
Fundamentos para el desarrollo de un
sistema informático transaccional de corresponsalía bancaria
El diseño de tres capas está conformado por las siguientes capas:
1.- Capa de presentación: es la que ve el usuario, presenta el sistema al usuario, le
comunica la información y captura la información del usuario dando un mínimo de proceso
(realiza un filtrado previo para comprobar que no hay errores de formato). Esta capa se
comunica únicamente con la capa de negocio.
2.- Capa de negocio: es donde residen los programas que se ejecutan, recibiendo las
peticiones del usuario y enviando las respuestas tras el proceso. Se denomina capa de
negocio (e incluso de lógica del negocio) pues es aquí donde se establecen todas las reglas
que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las
solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base
de datos para almacenar o recuperar datos de él.
3.- Capa de datos: es donde residen los datos. Está formada por uno o más gestores de
bases de datos que realiza todo el almacenamiento de datos, reciben solicitudes de
almacenamiento o recuperación de información desde la capa de negocio.
Todas estas capas pueden residir en un único ordenador (no sería lo normal), si bien lo más
usual es que haya una multitud de ordenadores donde reside la capa de presentación (son
los clientes de la arquitectura cliente/servidor). Las capas de negocio y de datos pueden
residir en el mismo ordenador, y si el crecimiento de las necesidades lo aconseja se pueden
separar en dos o más ordenadores. Así, si el tamaño o complejidad de la base de datos
aumenta, se puede separar en varios ordenadores los cuales recibirán las peticiones del
ordenador en que resida la capa de negocio.
22
Fundamentos para el desarrollo de un
sistema informático transaccional de corresponsalía bancaria
Si por el contrario fuese la complejidad en la capa de negocio lo que obligase a la separación,
esta capa de negocio podría residir en uno o más ordenadores que realizarían solicitudes a
una única base de datos. En sistemas muy complejos se llega a tener una serie de
ordenadores sobre los cuales corre la capa de datos, y otra serie de ordenadores sobre los
cuales corre la base de datos.6
3.4.3.- Modelos o vistas
Toda arquitectura software debe describir diversos aspectos del software. Generalmente,
cada uno de estos aspectos se describe de una manera más comprensible si se utilizan
distintos modelos o vistas. Es importante destacar que cada uno de ellos constituye una
descripción parcial de una misma arquitectura y es deseable que exista cierto solapamiento
entre ellos. Esto es así porque todas las vistas deben ser coherentes entre sí, evidente dado
que describen la misma cosa.
Cada paradigma de desarrollo exige diferente número y tipo de vistas o modelos para
describir una arquitectura. No obstante, existen al menos tres vistas absolutamente
fundamentales en cualquier arquitectura:
• La visión estática: describe qué componentes tiene la arquitectura.
• La visión funcional: describe qué hace cada componente.
• La visión dinámica: describe cómo se comportan los componentes a lo largo del
tiempo y cómo interactúan entre sí.
6
Larman, Craig. UML y Patrones, Introducción al análisis y diseño orientado a objetos. México:
Prentice Hall, 1999
23
Fundamentos para el desarrollo de un
sistema informático transaccional de corresponsalía bancaria
Las vistas o modelos de una arquitectura pueden expresarse mediante uno o varios
lenguajes. El más obvio es el lenguaje natural, pero existen otros lenguajes tales como los
diagramas de estado, los diagramas de flujo de datos, etc. Estos lenguajes son apropiados
únicamente para un modelo o vista. Afortunadamente existe cierto consenso en adoptar UML
(Unified Modeling Language, Lenguaje Unificado de Modelado) como lenguaje único para
todos los modelos o vistas. Sin embargo, un lenguaje generalista corre el peligro de no ser
capaz de describir determinadas restricciones de un sistema de información (o expresarlas
de manera incomprensible).
24
CAPITULO 4
Proceso
de
desarrollo
de
ISO8583 corresponsal bancario
25
Gateway
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
El desarrollo del proyecto Gateway Corresponsal Bancario ISO8583 fue dividido en cinco
etapas, estas se ilustran en la Tabla 4.1 en la cual podemos observar el personal
responsable de cada una de ellas.
Tabla 4.1 Etapas y responsables del proyecto.
Etapas del Proyecto
Responsable
1
Análisis de especificaciones del proyecto.
Pablo Nieto
2
Diseño de arquitectura lógica.
Pablo Nieto
3
Desarrollo.
Ivan Zapien
Pablo Nieto
4
Pruebas.
Wendy Lopez
Pablo Nieto
5
Producción.
Humberto Cardenas
A lo largo del presente capitulo describiré las etapas de análisis, diseño de arquitectura lógica
del proyecto y pruebas, actividades a mi cargo en el desarrollo del proyecto.
Mencionare que en el equipo de trabajo no existía experiencia previa en el tratamiento de
transacciones electrónicas ISO8583, quedando a mi cargo transmitir a los demás integrantes
del equipo la teoría y el esbozo rápido del análisis y diseño de la arquitectura del sistema ya
que se contaba con poco tiempo para tener el sistema final en un ambiente productivo
26
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.1.- Análisis de especificaciones del Proyecto
Como primer paso en el proceso de análisis estableceremos la premisa bajo la cual gira la
necesidad del desarrollo del proyecto Gateway Corresponsal bancario ISO8583.
Se requiere de un sistema que sirva de puente para establecer flujo de transaccional de
corresponsalía bancaria con formato ISO8583 y validación de reglas de negocio entre el
sistema transaccional de una cadena comercial Tiendas X y el sistema autorizador de
transacciones de corresponsalía bancaria del Banco Y.
Conociendo la premisa del desarrollo del sistema se hace necesario conocer las limitantes
que no permiten comunicar de forma directa a Tiendas X con Banco Y, para resolver esta
cuestión tenemos que conocer las características y especificaciones técnicas de cada uno de
los sistemas.
Veamos cuales son las características del sistema transaccional de Tiendas X, la Tabla 4.2
ilustra con un resumen las características y especificaciones importantes del sistema de
Tiendas X, la primer columna muestra el rubro, la segunda el detalle del rubro y la tercera la
especificación.
27
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Tabla 4.2 Resumen de especificaciones del sistema de Tiendas X.
Rubro
Detalle
Especificación
Conectividad
Tipo de conexión
TCP-IP, establecer una sola conexión permanente
para el envío y recepción de transacciones.
Rol de conexión
El sistema se conectara a sistema externo bajo el
rol de cliente.
Transaccional
Mensajes
de El sistema enviara mensajes 0200 por cada
autorización
transacción de corresponsalía bancaria y recibirá
0200 - 0210
como respuesta un mensaje 0210.
Mensajes de reverso El sistema enviara hasta 3 intentos mensajes 0420
0420 - 0430
por cada transacción de corresponsalía bancaria
no respondida y recibirá como respuesta un
mensaje 0430.
Mensajes
de
0800 - 0810
Echo El sistema enviara mensajes de Echo 0800 cada
minuto para monitorear el estado de la conexión y
recibirá como respuesta un mensaje 0810.
Veamos ahora cuales son las especificaciones requeridas del sistema transaccional de
Banco Y para recibir operaciones de corresponsalía bancaria. La Tabla 4.3, ilustra las
características y especificaciones importantes del sistema de Banco Y, la primer columna
muestra el rubro, la segunda el detalle del rubro y la tercera la especificación requerida.
28
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Tabla 4.3 Resumen de especificaciones del sistema de Banco Y.
Rubro
Detalle
Especificación
Conectividad
Tipo de conexión
TCP-IP, establecer conexión y desconexión por
cada transacción que se envíe.
Seguridad
de Establecer canal seguro Socket Secure Layer SSL.
conexión
Rol de conexión
El sistema recibe conexiones del sistema externo
bajo el rol de servidor.
Transaccional
Mensajes
de El sistema enviara mensajes 0200 por cada
autorización
transacción de corresponsalía bancaria y recibirá
0200 – 0210
como respuesta un mensaje 0210.
Mensajes de reverso El sistema enviara hasta 3 intentos mensajes 0420
0420 – 0430
por cada transacción de corresponsalía bancaria
no respondida y recibirá como respuesta un
mensaje 0430.
Calculo
de
campo Cada mensaje enviado deberá de incluir en el
MAC
ultimo campo, el campo Message Authentication
Code (MAC).
Reglas
Negocio
de Validación
de Validar horarios permitidos por sucursal.
horarios
Validación de montos
Validar montos máximos y mínimos así como
montos acumulados por sucursal.
29
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Definidas las características y especificaciones de ambos sistemas analicemos cuales de
ellas difieren e impiden comunicarlos de forma directa, justificando de esta forma la
existencia de un sistema intermedio para comunicarlos. Para ilustrarlo observemos la
Tabla 4.4, la primer columna muestra el rubro del requerimiento, la segunda los
requerimientos del sistema de Banco Y para aceptar transacciones de corresponsalía
bancaria de un cliente externo y la ultima columna muestra cuales de estas acciones son
soportadas actualmente por el sistemas de Tiendas X.
Tabla 4.4 Limitantes de Comunicación entre Tiendas X y Banco Y.
Rubro
Banco Y
Tiendas X
Conectividad
TCP. Establecer conexión y Siempre
conectado,
desconexión por cada envío desconexión
de transacción.
Establecer
conexión
transacción.
segura No soportado.
mediante Socket Secure Layer
SSL
Mensajería ISO8583
Aceptar
mensajes Soportado.
transaccionales 0200, 0210,
0400, 0420.
Realizar calculo de Mesage No soportado.
Authentication Code (MAC)
por cada transacción.
Reglas de negocio
Validar horarios permitidos.
No soportado.
Validar montos máximos y No soportado
mínimos, así como montos
acumulados por sucursal.
30
y
no
soporta
reconexión
por
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Como podemos observar en la Tabla 4.4 el sistema de Tiendas X no soporta varios de los
requisitos establecidos por Banco Y, por lo que se hace necesario establecer un puente entre
los dos sistemas el cuál será Gateway Corresponsal bancario ISO8583, este deberá
comunicar a ambos sistemas de forma transparente, por un lado estará diseñado para actuar
como servidor recibiendo transacciones ISO8583 provenientes de Tiendas X, internamente
realizara el calculo del campo MAC, validara reglas de negocio, traducirá la transacción para
ser enviada a Banco Y conectándose a su sistema como cliente por una conexión segura
SSL, al recibir respuesta cerrara la conexión con Banco Y, finalmente retornara la respuesta
de la transacción transformada al formato requerido por Tiendas X.
Veamos ahora que roles de comunicación cumplen cada uno de los sistemas inmersos
dentro del intercambio de transacciones, la Tabla 4.5 ilustra los roles de comunicación que
cumple Tiendas X, Gateway ISO8583 y Banco Y.
Tabla 4.5 Roles de comunicación de entidades.
Tiendas X
Gateway ISO8583
Banco Y
Cliente
Servidor - Cliente
Servidor
Como observamos en la Tabla 4.5 Gateway ISO8583 actuara como servidor por un extremo
recibiendo transacciones de Tiendas X, por el otro extremo se conectara como cliente
enviando las transacciones y recibiendo la respuesta de Banco Y.
31
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Conociendo los roles de comunicación que cumple cada uno de los sistemas, mostraremos a
detalle cuales son los requerimientos específicos que Gateway ISO8583 deberá cumplir.
1. Diseñar y desarrollar un sistema intermedio (Gateway) para comunicar, traducir y validar
de forma bidireccional transacciones electrónicas de corresponsalía bancaria entre
Tiendas X y Banco Y usando el protocolo ISO8583.
La Figura 4.6 muestra el flujo de información entre las entidades Tiendas X,
Gateway ISO8583 y Banco Y en una abstracción del sistema.
GATEWAY
ISO8583
Figura 4.6 Flujo de información entre entidades.
32
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
2. La conectividad entre Tiendas X -
Gateway ISO8583 - Banco Y será punto a punto
mediante el protocolo TCP/IP, teniendo las siguientes características entre entidades :
•
Comunicación a nivel protocolo entre Tiendas X y Gateway ISO8583, se tendrán las
siguientes características ilustradas en la Figura 4.7:
1. Gateway ISO8583 actuará como servidor exponiendo socket y puerto.
2. Tiendas X se conecta como cliente al socket y puerto expuesto por Getaway
ISO8583.
Figura 4.7 Conectividad a nivel protocolo entre Tiendas X y Gateway ISO8583.
33
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
◦
Comunicación a nivel protocolo entre Gateway ISO8583 y Banco Y, se tendrán las
siguientes características ilustradas en la Figura 4.8.
1. Gateway ISO8583 se conecta a Banco Y como cliente.
2. Por cada envío de mensajes se deberá de abrir y cerrar la sesión TCP/IP.
3. No existe intercambio de mensajes de Echo.
Figura 4.8 Conectividad a nivel protocolo entre Gateway ISO8583 y Banco Y.
34
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
3. La conexión entre Gateway ISO8583 y Banco Y debe utilizar canal encriptado Secure
Sockets Layer SSL con las siguientes especificaciones, ilustradas en la Figura 4.9:
1.
2.
3.
4.
Validar certificados de seguridad Verisign7 de ambos lados.
Algoritmos de encripción: AES - Advanced Encryption Standard (192 bit keys)8.
Hash algorithm: Secure Hash Standard.
Método de autenticación: Pre-Shared Key.
Figura 4.9 Canal SSL entre Gateway ISO8583 y Banco Y.
7
8
Verisign, entidad emisora de los certificados de seguridad.
Advanced Encryption Standard (AES), Esquema simétrico de cifrado por bloques.
35
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4. La estructura de las transacciones entre entidades estarán conformadas de la siguiente
manera:
1. Entre Tiendas X y Gateway ISO8583; La mensajería a intercambiar usará el
estándar ISO8583 definido por Tiendas X, como se ilustra en la Figura 4.10.
1. Deberá existir intercambio de mensajes de echo 0800 indicando con ello que
está listo para recibir las transacciones de Tiendas X (0200, 0420, 0421) .
2. Se deberá de estar enviando un mensaje de echo 0800 para verificar qué
Gateway ISO8583 está activo y puede recibir transacciones.
Figura 4.10 Mensajería ISO8583 entre "Tiendas X" y Gateway ISO8583.
36
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
2. Entre Gateway ISO8583 y Banco Y; La mensajería a intercambiar usará el
estándar ISO8583 definido por Banco Y teniendo en cuenta las particularidades
ilustradas en la Figura 4.11:
1. Padeo: Cuando no es divisible entre ocho los datos se rellenan de ceros
a la izquierda del bloque.
2. Incluir el campo MAC.
3. Informar campo MAC: Debe de ir en el último campo (64), si hay más de
64 campos debe de ir en el campo (128).
4. Se cierra y abre conexión por mensaje, no existen mensajes de echo.
Figura 4.11 Mensajería ISO8583 entre Gateway ISO8583 y Banco Y.
37
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
5. Las transacciones electrónicas de corresponsalía bancaria que se realizarán son:
1. Depósito a Tarjeta de Débito.
2. Reversos de transacciones.
6. Todas las transacciones deben registrarse en la pista de auditoría.
7. Toda la comunicación deberá realizarse a través de enlaces dedicados seguros.
8. El sistema deberá de ser configurable a través de archivos de configuración para:
1. Configuración general de la aplicación, puertos de escucha, llaves criptográficas,
direcciones de
aplicaciones remotas, formato general de mensajes.
2. Esquema de configuración de mensajería de transacciones entre Tiendas X.
3. Esquema de configuración de mensajería de transacciones entre Banco Y.
Teniendo el análisis de los requerimiento y las especificaciones propias del sistema pasemos
a diseñar la arquitectura del Gateway ISO8583 en el cual usaremos un modelo de
arquitectura de tres capas con la intención de facilitar el mantenimiento del sistema y
tratamiento de datos en un futuro.
38
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.2.- Diseño de arquitectura del sistema Gateway ISO8583
En el diseño de la arquitectura del sistema usaremos un modelo de tres capas, con la
finalidad de lograr una arquitectura modular y escalable que permita tener el control preciso
de los componentes y los procesos.
La Tabla 4.2 muestra un esbozo de las tres capas constituirán el esqueleto de la arquitectura
del sistema.
Tabla 4.12 Esbozo de la arquitectura del sistema.
Capa de Vista
Capa de Control
Capa de Datos
Arquitectura del sistema
Definidas cuales serán las capas que conformaran
responsabilidades dentro del funcionamiento del sistema.
el
sistema,
definamos
sus
Sabemos que el sistema requiere comunicar mensajes de forma bidireccional a dos
entidades externas actuando de un lado como servidor y del otro como cliente, por lo que las
funciones que permitan realizar estas acciones las ubicaremos dentro de la capa de vista ya
que esta es la capa que tiene contacto con el exterior.
Dentro de la capa de control se encontraran todas las funciones que permitan interpretar la
estructura ISO8583 de los mensajes transaccionales así como las validaciones de reglas de
negocio y transformaciones de formato.
39
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Finalmente dentro de la capa de datos se situaran todas las operaciones que permitan tener
acceso a las bases de datos del modelo de domino y registros de transacciones del sistema.
En la Tabla 4.13 se muestra un resumen con la descripción y responsabilidades que cada
capa tendrá dentro del sistema.
Tabla 4.13 Descripción y responsabilidades de capas del sistema.
Capa
Vista
Control
Datos
Descripción
Capa que contiene los servicios que
son expuestos como cliente/servidor
de socket y la representación en
código de cada caso de uso.
Capa que contiene la lógica de
negocio, definición para el parseo y
generación de mensajes en formato
ISO8583
Capa que contiene todas las
operaciones hacia los datos, también
contiene el modelo de dominio de la
aplicación así como los mapeos
necesarios para persistir las
instancias del modelo.
Responsabilidad
Administra peticiones de cliente Tienda X y
direccionar al servidor de aplicaciones del
Banco Y
Controlar reglas de negocio e
interpretación de mensajes ISO8583.
Almacenamiento y lógica de tratamiento de
datos de configuración y transacciones.
Teniendo claras las atribuciones de cada una de las capas es necesario establecer los nodos
de intercambio de información del sistema con el exterior, para realizar esta operación
recordemos el flujo de la transacción observando la Figura 4.6.
40
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Encontramos que el primer nodo con el exterior esta representado por el sistema de
Tiendas X que se conectara a Gateway ISO8583 como cliente para el envío y recepción de
transacciones.
El segundo nodo lo encontramos dentro de Gateway ISO8583 este expondrá un servidor
TCP-IP para recibir y responde las transacciones provenientes de Tiendas X, este nodo se
situara dentro de la capa de vista.
El tercer nodo estará dado por un cliente TCP-IP dentro de Gateway ISO8583 que permite
conectarse al sistema de Banco Y para envío y recepción de transacciones, este nodo se
situara de igual forma dentro de la capa de vista.
El cuarto nodo estará representado por el sistema externo de Banco Y el cual expondrá un
servidor TCP-IP que permite recibir y responder transacciones.
Finalmente el quinto nodo estará situado dentro de Gateway ISO8583 el cual permite
comunicar al sistema con una base de datos externa para almacenar los registro de actividad
del sistema, este nodo se situara dentro de la capa de datos.
41
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
En la Tabla 4.14 podemos observar un resumen que muestra en la primer columna el
nombre del nodo, en la segunda columna la descripción del nodo y la tercer columna las
responsabilidades de cada nodo.
Tabla 4.14 Descripción y responsabilidades de los nodos del sistema.
Nodo
Descripción
Sistema externo representado
por Tiendas X que se conecta a
Cliente
Gateway ISO8583 como cliente
a través de un socket
Es componente de Gateway
Servidor
ISO8583 que expone un servidor
de sockets
Es componente de Gateway
Cliente Banco ISO8583 que se conecta al
Banco a través de un socket
Sistema externo representado
por Banco Y al cual Gateway
Banco
ISO8583 se conecta como
cliente a través de un socket
DataBase
Es el recurso de base de datos
Responsabilidad
Envía mensajes transaccionales en
formato ISO 8583 y recibe respuesta a
ellos
Administra peticiones de Cliente, válida
reglas de negocio y direcciona al Cliente
Banco.
Envía mensajes transaccionales en
formato ISO 8583 y recibe respuesta a
ellos
Recibir y autorizar transacciones de
corresponsalía bancaria provenientes de
Tiendas X.
Administra los datos de todas las
aplicaciones conectadas a ella
42
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.3.- Diagrama de Arquitectura
Anteriormente definimos los roles de comunicación, responsabilidades de capas y nodos que
conformaran el sistema Gateway ISO8583 pasaremos a diagramar la arquitectura del
sistema con estos elementos.
La Figura 4.15 muestra el diagrama de arquitectura propuesto para el desarrollo del
Gateway ISO8583, en este se puede observar cómo están organizadas las capas para
comunicarse entre si, así como las responsabilidad de cada una y su conexión con los nodos
del sistema.
Figura 4.15 Diagrama de Arquitectura de tres capas Gateway ISO8583.
43
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
En la Capa de Vista del diagrama podemos observar una interfaz la cual tiene como
responsabilidad exponer los nodos Servidor y Cliente Banco, el primero encargado de recibir
y responder las transacciones provenientes del sistema de Tiendas X representado por el
nodo externo Cliente y el nodo Cliente Banco que permite comunicar las transacciones
recibidas al sistema de Banco Y representado por el nodo externo Banco, al mismo tiempo la
Capa de Vista se comunica con la Capa de Control en donde encontramos el componente
Control de Mensajes el cual tiene como finalidad realizar las validaciones de la estructura del
mensaje transaccional ISO8583, reglas internas y de negocio, esta capa se comunica con la
Capa de Datos la cual se conecta con el nodo externo Database el cual representa la base
de datos de donde se obtienen los datos propios para la validación de los mensajes y se
almacenan las transacciones procesadas con la finalidad de tener un registro de la actividad
del sistema para futuras aclaraciones y conciliación entre entidades.
Teniendo presente la funcionalidad y relación de los componentes que conforman el
diagrama de la arquitectura del sistema Gateway ISO8583 definamos ahora cuales son los
casos de usos que el sistema presentara.
4.4.- Casos de uso del sistema
El sistema Gateway ISO8583
requiere procesar dos tipos de transacciones de
corresponsalía bancaria provenientes de Tiendas X:
1. Depósitos a tarjeta de crédito o débito.
2. Reversos de depósitos a tarjeta de crédito o débito.
44
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Visto lo anterior definiremos dos casos de uso, al primero lo llamaremos Depósito y estará
encargado de procesar transacciones de Depósitos a tarjeta de crédito o débito y el segundo
caso lo nombraremos Reverso encargado de procesar transacciones de Reversos de
depósitos a tarjeta de crédito o débito, la Tabla 4.16 muestra la descripción de cada caso de
uso.
Tabla 4.16 Descripción de Casos de uso del sistema.
ID
Nombre
UC1
Depósito
UC2
Reverso
Descripción
Este caso de uso contiene la lógica para realizar un
depósito a tarjeta de crédito o débito.
Este caso de uso contiene la lógica para realizar un reverso
de depósito a tarjeta de crédito o débito.
Definidos los casos de uso definamos ahora los actores del sistema.
4.5.- Actores del sistema
Los personajes o entidades que participarán en un caso de uso se denominan actores. La
Tabla 4.17 describe los actores que intervienen en los casos de uso del sistema.
Tabla 4.17 Descripción de Actores del sistema.
Nombre
Descripción
Cliente
Este actor es un sistema que usa los servicios de Gateway ISO8583.
45
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
En la Figura 4.18 podemos observar como el actor Cliente con origen en Tiendas X puede
acceder a los dos casos de uso del sistema, Deposito y Reverso, ambos casos internamente
pasan por la validación de reglas de negocio y finalmente al envío y recepción del mensaje al
Banco Y.
Figura 4.18 Actores y Casos de Uso del sistema.
Definidos los casos de uso y actores del sistema definamos ahora el flujo de las operaciones
que internamente se realizaran para cada uno de los casos de uso Depósito y Reverso.
46
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.6.- Flujo Caso de Uso Depósito
1.- Descripción; Este caso de uso describe el comportamiento general para realizar un
depósito a tarjeta de crédito o débito.
2.- Actores; Cliente.
3.- Disparador; El cliente envía una petición 0200 al servidor con la especificación ISO8583.
4.-Precondiciones; Los datos enviados en la petición deben estar de acuerdo al layout del
mensaje 0200 de la especificación ISO8583.
5.-Flujo Principal
1. El sistema recibe una cadena de bytes del Cliente y al detectar que es un mensaje del
tipo depósito 0200 continúa con el flujo mostrado en la Figura 4.19.
2. Se valida la estructura y campos ISO8583 del mensaje de deposito 0200.
3. Se valida usuario y se obtienen las cadenas asociadas.
4. Se procesan las reglas de negocio validación de montos y horarios.
5. Se guarda la petición en la bitácora de transacciones.
6. Se genera mensaje de petición ISO8583 0200 con el formato requerido por Banco Y.
7. Se establece conexión con el Banco Y y se envía el mensaje 0200.
8. Se recibe el mensaje de respuesta del Banco Y 0210 y se cierra la conexión con el
Banco.
9. Se obtiene el listado de mensajes contenidos en la respuesta 0210.
47
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
10.
Se parsea el mensaje de respuesta 0210 para obtener los campos que le
conforman.
11.
Se valida la estructura y campos del mensaje ISO8583 de respuesta 0210.
12.
Se actualiza el valor de respuesta en la base de datos.
13.
Se guarda respuesta en bitácora de transacciones.
14.
Se genera mensaje de respuesta ISO8583 0210 con el formato de Tiendas X.
15.
Finalmente
se
envía
el
mensaje
de
respuesta
a
Tiendas
X
El diagrama de la Figura 4.19 ilustra gráficamente el flujo que sigue una transacción de
depósito a tarjeta de crédito o débito.
48
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Figura 4.19 Diagrama de flujo del caso de uso Depósito.
49
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.7.- Flujo Caso de Uso Reverso
1.- Descripción; Este caso de uso describe el comportamiento general para realizar un
reverso a depósito a tarjeta de crédito o débito.
2.- Actores; Cliente.
3.- Disparador; El cliente envía una petición 0420 al servidor con la especificación ISO8583.
4.- Precondiciones; Los datos enviados en la petición deben estar de acuerdo al layout del
mensaje 0420 de la especificación ISO8583.
5.-Flujo Principal
1. El sistema recibe cadena de bytes del cliente desde el flujo inicial al detectar que es un
mensaje del tipo reverso continua con el flujo mostrado en la Figura 4.20.
2. Se valida la estructura y campos ISO8583 del mensaje de reverso 0420.
3. Se valida usuario y se obtienen las cadenas asociadas.
4. Se procesan las reglas de negocio validación de montos y horarios.
5. Se guarda la petición en la bitácora de transacciones.
6. Se genera mensaje de petición ISO8583 0420 con el formato requerido por Banco Y.
7. Se establece conexión con el Banco Y y se envía el mensaje 0420.
8. Se recibe el mensaje de respuesta del Banco Y 0430 y se cierra la conexión con el
Banco.
9. Se obtiene el listado de mensajes contenidos en la respuesta 0430.
50
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
10.
Se parsea el mensaje de respuesta 0430 para obtener los campos que le
conforman.
11.
Se valida la estructura y campos del mensaje ISO8583 de respuesta 0430.
12.
Se actualiza el valor de respuesta en la base de datos.
13.
Se guarda respuesta en bitácora de transacciones.
14.
Se genera mensaje de respuesta ISO8583 0430 con el formato de Tiendas X.
15.
Finalmente se envía el mensaje de respuesta a Tiendas X
El diagrama de la Figura 4.20 ilustra gráficamente el flujo que sigue una transacción de
reverso de depósito a tarjeta de crédito o débito.
51
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Figura 4.20 Diagrama de flujo del caso de uso Reverso.
52
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.8. Diagramas de Proceso
El diagrama de proceso es una forma gráfica de presentar las actividades involucradas en el
flujo de cada uno servicios terminados.
Veamos a continuación los diagramas de proceso que ilustran las validaciones de reglas de
negocio definidas para los servicios de Depósito y Reverso.
4.8.1 Diagrama de Proceso Depósito
Una transacción de Depósito tiene que ser evaluada antes de ser enviada al Banco Y, por
dicho motivo se realizan las validaciones mostradas en la Tabla 4.21.
Tabla 4.21 Validaciones transacción de Depósito.
Validación
Descripción
Aplicación
Valida que la aplicación sea la correcta.
Comercio
Valida que el comercio exista y esté activo.
Punto de venta
Valida que el punto de venta exista y esté activo.
Cuenta
Valida formato de tarjeta, que esté activa y pertenezca a Banco Y.
Tipo Transacción
Valida que la transacción exista y esté activa.
Horario
Valida que la transacción esté dentro del horario de operación.
Limites
Valida limites por transacción y comercio.
53
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
El diagrama de la Figura 4.22 muestra las validaciones de reglas de negocio y procesos por
los que tiene que pasar una transacción de Depósito a tarjeta de crédito o débito proveniente
de Tiendas X antes de ser enviada a Banco Y, asegurando así la integridad de los datos
enviados. Al cumplir con todas las validaciones la transacción es enviada a Banco Y,
esperando recibir la respuesta la cual posteriormente es procesada como se ilustra en la el
diagrama de proceso.
Figura 4.22 Diagrama de proceso Depósito.
54
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
El diagrama de la Figura 4.23 muestra las validaciones realizadas al recibir la respuesta de
una transacción de Depósito a tarjeta de crédito o débito.
Figura 4.23 Diagrama de Validaciones Depósito.
55
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.8.2 Diagrama de Proceso Reverso
Una transacción de Reverso tiene que ser evaluada antes de ser enviada al Banco Y, por
dicho motivo se realizan las validaciones mostradas en la Tabla 4.24.
Tabla 4.24 Validaciones transacción de Reverso.
Validación
Descripción
Aplicación
Valida que la aplicación sea la correcta.
Comercio
Valida que el comercio exista y esté activo.
Punto de venta
Valida que el punto de venta exista y esté activo.
Cuenta
Valida formato de tarjeta, que esté activa y pertenezca a Banco Y.
El diagrama de la Figura 4.25 muestra las validaciones de reglas de negocio y procesos por
los que tiene que pasar una transacción de Reverso a tarjeta de crédito o débito proveniente
de Tiendas X antes de ser enviada a Banco Y, asegurando así la integridad de los datos
enviados.
Al cumplir con todas las validaciones la transacción es enviada a Banco Y, esperando recibir
la respuesta la cual posteriormente es procesada como se ilustra en la el diagrama de
proceso de la Figura 4.26.
56
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Figura 4.25 Diagrama de proceso Reversos.
.
57
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Figura 4.26 Diagrama de Validaciones Reversos.
58
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.9. Vistas de la Arquitectura
Las vistas de la arquitectura muestran diferentes perspectivas que pueden ayudar a
documentar las decisiones estructurales.
4.9.1- Vista Lógica
Esta vista describe los comportamientos y estructuras significativas del sistema. Se ha
descompuesto esta vista en varios apartados para su descripción. La Figura 4.27 muestra la
estructura lógica de los paquetes que conforman Gateway ISO8583.
Figura 4.27 Vista lógica de paquetes Gateway ISO8583.
59
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.9.2.- Vista Paquetes
Esta vista permite comprender la función de los paquetes que conforman las capas de datos,
control y vista, a continuación se enuncian los paquetes y su función.
• Data.domain: Este paquete perteneciente al componente Data, contiene las clases
que definen el modelo de dominio y archivos de mapeo.
• Data.persistence: Este paquete perteneciente al componente Data, contiene clases
concretas que permiten tener acceso a los datos así como persistirlos. La persistencia
se realiza utilizando un Framework a la medida, denominado persistence.
• Data.messages: Este paquete contiene las clases usadas para la definición de
mensajes ISO8583.
• Data.messages.exceptions: Este paquete contiene las clases para el manejo de
excepciones generadas al tener algún error en la estructura de los mensajes.
• Data.messages.gbTripleDES: Este paquete contiene las clases necesarias para la
encripcion 3DES.
• Data.messages.isoFactory: Este paquete contiene las clases necesarias para el
parseo y la formación de mensajes ISO8583 y sus respectivas validaciones de formato.
• Data.util: Este paquete contiene utilidades de ayuda para el manejo del acceso a
datos.
60
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
• Control.businessLogic: Este paquete contiene servicios de lógica de negocios.
• Control.businessLogic.loaders: Este paquete contiene cargadores de datos relativos
a la transacción, tales como el arreglo de comisiones asociadas a una entidad.
• Control.businessLogic.validators: Este paquete contiene el conjunto de validadores
de reglas de negocios.
• Control.exceptions: Este paquete contiene el conjunto de excepciones para el
manejo de reglas de negocios, así como las clases necesarias para el control de
errores los servicios.
• Control.transform: Este paquete contiene las clases necesarias para la traducción de
códigos de error entre entidades.
• Control.util: Contiene clases que facilitan el manejo del control de flujo al
programador.
• Gateway ISO8583: Contiene clases utilizadas para generar un servidor y cliente de
sockets TCP-IP.
• Server.Exceptions: Este paquete contiene las clases para el manejo de excepciones
de la capa de vista.
• Server.ssl: Este paquete contiene las clases necesarias para el manejo de la capa de
seguridad en la aplicación.
61
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.9.3.- Vista de Componentes
Esta vista permite observar la agrupación en componentes de los distintos paquetes
descritos en el apartado 4.9.2 para las capas de datos, vista y control.
• Componente capa de Datos: Este componente contiene los paquetes de la capa de
datos:
• Data.domain
• Data.persistence
• Data.messages
• Data.messages.exceptions
• Data.messages.gbTripleDES
• Data.messages.isoFactory
• Data.exceptions
• Data.util
• Componente capa de Vista: Este componente contiene los paquetes de la capa de
vista:
• Gateway ISO8583
• Server.exceptions
• Server.ssl
62
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
• Componentes de capa de Control: Este componente contiene los paquetes de la
capa de control:
• Control.businessLogic
• Control.businessLogic.loaders
• Control.businessLogic.validators
• Control.exceptions
• Control.transform
• Control.util
63
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.10.- Mensajería ISO8583 Corresponsal Bancario
Banco Y cuenta con una plataforma transaccional ISO8583 encargada de procesar y
administrar transacciones electrónicas, dicha plataforma define la conectividad y lógica de los
mensajes utilizados para recibir y responder transacciones de corresponsalía bancaria.
Por su lado Tiendas X es capaz de generar y procesar mensajes transaccionales con formato
ISO8583
teniendo
la
limitante
de
no
poder
realizar
el
calculo
del
campo
Mesage Authentication Code (MAC) requerido por Banco Y.
Gateway ISO8583 como intermediario entre ambas entidades tiene por responsabilidad
interpretar, validar, agregar el campo MAC transformando los mensajes recibidos de
Tiendas X al formato requerido por Banco Y.
La Figura 4.28 ilustra el flujo de una transacción originada por Tiendas X, esta viaja al
servidor expuesto por Gateway ISO8583 donde internamente es interpretada por el interprete
que entiende el formato de Tiendas X, posteriormente es traducida y completada con el
formato ISO8583 requerido de Banco Y, la nueva petición es enviada a Banco Y, este la
recibe y responde a Gateway ISO8583, este interpreta la respuesta de Banco Y, la
transforma al formato de Tiendas X y finalmente envía la respuesta a Tiendas X.
64
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Figura 4.28 Flujo de intercambio, validación y traducción de mensajes entre entidades.
A continuación se muestra los servicios disponibles para cada una de las entidades y el
formato de mensajería definida por Banco Y para el esquema de corresponsalía bancaria con
la cual se realizará el desarrollo del Gateway ISO8583 para establecer el diálogo con
Tiendas X.
65
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.10.1.- Definición de mensajería de corresponsalía bancaria
Veamos ahora la definición de la mensajería de cada uno de los servicios disponibles para el
proyecto de corresponsalía bancaria.
Por el lado de Tiendas X existen tres clases de servicios disponibles, autorización, reverso y
echo. De lado de Banco Y en cambio existen solo dos clases de servicios disponibles,
autorización y reversos.
En la Tabla 4.29 podemos observar los servicios de mensajería IS08583 disponibles para
Tiendas X y Banco Y.
Tabla 4.29 Servicios disponibles para Tiendas X y Banco Y.
Servicio Descripción
0200 / 0210 Servicio de autorización.
Servicio de reverso de la
0420 / 0430
autorización previa.
0800 / 0810 Servicio de echos.
Tiendas X
Disponible
Disponible
Banco Y
Disponible
Disponible
Disponible
No disponible
A continuación se describe el uso de cada uno de los servicios disponibles y el flujo entre
entidades.
66
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.10.2.- Servicio de autorización
El servicio de autorización está encargado de procesar transacciones de depósito a tarjeta de
crédito y débito, este consta de dos mensajes, mensaje de solicitud de autorización 0200 y
mensaje de respuesta de autorización 0210. En el proyecto este servicio es utilizado para
implementar el caso de uso Depósito.
La Figura 4.30 muestra el flujo para las transacciones de depósito a tarjeta de crédito o
débito entre entidades. Tiendas X inicia el flujo transaccional enviando un mensaje 0200 a
Gateway ISO8583 (1), esté valida el mensaje, si es válido se genera y envía un mensaje
0200 con el formato ISO8583 definido por Banco Y (2), si la transacción es válida Banco Y
responde a Gateway ISO8583 con un mensaje de respuesta 0210 (3), Gateway ISO8583
valida y transforma la respuesta y devuelve a Tiendas X la respuesta 0210 (4).
Figura 4.30 Flujo Servicio de Autorización.
67
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.10.3.- Servicio de reverso
El servicio de reversos se encarga de reversar transacciones de depósito a tarjeta de crédito
y débito previamente realizadas, este consta de dos mensajes, mensaje de solicitud de
reverso 0420 y mensaje de respuesta de reverso 0430. En el proyecto este servicio es
utilizado para implementar el caso de uso Reverso.
La Figura 4.31 muestra el flujo para las transacciones de reverso de depósito a tarjeta de
crédito o débito entre entidades. Tiendas X inicia el flujo transaccional enviando un mensaje
0420 a Gateway ISO8583 (1), esté valida el mensaje, si es válido se genera y envía un
mensaje 0420 con el formato ISO8583 definido por Banco Y (2), si la transacción es válida
Banco Y responde a Gateway ISO8583 con un mensaje de respuesta 0430 (3), Gateway
ISO8583 valida y transforma la respuesta y devuelve a Tiendas X la respuesta 0430 (4).
Figura 4.31 Flujo Servicio de Reversos.
68
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.10.4.- Servicio de Echos
El servicio de mensajes de echo tiene como finalidad monitorear la conexión entre Tiendas X
y Gateway ISO8583, este servicio consta de dos mensajes, mensaje de echo 0800 y el
mensaje de respuesta de echo 0810.
La Figura 4.32 muestra el flujo para las transacciones de echo. Tiendas X envía
periódicamente mensajes 0800 a Gateway ISO8583 (1), esté valida el mensaje, si es válido
responde con un mensaje 0810(2).
Figura 4.32 Flujo Servicio de Echos.
69
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.10.5.- Estructura de mensajes ISO8583
Los mensajes ISO8583 a intercambiar por las entidades se conforman de cinco componentes,
cada componente define un aspecto del mensaje, en la Tabla 4.32 podemos ver el orden
lógico de los componentes de la estructura del mensaje.
Tabla 4.33 Estructura de mensaje ISO8583.
Inicio del Mensaje
Longitud
Fin del Mensaje
Header MTI
Bitmap(s)
Campos del Mensaje
Veamos a continuación la definición de cada uno de los componentes del mensaje ISO8583.
4.10.5.1.- Longitud del mensaje
Es un componente de dos bytes usado como indicador de la longitud total del mensaje, a la
longitud total no se le suma los dos bytes del indicador de longitud.
Este se representa en código ASCII con el valor en Hexadecimal de la longitud, el primer
carácter se incrementa cada 256 unidades del segundo.
Por ejemplo si un mensaje es de longitud 275 (decimal) sin contar los 2 caracteres que
indican la longitud, los primero caracteres que deben colocarse en el mensaje serían la
representación de 0X01 y 0X13 en ASCII, es decir: “☺♪”.
70
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.10.5.2.- Header del mensaje
El Header es un componente de 12 bytes usado para definir la versión usada del estándar
ISO8583, el estado y origen del mensaje, este está compuesto por 6 subelementos definidos
en la Tabla 4.34.
Tabla 4.34 Componentes del header del mensaje.
Posición Longitud Valor
1-3
3-5
5-7
7-10
3
2
2
3
Descripción
“ISO” = Palabra ISO Indicador ISO
“02” = “transacción
Indicador del tipo de terminal punto
tipo terminal punto
de venta:
de venta (POS)”
02 = “POS”
“11” = “Número de
Versión de mensajería ISO8583
versión”
1.1
“000” = Campo en
error si lo hubiese.
11
1
“5” = Host
12
1
“5” = Host
Estado; indica si existió o no un
problema con la interpretación del
mensaje.
Mensaje Originado por el Host
Indica la entidad que responde el
mensaje.
71
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.10.5.3.- Mapas de Bits (Bitmaps)
Los Mapas de Bits o Bitmaps son dos componentes usados para indicar la presencia o
ausencia de los 126 campos del estándar ISO8583, se definen por una agrupación de 16
caracteres hexadecimales cada uno, al traducirse a código binario cada bit indica la
presencia/ausencia de los campos que viajaran en la estructura del mensaje. Si el bit está
activado (inicializado a 1) indica que el campo correspondiente viaja en el mensaje. La Tabla
4.35 muestra en la parte superior cuatro ejemplos de bitmaps y la explicación detallada del
ejemplo 4210001102C04804 en la parte inferior.
Tabla 4.35 Ejemplos de Bitmaps y detalle.
Bitmap
4210001102C04804
7234054128C28805
8000000000000001
0000000000000003
(Bitmap secundario)
Define la presencia de
Campos 2, 7, 12, 28, 32, 39, 41, 42, 50, 53, 62
Campos 2, 3, 4, 7, 11, 12, 14, 22, 24, 26, 32, 35, 37, 41, 42, 47,
49, 53, 62, 64 ,100 (Bitmap secundario requerido para mostrar la
presencia del campo - 100)
Campos 1, 64
Campos 127, 128
Explicación del Bitmap (8 bytes, Bitmap Primario = 64 Bit) campo 4210001102C04804
BYTE1 : 01000010 = 42x (campos 2 y 7 están presentes)
BYTE2 : 00010000 = 10x (campo 12 está presente)
BYTE3 : 00000000 = 00x (no hay campos presentes)
BYTE4 : 00010001 = 11x (campos 28 y 32 están presentes)
BYTE5 : 00000010 = 02x (campo 39 está presente)
BYTE6 : 11000000 = C0x (campos 41 y 42 están presentes)
BYTE7 : 01001000 = 48x (campos 50 y 53 están presentes)
BYTE8 : 00000100 = 04x (campo 62 esta presente)
Campos presentes en un mensaje de longitud variable:2-7-12-28-32-39-41-42-50-53-62
72
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.10.5.4.- Campos de mensajería ISO8583
Los campos de la mensajería ISO8583 son 126 componentes usados para definir el valor de
las propiedad específicas de cada mensaje. Cada campo tiene dos propiedades; tipo de dato
e indicador de longitud, cada uno está definido por una notación.
El tipo de dato indica el tipo de contenido específico que permite cada campo, para definirlo
se utilizan las abreviaturas de tipos de datos mostradas en la Tabla 4.36.
Tabla 4.36 Tipos de datos de los campos ISO8583.
Abreviatura
Significado
N
Solo valores numéricos
AN
Alfanumérico
ANS
Caracteres Alfabéticos, numéricos y especiales
ANS/B
ANS Longitud Binario
B
Información binaria
Además, cada campo puede tener una longitud fija o variable. Si es variable, el largo del
campo será precedido por un indicador de largo el cual indica la cantidad de bytes usados
como indicador. La Tabla 4.37 muestra las abreviaciones para definir el largo de los campos.
Tabla 4.37 Indicadores de longitud de los campos ISO8583.
Abreviación
F
Significado
Longitud fija
Longitud variable donde:
V N:L
N = El número de bytes utilizados para representar la
longitud del campo
L = Longitud máxima del campo
73
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.10.6.- Campos de mensajería ISO8583
Vimos anteriormente la notación que define a los campos del estándar ISO8583, en la
Tabla 4.38 se muestran las propiedades y uso de cada uno de los campos utilizados para
conformar las transacciones de corresponsalía bancaria.
Tabla 4.38 Definiciones de campos ISO8583 corresponsalía bancaria.
Campo
Formato
0. Primary Bit Map AN F 16
1. Secondary Bit
Map
AN F 16
Descripción
Determina la presencia/ausencia de
los campos opcionales del 1 al 63.
Determina la presencia/ausencia de
los campos opcionales del 65 al 128.
Comentarios / Posibles Valores
Posiciones:
1-2 Tipo de transacción
3. Processing Code
NF6
28 = Depósito Débito
Indica el tipo de transacción solicitada
21 = Depósito Crédito
(compra con tarjeta de crédito, retiro
de tarjeta de cuenta de ahorro,
consulta de cuenta de cheques, etc.).
00 = Cuenta por omisión
5-6 Cuenta Destino
00 = Cuenta por omisión
30 = Crédito
4. Transaction
Amount
7. Transmission
Date and Time
11.System Trace
Audit Number
12. Local
Transaction Time
13. Local
Transaction Date
15. Settlement
Date
17. Capture Date
N F 12
Monto de la transacción con centavos Monto total
N F 10
Fecha y hora de la transmisión del
mensaje (ya sea un 0200 o un 0420)
MMDDhhmmss
NF6
Identificación del mensaje
Este número es único para cada
mensaje enviado
NF6
NF4
NF4
NF4
22. Point of Service
NF3
Entry Mode
Hora local de la transacción (En el
punto de venta)
Día local de la transacción (En el
punto de venta)
Día en el cual se está contabilizando
la transacción
Día en el cual la transacción es
registrada por el Adquirente.
Determina La forma en la cual el
número de tarjeta fue introducido y la
capacidad de la terminal para
74
hhmmss
MMDD
MMDD
MMDD
Posiciones:
1-2 Forma de lectura del número de
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
aceptar/solicitar el NIP.
tarjeta:
00 = Desconocido
01 = Manual
02 = Banda Magnética leída. El
contenido de la misma fue
editado
05 = Chip leído, CVV confiable
80 = Fall Back
90 = Banda magnética leída y su
contenido es proporcionado integró al
Adquirente.
95 = Chip leído, CVV no
confiable
3 Capacidad de aceptación del NIP:
0 = Desconocido.
1 = Puede aceptar NIPs.
2 = No puede aceptar NIPs.
8 = PIN pad fuera de
servicio.
32. Acquiring
Institution
N V 2:11
Identification Code
35. Track 2 Data
ANS V 2:37
Identificador de la entidad Adquirente
Contiene la información del track 2
almacenada en la banda magnética.
Este campo se utiliza para identificar a
todos aquellos mensajes relacionados
con una operación (Folio).
37. Retrieval
AN F 12
Reference Number
Identificación de la transacción.
38.Authorization
Identification
Response
AN F 6
Determina el código asignado por el
Emisor/Adquirente que identifica la
aprobación de una autorización.
AN F 2
Contiene el código de respuesta del
Adquirente para la solicitud de
procesamiento de una transacción
generada por el Adquirente.
ANS F 16
Proporciona la identificación de la
Caja Punto de Venta usada en la
solicitud de la autorización.
39. Response
Code
41. Card Acceptor
Terminal
Identification
En la sección Códigos y Mensajes de
Respuesta se muestra una tabla que
contiene la acción que el Adquirente
realiza para cada uno de los códigos
ISO.
Posiciones:
1-8 Identificación de Terminal.
Justificado a la derecha con ceros a la
izquierda
9-10 Identificador de RFC
11-16 (Opcional)
75
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
43. Card Acceptor
Name/Location
ANS F 40
Nombre/Localización de la entidad
Adquirente (Dirección de las oficinas
centrales)
48. Additional
ANS
Data-Retailer Data V 3:27
Define la afiliación del establecimiento.
49. Transaction
Currency Code.
Código de moneda local usado en la
transacción
NF3
63. POS Additional ANS V
Data
3:102
1-22 Dirección
23-35 Ciudad
36-38 Estado
39-40 País
484 = Pesos
840 = Dólares
Información adicional
001 = Sign on / Logon
70. Network
Management
Information Code
NF3
Código que identifica la acción a
seguirse en relación a la conexión
entre la Interred y el Adquirente.
002 = Sign off / Logoff
201 = Cutoff
301 = Echo Test
Posiciones:
1-4 Id de mensaje de la transacción
original
5-16 Retrieval reference number de la
transacción original (C37)
90. Original Data
Elements
ANS F 42
Campo usado en los reversos para
incluir información de la transacción
original.
17-20 Fecha local de la transacción
original (C13)
21-26 Hora local de la transacción
original (C12)
27-28 ‘00’
29-32 Fecha de captura de la
transacción original (C17).
33-42 Espacios en blanco
64- 128 - Mesage
Authentication
Code (MAC)
ANS F 8
Campo usado como firmaq de
seguridad del mensaje
Resultado del calculo. (Ver Calculo
MAC)
76
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.10.7.- Estructura de mensajes ISO8583 de corresponsalía bancaria
Cada uno de los mensajes de corresponsalía bancaria dependiendo de su propósito se
componen por un cierto número de campos, Tiendas X como vimos anteriormente tiene
definido tres tipos de servicios en su mensajería (deposito, reverso y echo), mientras que
Banco Y solo tiene definidos dos (deposito y reverso).
A continuación la Tabla 4.39 muestra la estructura de campos para los tres tipos de
mensajes originados e intercambiados entre Tiendas X y Gateway ISO8583.
Tabla 4.39 Estructura de mensajes entre Tiendas X y Gateway ISO8583.
Depósito
CAMPO
1
3
4
7
11
12
13
15
17
22
32
35
37
38
39
41
43
48
49
63
70
90
0200
0210
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
C
M
M
C
M
M
M
M
M
M
M
C
Reverso
420
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
C
M
M
C
Echo
0430
M
M
M
M
M
0800
M
0810
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
C
M
C
M
M
M
Abreviaciones
C.- Campo Condicional
M.- Campo Mandatorio
77
M
CAMPO
1
3
4
7
11
12
13
15
17
22
32
35
37
38
39
41
43
48
49
63
70
90
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
La Tabla 4.40 muestra la estructura de campos para los dos tipos de mensajes originados e
intercambiados entre Gateway ISO8583 y Banco Y.
Tabla 4.40 Estructura de mensajes entre Gateway ISO8583 y Banco Y.
Depósito
CAMPO
1
3
4
7
11
12
13
15
17
22
32
35
37
38
39
41
43
48
49
63
64
90
128
Reverso
0200
0210
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
C
M
M
C
M
M
M
M
M
M
M
M
C
M
420
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
C
M
M
C
0430
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
C
CAMPO
1
3
4
7
11
12
13
15
17
22
32
35
37
38
39
41
43
48
49
63
64
90
128
Abreviaciones
C.- Campo Condicional
M.- Campo Mandatorio
Como podemos observar al comparar la definición de servicios y estructura de mensajes
disponibles para Tiendas X y Banco Y, se hacen evidentes las funciones que
Gateway ISO8583 tendrá como intermediario dentro del flujo de transacciones.
78
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.10.8.- Ejemplos de tramas ISO8583
Para comprender de forma sencilla como están conformados a nivel de bytes los mensajes
transaccionales de depósito, reverso y echo mostrare un ejemplo para cada uno de los
mensajes generados por Tiendas X.
4.10.8.1.- Ejemplo Trama Depósito
En la Tabla 4.41 se muestra en la parte superior un ejemplo de la representación ASCII de
una trama de depósito, mensaje 0200, en la parte inferior de la tabla se detalla el análisis de
los campos que conforman la estructura del mensaje.
Tabla 4.41 Ejemplo Trama 0200 Depósito.
“ISO02110005502003238840128A1800000000000000005400009261837241906011851000926092690
10212215579210000000386=0000000000005928CEN50FRDSS787932 Pitagoras 1234 Mexico DF
MX0276285027 00000000484”
Header = ISO021100055
MTI = 0200
BitMap = 3238840128A18000
Dato obtenido (datos entre [] = longitud
variable)
[3] Processing code (n 6)
'000000'
[4] Amount,transaction (n 12)
'000000054000'
[7] Transmission date & time (n 10)
'0926183724'
[11] Systems trace audit number (n 6)
'190601'
[12] Time, Local transaction (n 6)
'185100'
[13] Date, Local transaction (n 4)
'0926'
[17] Date,capture (n 4)
'0926'
[22] Point of service entry mode (n 3)
'901'
[32] Acquiring institution identification code (n ..11) '[02]12'
[35] Track2 data (z ..37)
'[21]5579210000000386=0000'
[37] Retrieval reference number (an 12)
'000000005928'
[41] Card acceptor terminal identification (ans 16) 'CEN50FRDSS787932'
[43] Card acceptor name/location (ans 40)
'Pitagoras 1234 Mexico DF MX'
[48] Additionaldata - Private (an ..999)
'[027] 6285027 00000000'
[49] Currency code, transaction (a 3)
'484'
Nombre del Campo
79
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.10.8.2.- Ejemplo Trama Reverso
En la Tabla 4.42 se muestra en la parte superior un ejemplo de la representación ASCII de
una trama de reverso, mensaje 0420, en la parte inferior de la tabla se detalla el análisis de
los campos que conforman la estructura del mensaje.
Tabla 4.42 Ejemplo Trama 0420 Reverso.
“ISO0211000550420B23A84012EA1800000000040000000000000000000000540000926183744190602
1851000926092609269010212215579210000000386=000000000000592800000068CEN50FRDSS7879
32 Pitagoras 1234 Mexico DF MX0276285027 0000000048402000000000059280926185100000926 ”
Header = ISO021100055
MTI = 0420
BitMap = B23A84012EA180000000004000000000
Dato obtenido (datos entre [] = longitud
Nombre del Campo
variable)
[3] Processing code (n 6)
'000000'
[4] Amount, transaction (n 12)
'000000054000'
[7] Transmission date & time (n 10)
'0926183744'
[11] Systems trace audit number (n 6)
'190602'
[12] Time, Local transaction (n 6)
'185100'
[13] Date, Local transaction (n 4)
'0926'
[15] Date, Settlement (n 4)
'0926'
[17] Date, capture (n 4)
'0926'
[22] Point of service entry mode (n 3)
'901'
[32] Acquiring institution identification code (n ..11)
'[02]12'
[35] Track 2 data (z ..37)
'[21]5579210000000386=0000'
[37] Retrieval reference number (an 12)
'000000005928'
[38] Authorization identification response (an 6)
'000000'
[39] Response code (an 2)
'68'
[41] Card acceptor terminal identification (ans 16)
'CEN50FRDSS787932'
[43] Card acceptor name/location (ans 40)
'Pitagoras 1234 Mexico DF MX'
[48] Additional data - Private (an ..999)
'[027]6285027
00000000'
[49] Currency code, transaction (a 3)
'484'
[90] Original data elements (n 42)
'02000000000059280926185100000926
80
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.10.8.3.- Ejemplo Trama Echo
En la Tabla 4.43 se muestra en la parte superior un ejemplo de la representación ASCII de
una trama de echo, mensaje 0800, en la parte inferior de la tabla se detalla el análisis de los
campos que conforman la estructura del mensaje.
Tabla 4.43 Ejemplo Trama 0800 Echo.
“ISO02110005608008222000000010000040000000000000003071149221260710307027BVBA3502156
00000000002”
Header = ISO021100055
MTI = 0800
BitMap = 82220000000100000400000000000000
Nombre del Campo
Dato obtenido (datos entre [] = longitud variable)
[7] Transmission date & time (n 10)
'0307115146'
[11] Settlement Date (n 6)
'814022'
[15] Time, Local transaction (n 4)
'0307'
[48] Additionaldata - Private (an ..999) '[027] BVBA3502156
00000000'
[70] Network Management I (a 3)
'002'
81
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.11.- Programación de Gateway ISO8583
Hemos visto a lo largo de este capitulo el proceso de análisis que nos llevo a establecer las
especificaciones del proyecto, basados en dichas especificaciones se genero el diseño de la
arquitectura lógica del sistema con un modelo de tres capas (vista, control y datos), vimos
también el proceso para definir e interpretar el formato de los mensajes de corresponsalía
bancaria ISO8583, hablemos ahora brevemente de la codificación del proyecto.
Como anteriormente se menciono Gateway ISO8583 requiere estar programado y compilado
usando como lenguaje de programación Visual Basic . Net, esto por solicitud y estándares
propios del Administrador de Corresponsales, en el desarrollo se codifico la arquitectura
diseñada en este reporte y se compilo dando por resultado un archivo ejecutable y tres
archivos de configuración ilustrados en la Tabla 4.44, un archivo utilizado para definir los
parámetros de configuración del sistema y dos utilizados para establecer los esquemas de
intercambio de transacciones con Tiendas X y Banco Y, no entraremos en el detalle de la
codificación de cada una de las clases del sistema ya el reporte se haría muy extenso, solo
mencionare que se codificaron en total 17 paquetes tres perteneciente a la capa de vista,
seis para la capa de control y ocho para la capa de datos podemos ver el resumen en la
Tabla 4.45.
Tabla 4.44 Archivos resultado de la compilación del sistema Gateway ISO8583.
Archivo
Descripción
GatewayISO8583.exe Ejecutable del aplicativo Gateway ISO8583
Config.ini
Archivo de configuración de parámetros del aplicativo .
ISODefinitionA.xml
Archivo XML de definición de mensajes con Tiendas X.
ISODefinitionB.xml
Archivo XML de definición de mensajes con Banco Y.
82
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Tabla 4.45 Paquetes codificados por capa.
Capa
Paquetes Codificados
Vista
Gateway ISO8583
Server.exceptions
Server.ssl
Control
Control.businessLogic
Control.businessLogic.loaders
Control.businessLogic.validators
Control.exceptions
Control.transform
Control.util
Datos
Data.domain
Data.persistence
Data.messages
Data.messages.exceptions
Data.messages.gbTripleDES
Data.messages.isoFactory
Data.exceptions
Data.util
83
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.12 .- Probando el funcionamiento de Gateway ISO8583
Después de haber realizado la codificación y compilación del sistema se realizaron las
pruebas, a continuación se enumeran las operaciones llevadas a cabo para comprobar el
correcto funcionamiento de
Gateway ISO8583 para recibir, validar y comunicar
transacciones de corresponsalía bancaria entre Tiendas X y Banco Y.
1. Pruebas de comunicación hacia Tiendas X y Banco Y.
2. Pruebas para validar recepción, contenido y estructura de los mensajes de Tiendas X.
3. Pruebas de envío de mensajes de Gateway ISO8583 hacia Banco Y.
4. Pruebas para validar recepción, contenido y estructura de los mensajes de Banco Y.
5. Pruebas de envío de mensajes de respuesta de Gateway ISO8583 hacia Tiendas X.
6. Pruebas masivas de envío y recepción de transacciones.
7. Pruebas en ambiente real.
Veamos ahora como se realizaron cada una de las pruebas anteriormente enlistadas.
84
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.12.1.- Pruebas de comunicación hacia Tiendas X y Banco Y
Para realizar las pruebas de comunicación comencemos por ver el diagrama de conectividad
entre entidades de la Figura 4.46, de lado izquierdo se muestra un bloque que representa a
los puntos de venta de Tiendas X, en dichos puntos de venta se generan las transacciones
de corresponsalía bancaria que posteriormente son enviadas al sistema central de
procesamiento de transacciones de Tiendas X el cual esta comunicado con Gateway
ISO8583 a través de una red virtual privada VPN 1, Gateway ISO8583 recibe y valida las
transacciones provenientes de Tiendas X y las envía al sistema autorizador de transacciones
de Banco Y comunicado por una segunda red virtual privada VPN 2.
Figura 4.46 Conectividad y flujo de información entre Tiendas X y Banco Y.
85
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Veamos ahora cuales fueron las pruebas que se realizaron para comprobar la comunicación
entre los aplicativos Gateway ISO8583 con los aplicativos de Tiendas X y Banco Y, tomando
en cuenta el previo establecimiento de los enlaces y VPN necesarias para la comunicación,
labor llevada a cabo por el área de infraestructura de la empresa, por dicho asunto
asumiremos desde un inicio la existencia de los medios necesarios y no entraremos en
detalle de cómo fueron establecidos, nos centraremos solo en las pruebas realizadas para
establecer la comunicación entre aplicaciones.
•
Pruebas de comunicación entre aplicativo Gateway ISO8583 y aplicativo de
Tiendas X : Para la realización de
estas pruebas se realizaron las siguientes
operaciones:
a. Iniciar el aplicativo Gateway ISO8583, estableciendo en la configuración de
este el numero de puerto de escucha que actuara como servidor para recibir
transacciones de Tiendas X.
b. Desde la ubicación en red del aplicativo de Tiendas X, realizar una conexión
por Telnet a la dirección IP y puerto en escucha expuesto por Gateway
ISO8583.
c. Iniciar el aplicativo de Tiendas X y establecer conexión con Gateway ISO8583.
Al ser el resultado de las tres operaciones anteriores positivo, podemos asegurar que
la conectividad con Tiendas X funciona de forma correcta.
86
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
•
Pruebas de comunicación entre aplicativo Gateway ISO8583 y aplicativo de
Banco Y : Para la realización de
estas pruebas se realizaron las siguientes
operaciones:
a. Iniciar el aplicativo Gateway ISO8583, estableciendo en la configuración de
este el numero de puerto y dirección IP del servidor de transacciones de Banco
Y.
b. Desde la ubicación de red local del aplicativo Gateway ISO8583, realizar una
conexión por Telnet a la dirección IP y puerto en escucha expuesto por
Banco Y.
c. Iniciar el aplicativo Gateway ISO8583 y establecer conexión con Banco Y.
Al ser el resultado de las tres operaciones anteriores positivo, podemos asumir que la
conectividad con Banco Y funciona de forma correcta.
4.12.2.- Pruebas para validar recepción, contenido y estructura de los
mensajes de Tiendas X
En estas pruebas se valido la recepción de la estructura correcta, el contenido y formato de
los campos del mensaje enviado por Tiendas X, para ello se realizaron las siguientes
operaciones:
•
Tiendas X realizara el envío de transacciones de Deposito, Reverso y Echo hacia
Gateway ISO8583.
87
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
•
Gateway ISO8583 al recibir mensajes de Tiendas X valida internamente la estructura
teniendo dos casos, el primero donde la transacción cumple con la estructura definida
y el segundo caso donde no cumple con la estructura, se probaron ambos casos para
validar la estructura de mensajes entrantes de Tiendas X así como el interprete de
transacciones de Gateway ISO8583, en la Tabla 4.47 se muestra un ejemplo para la
transacción de Deposito con la estructura correcta, en cambio en la Tabla 4.48 se
muestra una transacción con una estructura incompleta al no tener presente el campo
49.
Tabla 4.47 Transacción de deposito estructura completa.
“ISO02110005502003238840128A1800000000000000005400009261837241906011851000926092690
10212215579210000000386=0000000000005928CEN50FRDSS787932 Pitagoras 1234 Mexico DF
MX0276285027 00000000484”
Header = ISO021100055
MTI = 0200
BitMap = 3238840128A18000
Dato obtenido (datos entre [] = longitud
variable)
[3] Processing code (n 6)
'000000'
[4] Amount,transaction (n 12)
'000000054000'
[7] Transmission date & time (n 10)
'0926183724'
[11] Systems trace audit number (n 6)
'190601'
[12] Time, Local transaction (n 6)
'185100'
[13] Date, Local transaction (n 4)
'0926'
[17] Date,capture (n 4)
'0926'
[22] Point of service entry mode (n 3)
'901'
[32] Acquiring institution identification code (n ..11) '[02]12'
[35] Track2 data (z ..37)
'[21]5579210000000386=0000'
[37] Retrieval reference number (an 12)
'000000005928'
[41] Card acceptor terminal identification (ans 16) 'CEN50FRDSS787932'
[43] Card acceptor name/location (ans 40)
'Pitagoras 1234 Mexico DF MX'
[48] Additionaldata - Private (an ..999)
'[027] 6285027 00000000'
[49] Currency code, transaction (a 3)
'484'
Nombre del Campo
88
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Tabla 4.48 Transacción de deposito estructura incompleta.
“ISO02110005502003238840128A1800000000000000005400009261837241906011851000926092690
10212215579210000000386=0000000000005928CEN50FRDSS787932 Pitagoras 1234 Mexico DF
MX0276285027 00000000”
Header = ISO021100055
MTI = 0200
BitMap = 3238840128A18000
Dato obtenido (datos entre [] = longitud
variable)
[3] Processing code (n 6)
'000000'
[4] Amount,transaction (n 12)
'000000054000'
[7] Transmission date & time (n 10)
'0926183724'
[11] Systems trace audit number (n 6)
'190601'
[12] Time, Local transaction (n 6)
'185100'
[13] Date, Local transaction (n 4)
'0926'
[17] Date,capture (n 4)
'0926'
[22] Point of service entry mode (n 3)
'901'
[32] Acquiring institution identification code (n ..11) '[02]12'
[35] Track2 data (z ..37)
'[21]5579210000000386=0000'
[37] Retrieval reference number (an 12)
'000000005928'
[41] Card acceptor terminal identification (ans 16) 'CEN50FRDSS787932'
[43] Card acceptor name/location (ans 40)
'Pitagoras 1234 Mexico DF MX'
[48] Additionaldata - Private (an ..999)
'[027] 6285027 00000000'
Nombre del Campo
•
Validación de contenido y formato del mensaje, un mensaje requiere cumplir con el
formato establecido para cada uno de los campos, en las siguientes pruebas se
enviaron transacciones de Tiendas X a Gateway ISO8583 incluyendo errores en el
formato y contenido de los campos con la finalidad de corroborar que se estuviesen
realizando la validaciones adecuadas dentro de Gateway ISO8583, en la Tabla 4.49
vemos el ejemplo de una transacción de Deposito la cual presenta una estructura
completa, pero al observar el campo 4 de formato numérico el cual indica el monto de
la transacción este presenta un carácter no numérico, por lo cual la transacción será
rechazada, este tipo de pruebas se realizaron para cada uno de los campos.
89
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Tabla 4.49 Transacción de deposito tipo de dato incorrecto.
“ISO02110005502003238840128A1800000000$00000005400009261837241906011851000926092690
10212215579210000000386=0000000000005928CEN50FRDSS787932 Pitagoras 1234 Mexico DF
MX0276285027 00000000484”
Header = ISO021100055
MTI = 0200
BitMap = 3238840128A18000
Dato obtenido (datos entre [] = longitud
variable)
[3] Processing code (n 6)
'000000'
[4] Amount,transaction (n 12)
'$00000054000'
[7] Transmission date & time (n 10)
'0926183724'
[11] Systems trace audit number (n 6)
'190601'
[12] Time, Local transaction (n 6)
'185100'
[13] Date, Local transaction (n 4)
'0926'
[17] Date,capture (n 4)
'0926'
[22] Point of service entry mode (n 3)
'901'
[32] Acquiring institution identification code (n ..11) '[02]12'
[35] Track2 data (z ..37)
'[21]5579210000000386=0000'
[37] Retrieval reference number (an 12)
'000000005928'
[41] Card acceptor terminal identification (ans 16) 'CEN50FRDSS787932'
[43] Card acceptor name/location (ans 40)
'Pitagoras 1234 Mexico DF MX'
[48] Additionaldata - Private (an ..999)
'[027] 6285027 00000000'
[49] Currency code, transaction (a 3)
'484'
Nombre del Campo
4.12.3.- Pruebas de envío de mensajes de Gateway ISO8583 hacia
Banco Y
Anteriormente se valido la comunicación con Banco Y, ahora validaremos que Banco Y
reciba y entienda los mensajes enviados por Gateway ISO8583, para realizar dicha
operación se enviaron transacciones de Deposito y Reverso, en la configuración de Gateway
ISO8583 se establecieron los parámetros necesarios para la encripcion del mensaje,
probando con distintos valores para validar que Banco Y entiéndese solo mensajes
encriptados con los valores previamente establecidos por ambas instancias.
90
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.12.4.- Pruebas para validar recepción, contenido y estructura de
los mensajes de Banco Y
En estas pruebas se valido al igual que con Tiendas X la conformación de la estructura de
mensajes y contenido de los campos, para ello se enviaron transacciones de Deposito y
Reverso, en la Tabla 4.50 se muestra una transacción de Deposito con una estructura
completa, en la Tabla 4.51 en cambio vemos una transacción con una estructura incompleta
al no estar presente el campo 11, se realizaron varias pruebas para asegurar el buen
funcionamiento de Gateway ISO8583 validando todos los campos del mensaje.
Tabla 4.50 Transacción de deposito estructura completa.
“ISO02110005502003238840128A1800000000000000005400009261837241906011851000926092690
10212215579210000000386=0000000000005928CEN50FRDSS787932 Pitagoras 1234 Mexico DF
MX0276285027 000000004840D45A56B”
Header = ISO021100055
MTI = 0200
BitMap = 3238840128A18000
Dato obtenido (datos entre [] = longitud
variable)
[3] Processing code (n 6)
'000000'
[4] Amount,transaction (n 12)
'000000054000'
[7] Transmission date & time (n 10)
'0926183724'
[11] Systems trace audit number (n 6)
'190601'
[12] Time, Local transaction (n 6)
'185100'
[13] Date, Local transaction (n 4)
'0926'
[17] Date,capture (n 4)
'0926'
[22] Point of service entry mode (n 3)
'901'
[32] Acquiring institution identification code (n ..11) '[02]12'
[35] Track2 data (z ..37)
'[21]5579210000000386=0000'
[37] Retrieval reference number (an 12)
'000000005928'
[41] Card acceptor terminal identification (ans 16) 'CEN50FRDSS787932'
[43] Card acceptor name/location (ans 40)
'Pitagoras 1234 Mexico DF MX'
[48] Additionaldata - Private (an ..999)
'[027] 6285027 00000000'
[49] Currency code, transaction (a 3)
'484'
[68] Mesage Authentication Code (MAC) (ans 8)
0D45A56B
Nombre del Campo
91
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Tabla 4.51 Transacción de deposito estructura incompleta.
“ISO02110005502003238840128A1800000000000000005400009261837241851000926092690102122
15579210000000386=0000000000005928CEN50FRDSS787932 Pitagoras 1234 Mexico DF
MX0276285027 0000000048402A6C03F”
Header = ISO021100055
MTI = 0200
BitMap = 3238840128A18000
Dato obtenido (datos entre [] = longitud
variable)
[3] Processing code (n 6)
'000000'
[4] Amount,transaction (n 12)
'000000054000'
[7] Transmission date & time (n 10)
'0926183724'
[12] Time, Local transaction (n 6)
'185100'
[13] Date, Local transaction (n 4)
'0926'
[17] Date,capture (n 4)
'0926'
[22] Point of service entry mode (n 3)
'901'
[32] Acquiring institution identification code (n ..11) '[02]12'
[35] Track2 data (z ..37)
'[21]5579210000000386=0000'
[37] Retrieval reference number (an 12)
'000000005928'
[41] Card acceptor terminal identification (ans 16) 'CEN50FRDSS787932'
[43] Card acceptor name/location (ans 40)
'Pitagoras 1234 Mexico DF MX'
[48] Additionaldata - Private (an ..999)
'[027] 6285027 00000000'
[49] Currency code, transaction (a 3)
'484'
[68] Mesage Authentication Code (MAC) (ans 8)
02A6C03F
Nombre del Campo
•
Las respuestas recibidas de Banco Y se evaluaron por el interprete de
Gateway ISO8583 primeramente validando la estructura del mensaje como se
muestra en los ejemplos anteriores, posteriormente se evalúo que los datos
contenidos en los campos cumpliesen con los formatos requeridos, cerrando con esta
validación el flujo transaccional de Gateway ISO8583 a Banco Y.
92
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
•
Se realizaron pruebas para validar el contenido de los campos de las transacciones
de respuestas enviadas de Gateway ISO8583 hacia Banco Y así como en la
respuesta de este hacia Gateway ISO8583, la Tabla 4.52 muestra una transacción
con la estructura correcta pero el contenido del campo 4 no corresponde al formato
numérico requerido por el campo, se realizaron pruebas para validar los campos
sensibles de mensajes de entrada y salida.
Tabla 4.52 Transacción de deposito tipo de dato incorrecto.
“ISO02110005502003238840128A1800000000$00000005400009261837241906011851000926092690
10212215579210000000386=0000000000005928CEN50FRDSS787932 Pitagoras 1234 Mexico DF
MX0276285027 000000004843686C03F”
Header = ISO021100055
MTI = 0200
BitMap = 3238840128A18000
Dato obtenido (datos entre [] = longitud
variable)
[3] Processing code (n 6)
'000000'
[4] Amount,transaction (n 12)
'$00000054000'
[7] Transmission date & time (n 10)
'0926183724'
[11] Systems trace audit number (n 6)
'190601'
[12] Time, Local transaction (n 6)
'185100'
[13] Date, Local transaction (n 4)
'0926'
[17] Date,capture (n 4)
'0926'
[22] Point of service entry mode (n 3)
'901'
[32] Acquiring institution identification code (n ..11) '[02]12'
[35] Track2 data (z ..37)
'[21]5579210000000386=0000'
[37] Retrieval reference number (an 12)
'000000005928'
[41] Card acceptor terminal identification (ans 16) 'CEN50FRDSS787932'
[43] Card acceptor name/location (ans 40)
'Pitagoras 1234 Mexico DF MX'
[48] Additionaldata - Private (an ..999)
'[027] 6285027 00000000'
[49] Currency code, transaction (a 3)
'484'
[68] Mesage Authentication Code (MAC) (ans 8)
3686C03F
Nombre del Campo
93
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.12.5.- Pruebas de envío de mensajes de respuesta de Gateway
ISO8583 hacia Tiendas X
En estas pruebas se valido que la transacción de respuesta recibida de Banco Y se
transformara dentro de Gateway ISO8583 a una respuesta que cumpliese con el formato
indicado para ser enviado de regreso a Tiendas X, para realizar estas pruebas se enviaron
transacciones de Deposito y Reverso validando de lado de Tiendas X el mensaje de
respuesta originado por Banco Y concluyendo con estas pruebas el ciclo completo de una
transacción.
Dentro de estas pruebas se revisaron todos los procesos internos de almacenamiento y
tratamiento de datos de transacciones en Gateway ISO8583.
4.12.6.- Pruebas masivas de envío y recepción de transacciones
Concluidas las pruebas para validar la estructura y contenido de mensajes se realizaron
pruebas de envío masivo de transacciones, en estas pruebas Tiendas X tuvo la tarea de
lanzar grandes cantidades de transacciones de Deposito y Reverso con la finalidad de probar
el sistema en un ambiente parecido al real, el resultado de las pruebas fue exitoso teniendo
Gateway ISO8583 una capacidad de procesar hasta 1000 transacciones en un segundo.
4.12.7.- Pruebas en ambiente real.
Para finalizar las prueba se realizaron pruebas en un ambiente productivo real, en este
ejemplo veremos el flujo transaccional a detalle para las operaciones de Depósito y Reverso
dentro de las instalaciones de Tiendas X.
94
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.12.7.1.- Ejemplo de una transacción de Depósito
En este ejemplo se muestra el flujo transaccional de una petición de Depósito generada el
día 17/06/2014 a las 11:04:30:430 desde una sucursal ubicada en la ciudad de Guadalajara
en la calle de Pilares 3758, por un monto de 700 pesos al número de tarjeta
8915644845454545=0000.
En la Figura 4.53 se ilustra el flujo del mensaje de Depósito, a continuación se describen
cada uno de los paso del flujo.
Figura 4.53 Flujo Depósito.
Paso 1; Tiendas X genera en un punto de venta un mensaje 0200, este es enviado a
Gateway ISO8583 para su procesamiento, el detalle del mensaje se puede ver en la
Tabla 4.54.
95
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Tabla 4.54 Mensaje de Depósito de Tiendas X a Gateway ISO8583.
ISO02110005502003238840128A18002280000000000070000061711034642014111030006170617011
048536218915644845454545=0000000769944781TDF63KCDG
MX0276448310
Pilares 3758
Guadalajara GD
00000000484024030101B0200VAFAAR8303306
Request Message Length : 240
Request Message Header : ISO021100055
Request Message Type : 0200
Request Field [3] = 280000
Request Field [4] = 000000070000
Request Field [7] = 0617110346
Request Field [11] = 420141
Request Field [12] = 110300
Request Field [13] = 0617
Request Field [17] = 0617
Request Field [22] = 011
Request Field [32] = 8536
Request Field [35] = 8915644845454545=0000
Request Field [37] = 000769944781
Request Field [41] = TDF63KCDG
Request Field [43] = Pilares 3758
Request Field [48] = 6448310
Guadalajara GD MX
00000000
Request Field [49] = 484
Request Field [63] = 030101B0200VAFAAR8303306
Paso 2; Gateway ISO8583 después de haber validado el mensaje enviado por
Tiendas X en el paso 1, genera y envía un mensaje 0200 a Banco Y para su
procesamiento, el detalle del mensaje se puede ver en la Tabla 4.55.
96
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Tabla 4.55 Mensaje de Depósito de Gateway ISO8583 a Banco Y.
ISO02110005502003238840128A18003280000000000070000061711034642014111030006170617011
048536218915644845454545=0000000769944781TDF63KCDG
MX0276448310
Pilares 3758
Guadalajara GD
00000000484024030101B0200VAFAAR83033063BA6D1D0
Request Message Length : 0
Request Message Header : ISO021100055
Request Message Type : 0200
Request Field [3] = 280000
Request Field [4] = 000000070000
Request Field [7] = 0617110346
Request Field [11] = 420141
Request Field [12] = 110300
Request Field [13] = 0617
Request Field [17] = 0617
Request Field [22] = 011
Request Field [32] = 8536
Request Field [35] = 8915644845454545=0000
Request Field [37] = 000769944781
Request Field [41] = TDF63KCDG
Request Field [43] = Pilares 3758
Request Field [48] = 6448310
Guadalajara GD MX
00000000
Request Field [49] = 484
Request Field [63] = 030101B0200VAFAAR8303306
Request Field [64] = 3BA6D1D0
Paso 3; Banco Y
después de haber validado el mensaje enviado por
Gateway ISO8583 en el paso 2, genera y envía un mensaje de respuesta 0210 a
Gateway ISO8583 para su procesamiento, el detalle del mensaje se puede ver en la
Tabla 4.56.
97
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Tabla 4.56 Mensaje de respuesta de Depósito de Banco Y a Gateway ISO8583.
ISO0211000550210323A84002E818003280000000000070000061711034642014111030006170617061
7011218915644845454545=000000076994478100008100TDF63KCDG
0276448310
00000000484024030101B0200VAFAAR8303306479CA955
Response Message Length : 215
Response Message Header : ISO021100055
Response Message Type : 0210
Response Field [3] = 280000
Response Field [4] = 000000070000
Response Field [7] = 0617110346
Response Field [11] = 420141
Response Field [12] = 110300
Response Field [13] = 0617
Response Field [15] = 0617
Response Field [17] = 0617
Response Field [22] = 011
Response Field [35] = 8915644845454545=0000
Response Field [37] = 000769944781
Response Field [38] = 000081
Response Field [39] = 00
Response Field [41] = TDF63KCDG
Response Field [48] = 6448310
00000000
Response Field [49] = 484
Response Field [63] = 030101B0200VAFAAR8303306
Response Field [64] = 479CA955
Paso 4; Gateway ISO8583 después de haber validado el mensaje de respuesta
enviado por Banco Y en el paso 3, genera y envía un mensaje de respuesta 0210 a
Tiendas X para concluir con el flujo del mensaje, el detalle del mensaje se puede ver
en la Tabla 4.57.
98
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Tabla 4.57 Mensaje de respuesta de Depósito de Gateway ISO8583 a Tiendas X.
ISO0211000550210323A84002E818002280000000000070000061711034642014111030006170617061
7011218915644845454545=000000076994478100008100TDF63KCDG
00000000484024030101B0200VAFAAR8303306
Response Message Length : 0
Response Message Header : ISO021100055
Response Message Type : 0210
Response Field [3] = 280000
Response Field [4] = 000000070000
Response Field [7] = 0617110346
Response Field [11] = 420141
Response Field [12] = 110300
Response Field [13] = 0617
Response Field [15] = 0617
Response Field [17] = 0617
Response Field [22] = 011
Response Field [35] = 8915644845454545=0000
Response Field [37] = 000769944781
Response Field [38] = 000081
Response Field [39] = 00
Response Field [41] = TDF63KCDG
Response Field [48] = 6448310
00000000
Response Field [49] = 484
Response Field [63] = 030101B0200VAFAAR8303306
99
0276448310
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
4.12.7.2.- Ejemplo de una transacción de Reverso
En este ejemplo se muestra el flujo transaccional de una petición de reverso generada el día
17/06/2014 a las 11:04:30:4300 desde una sucursal ubicada en la ciudad de Guadalajara en
la calle de Pilares 3758, por un monto de 560 pesos al número de tarjeta
8915644845454545=0000.
En la Figura 4.58 se ilustra el flujo del mensaje de reverso, a continuación se describen cada
uno de los paso del flujo.
Figura 4.58 Flujo Reverso
100
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Paso 1; Tiendas X genera en un punto de venta un mensaje de reverso 0420, este es
enviado a Gateway ISO8583 para su procesamiento, el detalle del mensaje se puede ver
en la Tabla 4.59.
Tabla 4.59 Mensaje de Reverso de Tiendas X a Gateway ISO8583.
ISO0211000550420B23A84012EA18002000000400000000028000000000005600006171104024203221
10300061706170617011045215218915644845454545=000000076994449000000068TDF63KCDG
Pilares 3758
Guadalajara GD MX0276582316
00000000484024030101B0200GOESMA741212502000007699444900617110300000617
Request Message Length : 310
Request Message Header : ISO021100055
Request Message Type : 0420
Request Field [3] = 280000
Request Field [4] = 000000056000
Request Field [7] = 0617110402
Request Field [11] = 420322
Request Field [12] = 110300
Request Field [13] = 0617
Request Field [15] = 0617
Request Field [17] = 0617
Request Field [22] = 011
Request Field [32] = 5215
Request Field [35] = 8915644845454545=0000
Request Field [37] = 000769944490
Request Field [38] = 000000
Request Field [39] = 68
Request Field [41] = TDF63KCDG
Request Field [43] = Pilares 3758
Request Field [48] = 6582316
Guadalajara GD MX
00000000
Request Field [49] = 484
Request Field [63] = 030101B0200GOESMA7412125
Request Field [90] = 02000007699444900617110300000617
101
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Paso 2; Gateway ISO8583 después de haber validado el mensaje enviado por
Tiendas X en el paso 1, genera y envía un mensaje de reverso 0420 a Banco Y para
su procesamiento, el detalle del mensaje se puede ver en la Tabla 4.60.
Tabla 4.60 Mensaje de Reverso de Gateway ISO8583 a Banco Y.
ISO0211000550420B23A84012EA18002000000400000000128000000000005600006171104024203221103000617
06170617011045215218915644845454545=000000076994449000000068TDF63KCDG
Pilares 3758
Guadalajara GD MX0276582316
00000000484024030101B0200GOESMA741212502000007699444900617110300000617
Request Message Length : 0
Request Message Header : ISO021100055
Request Message Type : 0420
Request Field [3] = 280000
Request Field [4] = 000000056000
Request Field [7] = 0617110402
Request Field [11] = 420322
Request Field [12] = 110300
Request Field [13] = 0617
Request Field [15] = 0617
Request Field [17] = 0617
Request Field [22] = 011
Request Field [32] = 5215
Request Field [35] = 8915644845454545=0000
Request Field [37] = 000769944490
Request Field [38] = 000000
Request Field [39] = 68
Request Field [41] = TDF63KCDG
Request Field [43] = Pilares 3758
Request Field [48] = 6582316
Guadalajara GD MX
00000000
Request Field [49] = 484
Request Field [63] = 030101B0200GOESMA7412125
Request Field [90] = 02000007699444900617110300000617
Request Field [128] = A306A446
102
A306A446
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Paso 3; Banco Y
después de haber validado el mensaje enviado por
Gateway ISO8583 en el paso 2, genera y envía un mensaje de respuesta 0430 a
Gateway ISO8583 para su procesamiento, el detalle del mensaje se puede ver en la
Tabla 4.61.
Tabla 4.61 Mensaje de respuesta de Reverso de Banco Y a Gateway ISO8583.
ISO0211000550430B22284002E808002000000400000000128000000000005600006171104024203220
6170617011218915644845454545=000000076994449000000018TDF63KCDG
484024030101B0200GOESMA741212502000007699444900617110300000617
Response Message Length : 233
Response Message Header : ISO021100055
Response Message Type : 0430
Response Field [3] = 280000
Response Field [4] = 000000056000
Response Field [7] = 0617110402
Response Field [11] = 420322
Response Field [15] = 0617
Response Field [17] = 0617
Response Field [22] = 011
Response Field [35] = 8915644845454545=0000
Response Field [37] = 000769944490
Response Field [38] = 000000
Response Field [39] = 18
Response Field [41] = TDF63KCDG
Response Field [49] = 484
Response Field [63] = 030101B0200GOESMA7412125
Response Field [90] = 02000007699444900617110300000617
Response Field [128] = 6F82CAC8
103
6F82CAC8
Proceso de desarrollo de Gateway ISO8583 corresponsal bancario
Paso 4; Gateway ISO8583 después de haber validado el mensaje de respuesta
enviado por Banco Y en el paso 3, genera y envía un mensaje de respuesta 0210 a
Tiendas X para concluir con el flujo del mensaje, el detalle del mensaje se puede ver
en la Tabla 4.62.
Tabla 4.62 Mensaje de respuesta de Reverso de Gateway ISO8583 a Tiendas X.
ISO0211000550430B22284002E808002000000400000000028000000000005600006171104024203220
6170617011218915644845454545=000000076994449000000018TDF63KCDG
484024030101B0200GOESMA741212502000007699444900617110300000617
Response Message Length : 0
Response Message Header : ISO021100055
Response Message Type : 0430
Response Field [3] = 280000
Response Field [4] = 000000056000
Response Field [7] = 0617110402
Response Field [11] = 420322
Response Field [15] = 0617
Response Field [17] = 0617
Response Field [22] = 011
Response Field [35] = 8915644845454545=0000
Response Field [37] = 000769944490
Response Field [38] = 000000
Response Field [39] = 18
Response Field [41] = TDF63KCDG
Response Field [49] = 484
Response Field [63] = 030101B0200GOESMA7412125
Response Field [90] = 02000007699444900617110300000617
104
Conclusiones
Conclusiones
Después de asegurar el correcto funcionamiento de Gateway ISO8583 tras haber pasado por
un estricto periodo de pruebas en un ambiente real controlado, el siguiente paso fue probarlo
en un ambiente productivo real, haciendo uso de dos sucursales de Tiendas X por un periodo
de un mes, al concluir de forma satisfactoria las pruebas en las dos sucursales se lanzo la
apertura del sistema a todas las sucursales de Tiendas X a nivel nacional, funcionando en la
actualidad desde hace dos años, siendo un éxito para todas las partes inmersas en el
proceso de intercambio de información de corresponsalía bancaria.
Durante los dos años de operación el sistema no ha presentado problemas en el
funcionamiento continuo, el performance ha sido tan bueno que actualmente se usa como
proyecto base para desarrollar otras interfaces de intercambio de transacciones bancarias
con formato ISO8583, siendo esto una muestra del alcance logrado al realizar previamente el
análisis de las necesidades del sistema, para generar a partir de estas un sistema modular
con capacidad de ser configurable para recibir cualquier tipo de parametrización de
transacciones ISO8583.
Como conclusiones puedo mencionar nuevamente la importancia que tiene realizar el
análisis previo de los componentes que intervienen en el proceso de comunicación entre una
o mas entidades, la labor de un sistema de comunicaciones optimo esta siempre orientada a
reducir el tiempo de interpretación de información intercambiada entre un transmisor y un
receptor, por este motivo en la aplicación de la informática al intercambio de transacciones
electrónicas es de suma importancia la generación de modelos en donde la labor de
interpretación de información este claramente sustentada tomando como base la codificación
de la información en su forma primaria y sintética con la cual es posible generar interpretes
de datos dinámicos, parametrizables para ser modificados en la marcha sin interferir de
forma grabe con la operación o ser reutilizados como abstracciones.
En la actualidad los sistemas electrónicos de comunicación están presentes en la mayor
parte de nuestra interrelación con el otro, como seres sociales la información que
consumimos a partir de los sentidos juega un papel muy importante, como en cualquier
sistema de comunicación la información es internamente procesada e interpretada
moldeando de forma dinámica formando el sistema operativo personal que nos permite
intereactuar en una realidad sintetizada, por esta razón me pregunto como Ingeniero en
Comunicaciones y Electrónica ¿Tiene realmente un fin necesario para la vida toda esta gran
infraestructura de comunicaciones que estamos creado o solo somos esclavos inconcientes
de nuestros propios medios de control?
105
Bibliografía
Bibliografía
•
Comisión Nacional Bancaria y de Valores,
CMBV, Modelos de Negocio para la
Inclusión Financiera. Mexico 2010.
•
Booch,
Grady. Object-Oriented
Analysis
and
Design. Second
Edition.
Benjamin/Cummings, Redwood: 1994.
• Kruchten, Philippe. "Architectural Blueprints--The 4+1 View Model of Software
Architecture". IEEE Software, Institute of Electrical and Electronics Engineers.
November 1995.
•
Larman, Craig. UML y Patrones, Introducción al análisis y diseño orientado a
objetos. México: Prentice Hall, 1999.
•
Jean Baudrillard, El sistema de los objetos. Siglo XXI Editores. Decimoctava edición
en español. México 2004.
•
ISO8583, Wikipedia Español, http://es.wikipedia.org/wiki/ISO_8583
•
ISO8583, Wikipedia Ingles, http://en.wikipedia.org/wiki/ISO_8583
• www.codeproject.com/Articles/100084/Introduction-to-ISO
106