PUC / PRICE Manual Redsys de Integración a EMV v 5.5...ademdum “Control de Clave CA En PUC adaptación a EMV V5.0” emitido conjuntamente con reléase 5.0 de Especificaciones PUC

PUC / PRICE

Manual Redsys de Integración a EMV v 5.5.6

http://gesdoc.bancsabadell.com/sites/ic/logotipos/LogotiposMarcas/Marcas%20grupo/Marcas%20comerciales%20red/Sabadell/BSabadell_POS_BN.jpg

ESPECIFICACIONES TÉCNICAS

Protocolo Unificado de Comercios (PUC). Adaptación a EMV

Fecha abril 2019

Página: 2 de 203

ESP-TEC-PUC

Versión: 5.5.6

Histórico de Revisiones

Revisión Fecha de

Revisión

Razón del Cambio Estado Distribución

00.01 21.09.06 Incorporación de las modificaciones asociadas a la aplicación de la

Criptografía de Datos de Tarjeta

Draft Grupo Técnico

00.02 06.03.07 Incorporación del tratamiento del indicador Debito/Crédito Corrección de erratas


00.03 19.04.07 ▪ Indicación de la prohibición de almacenar información sensible de las tarjetas (punto 2.1)

▪ Concreción de datos mínimos obligatorios a imprimir en recibos (punto 2.6)

▪ Adaptación de la ci nta de descuadres a criterios de cifrado de datos de tarjeta y corrección de errores tipográficos (anexo G)


00.04 01.11.07 • Gestión de Seguridad en Modo No Atendido. Indicación de requerimientos de seguridad en modo No Atendido en Características Generales (2.1), Arquitectura (2.2), como afecta al proceso de entrada del PIN (2.11) y su descripción en Anexo H.

• Recibos de Venta (2.5.1). Como indicar, cuando es requerido, la no necesidad de firma

• Indicación de Obligatoriedad de Cierre gestionado por HCP en Escenario 1 de PCI-DSS

• Indicación de la posibilidad de conexión vía IP en el apartado de Características Generales (2.1), capitulo 3 y descripción de los requerimientos en Anexo I


00.05 16.02.09 • Se genera Versión 4.1 que incorpora la corrección de erratas detectada

en la versión anterior y además se elimina la Fecha de Caducidad en Recibos


00.06 25.05.11 • Aclaración del proceso y envío de los 2º Criptogramas en caso de Anulación

• Incorporación de nuevo Código en el campo P-39

• Modificación del campo P-48/Cod.16 para incorporar nuevos campos

• Ampliación del envío del campo P-48/Cod37 a los mensajes 1230

• Creación de un nuevo campo P-48/Cod38 para el envío Cifrado de los

Datos de Tarjeta obtenidos mediante Entrada Manual • Incorporación de la Tecnología Contactless

• Incorporación del valor “401” de Identificador de Proceso en el Código 14 del Bit 72 en proceso de Renovación de Claves

• Incorporación del P-48/Cod16 en mensaje 1600 para versiones PUP iguales o superiores a 1.6.0

• Incorporar tratamiento de doble clave (CA-CI) en carga inicial con claves

TDES • Incorporaciones de nueva información a incluir en recibos


00.07 01.03.13 • Se incorpora a este documento de especificaciones el documento

ademdum “Control de Clave CA En PUC adaptación a EMV V5.0” emitido conjuntamente con reléase 5.0 de Especificaciones PUC. (P-72. Cod.11)

• Se posibilita operar con tarjetas que requieren la utilización de PIN de longitud superior a “4”. P-48, subcampo 39 “Longitud del PIN Tecleado” y P-22, bit 12

• Se incorporan en campo P-22 nuevos valores para tarjetas V.me y

movile contactless • Se incorporan el campo P-48, los subcampos:

• Dato de Autenticación del Titular CAVV

• XID. Dato adicional de Autenticación del Titular

• UCAF. Universal Cardholder Authentication

• Código de Razón de Solicitud de Autenticación adicional en V.me

• Incorporación del Código 40 en P-48 "Referencia de Operación"

• Modificación del Anexo G para incluir opción de envío de la "Referencia de Operación

• Actuali zación de las referencias a Redsys y CecaBank

• Corrección de erratas


00.08 28.04.15 Nueva versión PUC 5.2. que incluye:

• Nuevos valores posición 2 del P22: U (seguro Visa), X (seguro Master)

• Nuevos valores posición 4 del P22: M (MPOS)

• Nuevos valores posición 7 P22: 1 (manual), K (móvil banda)

• Nuevos valores posición 8 P22: U(ecommerce 3D secure), Z(PUCE)

• Obligatoriedad del campo P48.16

• Aclaración de longitud en el campo P48.38 • Cambio subcampo P62.30 por P62.06

Draff Grupo Técnico



Fecha abril 2019

Página: 3 de 203

ESP-TEC-PUC

Versión: 5.5.6

• Obligatoriedad campo S72 en mensajes 1600

• Comentarios en ANEXO H sobre los códigos usados

• Aclaraciones en códigos IND del campo S72-11 y S72-13 • Inclusión ANEXO J con la tabla de conversión caracteres ascii-ebcdic

00.09 13.11.15 Nueva versión PUC 5,3 que incluye la posibilidad de gestión de PIN con un HE / Proveedor de servicio.


• Inclusión etiqueta 84 de EMV (Datos del AID)

• Operativa de Devoluciones de forma online, mediante mensajes de petición 1200

• Tratamiento de preautorizaciones

• Adaptación AFD (Automated Fuel Dispenser), terminales no

atendidos con preautorizaciones parciales


• Operativa AVS de verificación de tarjeta (Pago 0 euros)

• Pagos relacionados con la operación previa AVS de verificación de tarjeta

00.12 14.03.18 Nueva versión PUC 5.5.1 En la operativa AVS, indicar que es obligatorio enviar:

• bien el campo P48-11 (CVC2 o CVV2) y el campo P-14 (Fecha de caducidad)

• o bien el P48.38 (PAN+Fecha caduc+CVV2 cifrados)

00.13 08.10.18 Nuevo valor 195 en campo P39 (repita con contactos o necesaria autenticación)

00.14 22.03.19 Incorporación exenciones PSD2 en campo 34; Nuevo valor 196 en campo P39 para solicitar PIN. Operativa de credenciales en archivo P48.52

00.15 22.04.19 Versión 5.5.4: Incorporación campo P48.25, datos 3DS 2.x

00.16 30.04.19 Versión 5.5.6: Incorporación P48.61 datos 3DS 2.x

P48.58 PAR P48.22 marca de mismo ATC de la operación anterior

P34. Nueva exención por autenticación delegada en comercio P48.18 Machi ng data para operativa PUCE.



Fecha abril 2019

Página: 2 de 203

ESP-TEC-PUC

Versión: 5.5.6

Índice

1. INTRODUCCIÓN 7

1.1 Propósito y Alcance ..................................................................................................................................... 8 1.2 Estructura ................................................................................................................................................ 9 1.3 Referencias ........................................................................................................................................... 10

2. VISIÓN GENERAL 11

2.1 Características Generales ................................................................................................................... 12 2.2 Arquitectura EMV: PIN/Pad-Terminal-HE ........................................................................................... 14 2.3 Requerimientos del Terminal Punto de Venta con capacidad EMV................................................ 15 2.3.1 Requisitos de Seguridad del HE/Proveedores de servicio .............................................................. 17 2.4 Interfaz de Usuario en Terminales con capacidad EMV ................................................................... 18 2.5 Datos a incluir en el Recibo impreso ................................................................................................. 20 2.6 Operaciones soportadas en el Terminal ............................................................................................ 22 2.7 Autorización de Transacciones de Venta .......................................................................................... 24 2.8 Cierre y Conciliación ............................................................................................................................ 25 2.9 Gestión de Lista Negra ........................................................................................................................ 26 2.10 Envío de Criptogramas EMV ............................................................................................................... 27 2.11 Seguridad .............................................................................................................................................. 28

3. NIVEL DE RED 29

3.1 Introducción .......................................................................................................................................... 30 3.2 Descripción del Entorno ...................................................................................................................... 30 3.3 Descripción del Paquete de Llamada ................................................................................................. 30 3.4 Establecimiento de Conexión ............................................................................................................. 31 3.5 Interrupción y Recuperación de Enlace ............................................................................................ 31 3.6 Procedimiento de Respaldo ................................................................................................................ 32 3.7 Reglas de Presentación ....................................................................................................................... 32

4. NIVEL DE APLICACIÓN. DESCRIPCIÓN GENERAL 33

4.1 Introducción .......................................................................................................................................... 34 4.2 Definiciones .......................................................................................................................................... 34 4.3 Estructura de Mensajes de Aplicación .............................................................................................. 36

5. NIVEL DE APLICACIÓN. DEFINICIÓN DE MENSAJES 43

5.1 Introducción .......................................................................................................................................... 44 5.2 Tratamiento de preautorizaciones ...................................................................................................... 45 5.3 Tratamiento AFD ........................................................................................................................................ 45 5.4 Tratamiento AVS. Operativa de verificación tarjeta (0 Euros) ......................................................... 46 5.5 Tratamiento de Credenciales en Archivo .............................................................................................. 46 5.6 Definición de Mensajes de Petición ................................................................................................... 47 5.7 Definición de Mensajes Contables ..................................................................................................... 50 5.8 Definición de Mensajes de Actualización de Ficheros .................................................................... 58 5.9 Definición de Mensajes de Anulación Automática ........................................................................... 62 5.10 Definición de Mensajes de Conciliación ............................................................................................ 66 5.11 Definición de Mensajes Administrativos ........................................................................................... 70 5.12 Definición de Mensajes de Control de Dialogo ................................................................................. 76

6. NIVEL DE APLICACIÓN. DEFINICIÓN DE PROCESOS 84

6.1 Transacción de Sistema ...................................................................................................................... 85 6.2 Temporizadores (Time-Out) ................................................................................................................ 86 6.3 Reconocimiento y Validación de Mensajes ....................................................................................... 87 6.4 Descripción de la Transferencia de Datos ........................................................................................ 88



Fecha abril 2019

Página: 3 de 203

ESP-TEC-PUC

Versión: 5.5.6

6.5 Descripción del Procedimiento de Notificación de Mensajes no Reconocibles ........................... 95 6.6 Descripción del Procedimiento de Solicitud de Lista Negra ........................................................... 96 6.7 Descripción del Test del Dialogo ............................................................................................................ 97 6.8 Descripción de la Suspensión/Reanudación del Dialogo ................................................................ 98 6.9 Diagrama de Estados de Dialogo En la Aplicación del HE, cuando exista Enlace Permanente 101

7. DICCIONARIO DE ELEMENTOS DE DATOS 102

7.1 Identificador de Tipo de Mensaje ..................................................................................................... 104 7.2 Mapa de Bits Primario ....................................................................................................................... 104 7.3 Extensión del Mapa de Bits (P-1) ...................................................................................................... 104 7.4 PAN, Número de Tarjeta (P-2) ........................................................................................................... 105 7.5 Código de Proceso (P-3).................................................................................................................... 105 7.6 Importe de la Transacción (P-4) ........................................................................................................ 106 7.7 Número de Identificación de Transacción (P-11) ............................................................................ 106 7.8 Fecha y Hora Local de Transacción (P-12) ...................................................................................... 107 7.9 Fecha de Caducidad (P-14) ............................................................................................................... 107 7.10 Datos del Punto de Servicio (P-22) ................................................................................................... 108 7.11 Número de Secuencia de la Tarjeta (P-23) ...................................................................................... 110 7.12 Código de Función (P-24) .................................................................................................................. 110 7.13 Código de Razón de Mensaje (P-25) ................................................................................................ 111 7.14 Fecha de Conciliación (P-28) ............................................................................................................ 111 7.15 Número de Conciliación (P-29) ......................................................................................................... 112 7.16 Importe Original de la Transacción (P-30) ....................................................................................... 113 7.17 Código de Identificación de Adquirente (P-32) ............................................................................... 114 7.18 Nuevo campo P34 Datos de comercio electrónico ......................................................................... 115 7.19 Datos de Pista 2 (P-35) ...................................................................................................................... 119 7.20 Número de Referencia (P-37) ............................................................................................................ 119 7.21 Código de Autorización (P-38) .......................................................................................................... 120 7.22 Código de Acción (P-39) .................................................................................................................... 120 7.23 Identificación del Terminal (P-41) ..................................................................................................... 122 7.24 Identificación del Establecimiento (P-42) ........................................................................................ 122 7.25 Datos Adicionales de la Respuesta (P-44) ....................................................................................... 122 7.26 Datos Privados Adicionales (P-48) ................................................................................................... 123 7.27 Bloque de PIN (P-52) .......................................................................................................................... 140 7.28 Información Control y Seguridad (P-53) .......................................................................................... 140 7.29 Datos asociados al Chip EMV (P-55) ................................................................................................ 141 7.30 Elemento de Datos Adicionales (P-56) ............................................................................................ 151 7.31 Datos Privados Adicionales 2 (P-62) ................................................................................................ 152 7.32 Código de Autentificación del Mensaje (P-64/S-128) ..................................................................... 154 7.33 Registro de Datos (S-72) ................................................................................................................... 155 7.34 Abonos, Número (S-74) ...................................................................................................................... 159 7.35 Abonos, Número de Anulaciones (S-75) .......................................................................................... 159 7.36 Cargos, Número (S-76) ...................................................................................................................... 159 7.37 Cargos, Número de Anulaciones (S-77) .......................................................................................... 160 7.38 Abonos, Importe (S-86) ...................................................................................................................... 160 7.39 Abonos, Importe de Anulaciones (S-87)........................................................................................... 160 7.40 Cargos, Importe (S-88) ....................................................................................................................... 161 7.41 Cargos, Importe de Anulaciones (S-89) ........................................................................................... 161 7.42 Código de Identificación Destino (S-93) .......................................................................................... 162 7.43 Código de Identificación Origen (S-94) ............................................................................................ 163 7.44 Importe Total (S-97) ............................................................................................................................ 163 7.45 Nombre del Fichero (S-101) ............................................................................................................... 164

8. ANEXOS 165

8.1 Anexo A. Mecanismos de Seguridad del MAC ................................................................................ 166 8.2 Anexo B. Actualización de Claves Públicas RSA de CA (Emisor) ................................................ 168 8.3 Anexo C. Actualización de Parámetros EMV................................................................................... 169 8.4 Anexo D. Formatos y Validaciones a realizar con Tarjetas de Banda Magnética ....................... 171 8.5 Anexo E. Aplicación de Fallback ...................................................................................................... 175 8.6 Anexo F. Formato del fichero de Tarjeta en Lista Negra ............................................................... 179 8.7 Anexo G. Formato del fichero de Operaciones que han originado Descuadre ........................... 181



Fecha abril 2019

Página: 2 de 203

ESP-TEC-PUC

Versión: 5.5.6

8.8 Anexo H. Mecanismos de Seguridad para PIN On-Line en ePOS operando en modo No Atendido .............................................................................................................................................. 184

8.9 Anexo I. Conectividad IP ........................................................................................................................ 196 8.10 Anexo J. Tabla conversión ASCII-EBCDIC ...................................................................................... 203



Fecha abril 2019

Página: 3 de 203

ESP-TEC-PUC

Versión: 5.5.6

1. Introducción



Fecha abril 2019

Página: 2 de 203

ESP-TEC-PUC

Versión: 5.5.6

1.1 Propósito y Alcance El propósito de esta nueva versión de documento es ofrecer toda la información necesaria para que un Establecimiento/Negocio/Proveedor de Servicio, con toda la infraestructura Hw y Sw adaptada a EMV, pueda conectar su Host a los Centros Procesadores (REDSYS y CecaBank), con el fin de intercambiar mensajes originados, directa o indirectamente, por la utilización de la Tarjeta (de Banda Magnética o EMV) operando en modo contactos o contactless como medio de pago.

Esta nueva versión de documento es válida para la conexión de Establecimientos/Negocios/Proveedores de servicio que realicen operaciones de Venta de bienes o servicios y dispongan de toda la infraestructura Hw y Sw requerida para la aceptación y tratamiento de tarjetas Chip EMV y/o tarjetas de Banda Magnética (Lectura de Banda o Entrada Manual, esta última opción solo posible en ePOS funcionando en modo Atendido).

Se contempla en dicha conexión dos entornos:

a) Conexión de Grandes Clientes. Definido por:

• Elevado número de transacciones • Líneas de comunicaciones con enlaces permanentes

• Posibilidad de coexistir en la misma sesión diferentes Establecimientos (Conjunto de Terminales), con

diferentes códigos de actividad. Cierre a nivel de Negocio / Proveedor de Servicio (Conjunto de Establecimientos)

• Posibilidad de abono del importe neto de las operaciones a nivel de Establecimiento, Sector de Actividad, Negocio, Proveedor de servicio, Tipo de Tarjeta (Identificativo de Cuadre), etc.

b) Conexión de Pequeño Comercio. Queda definido por:

• Líneas de comunicación con enlaces conmutados

• Un único Establecimiento por sesión

• Posibilidad de abono del importe neto de las operaciones a nivel de Establecimiento o Tipo de Tarjeta (Identificativo de Cuadre)



Fecha abril 2019

Página: 3 de 203

ESP-TEC-PUC

Versión: 5.5.6

1.2 Estructura El documento está formado por CAPÍTULOS Y ANEXOS cuyo contenido describimos brevemente:

CAPITULO-1 Presenta el propósito, alcance y estructura del documento

CAPITULO-2 Ofrece una visión general de todo el proyecto, destacándose las características operativas más significativas

CAPITULO-3 Describe las normas y procedimientos necesarios para la conexión de los Hosts. CAPITULO-4 Describe la estructura de los mensajes de APLICACIÓN, realizando una definición de conceptos

CAPITULO-5 Define detalladamente los mensajes de APLICACIÓN.

CAPITULO-6 Describe las características de diálogo entre APLICACIONES.

CAPITULO-7 Contiene una DICCIONARIO DE DATOS donde se definen y comentan cada uno de los datos involucrados en el diálogo.

ANEXO-A Describe la gestión de claves y los procedimientos de cifrado utilizados en el proceso de obtención

del Código de Autentificación de Mensajes

ANEXO-B Describe la gestión de claves públicas de Emisor a realizar en el HE

ANEXO-C Describe el procedimiento de actualización de Parámetros EMV

ANEXO-D Proporciona los formatos de Pista 2 de los distintos tipos de tarjetas de Banda Magnética admitidas y describe como reconocer y validar cada uno de ellos. Se incluye la descripción del método de verificación de dígito de control del PAN.

ANEXO-E Aplicación de Fallback

ANEXO-F Detalla el formato de la cinta a intercambiar para sustituir mensualmente el archivo de Listas Negras

ANEXO-G Contiene el formato de la cinta de operaciones que el HE enviara al HCP en caso de descuadre.

ANEXO-H Contiene la información necesaria para realizar la gestión de seguridad requerida en aquellos HE con ePOS que operen en modo No Atendido

ANEXO-I Describe los requerimientos a nivel de red para utilizar conectividad IP.

ANEXO-J Tabla conversión ASCII-EBCDIC



Fecha abril 2019

Página: 2 de 203

ESP-TEC-PUC

Versión: 5.5.6

1.3 Referencias

EMV 2000 Versión 4.0 (12/00)

Integrated Circuit Card. Specifications for Payment System Book's 1, 2, 3, 4

ISO 8583 1992 (E) Mensajes originados por tarjetas bancarias - Especificaciones de intercambio de mensajes.

ISO 3554 Tarjetas Bancarias - Datos contenidos en Pistas 1 y 2. ISO 7810 a 7813 Identificación de Tarjetas

ISO/IEC 9797-1 Algoritmo de Autentificación de mensajes BEST Bilateral European Standard

P.R.I.C.E. Procedimiento Integrado Conexión Entidades.

EDC/MAESTRO Technical and Functional specifications

PUP Protocolo Unificado de PIN/Pad para conexión a ePOS PUC Protocolo Unificado de Comercios



Fecha abril 2019

Página: 3 de 203

ESP-TEC-PUC

Versión: 5.5.6

2. Visión General



Fecha abril 2019

Página: 2 de 203

ESP-TEC-PUC

Versión: 5.5.6

2.1 Características Generales Las características más importantes, desde el punto de vista operativo y funcional, aplicables a los Terminales/Host del

Establecimiento son:

1. Capacidad de comunicación On-Line con los Centros Procesadores, para realizar:

• Solicitud de autorización de operaciones y envío de Datos asociados al Chip EMV (ver punto 7.30) en

operaciones realizadas con Chip EMV que impliquen Cargo en la Cuenta del Cliente.

• Envío de diferidos (operaciones autorizadas en modo local por el Establecimiento/Negocio/Proveedor de servicio, anulaciones automáticas)

• Carga/Actualización de Lista Negra

2. Capacidad de realizar:

• Carga inicial en fábrica de claves TDES en PIN/Pad's para Securización de Datos de Tarjeta (ver Documento de especificaciones del Protocolo PUP)

• Actualización en los PIN/Pad's de claves Publicas RSA de CA (Emisor) recibidas desde los CPD's (ver Anexo B)

• Para PIN/Pads conectados a EPOS operando en Modo No Atendido, gestión de PIN-Online para banda magnética (ver Documento de especificaciones del Protocolo PUP)

• Carga y actualización On-Line de claves de transporte y/o claves de protección de PIN (ver Anexo H)

3. Capacidad de actualización de:

• Parámetros EMV recibidos desde los CPD's (ver Anexo C)

• Y

4. Capacidad para soportar:

• Todas las tarjetas de Banda Magnética cuyo PAN sea numérico, no comience por "59" y cuya longitud sea igual

o inferior a 19 caracteres. Dentro de esta amplia definición estarían todas las tarjetas de uso más frecuente: VISA, VISA Electrón, 4B, MASTERCARD, MAESTRO, EURO 6000, ServiRed, AMEX y DINERS CLUB

• Hasta veinte productos de tarjetas EMV identificados cada uno por su AID correspondiente. Todos los procesos que se lleven a cabo con la tarjeta Chip se realizarán de acuerdo a EMV, como mínimo EMV 96 (versión 3.1.1) garantizando el transporte hasta el Adquirente de todos los datos EMV requeridos para realizar la operación. No se permitirá truncamiento de datos EMV ni en el terminal ni en el Host del Establecimiento/Negocio/Proveedor de servicio.

• Hasta 6 Claves Publicas RSA de CA por Emisor y hasta 8 Emisores (máx. 48 claves). Ver Anexo B

• Hasta 10 claves TDES para Securización de Datos de Tarjeta. La gestión de estas claves y los procesos de cifrado que se realizan con ellas se describen en el Documento de Especificaciones del Protocolo PUP

• Por Procesador, capacidad de soportar los modelos de carga de claves de PIN, basados en carga inicial TDES o RSA en fabrica. La gestión de estas claves y los procesos de cifrado que se realizan con ellas se describen en el Documento de Especificaciones del Protocolo PUP. La carga On-Line de las claves de transporte y/o de protección de PIN se describe en el anexo H de este documento

• Realización de Fallback. En caso de fallo en la lectura del Chip EMV y siempre y cuando la parametrización de la conexión lo permita, se realizara la operación con la Banda Magnética de la tarjeta (Fallback). Este modo de operar debe quedar identificado en el mensaje entre el terminal y el Centro Procesador Adquirente.

• Detalle de cuando se debe aplicar Fallback queda descrito en Anexo E

• En caso de Fallback y fallo en la lectura de la Banda magnética se permite entrada manual de datos (obviamente solo es aplicable a Terminales Atendidos y siempre sujeto a los Acuerdos Nacionales e internacionales existentes).

5. Capacidad para identificar, en los mensajes enviados al HCP, la tecnología con que se realizó la operación

Contactos o Contactless y el modo como se realiza la operación:

• En el caso de tecnología Contactos: Banda Magnética, Entrada Manual, Chip EMV, Banda Magnética como

Fallback o Entrada Manual por fallo previo en Lectura de Banda Magnética.

• En el caso de tecnología Contactless: Operativa Visa qVSDC basada en EMV, Operativa M/Chip MasterCard basada en EMV y Operativa MagStripe de MasterCard basada en Banda Magnética

6. Capacidad, para identificar al titular mediante firma, PIN, firma y PIN o no realizar identificación de cliente.

7. Capacidad de recepción en los terminales de Script's EMV de Emisor con una longitud de hasta 128 Bytes.

8. Capacidad en los terminales para soportar la parametrización de las opciones EMV siguientes, según acuerdos con

el HCP:



Fecha abril 2019

Página: 3 de 203

ESP-TEC-PUC

Versión: 5.5.6

• Solicitud obligatoria de firma en recibo solo cuando sea requerida por el CVM o Solicitud obligatoria de Firma en

recibo independientemente del valor en CVM. No aplicable a Terminales No Atendidos

• Permitir el Bypass del PIN o no permitirlo

9. Las operaciones intercambiadas serán consideradas transacciones contables, evitándose el posterior envío de

ficheros.

10. La gestión de sesiones contables puede ser realizada, tanto por el Establecimiento/Negocio/Proveedor de servicio

como por el Centro Autorizador.

11. En el caso de que sea realizado por el Establecimiento y previo acuerdo con el HCP podrá seleccionar en el

momento en que realiza la operación de Totalización el Banco, sucursal y cuenta sobre la que desea se le abonen los importes de las operaciones que totalizan.

12. La conexión se realiza bien a través de la RED PUBLICA X-25 con enlaces temporales (cuando el volumen de

tráfico y el coste de las líneas lo justifiquen, se podrán utilizar enlaces permanentes) o bien mediante comunicación IP.

13. El establecimiento debe implementar el pago con tarjetas financieras conforme a las medidas de seguridad sobre

protección de datos requeridos por las marcas de tarjetas dentro del programa PCI-DSS (ver www.pcisecuritystandards.org) o en su defecto utilizar el “Sistema Nacional de Cifrado de Pistas” en PIN/Pad (ver 7.27 Información Control y Seguridad). En especial debe garantizarse que no se almacenan las pistas de las tarjetas una vez finaliza la transacción



Fecha abril 2019

Página: 2 de 203

ESP-TEC-PUC

Versión: 5.5.6

TERMINAL

EPOS

APLICACIÓN

DE PAGO

INTERFACE

CON EL HE

HE

INTERFACE

APLICACIÓN

HCP

2.2 Arquitectura EMV: PIN/Pad-Terminal-HE A continuación se esquematiza la arquitectura EMV a implementar en el HE.

PIN/PAD

LE

CT

OR

EM

V

APLICACIÓN EMV

EMV

NIVEL II

EMV

NIVEL I

En esta arquitectura:

1. El PIN/Pad está conectado directamente al Terminal, o a la red de Terminales del HE

2. Como principio toda la aplicación EMV reside en el PIN/Pad si bien otras soluciones homologadas por EMVco serán estudiadas por los HCP.

3. La Gestión de Riesgos puede realizarse en el Terminal o en el PIN/Pad

4. Los parámetros EMV, diferentes por Merchant-Tipo de Terminal-Producto EMV y la Lista Negra pueden

almacenarse:

• a nivel de la Aplicación de Pago del HE, debiéndolos pasar al Terminal o al PIN/Pad (dependiendo de quien realice la Gestión de Riesgos) en cada transacción EMV

• a nivel de Aplicación de Pago del Terminal y este deberá pasarlos o no al PIN/Pad en función de quien realice la Gestión de Riesgos.

• o a nivel del PIN/Pad.

En estos dos últimos casos deberá existir un procedimiento en el HE que permita realizar la actualización de Parámetros en cada Terminal o PIN/Pad, siempre que sea requerido

5. En caso de instalaciones operando en modo No Atendido, toda la seguridad ligada al PIN reside en el PIN/Pad y

deberá implementarse un procedimiento que permita realizar la inicialización y renovación de claves en cada PIN/Pad, de modo On-Line bien con el HCP (ver Documento de Especificaciones del Protocolo PUP y Anexo H de

este documento) o bien con el HE (ver Requerimientos del Proveedor de servicio)



Fecha abril 2019

Página: 3 de 203

ESP-TEC-PUC

Versión: 5.5.6

2.3 Requerimientos del Terminal Punto de Venta con capacidad EMV Requisitos Hw

TERMINAL PIN/PAD

Lector Banda Magnética (Opcional):

• Bidireccional ISO 1/2 con lectura completa de pistas En caso de existir esta componente en el Terminal y en el PIN/Pad se utilizará la del PIN/Pad

Lector Banda Magnética (Recomendado):

• Bidireccional ISO 1/2 con lectura completa de pistas

Lector de tarjeta Chip:

• Certificado EMV Nivel 1 de acuerdo a la última versión de

especificaciones EMVco • Posición de los contactos de los lectores chip. Los lectores de

Tarjeta Inteligente únicamente incorporarán los contactos según la norma ISO 7816-2

• Tensión de alimentación de la tarjeta programable (5 voltios, 3 voltios) (Recomendado)

• Frecuencia de reloj programable adaptándose a la máxima

permitida por la tarjeta (mínimo 5Mhz). (Recomendado)

Teclado Comercio: Teclado: Como Mínimo

• Numérico: mínimo 10 teclas (0 a 9)

• Control:

• 2 teclas obligatorias (Cancelar y Validar) con Serigrafía y Color

(CAN-Roja VAL/OK-Verde)

• 1 tecla opcional con Serigrafía y Color (BOR-Amarilla) (Recomendado)

• Preparado para invidentes en tecla '5' ('.' en relieve)

Pantalla Comercio: Pantalla Cliente: • Mínimo texto 2x16 STN

Impresora: • Obligatoria. Características según implementación

Reloj tiempo real Deberá tener una precisión de forma que no se adelante o atrase más de 1 minuto al mes.

Reloj tiempo real Opcional

Micro-controlador

• Características según implementación de acuerdo al CPD

Tecnología de Seguridad

• Criptoprocesador, mínimo de 32 bits capaz de realizar cálculos Criptográficos con algoritmos de clave pública (RSA) y claves TDES. Entre las funcionalidades RSA del PIN/Pad deberán estar la generación de parejas de claves RSA de hasta 2048 bits

• Conforme a requerimientos de Seguridad definidos en punto 2.4

Memoria Deberá como mínimo cumplir con los siguientes requisitos:

• Espacio suficiente para el programa.

• Espacio de memoria libre para la incorporación de futuras funcionalidades.

• Capacidad mínima de 500 operaciones en el diario.

• Capacidad para un mínimo de 2.000 ítems EMV en la lista

negra. • Capacidad para el almacenamiento de los parámetros de

configuración del terminal.

Memoria Con capacidad para almacenar el Kernel Nivel II EMV y garantizar los requerimientos de los CPD's, con espacio adicional para soportar futuras funcionalidades

Elementos Físicos de Comunicación Externos Elemento de comunicación con Terminal • 1 RS232 velocidad hasta 19.200 bps mínimo

Zumbador (duración y frecuencia de los sonidos programables) (Recomendado)

Zumbador (duración y frecuencia de los sonidos programables) o Led (intensidad y duración programables) (Recomendado)

Alimentación a través de cable único Comunicación-Alimentación entre Terminal y PIN/Pad



Fecha abril 2019

Página: 2 de 203

ESP-TEC-PUC

Versión: 5.5.6

Requisitos Sw

• Kernel Nivel II EMV obligatorio en el PIN/Pad y con Certificación nivel 2 EMV de acuerdo a la última versión de especificaciones de EMVco.

• Protocolos de comunicación con tarjeta inteligente (de Cliente y de Seguridad) (T=0, T=1).

• Velocidad de transmisión con las tarjetas inteligentes (de Cliente y de Seguridad) de 9600 baudios. El terminal deberá ser capaz además de comunicarse a velocidades superiores a ésta, alcanzando un mínimo de 38.400 baudios, siendo recomendado poder alcanzar 115.200 baudios.

• El procedimiento de negociación de la velocidad de transmisión con las tarjetas inteligentes será el PPS según ISO 7816-3.

• Telecargable modularmente tanto el Sw como los parámetros de configuración

• Capacidad para soportar las operaciones definidas en este manual

• Capacidad de conectarse en tiempo real con el ordenador central del establecimiento.

Requisitos de Seguridad del PIN/Pad Los PIN/Pad deberán ser dispositivos físicamente seguros tal y como se define en las normas ISO 13491 e ISO 9564. La norma ISO 13491 define distintos tipos de dispositivos seguros, los PIN/Pad deberán cumplir con los requisitos exigidos a los dispositivos denominados “Tamper-Evident Device”.

Deberá cumplir la norma ISO 9564 en lo relativo a los métodos de cifrado de PIN y a los requisitos exigidos para la introducción del mismo y la norma ISO/IEC 9797 modo CBC y padding según ISO/IEC 7816-4.

Además debe haber sido certificado por Visa Internacional y MasterCard Internacional, de acuerdo a los requisitos de ambas marcas que haya vigentes en cada momento. En concreto y para la fecha actual, los PIN/Pad deberán tener la certificación PCI (“Payment Card Industry”) para PIN offline. Para aquellos entornos en los que, excepcionalmente trabajen con PIN online, los PIN/Pad deberán tener además, la certificación PCI para PIN online y con el mismo firmware que se vaya a instalar en el comercio. Se detallan a continuación algunos de los requerimientos necesarios:

• Utilización de clave única por transacción y cifrado triple DES para criptografía de PIN Online.

• El PIN/Pad dispondrá de mecanismos que provoquen el borrado automático de las claves ante cualquier intento de manipulación.

• El PIN/Pad proporcionará mecanismos para impedir la observación visual del PIN tecleado.

• El teclado del PIN/Pad será exclusivo para la entrada de PIN o de lo contrario el control del teclado debe residir en el procesador de seguridad del PIN/Pad.

• No debe ser posible averiguar el PIN tecleado a través de radiaciones electromagnéticas emitidas por el PIN/Pad, ni tampoco de forma audible.

Requisitos de Seguridad de las comunicaciones Se garantiza mediante la utilización de MAC en los mensajes intercambiados. El MAC se genera/verifica en el punto origen de la comunicación con el CPD. Los algoritmos y las claves requeridas para generar/verificar el MAC estarán almacenados de forma segura con el fin de garantizar la integridad de las comunicaciones

Requisitos de Calidad Certificado TQM de los Terminales y PIN/Pads instalados



Fecha abril 2019

Página: 3 de 203

ESP-TEC-PUC

Versión: 5.5.6

2.3.1 Requisitos de Seguridad del HE/Proveedores de servicio En el caso de Proveedores de servicio que realicen la gestión del pin directamente con los pin/pad, se les exigirá cumplir la normativa " PCI PIN Security Requirements", y otras normas o requerimientos que las entidades adquirentes o esquemas determinen en cada momento.

Las 7 secciones en las que se divide y se establecen los requisitos de seguridad de la norma PCI-PIN son:

1. Cifrado del PIN (PIN Encryption). Los PINes utilizados en las operaciones reguladas por estos requisitos se procesan utilizando equipos y metodologías que garanticen que se mantienen seguros.

2. Creación de Claves (Key Creation). Las claves criptográficas utilizadas para el cifrado /descifrado del PIN y la gestión de las claves relacionadas, se crean mediante procesos que aseguran que no es posible predecir o averiguar cualquier clave.

3. Transmisión de Claves (Key Transmission). Las claves se transmiten y se transportan de una manera segura.

4. Carga de Claves (Key Loading). La carga de claves a los hosts y a los dispositivos donde se introduce el PIN, se realiza de una manera segura.

5. Uso de las Claves (Key Usage). Las claves son usadas de manera que se previene o detecta su uso no autorizado.

6. Administración de las Claves (Key Administration). Las claves son administradas y gestionadas de forma segura.

7. Equipamiento de seguridad y control (Equipment Security And Control). Los equipos utilizados para procesar los PINes y las claves se gestionan de una manera segura.



Fecha abril 2019

Página: 2 de 203

ESP-TEC-PUC

Versión: 5.5.6

2.4 Interfaz de Usuario en Terminales con capacidad EMV Se detallan a continuación los mensajes a mostrar en pantalla del Terminal y PIN/Pad asociados a:

• Solicitud de datos o de confirmación de datos

• Resultado de validaciones

• Entretenimiento

Nota: En aquellos casos en los que existan varias alternativas, se deberá acordar entre el HE y el HCP la propuesta definitiva

Solicitud o Confirmación de Datos

Solicitud/Confirmación de Datos Display del terminal Display del PIN/Pad

1. Solicitud de Tarjeta PASE O INSERTE (o INTRODUZCA) LA TARJETA

INTRODUZCA (o INSERTE) LA TARJETA

2.a. Selección de aplicación EMV en caso de existir más de una aplicación en común entre terminal y tarjeta.

ESPERE SELECCIÓN (o SOLICITE SELECCIÓN)

"Etiqueta de 1ª Apl."

PULSE VAL (u OK) + opción para elegir otra apl

2.b. Validación/Confirmación de aplicación EMV cuando existe una aplicación común entre terminal y tarjeta y se requiere su validación/confirmación.

"Etiqueta de Apl."

ESPERE SELECCIÓN (o SOLICITE CONFIRMACIÓN)

"Etiqueta de Apl."

PULSE VAL (u OK)

3. Solicitud de importe "Etiqueta de Apl." IMPORTE Y VALIDE

0,00 EUR

"Etiqueta de Apl. seleccionada

para operar"

4. Validación/Confirmación de Importe cuando no se requiere PIN

ESPERE CONFIRMACIÓN (o SOLICITE CONFIRMACIÓN)

IMP : XXX,XX EUR PULSE VAL (u OK)

5. Solicitud de PIN, según CVM y capacidades del terminal y validación/confirmación del importe

ESPERANDO N. SECRETO (o SOLICITE N. SECRETO)

IMP : XXX,XX EUR TECLEE N. SECRETO Y PULSE

VAL (u OK)

6. Solicitud del número de operación original N. OPERACIÓN ORIGINAL Y PULSE VAL (u OK)

ESPERE POR FAVOR

7. Solicitud de la fecha de operación original FECHA OPERACIÓN

ORIGINAL Y PULSE VAL (u OK)

ESPERE POR FAVOR

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Resultado de Validaciones

Resultado de Validaciones Display del terminal Display del PIN/Pad

1. Tarjeta Bloqueada o APL bloqueado TARJETA INVALIDA RETIRE TARJETA

TARJETA INVALIDA RETIRE TARJETA

2. Se produce error en la detección del ATR,

solicitándose de nuevo la inserción de la tarjeta

ERROR DE LECTURA INSERTE TARJETA

NUEVAMENTE

ERROR DE LECTURA INSERTE TARJETA

NUEVAMENTE

3. Se produce error en proceso con el Chip o no se encuentra aplicaciones coincidentes entre Terminal y Tarjeta. Se permite Fallback y se requiere lectura de tarjeta de Banda

ERROR DE LECTURA (APL NO DISPONIBLE)

PASE TARJETA

ERROR DE LECTURA (APL NO DISPONIBLE)

PASE TARJETA

4. Se produce error en proceso con el Chip o no se encuentra aplicaciones coincidentes entre Terminal y Tarjeta. Se permite Fallback y no se requiere lectura de tarjeta de Banda

RETIRE TARJETA OPERE CON BANDA

RETIRE TARJETA OPERE CON BANDA

5. Se produce error en proceso con el Chip o no se encuentra aplicaciones coincidentes entre Terminal y Tarjeta y no se permite Fallback

ERROR DE LECTURA RETIRE TARJETA

ERROR DE LECTURA RETIRE TARJETA

6. Si valida correctamente el PIN Off-Line ESPERE POR FAVOR

N. SECRETO

CORRECTO

7. Se produce error de validación de PIN Off-Line y no se han agotado el número de reintentos

ESPERANDO N. SECRETO (o SOLICITE N. SECRETO)

N. SECRETO ERRÓNEO

TECLEE N. SECRETO Y PULSE VAL (u OK)

8. Se cancela la transacción estando la tarjeta en el lector

OPERACIÓN CANCELADA RETIRE TARJETA

OPERACIÓN CANCELADA RETIRE TARJETA

9. Se cancela la transacción no estando la tarjeta en el lector

OPERACIÓN CANCELADA

OPERACIÓN CANCELADA

10. Si la operación resulta ACEPTADA, independientemente de serlo en modo Off-Line u On-line

OPERACIÓN ACEPTADA OPERACIÓN ACEPTADA

11. Si la operación resulta ACEPTADA, independientemente de serlo en modo offline u online y el método de verificación del titular es la firma

OPERACIÓN ACEPTADA VALIDE FIRMA

OPERACIÓN ACEPTADA

12. Si la operación resulta DENEGADA, independientemente de serlo en modo offline u online

OPERACIÓN DENEGADA OPERACIÓN DENEGADA

Entretenimiento

Entretenimiento Display del terminal Display del PIN/Pad

1. Cuando se requiera mostrar mensaje a pantalla mientras se espera resultado de un proceso

ESPERE POR FAVOR ESPERE POR FAVOR

CONFIDENCIAL Release: 05.4



Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

2.5 Datos a incluir en el Recibo impreso Recibos de operaciones de Venta Información a incorporar en los recibos de ventas aceptadas. En rojo los datos mínimos obligatorios que se deben imprimir:

• En Operaciones Contactless, el logo Contactless

• Tipo de operación (VENTA).

• Modo de Autorización (On 'O', Off 'D')

• Código de respuesta a la autorización (ARC) (Solo si la operación se realizó con tarjeta EMV)

• Modo de entrada de datos (Banda 'B', Chip 'C', Manual 'M')

• Modo de Verificación del Usuario (PIN 'P', Firma 'F', Ninguna '*')

• Código F.U.C. asignado al establecimiento (identificación del establecimiento).

• Identificación del terminal.

• Identificación del HCP que procesa la operación (REDSYS y CecaBank).

• Nombre del establecimiento.

• Ciudad del establecimiento.

• Nombre del titular si existe en la tarjeta y en Comercios trabajando en Escenario 1 y 2, si es enviado por el PIN/Pad (versiones PUP anteriores a la 1.5.0).

• Identificador de la aplicación AID (Solo si la operación se realizó con tarjeta EMV)

• DDF Name (Et. 84)

• Etiqueta de la Aplicación (Et. 50)

• En operaciones Contactless, el literal cargado en el campo Etiqueta de la tabla 08 correspondiente a la aplicación seleccionada y que está cargada en el PIN/Pad

• Nº de tarjeta truncando los 12 primeros dígitos sustituyéndolos por '*'

• Nº secuencial de tarjeta (Solo si la operación se realizó con tarjeta EMV).

• Etiqueta de la aplicación con la siguiente prioridad 'Application Label (T50), 'Etiqueta del terminal' (Solo si la operación se realizó con tarjeta EMV)

• Fecha y hora de la operación (DDMMAA hhmm)

• Nº de operación del terminal, secuencial por terminal

• Nº de autorización.

• Importe de la operación con indicación de moneda

• Espacio para Mensaje Informativo con un máximo de 64 caracteres. Este texto puede ser enviado de forma opcional por los Centros Procesadores.

• Recibo para el Comercio. • Recuadro de firma, siempre que sea el método aplicado para la autenticación del titular o cuando no

siéndolo así este programado en el terminal. • En caso de que la autenticación del titular se realice mediante PIN y no esté programado el terminal para

solicitar firma, se recomienda incluir el texto "OPERACIÓN CON PIN. FIRMA NO NECESARIA" y no se requerirá imprimir Recuadro de Firma. Y se deberá imprimir “Verificado por dispositivo” cuando la autenticación del titular se haya realizado vía dispositivo móvil.

• Se indicará que el recibo es para el Establecimiento

Recibo para el Cliente: indicar que es Copia y que es para el Cliente.

Resto de Copias: indicar que es Copia

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Recibos de operaciones de Devolución Información a incorporar en los recibos de devolución: En rojo los datos mínimos obligatorios que se deben imprimir:

• En Operaciones Contactless, el logo Contactless

• Tipo de operación (DEVOLUCIÓN).

• Modo de Autorización (Off 'D')

• Modo de entrada de datos (Banda 'B', Chip 'C', Manual 'M')

• Código F.U.C. asignado al establecimiento (identificación del establecimiento).

• Identificación del terminal.

• Identificación del HCP que procesa la operación (REDSYS y CecaBank).

• Nombre del establecimiento.

• Ciudad del establecimiento.

• Nombre del titular si existe en la tarjeta y en Comercios trabajando en Escenario 1 y 2, si es enviado por el PIN/Pad

(versiones PUP anteriores a la 1.5.0).

• Identificador de la aplicación AID (Solo si la operación se realizó con tarjeta EMV)

• DDF Name (Et. 84)

• Etiqueta de la Aplicación (Et. 50)

• En operaciones Contactless, el literal cargado en el campo Etiqueta de la tabla 08 correspondiente a la aplicación seleccionada y que está cargada en el PIN/Pad

• Nº de tarjeta truncando los 12 primeros dígitos sustituyéndolos por '*'

• N. º secuencial de tarjeta (Solo si la operación se realizó con tarjeta EMV).

• Etiqueta de la aplicación con la siguiente prioridad 'Application Label (T50), 'Etiqueta del terminal' (Solo si la operación se realizó con tarjeta EMV)

• Fecha y hora de la operación (DDMMAA hhmm)

• Nº de operación del terminal, secuencial por terminal

• Nº de autorización.

• Importe de la operación con indicación de moneda

• Recibo para el Cliente. • Recuadro de firma del Establecimiento indicando que el recibo es para el Cliente

Recibo para el Comercio: indicar que es Copia y para el Establecimiento.

Resto de Copias: indicar que es Copia




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

2.6 Operaciones soportadas en el Terminal El terminal deberá soportar las siguientes operaciones:

• Venta

• Devolución

• Cancelación (opcional)

Venta

Esta operación se realizará con lectura de Banda Magnética (lectura de pista 2) o lectura de Chip EMV.

Para aquellos casos en los que el tipo de tarjeta seleccionado requiera la anotación de Número Secreto, se solicitará

éste al cliente, después de la anotación del importe de la operación y antes del envío de la petición de autorización al Centro Autorizador o de la autorización local de la operación (solo en caso de operaciones realizadas con Chip EMV). La introducción del Número Secreto será obligatoria en caso de ser requerido, pudiéndose realizar Bypass (validar la solicitud de Número Secreto sin haberlo introducido) únicamente en caso de transacciones realizadas con Chip EMV y siempre que esta funcionalidad este permitida para el Establecimiento/Negocio/Proveedor de servicio por los HCP's a los que se conecte. La verificación de este Número Secreto será realizada, por el Emisor de la tarjeta o su agente (Centro Autorizador, HCP) en caso de transacciones realizadas con PIN On-Line y por la propia tarjeta, en caso de transacciones realizadas con PIN Off-Line (tarjetas EMV)

En caso de que la operación se inicie con lectura de Chip EMV y se produzca un fallo de lectura del Chip, se podrá realizar la operación con la Banda Magnética de la tarjeta (Fallback), siempre que esta funcionalidad este permitida para el Establecimiento/Negocio/Proveedor de servicio por los HCP's a los que se conecte. Este modo de operar debe quedar identificado en el mensaje entre el terminal y el Centro Procesador Adquirente (detalle de cuando se debe aplicar “Fallback” queda descrito en Anexo E)

En caso de Fallback y posterior fallo en la lectura de la Banda magnética o cuando la operación se inicia con lectura de Banda Magnética y no sea posible leer la pista 2 de la tarjeta, se podrá realizar la operación tecleando los datos del relieve, no permitiéndose en este caso la anotación del Número Secreto ni la autorización local de la transacción. La aplicación de este procedimiento deberá ser previamente aprobado por los HCP's a los que se conecta el Establecimiento/Negocio/Proveedor de servicio.

En caso de que la transacción resulte aceptada, deberá procederse a emitir un recibo, conteniendo la información definida en el punto 2.5.1. La firma del recibo por parte del cliente, será obligatoria: • En todas las operaciones de Venta realizadas con lectura de Banda Magnética o Entrada Manual • Y en todas las operaciones de Venta realizadas con Chip EMV cuando el Chip lo requiera o cuando no siendo

requerido por el Chip, el Establecimiento/Negocio/Proveedor de servicio tiene indicación de los HCP's de solicitarse firma del cliente

El modo de autorizar las operaciones de Venta dependerá de la tecnología utilizada para obtener los datos de la tarjeta. Según esto:

• Las operaciones realizadas con Entrada Manual de datos de la tarjeta o con lectura de Banda Magnética por Fallback del Chip EMV, siempre requieren autorización del HCP, no permitiéndose autorización local.

• En caso de operaciones realizadas con lectura de Banda Magnética siempre se deberá solicitar autorización al HCP. Solo cuando no sea posible encaminar la operación al HCP o no se recibiera respuesta del mismo y el HCP al que se conecta lo permita, el Establecimiento/Negocio/Proveedor de servicio podrá iniciar el procedimiento de autorización local (ver punto 2.7).

• En caso de operaciones realizadas con lectura de Chip EMV el modo de autorización de la operación dependerá de la propia tarjeta en base a parámetros internos (ver punto 2.7).

En caso de que un mensaje de Venta enviado al Centro Procesador no finalice correctamente (no reciba respuesta el terminal en el tiempo esperado o se produzca cualquier fallo técnico), se deberá generar un mensaje de anulación hacia el Centro Autorizador.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Devolución Se considera la Devolución como una operación de Abono al Cliente que deberá ser autorizada por el emisor en tiempo real esto es online, pero el Centro Procesador no verifica la correspondencia con una Venta anterior.

Nunca requiere anotación de Número Secreto, pudiendo ser la captura de datos manual, desde el relieve de la tarjeta o electrónica, mediante lectura de Chip EMV o de la pista 2 de Banda Magnética

En caso de que la transacción resulte aceptada, deberá procederse a emitir un recibo, conteniendo la información definida en el punto 2.5.2. Al cliente se le deberá facilitar copia firmada por el establecimiento de la operación realizada.

Se recomienda que el establecimiento o su aplicación arbitren procedimientos que permitan restringir la realización de esta operación a personal autorizado.

Las devoluciones serán enviadas al Centro Autorizador como Petición de Transacción Contable, lo que garantiza su recepción.

Se considera una buena práctica para los HE con PIN/Pad que securizan los datos de las tarjetas (SNCP), el envío online de las devoluciones.".

La utilización de esta operación, por parte del HE, deberá ser previamente aprobado por el HCP al que se conecte.

Los HE con PIN/Pad que securizan los datos de las tarjetas (SNCP) [punto 2.11], deberán utilizar el subcampo P-48.40, en lugar del P-02 para enviar la Referencia de la operación cuando necesite realizar devoluciones sin presencia del titular.

Cancelación

Toda operación de Venta y Devolución puede ser cancelada antes de ser completada mediante el uso de la función "CANCELAR" en el terminal.

En el caso de que se cancele una operación que ha sido enviada desde el establecimiento al Centro Procesador solicitando Autorización (Petición Contable), se deberá generar el mensaje de anulación correspondiente.

La Cancelación de la Devolución podrá ser generada cuando se desee corregir errores en el tecleo de los datos de la operación de Devolución. Esta operación queda restringida a personal autorizado y será retrocedida al comercio en caso de reclamación del cliente.

La habilitación de la función "CANCELAR" para operaciones de Devolución deberá ser pactada previamente entre el Establecimiento/Negocio/Proveedor de servicio y el Centro Autorizador.




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

2.7 Autorización de Transacciones de Venta El Modo de autorizar una transacción de Venta dependerá de la tecnología utilizada para obtener los datos de la tarjeta.

En aquellos casos en los que este permitida la Autorización Off-Line, los parámetros utilizados para realizar el Control de Riesgos serán diferentes por Merchant, Tipo de Terminal, Producto y Tecnología.

Entrada Manual de Datos de Tarjeta o lectura de Banda Magnética por Fallback del Chip EMV

Todas las operaciones iniciadas en el Terminal y realizadas con Entrada Manual de Datos de Tarjeta o lectura de Banda

Magnética por Fallback del Chip EMV, serán encaminadas como transacciones contables, a través del ordenador del

establecimiento, hacia el HCP. Una vez recibida la respuesta, el ordenador del establecimiento la encamina hacia el Terminal que inició la transacción.

En caso de no recibirse respuesta del HCP o que por cualquier circunstancia ésta no se procese correctamente en el

Terminal, no se permitirá autorización local debiendo generarse, desde el Terminal o del ordenador del establecimiento,

un mensaje de anulación automática hacia el HCP.

El Establecimiento/Negocio/Proveedor de servicio debe tener presente la posibilidad de utilizar HCP's alternativos para ciertos tipos de tarjetas

Lectura de Banda Magnética Todas las operaciones iniciadas en el Terminal y realizadas con lectura de Banda Magnética, serán encaminadas como transacciones contables, a través del ordenador del Establecimiento/Negocio/Proveedor de servicio, hacia el HCP. Una vez recibida la respuesta, el ordenador del establecimiento la encamina hacia el Terminal que inició la transacción.

En caso de no recibirse respuesta del HCP o que por cualquier circunstancia ésta no se procese correctamente en el

Terminal, y no sea posible realizar una autorización local de la transacción, deberá generarse, desde el Terminal o del

ordenador del establecimiento, un mensaje de anulación automática hacia el HCP.

El Establecimiento/Negocio/Proveedor de servicio deberá tener presente la posibilidad de utilizar HCP's alternativos para ciertos tipos de tarjetas

Lectura de Chip EMV

En caso de operaciones realizadas con lectura de Chip EMV, el modo de autorización de la operación dependerá del resultado del proceso de Control de Riesgos realizado por el terminal en base a los parámetros cargados por Merchant-

Tipo de Terminal-Producto y en última instancia a la decisión de la propia tarjeta en base a parámetros internos.

Una operación podrá ser denegada o autorizada en Off-Line directamente por la tarjeta o indicar que se solicite

autorización al HCP y en caso de no existir respuesta, la tarjeta podrá denegarla o autorizarla en Off-Line.

De igual forma, el procedimiento de validación del cliente dependerá de la parametrización de la propia tarjeta y del Tipo y Capacidades del Terminal en el que se realiza la operación.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

2.8 Cierre y Conciliación El proceso de cierre de sesión está ligado al proceso de conciliación entre el Establecimiento/Negocio/Proveedor de

servicio y el Centro Procesador, en el sentido de que el cierre de sesión se establece en el momento en que se concilien

los centros.

La conciliación y conmutación de sesiones puede ser:

Gestionada por el Establecimiento El ordenador del Establecimiento/Negocio/Proveedor de servicio generará cuando lo desee, un mensaje de conciliación (pudiendo incluir sábados, domingos y festivos o incluso más de un Cierre al día). Este mensaje se dirigirá al Centro Procesador, pudiendo contener, en caso de ser conocido, el Banco, Sucursal y Cuenta de Abono y/o toda la información necesaria para realizar el cuadre y el abono (Descuentos, Importes, etc.)

Los Centros Procesadores podrán enviar sus totales en caso de descuadre. Una vez recibida esta respuesta, el ordenador del establecimiento dará por conciliada la sesión contable procediendo a iniciar los totales.

El cambio de sesión es realizado por el HE (Host del Establecimiento).

Gestionada por el HCP En este caso el establecimiento fijara el horario de Cierre con el Centro Procesador (REDSYS y CecaBank), siendo realizado por este, así como el cambio de sesión correspondiente.

No será necesario contabilizar las operaciones por el establecimiento ya que estos totales se podrán consultar en cualquier momento. La sesión contable se le comunicara al establecimiento en todos y cada uno de los mensajes de respuesta.

Con el fin de evitar que se produzcan descuadres en el Cierre de la sesión, todos los mensajes de Anulación que el HE envíe al HCP deberán llevar el Código de Razón de Mensaje (P-25) con valor '4007' o ‘4352’

NOTA 1: En caso de producirse una situación de catástrofe que imposibilite realizar el cierre por el procedimiento previsto, se habilitará una vía administrativa que permita realizar el cierre unilateralmente. Para ello el centro afectado, comunicará la situación al otro centro (mediante teléfono, fax o e-mail). Una vez recibida la confirmación, cada uno de ellos procederá a realizar un Cierre unilateral de la sesión, abriendo a continuación una sesión nueva.

NOTA 2: Este procedimiento de Cierre Gestionado por el HCP será obligatorio siempre que el HE opere dentro del Escenario 1 en SNCP (Sistema Normalizado de Cifrado de Pistas)




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

2.9 Gestión de Lista Negra En caso de que el HCP lo requiera, será obligatoria la gestión de lista negra en los

Establecimientos/Negocios/Proveedores de servicio con capacidad de autorización Off-Line de operaciones realizadas

con lectura de Chip EMV. El tamaño de la Lista Negra será de 2000 tarjetas máximo

Existirán dos modos de realizar la actualización de la Lista Negra del HE:

Actualización On-line. El HCP podrá realizar la actualización On-Line de la Lista Negra, utilizando tres procedimientos

Procedimiento 1

Comunicando al HE, en los mensajes de respuesta 1530 y 1614 que aprueben o acepten la Comunicación previa, que debe realizar una Solicitud de Actualización de Lista Negra al HCP. Para ello el HCP, enviara en el Código de Acción (P-39) un valor que así lo indique.

Una vez recibida esta indicación, el HE enviara un mensaje 1644 solicitando la actualización de la Lista Negra. En este mensaje el HE informara al HCP, mediante el Registro de Datos (S-72), la versión actual de Lista Negra que tiene almacenada y el tamaño de la Lista Negra que es capaz de almacenar.

El HCP, como respuesta a la solicitud de Actualización de Lista Negra, enviara un mensaje 1304 que contendrá, en el Registro de Datos (S-72), las actualizaciones de la Lista Negra y el valor de la Versión actual.

El HE una vez recibido el mensaje 1304, procederá a actualizar su fichero de Lista Negra grabando un registro que contendrá el Número de tarjeta que viaja en el campo "PAN Número de Tarjeta" y el Número de Secuencia que viaja en el campo 'Número de Secuencia' y que ocupará en el fichero la posición referenciada por el campo "Posición en el fichero". Este proceso se realizara independientemente de que en esa posición ya este almacenado el PAN de otra tarjeta.

.

Procedimiento 2

Comunicando al HE, en los mensajes de respuesta 1110 1210 que aprueben o acepten la Petición previa, que debe realizar una Solicitud de Actualización de Lista Negra al HCP. Para ello el HCP, enviara en el Código de Acción (P-39) un valor que así lo indique.

Una vez recibida esta indicación, el HE enviara un mensaje 1644 solicitando la actualización de la Lista Negra. En este mensaje el HE informara al HCP, mediante el Registro de Datos (S-72), la versión actual de Lista Negra que tiene almacenada y el tamaño de Lista Negra que es capaz de almacenar.

El HCP, como respuesta a la solicitud de Actualización de Lista Negra, enviará un mensaje 1304 que contendrá, en el Registro de Datos (S-72), las actualizaciones de la Lista Negra y el valor de la Versión actual.

El HE una vez recibido el mensaje 1304, procederá a actualizar su fichero de Lista Negra grabando un registro que contendrá el Número de tarjeta que viaja en el campo "PAN Número de Tarjeta" y el Número de Secuencia que viaja en el campo 'Numero de Secuencia' y que ocupará en el fichero la posición referenciada por el campo "Posición en el fichero". Este proceso se realizara independientemente de que en esa posición ya este almacenado el PAN de otra tarjeta.

Procedimiento 3

Enviando en los mensajes de respuesta 1230, un Código de Acción indicando que debe ponerse la tarjeta en Lista

Negra. El elemento de dato (P-48) indicará la posición del fichero que deberá ocupar la tarjeta.

.

Sustitución periódica.

Mediante el envío en soporte magnético o por transmisión de ficheros del archivo de Listas Negras, desde el Centro Procesador. Esta sustitución no deberá afectar a aquellas tarjetas incorporadas en On-line y con igual número ó superior de versión de Lista negra.

Solo en caso de acuerdo entre las partes (HE/HCP)

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

2.10 Envío de Criptogramas EMV Todos los Establecimiento/Negocio/Proveedor de servicio que dispongan de terminales con capacidad de

funcionamiento EMV, deben disponer de la funcionalidad de envío al HCP de Criptogramas (y todos los datos EMV

requeridos para su procesamiento) debidos a operaciones realizadas con Chip EMV, con los siguientes criterios:

Envío de los 1os Criptogramas Se enviará en los siguientes casos:

• Operaciones que requieren autorización On-Line del HCP/Emisor. El envío de estos Criptogramas (ARQC) y sus datos asociados, se realizará en el campo P-55 incorporado en los mensajes 1200

• Operaciones autorizadas Off por terminal/tarjeta. El envío de estos Criptogramas (TC) y sus datos asociados, se realizará en el campo P-55 incorporado en los mensajes 1220-1

Envío de Criptogramas de Anulación

Se enviarán todos los Criptogramas de Anulación (AAC) disponibles al Adquirente. Se entiende por Criptograma de Anulación aquel que ha sido generado por denegación en el terminal/tarjeta de una transacción de la que previamente se ha recibido en el terminal autorización del emisor. El envío de estos Criptogramas y sus datos asociados, se realizará en el campo P-55 incorporado en los mensajes 1420/1 debidos a anulaciones automáticas de transacciones e indicando el motivo de la denegación en el campo P-25 “Código de Razón del mensaje” con el valor “4352”

Envío de los 2os Criptogramas • Aplicable a Operaciones autorizadas en modo Off por time-out (ausencia de respuesta)

• El envío de estos Criptogramas (TC) y sus datos asociados, se realizará en el campo P-55 incorporado en los mensajes 1220-1




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

2.11 Seguridad Al contemplarse la existencia de transacciones con anotación de número secreto (PIN) y la utilización de Códigos de Autentificación del Mensaje (MAC) en el intercambio de mensajes entre el ordenador del establecimiento y el ordenador de los Centros de Proceso, se establece un modelo de Seguridad que engloba tanto los conceptos asociados con la seguridad física de los grupos de cifrado (PIN/PAD), como los procedimientos utilizados para el manejo de datos y gestión de claves durante los procesos de Cifrado.

Número Secreto (PIN).

Los siguientes procesos asociados al proceso de introducción, cifrado y verificación, deberán realizarse en un dispositivo PIN/PAD, homologado por los Centros Procesadores.

• La introducción del Número Secreto

• Generación del bloque de PIN

• Si la verificación de PIN es Off-Line en claro o cifrado (realizada por la tarjeta) su posterior presentación a la tarjeta y además en caso de verificación de PIN Off Cifrado, su cifrado previo a la presentación a la tarjeta

• Y en caso de verificación de PIN On-Line, su posterior cifrado y envío al HCP (solo permitido en instalaciones funcionando en modo No Atendido, ver Anexo H)

El equipo PIN/Pad admitirá tecleo de Números Secretos de longitud variable, con el siguiente tratamiento:

• Método PIN Cifrado para PIN Off-Line. El procedimiento será el definido por EMV 2000 (versión 4.0)

• Método PIN Cifrado para PIN On-Line. El procedimiento será el definido en el Documento de Especificaciones del protocolo PUP

• Método PIN en Claro para PIN Off-Line. El procedimiento será el definido por EMV 2000 (versión 4.0)

Código de Autentificación del Mensaje (MAC) El Código de Autentificación del Mensaje es un valor asociado al mensaje que autentifica el origen del mismo y garantiza la integridad de los datos que lo componen.

Los mensajes intercambiados entre el terminal y el ordenador del establecimiento deben estar protegidos por un MAC, en el que intervienen, al menos, los siguientes datos: Número de Tarjeta, Importe de la Transacción, Fecha y Hora Local y Código de Acción.

Los mensajes intercambiados entre el ordenador del establecimiento y el HCP llevarán MAC, definiéndose a lo largo del documento su generación y verificación. La gestión de las claves que intervienen se detalla en el Documento de Cifrado. (Ver Anexo A)

Securización de Datos de Tarjeta La confidencialidad de los datos se establecerá entre el PIN/Pad y el Sistema Central del HE. Para ello el PIN/Pad cifrará TDES los datos críticos del mensaje de petición antes de que éstos sean transmitidos.

Los datos de la tarjeta a cifrar son los contenidos en la pista 2, para el caso de que la procedencia de los datos sea lectura de una tarjeta de banda magnética o la lectura de una tarjeta chip EMV

Los datos a cifrar, de longitud variable, se precederán del byte de longitud correspondiente. La cadena resultante se dividirá en bloques de 8 bytes. Si la longitud del último bloque es menor de 8 bytes, se rellenará con ceros binarios hasta completar los 8 bytes de longitud.

La clave a utilizar en el proceso de cifrado será la indicada por el dígito número 11 del PAN de la tarjeta. Existirá un juego de claves (0 a 9) por fabricante de PIN/Pads, versión de claves y número de serie del PIN/Pad.

La clave indexada por la tarjeta podrá ser derivada, en tiempo de transacción, por número aleatorio (de longitud 6) generado por el PIN/Pad

Además de los datos citados, el PIN/Pad devolverá:

• El BIN en claro de la tarjeta

• El número de clave utilizado para el cifrado

• En caso de derivación de claves, el número aleatorio utilizado para derivar la clave

• Y opcionalmente, el PAN en claro de la tarjeta y el Nombre del titular de la tarjeta

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

3. Nivel de Red




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

3.1 Introducción En este apartado se especifican una serie de normas, definiciones y procedimientos que permiten la conexión entre el

Host del establecimiento (HE) y los Hosts de los Centros Procesadores (HCP).

Aquellos Establecimientos que deseen conectar su Host vía IP, encontrarán la descripción de los requerimientos a nivel de red en el Anexo I.

3.2 Descripción del Entorno El HE se conectará a los HCP de acuerdo al el Anexo I

Esta conexión se realizará a través de canales conmutados o permanentes y por línea de red pública o línea punto a punto.

Para este tipo de conexión de bajo volumen de tráfico, se recomienda la utilización de circuitos conmutados.

Los canales conmutados podrán ser establecidos por cualquiera de los dos interlocutores que requieran en el momento de enviar un mensaje y no esté el canal establecido ya.

Estos canales podrán ser liberados si transcurre más de un tiempo sin tráfico cuando se establecen por redes públicas o mantenidos permanentemente establecidos cuando el volumen del tráfico lo justifique y sea económicamente más rentable.

3.3 Descripción del Paquete de Llamada Definición de los Campos para REDSYS

Los DATOS DE USUARIO del paquete de llamada deberán ajustarse al siguiente formato:

IE 0 RRRRR AA CCCC 000000TT EE N 0

IE Identificador del Elemento conectado. Toma valor "C7".

T Tipo de Entorno (pruebas o real) al que se desea conectar. Su valor será fijado por REDSYS en el momento de comenzar el proceso de certificación

RRRRR Reservado. Se asignará su valor al comenzar la certificación

AA Número Identificativo de la Aplicación a enlazar. Toma valor "13" para conexiones permanentes y "43" para las conmutadas

CCCC Código asignado al HE.

EE Número de Enlace. Tendrá siempre el valor "01", excepto cuando se utilice más de un CVC, en cuyo caso irá tomando valores superiores correlativos, para cada nuevo CVC enlazado.

N Atributo del Enlace. Podrá tomar los valores: "0" Entrada/Salida "1" Salida (Visto desde HCP)

"2" Entrada (Visto desde HCP)

En caso de elegirse un único CVC de E/S, se deberá tener especial cuidado en el diseño del sistema informático del HE, de tal forma que la aplicación no esté espacios largos de tiempo en estado de "sólo envío", pues se impedirá de esta forma la recepción de mensajes desde el HCP. Deberá producirse una mutación adecuada del estado de "envío" a "recepción" y viceversa, evitando los indeseados monólogos

0 Valor "0".

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Definición de los Campos para REDSYS REDSYS utilizará normalmente un solo canal que será siempre la entrada/salida. En establecimientos con muy alto tráfico se podrá definir más de un canal y las normas de utilización de éstos cuando el número de transacciones simultáneas, en horas punta, lo requiera. El "User Data" en los paquetes de llamada será 22 00 00 00 en 4 bytes en hexadecimal.

Se utilizará "Subaddressing". Los NRI's primarios y alternativos así como el subdireccionamiento, serán proporcionados por REDSYS y deben ser fácilmente modificables si se requiriese.

Definición de los Campos para CecaBank

En caso de Comercios con bajo volumen de tráfico, solo se permite la utilización de un único circuito de entrada/salida En el caso de Comercios con alto volumen de tráfico, será obligatorio la utilización de 2 circuitos uno de entrada y otro

de salida.

Los DATOS DE USUARIO del paquete de llamada son 4 bytes (1-2-3-4) con el siguiente formato:

Byte 1 (MSB) valor hexadecimal 'EE'

Bytes 2,3 y 4 valor numérico en 6 dígitos que previamente deben ser acordados con CecaBank

.

3.4 Establecimiento de Conexión El CVC se establecerá cuando el Establecimiento tenga algo que enviar y lo liberará si transcurren 2 minutos sin tráfico, salvo acuerdo previo en que por ser muy elevado el número de transacciones se decida mantener el circuito permanentemente establecido. En conexiones con varios canales, se acordará si se tienen uno o varios permanentemente establecidos y cuántos se establecen de forma dinámica, en función de las necesidades. Cada circuito primario tendrá asociado uno alternativo de back-up por el que deberá intentar la conexión, en caso de no conseguirlo por el primario (Ver 3.6).

Una vez aceptado el Paquete de Llamada por el HCP la sesión con la aplicación quedará establecida, pudiéndose comenzar el envío de mensajes de aplicación.

3.5 Interrupción y Recuperación de Enlace La interrupción de la conexión se puede producir a nivel de enlace físico o lógico:

Físico: Provoca la caída de todas las sesiones establecidas. Una vez detectada la caída del enlace se deberá efectuar

una reconexión, desde ambos extremos (HE y HCP), tanto a nivel lógico como físico.

Lógico: Provoca la caída de la sesión correspondiente al CVC afectado. Al detectarse la caída de la sesión se procederá a enviar un nuevo Paquete de Llamada reiniciándose la sesión interrumpida.

En caso de no conseguirse la reconexión de la/s sesión/es interrumpida/s se iniciará el Procedimiento de Respaldo. (Ver 3.6)




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

3.6 Procedimiento de Respaldo. Este procedimiento proporciona una vía alternativa para la comunicación entre el HE y el HCP, en caso de problemas

irrecuperables en alguno de los elementos de la conexión.

Se basa en la utilización de la línea alternativa a la conexión principal que poseen las H.C.P.

Para establecimientos con tráfico elevado se recomienda la utilización de líneas alternativas en el entorno del establecimiento y a la previsión de tantos CVC's de reserva como se contempla en la conexión principal.

Cuando no se acepte el Paquete de Llamada a través de la Conexión Principal, se emitirá de forma automática un nuevo Paquete de Llamada a través de la Conexión Alternativa preparada para esta situación, utilizándose el NRI que el CP tenga preparado para dar servicio en estos casos.

Iniciada la Conexión Alternativa se procedería a la determinación del problema de la Conexión Principal por parte de los Centros de Gestión de Red del establecimiento y del Centro Procesador.

Una vez recuperado el circuito principal, el HE deberá romper las sesiones establecidas a través del alternativo, dando por finalizada la situación de Respaldo.

3.7 Reglas de Presentación Los mensajes ISO 8583 intercambiados por las aplicaciones deberán ser transformados sintácticamente con arreglo a

las siguientes reglas:

Con excepción del Mapa de Bits, los elementos de datos exclusivamente numéricos (atributo "n") y los elementos de datos con atributo "b" todos los datos serán codificados utilizando caracteres de 8 bits ASCII

Todos los datos de longitud fija y numéricos estarán ajustados a la derecha y rellenos con ceros a la izquierda.

Los datos de longitud fija no exclusivamente numéricos, serán ajustados a la izquierda rellenando con espacios a la derecha.

Los elementos de datos exclusivamente numéricos (atributo "n") junto con el campo Tipo de mensaje, deberán codificarse utilizando caracteres de cuatro bits BCD. Tendrán que tenerse en cuenta las siguientes reglas:

• En los elementos de datos LLVAR, la longitud ocupará un octeto, conteniendo los dígitos LL. Debemos aclarar que

los dígitos LL indican el número de caracteres del dato que viene a continuación: por ejemplo, el PAN de 17 dígitos 12345678901234567 se representaría en diez octetos con el valor: 17012345678901234567.

• En los elementos de datos LLLVAR, la longitud ocupará dos octetos, conteniendo los dígitos 0LLL.

• Por ejemplo, el campo DATOS PRIVADOS ADICIONALES (P-48) con 126 dígitos se representara como: 0126nnn..nnn

• Si el elemento de dato tiene un número impar de dígitos, el primer medio octeto (cuatro bits de la izquierda) se pondría a cero. Por ejemplo, el valor 200 que está compuesto de tres dígitos, se codificaría en dos octetos de la siguiente forma: 0000 0010 0000 0000.

• Los datos binarios se ajustarán a la izquierda, rellenando con ceros binarios a la derecha.

Una vez transformados sintácticamente los datos, no deberán sufrir ningún tipo de encriptado ni proceso de compresión.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

4. Nivel de Aplicación. Descripción General




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

4.1 Introducción El Nivel de Aplicación de este procedimiento de conexión se basa en la norma ISO 8583: 1993.

4.2 Definiciones

Actualización de fichero Transacción usada para añadir, modificar, borrar o reemplazar un registro de un fichero

Anulación Una transacción iniciada por el Host del establecimiento o terminal que informa al Host del

Centro Procesador que la transacción anteriormente iniciada no debe ser procesada. El

efecto de la anulación variará según el estado en que se encuentre la transacción original a la que pretende anular. El importe de la anulación será siempre al de la operación que anula.

Autorización La aprobación o garantía de fondos dada por el Emisor de la tarjeta al establecimiento aceptador de la misma

Bypass Proceso que permite a un usuario no introducir el Número Secreto (PIN) cuando le es

solicitado Operativamente consistirá en la pulsación de la tecla VAL u OK durante la fase de presentación del mensaje de solicitud de Número Secreto, sin haberlo introducido

Centro Autorizador Ver Centro Procesador

Centro Procesador (CP) Institución financiera (REDSYS y CecaBank), que recibe las transacciones de los establecimientos aceptadores de tarjeta para su resolución, conciliación y compensación. En el manual se hace mención indistintamente a Centro Procesador o Centro Autorizador.

Clase de mensaje División de mensajes la cual describe con exactitud la función que se está ejecutando

Compensación Transferencia de fondos resultado de una o más transacciones realizadas con anterioridad.

Comunicación Un mensaje donde el remitente notifica al receptor que una acción ha sido tomada en su

nombre, no requiriendo aprobación, pero sí una respuesta. Conciliación Intercambio de mensajes entre los Hosts del establecimiento y del Centro Procesador

para alcanzar un acuerdo en los totales financieros relativos a una sesión contable. La

conciliación facilita el proceso de compensación. Destino Parte receptora del primer mensaje de una transacción.

Establecimiento

Aceptador de Tarjetas o

Establecimiento (E)

Parte aceptadora de la tarjeta que presenta al HCP los datos de la transacción realizada

en un terminal, bien directamente o bien a través del Establecimiento/Negocio/Proveedor de servicio. Así pues, un Establecimiento está constituido por un conjunto de Terminales agrupados en el mismo código FUC.

Fallback Se entiende como Fallback el uso de cierta tecnología cuando una previa y prioritaria no

está disponible por alguna razón. En el presente documento el Fallback consistirá en la posibilidad de utilizar la Banda Magnética para completar una transacción cuando se ha producido algún problema en el Chip EMV (Detalle de cuando se debe aplicar Fallback queda descrito en Anexo E)

Grandes Clientes Comercios que concentran las operaciones de pago con tarjetas debido a sus establecimientos en un punto único (HE), que sirve de enlace con los Centros Procesadores. El enlace entre el HCP y HE se caracteriza por: • Elevado número de transacciones. Enlace permanente • Cuadre a nivel de sesión • Posibilidad de realizar el Abono por establecimiento, Sector de Actividad, Comercio,

etc.

Host del Centro

Procesador (HCP)

Ordenador del Centro Procesador que dialoga

Host del Establecimiento (HE)

Ordenador del Establecimiento que dialoga con el HCP. Estará ubicado en el Establecimiento, en entidades con "Pequeños Comercios" y en el Negocio/Proveedor de servicio en enlaces con "Grandes Clientes"

Identificativo de Cuadre (o Identificativo de Referencia)

Información necesaria que permite la generación de subtotales en los que se acumularán las operaciones realizadas en una sesión para posteriores procesos de cuadre y abono.

Mapa de bits Serie de 64 bits utilizados para denotar la presencia (1) o ausencia (0) de cada elemento de dato en un mensaje

Mensaje Un conjunto de elementos de datos utilizados para intercambiar información entre

instituciones (o sus agentes). No se contemplan datos específicos de comunicaciones Negocio/Proveedor de servicio

Host del Establecimiento para enlaces del HCP con "Grandes Clientes". Al Negocio/Proveedor de servicio se le conectará uno a más establecimientos

Notificación Mensaje utilizado por el remitente para informar al receptor de una acción tomada en su

nombre, no requiriendo aprobación ni respuesta

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Origen Para iniciadora del primer mensaje de una transacción

Pequeño Comercio Comercio que concentra las operaciones de pago con tarjetas debidas a sus Terminales en un punto único (HE) que sirve de enlace con los Centros Procesadores. El enlace entre el HCP y HE se caracteriza por: • Volumen de transacciones de tipo medio. Enlace conmutado

• Cuadre y abono a comercio a nivel del establecimiento o a nivel de Identificativo de

Cuadre (Tipo de Tarjeta)

Petición Un mensaje mediante el cual el remitente informa al receptor que una transacción se está realizando y se requiere una respuesta para completarla

Punto de servicio De forma genérica, lugar donde se origina la transacción.

Sesión Contable Se puede definir como periodo de tiempo comprendido entre la realización completa de dos conciliaciones consecutivas o como el conjunto de transacciones con la misma fecha de conciliación (P-28), número de conciliación (P-29) y Código de Identificación del Adquirente (P-32). En funcionamiento normal sólo existirá una sesión abierta, pudiendo estar otra en fase de cierre durante el momento de la conmutación de sesiones.

Titular Persona física usuaria de la tarjeta (cardholder). A veces utilizaremos el término cliente con el mismo sentido

Transacción Uno o más mensajes relacionados dentro de la misma clase cuyo fin es completar (si es posible) la intención del remitente del primer mensaje

Transacción Contable Una transacción desde el adquirente (el establecimiento) al emisor (HCP) que tiene todos los datos necesarios para realizar el proceso de autorización, efectuar el apunte en la cuenta del titular y realizar la conciliación.




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

4.3 Estructura de Mensajes de Aplicación La estructura de los mensajes de aplicación que se utilizan está basada en la norma ISO 8583: 1992 teniendo la

siguiente composición: • Identificador de Tipo de Mensaje (n4) • Uno o más Mapas de Bits

• Una serie de Elementos de Datos, cuya presencia viene indicada por el Mapa de Bits.

Identificador de Mensaje Mapa de Bit's Elementos de Datos

Identificador de Tipo de Mensaje Cada mensaje comienza con un campo de 4 octetos con contenido numérico que indican: • Número de Versión

• Clase del Mensaje

• Función del Mensaje

• Iniciador de la transacción

4.3.1.1 Estructura

Primera posición Número de Versión 0 ISO 8583:1987 1 ISO 8583:1993 2 ISO 8583:2003 3-7 Reservado uso ISO 8 Reservado uso nacional 9 Reservado uso privado

Segunda posición Clase de Mensaje 0 Reservado para uso ISO 1 Autorización 2 Contable 3 Actualización de ficheros 4 Anulaciones 5 Conci liación 6 Administrati vo 7 Cobro/Pago cuotas 8 Control de diálogo 9 Reservado uso ISO

Tercera posición Función del Mensaje 0 Petición 1 Respuesta a Petición 2 Comunicación 3 Respuesta a Comunicación 4 Notificación 5-9 Reservado uso ISO

Cuarta posición Iniciador de transacción 0 Adquirente 1 Adquirente, repetición 2 Emisor Tarjeta 3 Emisor Tarjeta, repetición 4 General 5 General, repetición 6-9 Reservado uso ISO

Es importante destacar que los mensajes de repetición (1xx1, 1xx3, 1xx5) serán idénticos a los mensajes originales excepto en: Identificador de Tipo de Mensaje.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

4.3.1.2 Descripción A continuación, describimos cada clase de mensaje que contemplamos en la interface Host Establecimiento - Host Centro Procesador.

4.3.1.2.1 Mensajes de Autorización y Pre autorización

IDTM Tipo de Mensaje De A

1100 1110

Petición de autorización Respuesta a petición autorización

HE HCP

HCP HE

Una Petición de Autorización no permite aplicar en la cuenta del cliente el importe de la transacción autorizada. Requieren un proceso de compensación posterior, realizado mediante un mensaje de Comunicación Contable, que permita realizar un apunte sobre la cuenta del usuario de la tarjeta.

Las siguientes reglas son aplicables a esta clase de Transacciones:

• Los mensajes de petición de Autorización serán utilizados cuando la transacción no se pueda completar en el punto

de servicio hasta que se reciba un mensaje de respuesta donde se indique la acción a tomar.

• Un mensaje de respuesta de petición de Autorización es siempre requerido en respuesta a una petición de Autorización. Este mensaje de respuesta indica la aprobación o garantía de fondos de la acción a ser tomada.

Las operaciones con tarjeta que dan lugar a un Mensaje de Petición de Autorización son:

• Solicitud de Autorización no contable

• Preautorizaciones: Iniciales o de Sustitución

• Operación de verificación de tarjeta, (operación 0 Euros)




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

4.3.1.2.2 Mensajes Contables

IDTM Nombre De A

1200 1210

Petición contable Respuesta petición contable

HE HCP

HCP HE

1220 1221 1230

Comunicación contable Repetición com. contable Respuesta com. contable

HE HE

HCP

HCP HCP HE

Una transacción contable permite aplicar en la cuenta del cliente el importe de la transacción aprobada.

Se utiliza cuando todos los elementos de datos necesarios para autorizar, realizar el apunte en la cuenta del cliente y

efectuar la conciliación, son informados por el HE.

Las siguientes reglas son aplicables a esta clase de transacciones:

• Los mensajes de petición contable serán utilizados cuando la transacción no se pueda completar en el punto de

servicio sin la recepción de un mensaje de respuesta donde se indique la acción a tomar.

• Un mensaje de respuesta de petición contable es siempre requerido en respuesta a una petición contable. Este mensaje de respuesta indica la aprobación o garantía de fondos de la acción a ser tomada.

• Los mensajes de comunicación contable son utilizados para comunicar al HCP de una transacción contable autorizada en modo local por el HE (Ventas offline).

• Los mensajes de comunicación contable son utilizados para comunicar al HCP de una 'Confirmación de

Preautorización' autorizada en modo local por el HE.

• Los mensajes de comunicación contable siempre requieren respuesta, indicando el HCP la aceptación o rechazo de la transacción completada.

Las operaciones con tarjeta que dan lugar a una transacción contable son:

• Adquisición de bienes o servicios (Ventas) (1200-1220/1221)

• Devoluciones (1200)

• Confirmación de preautorización (1220/1221)

Las Devoluciones serán siempre enviadas al HCP como Peticiones Contables.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

4.3.1.2.3 Mensajes de Actualización de Ficheros

IDTM Nombre De A

1304 1305 1314

Petición actualización fichero Repetición Petición Actual. Fichero Respuesta Petición Actual. Fichero

HCP HCP HE

HE HE

HCP

Se utilizan para añadir o borrar registros del fichero de Listas Negras. El elemento de dato Registro de Datos (S-72) se

utiliza para especificar de forma concreta los campos del registro a añadir.

4.3.1.2.4 Mensajes de Anulación Automática

IDTM Nombre De A

1420

1421 1430

Comunicación de Anulación Automática Comunicación de Anulación de Preautorización Comunicación de Anulación de confirmación de preautorización

Repetición Comunic. de Anulación

Respuesta Com. de Anulación

HE

HE

HCP

HCP

HCP

HE

Un mensaje de Anulación es usado para cancelar los efectos de una transacción contable / preautorización o confirmación de preautorización previa. Solo se usarán mensajes de comunicación debido a que la acción ya se ha producido.

Las siguientes reglas se aplicarán en los mensajes de Anulación:

• El mensaje de anulación será iniciado por el HE, indicando la razón en el Código de Función (P-24) = ‘400’

• El mensaje de Anulación de Preautorización será iniciado por el HE, indicando la razón en el Código de Función (P-24) = 481

• El mensaje de Anulación de Confirmación de Preautorización será iniciado por el HE, indicando la razón en el Código de Función (P-24) = 482

• Un mensaje de anulación automática puede ser generado antes de recibir la respuesta al mensaje de Petición

Contable / preautorización o confirmación original que se pretende anular, debiendo tomar el Código de Razón de

Mensaje (P-25) el valor "4006" (indicando vencimiento de temporizaron en la espera de respuesta a la Petición).

Cuando el Código de Razón de Mensaje (P-25) de una anulación toma un valor "4007" indica que el HE ha recibido

una respuesta afirmativa a la Petición Contable que desea anular, pero no se ha podido finalizar la operación en el

punto de servicio (fallo del punto de servicio o cancelación), lo cual permite al HCP aceptar el mensaje de anulación aun cuando no encuentre la operación original correspondiente

• Los mensajes de anulación por vencimiento de temporizador tienen la misma fecha y número de conciliación que la

operación que anulan.

• Los mensajes de anulación no pueden ser rechazados por el HCP, excepto por errores de formato. La inexistencia

de la Petición Contable a anular, provocará que sea ignorada si la razón fue vencimiento de temporizador.

• Un mensaje de anulación automática no puede ser anulado automáticamente.

• Sólo las Peticiones (11xx y 12xx) con Código de Proceso (P-3) "00" (Ventas), y "20" (Devoluciones) en sus dos

primeras posiciones, podrán ser anuladas automáticamente.

• Los mensajes de anulación automática siempre requieren respuesta, indicando el HCP su aceptación o rechazo.

• Las 'Devoluciones' que se produzcan en un establecimiento no son anulaciones. Se deben tipificar como

transacciones de petición contable (1200) con Código de Proceso (P-3) igual a '20' (Devoluciones) en sus dos

primeras posiciones.

• Las Anulaciones Automáticas con Código de Razón de Mensaje (P-25) con valor '4001' sólo podrán ser generadas por producirse 'Cancelación' manual en el Establecimiento y tras la recepción de la respuesta a la operación que anula




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

4.3.1.2.5 Mensajes de Conciliación

IDTM Nombre De A

1520 1521 1530

Comunicación de Conciliación Repetición Comunic. Conciliación Respuesta Comunic. Conciliación

HE HE

HCP

HCP HCP HE

Los mensajes de Conciliación sólo serán utilizados por establecimientos que gestionen las sesiones contables (Cierre y

Conciliación gestionado por el establecimiento)

Los mensajes de conciliación permiten realizar los procesos de compensación, suministrando la información necesaria

para efectuar los movimientos de fondos entre las entidades Merchant y los estableci mientos.

Deberá existir un mensaje de comunicación de conciliación por cada "Código de Identificación de Adquirente" (P-32) diferente en un enlace entre el HE y HCP.

Las siguientes reglas se aplicarán en las conciliaciones:

• Los mensajes de comunicación de conciliación solicitan al HCP confirmación de los totales (Número e Importe)

correspondientes a las operaciones realizadas con la misma fecha, número de conciliación y "Código de

Identificación del Adquirente" (P-28/P-29/P-32) (Sesión Contable).

• Los mensajes de comunicación de conciliación siempre requieren respuesta, indicando al HE la existencia, o no, de acuerdo.

• La recepción de la respuesta por parte del HE, implica el cierre de la sesión contable cuyos totales han sido intercambiados.

El proceso de cierre de una sesión consta de las siguientes fases:

• Apertura de nueva sesión. Utilizar una nueva Fecha y Número de Conciliación (P-28/29) en los mensajes de petición, comunicación y anulación que se generen a partir de ese momento.

• Cierre de la sesión actual. Antes de enviar la comunicación de Conciliación correspondiente a una sesión contable,

el HE deberá haber enviado y recibido respuesta a todas las operaciones con Fecha y Número de Conciliación igual a la del mensaje de Comunicación de Conciliación.

• La recepción de una respuesta de Comunicación Contable (1530) (en acuerdo o desacuerdo) por parte del HE,

indica que la sesión contable ha sido conciliada, recogiéndose en los procesos necesarios para que la entidad Merchant la abone al/los establecimiento(s).

• Se podrá establecer que un Cierre de sesión produzca un único abono o que se generen tantos abonos a comercios

como identificaciones de establecimiento (bit-42) o Identificadores de Cuadre (P-48) diferentes, generen transac-

ciones en una sesión (bit-32).

• Cuando le sea abonado al/los establecimiento/s la sesión conciliada, diremos que la sesión está abonada, siendo éste el último estado de su ciclo de vida.

• El establecimiento no podrá tener más de una sesión abierta, pudiendo estar únicamente otra en proceso de cierre. El HCP responderá con el valor 944 en el campo "Código de Acción " (P-39), cuando reciba un mensaje con Fecha y Número de Conciliación no admitida.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

4.3.1.2.6 Mensajes Administrativos

IDTM Nombre De A

1604 1614

Petición Administrativa Respuesta a Petición Administrativa

HE HCP

HCP HE

1644 Notificación Administrativa Origen Origen

Se utilizan para:

• Mensajes 1604: Solicitar consulta de totales (número e importe) de la sesión en curso y/o de previas (hasta 7 días)

• Mensajes 1644: Reportar la recepción de mensajes "no reconocibles" o "inesperados" y para solicitar al HCP la Actualización de Lista Negra

Las siguientes reglas se aplicarán en los mensajes administrativos:

• Las peticiones administrativas (1604) siempre requieren respuesta (1614), en la que se informa con los datos

solicitados. Este tipo de peticiones nunca es rechazado, excepto por error de formato.

• Los mensajes 1644 nunca requieren respuesta.

4.3.1.2.7 Mensajes de Control de Dialogo

IDTM Nombre De A

1804 1814

Petición de Control de Dialogo

Respuesta Petición Control Dialogo

Origen

Destino

Destino

Origen 1824 1834

Comunicación Control Dialogo Respuesta Com. Control Dialogo

HCP HE

HE HCP

Se utilizan para controlar las condiciones de diálogo entre aplicaciones, salvo el mensaje de test del Diálogo de origen

HE y destino HCP, que puede ser usado para cualquier tipo de enlace, el resto son sólo utilizables cuando existe un

enlace permanente entre HCP y HE.

Se contemplan las siguientes transacciones de control de diálogo:

• Test del Diálogo entre las aplicaciones (1804/1814).

• Comunicación al HE que, por errores de diálogo, la aplicación del HCP pasa el estado de SUSPENSIÓN, lo cual significa tratar sólo mensajes de control de diálogo (1824/1834).

• Solicitar al HE conformidad para pasar al estado de diálogo ACTIVO, una vez subsanados los problemas existentes

(1804/1814).

Mensaje diálogo pregunta Grandes Clientes Pequeño Comercio

Test HE-HCP HCP-HE

SI SI

SI NO

Suspensión HE-HCP

HCP-HE

NO

SI

NO

NO Activación HE-HCP

HCP-HE NO SI

NO NO




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Mapa de Bits El segundo componente del mensaje es el Mapa de Bits, consistente en grupo de 64 bits. Cada bit significa la presencia

(1) o ausencia (0) en el mensaje del elemento de datos a él asociado.

Los primeros 64 bits forman el Mapa de Bits Primario que debe estar siempre presente.

El primer bit del Mapa de Bits Primario indica la presencia (1) o ausencia (0) de un Mapa de Bits Secundario. El Mapa de Bits Secundario solo debe estar presente si el mensaje contiene un elemento de dato numerado a partir del valor 64.

Elementos de Datos

El tercer componente del mensaje está formado por una serie de elementos de datos, los cuales son definidos en el

CAPITULO 7.

Cada elemento de datos está caracterizado por: • Nombre

• Bit asociado

• Tipo, expresado en términos de alfabético, numérico, carácter especial, y binario. • Longitud, expresado en número de posiciones.

• Utilización y significado.

Las abreviaturas utilizadas para describir el Tipo y Longitud del elemento de dato son:

a caracteres alfabéticos (A-Z)

n dígitos numéricos (0-9)

p espacio

s caracteres especiales

an caracteres alfabéticos y numéricos

as caracteres alfabéticos y especiales

ns caracteres numéricos y especiales

anp caracteres alfabéticos, numéricos y espacio

ans caracteres alfabéticos, numéricos y especiales

ansb caracteres alfabéticos, numéricos, especiales y binarios

MM Mes (01-12)

DD Día (01-31)

AA Año (00-99)

hh hora (00-23)

mm minuto (00-59)

ss segundo (00-59)

LL longitud de elemento de dato variable (01-99)

LLL longitud de elemento de dato variable (001-999)

VAR elemento de dato de longitud variable

3 longitud fija, tres caracteres

..17 longitud variable con un máximo de 17 caracteres. Todos los campos de longitud variable contendrán dos o tres posiciones al principio del elemento de dato para indicar el número de posiciones hasta el final de este elemento de dato

X "C" para abono y "D" para cargo, estará asociado con una cantidad numérica

b representación binaria de datos

z conjunto de caracteres de pista 2 tal y como están definidos por ISO 7811/7813 y 3554

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

5. Nivel de Aplicación. Definición de Mensajes




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

5.1 Introducción En este capítulo vamos a definir la composición de cada uno de los mensajes soportados por la interface, utilizando

para ello unas tablas con el siguiente contenido: • Bit asociado al elemento de dato

• Nombre del elemento de dato

• Condición de utilización del elemento de dato, siendo el remitente el HE y el receptor el HCP. • Condición de utilización del elemento de dato, siendo el remitente el HCP y el receptor el HE. • Comentarios de utilización o contenido.

Los códigos de condición de utilización del elemento de dato son:

-- Opcional

O Obligatorio.

OI Obligatorio, deberá contener el mismo valor que el mensaje original.

02 Obligatorio si el dato está disponible y no está presente en Datos de Pista 2 (P-35).

03 Obligatorio, deberá contener el mismo valor que la transacción contable (12xx) original. Aplicable solo en caso de

No realizarse Criptografía de Datos de Tarjeta 05 Obligatorio si la moneda de transacción y conciliación no coinciden y no viaja en el mensaje de pregunta

06 Obligatorio, si pista 2 es capturada en el punto de servicio. En transacciones con PIN online deberá estar

presente. Aplicable solo en caso de No realizarse Criptografía de Datos de Tarjeta 13 Obligatorio en los mensajes de respuesta de conciliación en caso de no existir acuerdo.

16 Obligatorio en el mensaje de respuesta si estaba presente en el mensaje de petición ó comunicación

21 Obligatorio, si la petición contable es denegada o no procesada, si la comunicación contable es rechazada o no procesada, si la anulación es ignorada o no procesada, o en el caso de preautozación AFD si la respuesta a la preautorización es autorizada por un importe inferior al solicitado.

301 Obligatorio en transacciones con PIN, cuando éste aún no ha sido verificado.

303 Obligatorio en mensajes de respuesta de petición de autorización si la transacción es aprobada.

313 Obligatorio si el establecimiento eligió gestionar las sesiones contables.

314 Solo usada de forma obligatoria, si el establecimiento optó por una gestión de sesiones contables centralizadas

en el Centro de Proceso. 315 Obligatorio en mensajes de respuesta a Petición Administrativa y Código de Función P-24 '690', en caso de que

el Código de Acción P-39 tome valor '600' y '660'

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

5.2 Tratamiento de preautorizaciones

Se incluye en el documento el tratamiento de las preautorizaciones:

▪ Preautorización Original. Es la primera operación que se realiza

▪ Preautorización Sustitución Cuando se desee sustituir una preautorización anterior por una nueva con un importe diferente

▪ Confirmación de Preautorización Cierra el ciclo de una preautorización informando el importe definitivo a cargar sobre la cuenta del cliente que nunca podrá ser superar en un 15% al importe autorizado

Mensaje P24 P25 P04 P30 P56

1100 Primera Preautorización

101 - - importe estimado -- - -

1100 Preautorización de Sustitución

103 - - nuevo importe importe sustituido (el de la última preautorización)

RTS de la última preautorización

1220 / 1221 Confirmación Contable de Preautorización

201

202

1377

importe real, (no podrá ser

superior al autorizado de

preautorizaciones

incrementado en un 15 %)

importe inferior al

preautorizado

importe preautorizado RTS de la última

preautorización

1420 / 1421 Anulación de Preautorización

481 4001, 4006 4007

4352 4353

importe Preautorizado -- RTS de la última preautorización

1420 /1421

Anulación de Confirmación de Preautorización

482 4001 4006 4007

4352 4353

importe confirmado en la confirmación que se pretende anular

-- RTS de la Confirmación de Preautorización que se anula

5.3 Tratamiento AFD Para el tratamiento de AFD de preautorizaciones parciales, se crean nuevos campos:

Campo P48.48 (donde se indica que el Terminal que se está solicitando la preautorización está adaptado para realizar el tratamiento de AFD

Nuevo valor en respuesta P39: Valor 010 indicando que el emisor ha aceptado la preautorización, pero con un importe menor al solicitado.

Cambios en campo P04 y P30.

Cuando se responda P39 = 010 que indica que el importe preautorizado es menor al solicitado, se enviará en el P04 el

importe real preautorizado y en el P30 el importe que solicitó el comercio.




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

5.4 Tratamiento AVS. Operativa de verificación tarjeta (0 Euros) Para el tratamiento de AVS de verificación de tarjeta, (0 euros) aparecen nuevos valores:

Aparece un nuevo valor en el campo P24: En el mensaje de petición mensaje 1100 el comercio enviará al host un nuevo valor en el campo P24 = 150.

Aparece un nuevo valor en respuesta P39: Valor 085 indicando que el emisor ha aceptado la comprobación de la tarjeta y es válida

En mensajes de venta que haya existido una operación 1100 AVS previa, el comercio debe mandar el P56 de la operación previa AVS.

5.5 Tratamiento de Credenciales en Archivo. En virtud de los nuevos requerimientos y funcionalidades para la adaptación a la normativa de las marcas

internacionales, cuando un comercio utiliza datos de pago de clientes previamente registrados, las marcas obligan a que se indique dicha operativa.

Las operaciones con credenciales almacenadas son aquellas en las que un titular de una tarjeta autoriza explícitamente a un establecimiento (o facilitador de pagos) a almacenar la información de su tarjeta (PAN y fecha de caducidad o PAN token y fecha de caducidad), y consecuentemente autoriza a dicho establecimiento a usar dichos datos para facturarle.

Para identificar correctamente esta operativa, según la normativa, es necesario incluir cambios en el protocolo unificado de Comercios.

Estas operaciones vendrán marcadas en la posición 9 del P22 con valor = ‘F’ y traerán un nuevo p48.52 con el contenido de los datos

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

5.6 Definición de Mensajes de Petición

Petición de Autorización -1100-

Ruta De HE a HCP

Propósito Pedir aprobación o garantía de fondos para una Solicitud de Autorización.

Respuesta Siempre 1110.

1100 Especificaciones de Formato

Bit Nombre Elemento de Dato HE a HCP Comentarios

Identificador tipo de mensaje O Debe tener el valor "1100"

2 PAN o número de tarjeta -- Identifica la cuenta del titular o una relación con ésta. Solo será obligatorio cuando no se realice Criptografía de Datos de Tarjeta

3 Código de proceso O Especifica el efecto que tendrá la transacción sobre la cuenta asociada

4 Importe transacción O Importe Prefijado (Importe Estimado) en la moneda en que se realiza la transacción.

11 Número identificación transacción O Identifica la transacción de Petición de Autorización, permaneciendo invariable.

12 Fecha hora local de transacción O Tendrá el formato: aammddhhmmss

14 Fecha caducidad 02 Sólo estará presente si se realiza entrada manual de datos desde el relieve de la tarjeta.

22 Datos punto de servicio O Especifica características de la operación y terminal donde se realiza.

23 Numero de Secuencia de la Tarjeta

-- Obligatorio en transacciones realizadas con el Chip de Tarjeta EMV cuando este presente en la tarjeta

24 Código Función O Valor “101” o"103" en preautorizaciones y

Valor “150” para operativa AVS de verificación de tarjeta, (0 euros).

30 Importe Original de la transacción -- Obligatorio en preautorizaciones de sustitución para informar el importe de la preautorización anterior

32 Código Identificación adquirente O Identificación del HE

34 Exenciones PSD2 --

35 Datos pista 2 06 Obligatorio, si Pista 2 en Banda o Pista 2 equivalente en Chip es capturada en el punto de servicio. En transacciones con PIN On-Line deberá estar presente. Aplicable solo en caso de No realizarse Criptografía de Datos de Tarjeta

37 Numero de referencia O Número de operación en el Terminal.

41 Identificación terminal O Número de serie e identificación lógica del terminal.

42 Identificación establecimiento O Identifica, mediante un Código FUC, al establecimiento

48 Información adicional - Información adicional a la Operación.

52 Bloque PIN 301 Deberá ser informado cuando se utilice PIN y no haya sido verificado.

53 Información control de seguridad O Especifica los números de Claves a utilizar y el formato del bloque de PIN.

55 Datos asociados al Chip EMV -- Obligatorio en transacciones realizadas con el Chip de Tarjeta EMV, informando datos específicos del Chip

56 Elementos de Datos Originales -- Obligatorio en preautorizaciones de sustitución para informar la referencia de la preautorización anterior

64 Código autentificación mensaje O Autentifica origen y ciertos datos del mensaje




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Respuesta Petición de Autorización -1110-

Ruta De HCP a HE

Propósito Se enviará como respuesta a una petición de Autorización

Respuesta Ninguna

Comentarios En este mensaje los elementos de datos siguientes deben ser obligatoriamente iguales al mensaje de petición:

• PAN, Número de Tarjeta (P-2).

• Código de Proceso (P-3).

• Número de Identificación de Transacción (P-11).

• Fecha Hora Local de Transacción (P-12).

• Código de Identificación Adquirente (P-32).

• Identificación Terminal (P-41).

• Identificación Establecimiento (P-42).

De los elementos de datos que permanecen invariables durante la Confirmación de Preautorización recomendamos utilizar para el emparejamiento de mensajes petición/respuesta la clave formada por los siguientes datos:

Número de Identificación de Transacción (P-11). Fecha y Hora local de Transacción (P-12).

Código de Identificación de Adquirente (P-32). Identificación Establecimiento (P-42).

El mensaje de respuesta de petición Autorización (1110) proporciona la decisión del HCP aprobando, denegando o rechazando la transacción.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6


Bit Nombre Elemento de Dato HCP a HE Comentarios

Identificador tipo de mensaje O Debe tener el valor "1110"

2 PAN o Número de Tarjeta OI

3 Código de proceso OI

4 Importe Transacción O Deberá ir a cero si no se aprueba la petición.

En operativa AFD podría viajar un importe inferior al solicitado, viajando en el P30 el realmente solicitado.

11 Numero Identificación Transacción

OI

12 Fecha hora local de Transacción OI

30 Importe original Transacción 21 Si se deniega o no procesa la petición, se informará con Importe de Transacción. En operativa AFD autorizada, se informará el importe solicitado inicialmente por el comercio.

32 Código Identificación adquirente OI

38 Numero de autorización 303 Sólo cuando se apruebe la transacción 39 Código acción O Acción a realizar

41 Identificación terminal OI

42 Identificación establecimiento OI

44 Datos adicionales respuesta -- Mensaje a imprimir en el recibo de la operación

48 Información adicional -- Obligatorio cuando el P-39 tiene valor "102"

55 Datos asociados al Chip EMV -- Opcional y en operaciones realizadas con el Chip de Tarjeta EMV, informando datos específicos del Chip

64 Código autentificación mensaje O Autentifica origen del mensaje y algunos datos del mismo




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

5.7 Definición de Mensajes Contables Petición Contable -1200- Ruta De HE a HCP

Propósito Pedir aprobación o garantía de fondos para una transacción contable

Respuesta Siempre 1210

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6



Identificador tipo de mensaje O Debe tener el valor "1200" Mapa de Bits Primario O

2 PAN o número de tarjeta -- Identifica la cuenta del titular o una relación con ésta. Solo será obligatorio cuando no se realice Criptografía de Datos de Tarjeta

3 Código de proceso O Especifica el efecto que tendrá la transacción sobre la cuenta asociada

4 Importe transacción O Importe en la moneda en que se realiza la transacción. Por defecto se expresará en Euros con dos decimales

11 Número identificación transacción O Identifica la transacción de Petición de Autorización, permaneciendo invariable.

12 Fecha/Hora local de transacción O Fecha y Hora en que se inicia la Petición. Tendrá el formato: AAMMDDhhmmss

14 Fecha caducidad 02 Sólo estará presente si se realiza entrada manual de datos desde el relieve de la tarjeta.

22 Datos punto de servicio O Especifica características de la operación y terminal donde se realiza.

23 Número de Secuencia -- Obligatorio en transacciones realizadas con el Chip de tarjetas EMV cuando esté presente en la tarjeta

24 Código Función O Siempre tomará valor '200'

28 Fecha de sesión 313 Identifica junto con el P-29, la sesión a la que pertenece la transacción

29 Número de Sesión 313 Identifica junto con el P-28, la sesión a la que pertenece la transacción

32 Código Identificación Adquirente O Identificación dada al HE


35 Datos pista 2 06 Obligatorio, si Pista 2 en Banda o Pista 2 equivalente en Chip es capturada en el punto de servicio. En transacciones con PIN On-Line deberá estar presente. Aplicable solo en caso de No realizarse Criptografía de Datos de Tarjeta

37 Número de referencia O Número de operación en el Terminal.

41 Identificación terminal O Número de serie e identificación lógica del terminal.

42 Identificación establecimiento O Identifica, mediante un Código FUC al establecimiento

48 Información adicional -- Información adicional a la Operación.

52 Bloque PIN 301 Deberá ser informado cuando se utilice PIN y no haya sido verificado.

53 Información control de seguridad O Especifica los números de Claves a utilizar y el formato del bloque de PIN.

55 Datos asociados al Chip EMV -- Obligatorio en operaciones realizadas con Chip EMV, informando datos específicos del Chip (ver 2.10)

56 Elementos de Datos Originales -- Obligatorio en ventas en las que haya realizado una operación AVS de verificación de tarjeta previa.

64 Código autentificación mensaje O Autentifica origen y ciertos datos del mensaje




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Respuesta a Petición Contable -1210- Ruta De HCP a HE

Propósito Se enviará como respuesta a una petición contable '1200'

Respuesta Ninguna

Comentarios En este mensaje los elementos de datos siguientes deben ser obligatoriamente iguales al mensaje de petición contable • PAN, Número de Tarjeta (P-2). • Código de Proceso (P-3). • Número de Identificación de Transacción (P-11). • Fecha Hora Local de Transacción (P-12). • Código de Identificación Adquirente (P-32). • Identificación Terminal (P-41).

• Identificación Establecimiento (P-42).

De los elementos de datos que permanecen invariables durante la transacción contable

recomendamos utilizar para el emparejamiento de mensajes petición/respuesta la clave formada por los siguientes datos:


Código de Identificación de Adquirente (P-32). Identificación Establecimiento (P-42).

El mensaje de respuesta de petición contable (1210) proporciona la decisión del Host del Centro Procesador aprobando, denegando o rechazando la transacción.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6






4 Importe Transacción O Deberá ir a cero si no se aprueba la petición

11 Número Identificación Transacción

OI

12 Fecha/Hora local de transacción OI

28 Fecha de sesión 314

29 Número de Sesión 314

30 Importe original Transacción 21 Si se deniega o no procesa la petición, se informará con Importe de Transacción

32 Código Identificación Adquirente OI

38 Número de autorización 303 Sólo cuando se apruebe la transacción

39 Código acción O Acción a realizar 41 Identificación terminal OI


44 Datos adicionales respuesta -- Mensaje a imprimir en el recibo de la operación

48 Información adicional -- Obligatorio cuando el P-39 tiene valor '102' y los comprendidos entre '200' y '299'

55 Datos asociados al Chip EMV -- Opcional y en operaciones realizadas con Chip EMV, informando datos específicos del Chip





Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Comunicación Contable (Repetición) -1220- (1221) Ruta De HE a HCP

Propósito Comunicar una transacción contable autorizada en nombre del Centro Procesador


Comentarios Se comunica, mediante este mensaje, al HCP de cualquier transacción contable (Venta o Confirmación de preautorización), aprobada en modo local

A diferencia de los mensajes de petición contable, estos mensajes incorporan la posibilidad de enviar "repeticiones", la forma y el número de repeticiones que se pueden efectuar se detallará en el CAPITULO 6.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

1220-1221 Especificaciones de Formato


Identificador tipo de mensaje O Debe tener el valor "1220-1221" Mapa de Bits Primario O

2 PAN o Número de Tarjeta -- Identifica la cuenta del titular o una relación con ésta. Solo será obligatorio cuando no se realice Criptografía de Datos de Tarjeta

3 Código de proceso O Especifica el efecto que tendrá la transacción y tipo de cuenta afectada.

4 Importe Transacción O Importe en la moneda en que se realiza la transacción. Por defecto se expresará en Euros con dos decimales


O Identifica la transacción de Comunicación de Autorización, permaneciendo invariable.

12 Fecha/Hora local de transacción O Fecha y Hora en que se inicia la Comunicación. Tendrá el formato: AAMMDDhhmmss

14 Fecha caducidad 02 Sólo estará presente si se realiza entrada manual de datos desde el relieve de la tarjeta

22 Datos punto de servicio O Características de la operación y el terminal

23 Número de Secuencia -- Obligatorio en transacciones realizadas con el Chip de tarjetas EMV cuando esté presente en la tarjeta

24 Código Función O Ventas valor "200"

Valores para confirmaciones de preautorización: "201" o “202”

25 Código razón mensaje O Indica la razón que motivó la resolución del HE.



30 Importe Original de la transacción -- Obligatorio en confirmaciones de preautorización. Debe para informar el importe de la preautorización anterior

32 Código Identificación adquirente O Identificación dada al HE


35 Datos pista 2 06 Obligatorio, si Pista 2 en Banda o Pista 2 equivalente en

Chip es capturada en el punto de servicio. En

transacciones con PIN On-Line deberá estar presente. Aplicable solo en caso de No realizarse Criptografía de Datos de Tarjeta

37 Número de referencia O Número de operación del terminal.

38 Número de autorización O Número asignado por el HE en la autorización de la transacción contable.

39 Código acción O Respuesta dada a la petición resuelta.

41 Identificación terminal O Número de serie e identificación lógica del terminal. 42 Identificación establecimiento O Código FUC, Identificativo del establecimiento.

48 Información adicional -- Información adicional a la operación.

53 Información control de seguridad O Identifica número de clave a utilizar en el MAC

55 Datos asociados al Chip EMV -- Obligatorio en operaciones de Venta realizadas con Chip EMV, informando datos específicos del Chip (ver 2.10)

56 Elementos de Datos Originales -- Obligatorio en confirmaciones de preautorización o en ventas en las que haya realizado una operación AVS de verificación de tarjeta previa.





Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Respuesta a Comunicación Contable -1230- Ruta De HCP a HE

Propósito Se enviará como respuesta a una Comunicación de Transacción Contable

Respuesta Ninguna

Comentarios En este mensaje los elementos de datos siguientes deben ser obligatoriamente iguales al mensaje de comunicación contable: • PAN, Número de Tarjeta (P-2). • Código de Proceso (P-3) • Número de Identificación de Transacción (P-11) • Fecha Hora Local de Transacción (P-12) • Código de Identificación Adquirente (P-32) • Identificación Establecimiento (P-42)

De los elementos de datos que permanecen invariables durante la transacción contable recomendamos utilizar para el emparejamiento de mensajes comunicación/respuesta la clave formada por los siguientes datos:


Código de Identificación de Adquirente (P-32).

Identificación Establecimiento (P-42).

El mensaje de respuesta de comunicación contable no aprueba o deniega la transacción financiera realizada, simplemente, mediante los siguientes valores del Código de Acción (P-39) se indica

'900' Aceptación de la comunicación.

'901' Aceptación de la comunicación. El HE deberá incluir la tarjeta en el fichero de Lista Negra, en la posición indicada por él (P-48)

'904' Error formato. La comunicación no podrá ser procesada debiendo resolverse la incidencia detectada por descuadre de sesiones de forma manual. El descuadre se origina al haber sido contabilizada la operación en el HE y no en el HCP

'913' Recepción en el HCP de un Mensaje 1220 duplicado (se ha procesado otro 1220 con el

mismo RTS). Producirá descuadre al haber sido contabilizada por el HE y no por el HCP. El

descuadre deberá resolverse de forma manual '947' Recepción en el HCP de una repetición de comunicación (1221), cuando aún se está

procesando la comunicación (1220/1). Sólo se puede dar como respuesta a mensajes de

repetición y es el único caso, junto con la no recepción de respuesta, en que se debe seguir enviando la comunicación mediante los mensajes de repetición correspondientes. Es decir, el HE ignorará esta respuesta

'950' Rechazo de la comunicación por incumplimiento de norma de resolución local. Producirá

descuadre al haber sido contabilizada por el HE y no por el HCP. El descuadre deberá resolverse de forma manual

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6






4 Importe Transacción O


OI





39 Código acción O Aceptación o rechazo de comunicación contable.



48 Información adicional -- Obligatorio cuando el P-39 toma el valor "901". 64 Código autentificación mensaje O Autentifica origen del mensaje y algunos datos del mismo




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

5.8 Definición de Mensajes de Actualización de Ficheros Petición de Actualización (Repetición) -1304- (1305) Ruta De HCP a HE

Propósito Pedir la actualización de un registro del fichero de Listas Negras


[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6




1 Extensión del Mapa de Bits O


O Identifica la transacción de Petición de Actualización, permaneciendo invariable.

12 Fecha/Hora local de transacción O Fecha y Hora en que se inicia la Solicitud. Tendrá el formato: AAMMDDhhmmss

24 Código Función O

53 Información control de seguridad O Identifica número de clave a utilizar en el MAC 72 Registro de Datos O Contendrá los datos del registro a actualizar

93 Código de Identificación Destino O Identifica el HE, mediante un código asignado por los HCP's

94 Código de Identificación Origen O Identifica al HCP

101 Nombre del Fichero O Nombre del Fichero del que se solicita la actualización 128 Código autentificación mensaje O Autentifica origen del mensaje y algunos datos del mismo




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Respuesta a Petición de Actualización -1314- Ruta De HE a HCP

Propósito Respuesta a una petición de actualización realizada

Respuesta Ninguna

Comentarios En este mensaje los elementos de datos siguientes deben ser obligatoriamente iguales al mensaje de petición

• Número de Identificación de Transacción (P-11) • Fecha y Hora Local de Transacción (P-12)

• Código de Identificación Destino (S-93) • Código de Identificación Origen (S-94)

Siendo los elementos de datos S-94, P-12 y P-11 los utilizados en el emparejamiento pregunta/respuesta

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6






OI Identifica la transacción de Petición de Actualización, permaneciendo invariable.


39 Código de Acción O Indica el resultado de la actualización 72 Registro de Datos O Contendrá la versión del Fichero que se acaba de recibir

93 Código de Identificación Destino OI

94 Código de Identificación Origen OI





Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

5.9 Definición de Mensajes de Anulación Automática Comunicación de Anulación Automática (Repetición) -1420- (1421) Ruta De HE a HCP

Propósito Comunicar la anulación de una transacción contable


Comentarios Este mensaje se generará siempre que • No se pueda completar la transacción en el punto de Servicio habiendo recibido la aprobación de

la Transacción o se ha producido una cancelación manual de la Transacción después de recibir respuesta (P-25 valor "4007").

• Cuando la respuesta se reciba demasiado tarde, bien por vencimiento del Temporizador en una petición contable o por Cancelación manual de una Transacción contable antes de recibir respuesta (P-25 valor "4006").

El emparejamiento de la anulación con la transacción contable que se pretende anular se hará mediante el elemento de datos: • Elementos de datos Originales (P-56).

Pudiéndose realizar este emparejamiento durante el ciclo de vida de la transacción (Ver CAPITULO 6).

Se debe verificar que los siguientes datos tengan el mismo valor que en la transacción contable

original: • PAN, Número de Tarjeta (P-2). • Código de Proceso (P-3) • Importe Transacción (P-4)

• Código Identificación adquirente (P-32) • Identificación terminal (P-41) • Identificación Establecimiento (P-42)

Al igual que los mensajes de comunicación contable, estos mensajes incorporan la posibilidad de enviar "repeticiones", la forma y el número de repeticiones que se pueden efectuar se detallará en el CAPITULO 6.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6




2 PAN o Número de Tarjeta 03 Aplicable solo en caso de No realizarse Criptografía de Datos de Tarjeta

3 Código de proceso 03

4 Importe Transacción 03


O Identifica la transacción de Comunicación de Anulación, permaneciendo invariable.

12 Fecha/Hora local de transacción O Fecha y Hora en que se inicia la anulación. Tendrá el formato: AAMMDDhhmmss

23 Número de Secuencia -- Obligatorio en transacciones realizadas con el Chip de tarjetas EMV cuando esté presente en la tarjeta e igual al mensaje original (12xx)

24 Código Función O Anulación de venta o devolución 400 Anulaciones de preautorización 481 Anulaciones de confirmaciones de preautorización 482

25 Código razón mensaje O Indica la razón que motivó la resolución del HE



32 Código Identificación adquirente 03 Identificación dada al HE por los HCP's 41 Identificación terminal 03

42 Identificación establecimiento 03

48 Información Adicional -- Información adicional a la operación

53 Información control de seguridad O Sólo para el MAC.

55 Datos asociados al Chip EMV -- Obligatorio en operaciones realizadas con Chip EMV en

las que sea requerido informar el Criptograma de Anulación y sus datos asociados y se disponga de ellos (ver 2.10)

56 Elementos de Datos Originales O Datos transacción contable a anular. 64 Código autentificación mensaje O Autentifica origen del mensaje y alguno de sus datos.




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Respuesta a Comunicación de Anulación Automática -1430- Ruta De HCP a HE

Propósito Se enviará como respuesta a una Comunicación de Anulación

Respuesta Ninguna

Comentarios En este mensaje los elementos de datos siguientes deben ser obligatoriamente iguales al mensaje de comunicación de anulación: • PAN, Número de Tarjeta (P-2) • Código de Proceso (P-3) • Número de Identificación de Transacción (P-11) • Fecha Hora Local de Transacción (P-12) • Código de Identificación Adquirente (P-32) • Identificación Establecimiento (P-42)

De los elementos de datos que permanecen invariables durante la transacción de anulación recomendamos utilizar para el emparejamiento de mensajes anulación/respuesta la clave formada por los siguientes datos:

Número de Identificación de Transacción (P-11). Fecha y Hora local de Transacción (P-12). Código de Identificación de Adquirente (P-32). Identificación Establecimiento (P-42).

El Código de Acción (P-39) podrá tomar los siguientes valores:

400 Aceptación de la Anulación

480 Aceptación de la anulación. El HCP no encontró la operación que se quiere anular, pues previsiblemente se adelantó a la transacción de autorización que se quiere anular. Se puede dar este valor en las respuestas de anulaciones iniciadas por vencimiento de temporizador o por Cancelación manual antes de recibir respuesta

481 Aceptación de la anulación. El HCP no encontró la operación que se quiere anular. Se dará este código como respuesta a una anulación generada por causa distinta a la temporización. Por ejemplo cuando se quiere aceptar anulaciones de operaciones muy antiguas. (Toma valor 914 cuando se desee denegar la anulación)

904 Indica que la anulación no podrá ser procesada por el HCP por error de formato. Se resolverá la incidencia de forma manual, siendo detectado en el descuadre de sesión que produce.

913 Recepción en el HCP de un Mensaje 1420 duplicado (se ha procesado otro 1420 con el

mismo RTS). Producirá descuadre al haber sido contabilizada por el HE y no por el HCP. El descuadre deberá resolverse de forma manual.

914 Denegación de la Anulación. El HCP no encontró la operación que se quiere anular o ya esté anulada con distinto RTS como respuesta a una anulación generada por causa distinta a la temporización (Ver 481)

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6






4 Importe Transacción O


OI





39 Código acción O Aceptación o rechazo de comunicación de anulación







Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

5.10 Definición de Mensajes de Conciliación Comunicación de Conciliación (Repetición) -1520- (1521) Ruta De HE a HCP

Propósito Conciliar, a nivel de Establecimiento o Negocio/Proveedor de servicio, las operaciones realizadas durante la sesión contable en curso, provocando su cierre. Sólo será generado por aquel HE que haya seleccionado la opción de Gestión de Cierre por el establecimiento


Comentarios Antes de enviar los mensajes de Conciliación, el HE deberá: • Efectuar el cierre de la sesión en curso, abriendo una nueva, lo que significa que las

transacciones contables y anulaciones (no debidas a Respuesta recibida fuera de tiempo) que se inician a partir de ese momento, contendrán una nueva Fecha de y número de conciliación.

• Haber enviado y recibido respuesta de todas las transacciones contables y anulaciones con igual fecha y número de conciliación que se cierra.

• Haber enviado y recibido respuesta de todas las anulaciones debidas a temporización de transacciones contables debidas a Respuesta recibida fuera de tiempo con igual fecha y número de conciliación que se cierra.

El procedimiento de obtención de totales, número e importe, del mensaje de comunicación de

conciliaciones se describe en el punto 6.4.6.1 y está basado: • En las transacciones contables (1200/1210), el HE actualizará el acumulador correspondiente (P-

88) con el importe de la transacción (P-4) recibido en el mensaje respuesta (1210). Además, cuando este importe (P-4) sea distinto de cero, se incrementará en uno el contador del número de

operaciones correspondiente (P-76). • En las respuestas a transacciones contables (1210) recibidas después de haber vencido el

temporizador no serán contabilizadas ni en totales ni en contadores. • En las transacciones de comunicación contable (1220/1230) y anulaciones contables (1420/1430),

se incrementará el contador y se acumulará el importe de la transacción (P-4), en el momento de generar el mensaje de comunicación (1220 o 1420) que inicia la transacción, salvo los 1420

generados por vencimiento de temporizador o cancelación manual antes de recibir respuesta que

nunca afectan a los contadores ni totales.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6




1 Extensión del Mapa de bits O


O Identifica la transacción de autorización, permaneciendo invariable.

12 Fecha/Hora local de transacción O Fecha y Hora en la que inicia la Conciliación Tendrá el formato: AAMMDDhhmmss

28 Fecha de sesión O Identifica, junto P-29 la sesión de la que se comunica el cierre

29 Número de sesión O Identifica, junto P-28 la sesión de la que se comunica el cierre

32 Código identificación Adquirente O Identificación dada al HE por los HCP's

48 Datos privados Adicionales O Obligatorio, cuando el Establecimiento tenga que especificar el Banco/ Sucursal y cuenta de abono o se trabaje en entorno Multibancario o el Abono se realice a nivel de Identificativo de Cuadre.

62 Datos privados Adicionales 2 O Obligatorio, cuando el Establecimiento trabaje en entorno Multibancario o el Abono se realice a nivel de Identificativo de Cuadre y el número de 'Datos de Abono en Entorno Multibancario' supere los 25 elementos

74 Abonos, Numero O Número total de Transacciones contables (12xx) con Código de Proceso "20-29".

75 Abonos, Numero de Anulaciones O Nº total de anulaciones automáticas (14xx) de Peticiones Contables (1200) con Código de Proceso "00-19".

76 Cargos, Numero O Nº total de Transacciones contables (12xx) con Código de Proceso "00-19".

77 Cargos, Numero de Anulaciones O Nº total de anulaciones automáticas (14xx) de Peticiones Contables (1200) con Código de Proceso "20-29"

86 Abonos, Importe O Importe total de Transacciones contables (12xx) con Código de Proceso "20-29".

87 Abonos, Importe de Anulaciones O Importe total de anulaciones automáticas (14xx) de Peticiones Contables (1200) con Código de Proceso 00-19

88 Cargos, Importe O Importe total de Transacciones contables (12xx) con Código de Proceso "00-19".

89 Cargos, Importe de Devoluciones O Importe total de anulaciones automáticas (14xx) de Peticiones Contables (1200) con Código de Proceso 20-29

97 Importe Total O Importe intercambiado en la sesión contable




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Respuesta a Comunicación de Conciliación -1530- Ruta De HCP a HE

Propósito Se enviará como respuesta a una Comunicación de Conciliación, informándose del acuerdo o desacuerdo con los totales recibidos. También podrán contener el valor de las comisiones a aplicar y el Neto a abonar al Establecimiento

Respuesta Ninguna

Comentarios En este mensaje los elementos de datos siguientes deben ser obligatoriamente iguales al mensaje de petición de conciliación • Código de Proceso (P-3)

• Número de Identificación de Transacción (P-11) • Fecha Hora Local de Transacción (P-12) • Fecha de Conciliación (P-28)

• Número de Conciliación (P-29) • Código de Identificación Adquirente (P-32)

De los elementos de datos que permanecen invariables durante la transacción de conciliación

recomendamos utilizar para el emparejamiento de mensajes conciliación/respuesta la clave formada por los siguientes datos: Número de Identificación de Transacción (P-11).

Fecha y Hora local de Transacción (P-12).

Código de Identificación de Adquirente (P-32).

El Código de Acción (P-39) tomará valores:

"500" Acuerdo

"501" Desacuerdo

"503" Totales No disponibles

"560" Acuerdo. Encadenar con solicitud de LN

"561" Desacuerdo. Encadenar con solicitud de LN

"563" Totales No disponibles. Encadenar con solicitud de LN

"580" Datos de Abono erróneos.

"581" Datos de Abono erróneos. Encadenar con solicitud de LN

El HE deberá considerar cerrada la sesión contable cuando reciba una respuesta de Conciliación (1530) con cualquiera de los valores definidos en el P-39

Con el fin de que el HCP conteste a todos los mensajes 1520, deberá contestar con Código de Acción (P-39), con valor 503-563 y 580-581, en caso de fallo de acceso o fallo de sistema

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6






OI

12 Fecha y hora local de Transacción mensaje

OI

28 Fecha de sesión OI

29 Número de sesión OI

32 Código identificación Adquirente OI

39 Código Identificación Adquirente O Identifica la existencia de acuerdo o desacuerdo

48 Datos privados Adicionales O

74 Abonos, numero 13

75 Abonos, número de anulaciones 13

76 Cargos, numero 13

77 Cargos, número de anulaciones 13

86 Abonos, importe 13

87 Abonos, importe de anulaciones 13

88 Cargos, importe 13

89 Cargos, importe de devoluciones 13

97 Importe total O




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

5.11 Definición de Mensajes Administrativos Petición Administrativa -1604- Ruta De HE a HCP

Propósito Este tipo de mensajes se utiliza para Solicitar los totales (Número e Importe) correspondientes a la sesión contable en curso o anteriores


Comentarios La Solicitud de Totales no debe ser utilizada para detectar descuadres contables, ya que las transacciones contables en curso pueden contener diferencias entre los totales del HE y los del HCP

El HE informará el motivo de Petición Administrativa en el Elemento de Dato 'Código de Función' (P- 24), que podrá tomar los siguientes valores

690 Solicitud de Totales de la sesión Contable en curso

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6




1 Extensión del Mapa de bits 316


O Identifica la transacción.

12 Fecha/Hora local de transacción O Fecha y Hora en que se inicia la petición administrativa. Tendrá el formato: AAMMDDhhmmss

24 Código Función O Identifica el propósito del mensaje



32 Código Identificación adquirente O Identificación dada al HE por los HCP's




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Respuesta a Petición Administrativa -1614- Ruta De HCP a HE

Propósito Enviar los datos solicitados en la Petición Administrativa

Respuesta Ninguna.

Comentarios Los elementos de datos que deben permanecer invariables en el mensaje de respuesta son:

• Número de Identificación de Transacción (P-11)

• Fecha y Hora Local de Transacción (P-12) • Código de Identificación de Adquirente (P-32)

Siendo los elementos de datos P-32, P-12 y P-11 los utilizados para realizar el emparejamiento con la petición

El HCP responderá con Código de Acción (P-39) con los siguientes valores

600 Aceptación

604 No es posible encontrar los totales que se solicitan

660 Aceptada, encadenar con Solicitud de Lista Negra

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6






OI

12 Fecha y hora local de Transacción mensaje

OI

28 Fecha de sesión OI

29 Número de sesión OI

32 Código identificación Adquirente OI

39 Código de Acción O

72 Registro de Datos 318

74 Abonos, numero 315

75 Abonos, número de anulaciones 315

76 Cargos, numero 315

77 Cargos, número de anulaciones 315

86 Abonos, importe 315

87 Abonos, importe de anulaciones 315

88 Cargos, importe 315

89 Cargos, importe de devoluciones 315

97 Importe total 315




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Notificación Administrativa -1644-

Ruta De HE a HCP

De HCP a HE Propósito • Notificar la recepción de un mensaje "no reconocible" ó "inesperado".

• Solicitar al HCP una Actualización de Lista Negra

Respuesta Ninguna. Ahora bien, en el caso de Solicitar Actualización de Lista Negra, el HE esperara el envío desde el HCP de un 1304, con otro RTS. En caso de producirse un vencimiento de time-out sin respuesta del HCP, el HE podrá enviar un nuevo 1644

Comentarios En el CAPITULO 6 se aborda en profundidad la utilización de este mensaje

El HCP responderá con Código de Acción (P-39) con los siguientes valores

687 No es posible reconocer el mensaje recibido

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6


Bit Nombre Elemento de Dato HE a HCP HCP a HE Comentarios

Identificador de Tipo de Mensaje O O Debe tener valor '1644' Mapa de Bits Primario O O

1 Extensión del Mapa de Bits O O

11 Número de Identificación Transacción

O O Identifica la notificación administrativa permaneciendo invariable

12 Fecha/Hora Local de Transacción O O Fecha y Hora en la que inicia la notificación Tendrá el formato: AAMMDDhhmmss

24 Código de Función O O Identifica la función del mensaje de control valor 689 o 691

39 Código de Acción O O Motivo de la notificación

72 Registro de Datos O O Datos del mensaje que originó la notificación o Versión y tamaño de Lista Negra

93 Código de Identificación Destino O O Identificación del Host que recibirá el mensaje. Puede tomar valor ceros cuando sea desconocido

94 Código de Identificación Origen O O Identificación del Host que envía el mensaje




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

5.12 Definición de Mensajes de Control de Dialogo Petición de Control de Dialogo -1804-

Ruta De HE a HCP

De HCP a HE Propósito Realizar un test del diálogo de aplicación o solicitar la reanudación del diálogo previamente

suspendido. Se utilizan para controlar las condiciones de diálogo entre aplicaciones, excepto el mensaje de test iniciado por el HE que puede ser utilizado por cualquier tipo de enlace (Permanentes o Conmutados), el resto sólo existirá en enlaces permanentes entre HCP y HE.


Comentarios Se enviará siempre que se desee. Los mensajes de Control de Diálogo referente a reanudación de diálogo, sólo pueden ser iniciados por el HCP

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6






O O Identifica la Petición de Control de Dialogo permaneciendo invariable

12 Fecha/Hora Local de Transacción O O Fecha y Hora en la que inicia la Petición Tendrá el formato: AAMMDDhhmmss

24 Código de Función O O Identifica la función del mensaje de Petición de Control de Dialogo

93 Código de Identificación Destino O O Identificación del Host que recibirá el mensaje.





Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Respuesta a Petición de Control de Dialogo -1814- Ruta De HE a HCP

De HCP a HE

Propósito Responder a la petición de control de diálogo y al mismo tiempo informar los datos de la sesión más actual

Respuesta Ninguna.

Comentarios Los elementos de datos que deben permanecer invariables en el mensaje de respuesta son: • Número de Identificación de Transacción (P-11) • Fecha y Hora Local de Transacción (P-12)

• Código de Identificación Destino (S-93) • Código de Identificación Origen (S-94)

Siendo los elementos de datos S-94, P-12 y P-11 los utilizados para realizar el emparejamiento con la petición

En este mensaje de respuesta se incluyen la Fecha y Número de Conciliación de la sesión más actual

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6






OI OI Identifica la Petición de Control de Dialogo permaneciendo invariable

12 Fecha/Hora Local de Transacción OI OI Fecha y Hora en la que inicia la Petición Tendrá el formato: AAMMDDhhmmss

28 Fecha de Conciliación O O Solo usado de forma obligatoria en los mensajes de Test

29 Numero de Conciliación O O Solo usado de forma obligatoria en los mensajes de Test

39 Código de Acción O O Indica aceptación o imposibilidad de proceso

93 Código de Identificación Destino OI OI

94 Código de Identificación Origen OI OI




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Comunicación de Control de Dialogo -1824- Ruta De HCP a HE

Propósito Comunicar Suspensión del diálogo. Se utilizan para controlar las condiciones de diálogo entre

aplicaciones, siendo sólo utilizable cuando existe un enlace permanente entre HCP y HE. Respuesta Siempre 1834

Comentarios El mensaje de comunicación de control de diálogo sólo será enviado por la aplicación del HCP. Este

mensaje será utilizado para comunicar un cambio de estado en la aplicación del HCP, la cual podrá

migrar al estado de diálogo suspendido (suspensión)

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6






O Identifica la transacción de Comunicación de Control de Dialogo, permaneciendo invariable.

12 Fecha/Hora local de transacción O Fecha y Hora en que se inicia la Comunicación. Tendrá el formato: AAMMDDhhmmss

24 Código Función O Indica mediante un valor '88x' el motivo de la suspensión

93 Código de Identificación Destino O Identifica el HE, mediante un código asignado por los HCP's

94 Código de Identificación Origen O Identifica al HCP




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Respuesta a Comunicación de Control de Dialogo -1834- Ruta De HE a HCP

Propósito Responder a la comunicación de control de diálogo.

Respuesta Ninguna

Comentarios Los elementos de datos que deben permanecer invariables en el mensaje de respuesta son:


• Fecha y Hora Local de Transacción (P-12) • Código de Identificación Destino (S-93) • Código de Identificación Origen (S-94)

Siendo los elementos de datos S-94, P-12 y P-11 los utilizados para realizar el emparejamiento con la petición.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6






OI


39 Código de Acción O Indica la recepción del mensaje de comunicación 93 Código de Identificación Destino OI

94 Código de Identificación Origen OI




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

6. Nivel de Aplicación. Definición de Procesos

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

El Nivel de Aplicación del sistema informático del Host de establecimiento (HE) debe contemplar una aplicación con las siguientes funciones:

Transferencia de datos

Correspondiente al intercambio de mensajes originados, directa o indirectamente, por la utilización de la tarjeta como medio de pago, es decir, mensajes 12xx, 13xx, 14xx, 15xx y 16xx.

Test del diálogo

En enlaces permanentes permite verificar la existencia de conexión entre las aplicaciones. Se utilizarán mensajes 18xx.

Suspensión/Reanudación del Diálogo

Permite que las aplicaciones del HE puedan, ante condiciones excepcionales, suspender temporalmente el diálogo establecido, reanudándolo una vez subsanadas las condiciones de error. Se soporta mediante mensajes 18xx.

6.1 Transacción de Sistema Aunque ya definimos, desde el punto de vista ISO 8583 el concepto de transacción queremos definir con claridad lo que nuestros sistemas informáticos entienden por transacción.

Una Transacción de Sistema es una agrupación de mensajes de la misma clase que tiene una identificación única. Según esto tendremos los siguientes tipos de Transacciones de Sistema:

Preautorizaciones Peticiones Contables

1100/1110 1200/1210

Comunicación Contable 1220/1221/1230 Actualización Ficheros 1304/1314 Comunicaciones de Anulación Automática 1420/1421/1430 Conciliación 1520/1521/1530 Petición administrativa 1604/1614/1644 Notificación Administrativa/Solicitud Actualización Lista Negra 1644 Control de diálogo, Test y Reanudación 1804/1814 Control de diálogo, Suspensión 1824/1834

La identificación de una transacción de Sistema está formada por los siguientes datos: • Código de Identificación de Adquirente (P-32) o Código de Identificación de Origen (S-94), según clase de

mensajes

• Identificación de Establecimiento (P-42), si está presente

• Fecha y Hora local de Transacción (P-12)


A partir de ahora la identificación de una Transacción de Sistema la denominaremos Referencia de Transacción de

Sistema (RTS), que identifica de forma única una Transacción de Sistema.

Los componentes de la Referencia de Transacción son asignados por el iniciador de la transacción, y aunque la repetición de todos los componentes es muy difícil, el iniciador de la transacción no debe duplicar el Número de Identificación de Transacción (P-11) durante un periodo de "24 Horas", con lo que se asegura la existencia de una única RTS por transacción de sistema.

Con el fin de controlar la integridad de las anulaciones y de detectar posibles transmisiones duplicadas, el HCP guardará, utilizando la RTS como clave, todas las transacciones durante un cierto tiempo. A este periodo de tiempo se le denominará Ciclo de Vida de la Transacción de Sistema y su duración no será inferior a 7 días naturales.

En relación con el Ciclo de Vida se verificará:

• El HCP rechazará, como duplicado, cualquier mensaje con Referencia de Transacción de Sistema coincidente con

una ya asignada a otra transacción.

• El HCP admitirá anulaciones que referencien en Elementos de Datos Originales (P-56) a una RTS asignada a una transacción cuyo Ciclo de Vida no haya expirado.

• Al final del Ciclo de Vida la Referencia de Transacción desaparece, rechazándose las anulaciones, mediante un

Código de Acción (P-39) igual a "914" ó aceptándose con el "481", que la referencien a través de Elementos de Datos Originales (P-56).




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

6.2 Temporizadores (Time-Out) La detección y recuperación de errores de diálogo en la aplicación se basa en la utilización de Temporizadores, los

cuales detectan la ausencia de respuesta a un mensaje de petición o comunicación en un periodo de tiempo

predefinido.

Los valores de los Temporizadores serían:

TN1 En mensajes 1200 30 sg.

TN2 En mensajes 1220, 1420 10 sg


TN4 En mensajes de repetición 40 sg.


TN6 En mensajes 1604/1644 40 sg.

TC1 En mensajes de TEST 10 sg.

TC2 En mensajes de SUS/REA 40 sg.

Estos valores se estudiarán con más rigor, llegándose a valores definitivos tras el proceso de certificación.

El comportamiento de la aplicación del HE ante TIME-OUT de los distintos temporizadores será:

TN1 Generará automáticamente una anulación (1420) con el valor "4006" en el Código de Razón de Mensaje (P-25).

TN2 Generará automáticamente la correspondiente repetición 1221 o 1421

TN3 Generará la correspondiente repetición 1521

TN4 Repetir automáticamente los mensajes de "repetición", según se especifica en 6.4.4.1

TN6 Volver a generar el mensaje de petición administrativa o de Solicitud de Actualización de Lista Negra

TC1 Enviar otro, notificando lo sucedido al Centro de Gestión de Red del establecimiento

El comportamiento del HCP ante Time-out de los distintos temporizadores será:

TN5 Volver a generar el mensaje 1304

TC2 Comunicar al Centro de Gestión de Red.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

6.3 Reconocimiento y Validación de Mensajes Por cada mensaje recibido, las aplicaciones dialogantes realizarán validaciones de presencia y contenido de cada uno de los elementos de datos del mensaje, comprobando que cumple las reglas descritas en los CAPÍTULOS 5 y 7. Si el mensaje no superase estas validaciones no comenzará el proceso del mismo, siendo respondido e ignorada su recepción.

Ante la recepción de un mensaje de petición/comunicación (1x0x/1x2x) no conforme a lo expuesto en los CAPÍTULOS 5 y 7, las aplicaciones del HE y HCP enviarán el mensaje de respuesta correspondiente (1x1x/1x3x) con el valor "904" en el Código de Acción (P-39), excepto si no fuera posible formatear la respuesta, en cuyo caso se enviará un mensaje de notificación (1644).

Consideramos que no será posible formatear el mensaje de respuesta cuando alguno de los siguientes elementos de

datos no esté de acuerdo con lo expuesto en los CAPÍTULOS 5 y 7:

• Identificador de Tipo de Mensaje

• Mapa de Bits (P-1)

• PAN, Número de Tarjeta (P-2)

• Código de Proceso (P-3)

• Importe de la Transacción (P-4)

• Número de Identificación de la Transacción (P-11)

• Fecha y Hora Local de la Transacción (P-12)

• Código de Identificación de Adquirente (P-32)

• Identificación del Establecimiento (P-42)

• Código de Identificación de Origen (S-94)

Ante la recepción de un mensaje de respuesta (1x1x/1x3x) no conforme a lo expuesto en los CAPÍTULOS 5 y 7 las aplicaciones del HE y HCP enviarán un mensaje de notificación (1644), pudiendo este hecho producir descuadre en la posterior conciliación de la sesión.

Cuando el HE o HCP reciban mensajes de respuesta (1x1x/1x3x) con un Código de Acción (P-39) con valores '902-949', se realizará el siguiente proceso:

• Considerar, en respuestas de peticiones contables (1210), la operación como no autorizada y por consiguiente no

actualizar totales. Se informará lo ocurrido al Centro de Gestión de Red.

• Si es una respuesta a un mensaje de comunicación de autorización, contable, anulación, conciliación o administrativa (1130, 1230, 1430, 1530, 1634), no repetir el envío e informar al Centro de Gestión de Red para su

posible liberación manual.




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

6.4 Descripción de la Transferencia de Datos Describimos en este punto características de funcionamientos y elementos que intervienen en la Transferencia de Datos

entre las aplicaciones del HE y HCP.

Dentro del término Transferencia de Datos englobamos todo el intercambio de mensajes derivado de la realización de transacciones:

Preautorizaciones Peticiones Contables

1100/1110 1200/1210

Comunicación Contable 1220/1221/1230 Actualización Ficheros 1304/1314 Comunicaciones de Anulación Automática 1420/1421/1430 Conciliación 1520/1521/1530 Petición administrativa 1604/1614 Solicitud Actualización Lista Negra 1644

No se incluye la transacción de sistema Notificación Administrativa, porque lo único que se hace ante la recepción de un mensaje 1644 con este fin es almacenarlo, para analizar posteriormente la causa que lo originó.

Tampoco se incluyen en este apartado las transacciones de Control de Diálogo, ya que el tratamiento de este tipo de transacciones debe realizarse en un nivel distinto, pues pueden influir en el comportamiento general de la aplicación. De hecho la recepción, en la aplicación del HE, de un mensaje de control de diálogo (1824), comunicando la transición al estado de Diálogo Suspendido, provocará que la aplicación del HE suspenda el envío de mensajes al HCP, resolviendo en local (si es soportado) todas las peticiones contables que le lleguen desde los Terminales Punto de Venta.

Autorización Efectiva La manipulación de los mensajes de petición contable (1200) se basa en el concepto de Autorización Efectiva, lo cual implica que el HCP asume, en el momento de generar la respuesta, que la transacción será completada normalmente en el punto de servicio, a no ser que le sea comunicado lo contrario, mediante una anulación (1420).

Seguridad de Transporte La manipulación de mensajes de comunicación de autorización contable, anulación, conciliación y administrativa (1220, 1420, 1520, 1624) se basa en el concepto de Seguridad de Transporte, lo cual implica que el HE asegura el envío de esta clase de mensajes. Si tras repetidos intentos no se lograra un envío se deberá proceder a su comunicación al HCP por algún método alternativo (Ver 6.4.6).

Para el envío de los mensajes de esta clase recomendamos la utilización de un procedimiento de Envío Controlado, de tal forma que el número de transacciones en curso no sea superior a seis.

Garantía de Respuesta

El HCP y el HE garantizan el envío del mensaje de respuesta apropiado a cualquier mensaje donde éste sea requerido. Por supuesto esta garantía no alcanza a posibles interrupciones de comunicaciones.

El HCP establece unos temporizadores en la ampliación que permitan reducir el número de respuestas fuera de tiempo en el HE.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Garantía de Comunicación de Autorizaciones En el caso de que el establecimiento realice, como consecuencia de una indisponibilidad transitoria, autorizaciones en modo local, se debe garantizar el envío al HCP de:

• Los mensajes de anulación (1420), en caso de haberse enviado el mensaje de petición contable original (1200).

• El mensaje de comunicación contable (1220) en el caso de haber aprobado la petición contable de forma local.

Mensajes de Repetición Se soportan mensajes de repetición para los mensajes de comunicación (1220, 1420), para los mensajes de actualización de ficheros (1304) y para los mensajes de comunicación de conciliación (1520)

Estos mensajes deben ser idénticos al mensaje original con excepción del Identificador de Tipo de Mensaje.

Cuando un mensaje de repetición es recibido por la aplicación del HCP o del HE, se comprobará la existencia del mensaje original, utilizándose para ello la Referencia de la Transacción de Sistema. Si se encuentra se retransmitirá la respuesta dada al mensaje de comunicación original, en caso contrario se tratará de la misma forma que si del mensaje original se tratara.

La aplicación del HE deberá generar mensajes de repetición ante un time-out en un mensaje de comunicación contable (1220/1), en una anulación (1420/1), en un mensaje de conciliación (1520) y también se deberá enviar "repetición" ante la recepción de una respuesta de comunicación contable, de anulación, de conciliación o administrativa (1230, 1430, 1530), con código de acción (P-39) "947".

En el epígrafe 6.4.6 se detalla la periodicidad y número de los mensajes de "repetición".

Definición Formal del Dialogo HE-HCP

En este epígrafe, mediante diagramas de transición de estados, se va a describir el procedimiento a seguir por el Nivel de Aplicación del Host del Establecimiento en la Transferencia de Datos.

El diagrama de transición de estados está realizado con las siguientes características:

Se asume la existencia de un "Estado" asociado a cada Referencia de Transacción de Sistema (RTS).

Se definen los "Eventos" que causan el paso de un estado a otro. Básicamente estos "Eventos" serán mensajes

recibidos o Time-Outs.

Se definen también las distintas "Acciones" a realizar por la aplicación del HE en función del "Evento" producido y el "Estado".

Los símbolos utilizados son:

ESTADO 1

EVENTO QUE CAUSA LA TRANSICIÓN DE ESTADO --- ACCIÓN A SER TOMADA

ESTADO 2




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

EVENTO

-- (7-8)

ACCION

ESPERA

1530

ESPERA

1614

CON ANULACIÓN

EVENTO

-- (3)

ACCION

ESPERA 1210

EVENTO -- ACCION

NO ASIGNADO

6.4.1.1 Diagrama de Transición de Estados, en fase de Dialogo Activo de la Aplicación del HE

El diagrama de transición de estados se ha realizado suponiendo que los mensajes recibidos han superado las

validaciones de reconocimiento expuestas el epígrafe 6.3, comen zando por tanto su proceso, y además el diálogo está ACTIVO.

Aunque no se refleja en el Diagrama de Transición de Estados, se debe tener presente que mientras un Establecimiento se encuentre en situación de conciliación, no deberán producirse transacciones en que esté involucrado.

Con el fin de garantizar la no utilización del mismo RTS para dos transacciones, la aplicación del HE deberá utilizar un

temporizador de 24 horas que se activará al asignarse un RTS a una transacción.

EVENTO -- ACCION

(14)

EVENTO -- ACCION

(13)

EVENTO

EVENTO

-- ACCION

(11)

-- ACCION

(12)

EVENTO

-- ACCION

(15)

EVENTO

EVENTO

--

ACCION

(16)

NO

LIBERADO -- ACCION

(18)

EVENTO -- ACCION

(18)

EVENTO -- (4)

ACCION

EVENTO -- ACCION

(1)

EVENTO

-- (2)

ACCION

EVENTO

-- ACCION

(5) EVENTO

-- ACCION

(6)

(9)

EVENTO --

ACCION

(10)

EVENTO

-- (17)

ACCION

EVENTO

-- (7-8)

ACCION

ESPERA

1230

EVENTO

-- (7-8)

ACCION

ESPERA 1430

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

EVENTO/ACCIÓN (1). ENVIÓ PETICIÓN CONTABLE (1200).

Se asigna este RTS a un mensaje 1200 a enviar, como consecuencia de la recepción de una operación de un Terminal Punto de Venta.

--

Inicializar el Temporizador de 24 horas. Inicializar el Temporizador TN1.

Enviar el mensaje 1200.

EVENTO/ACCIÓN (2). RECEPCIÓN RESPUESTA PET. CONTABLE (1210).

Recepción de un mensaje 1210 con este RTS.

--

Sumar el Importe de Transacción (P-4) al elemento de datos Cargos Importe (S-88). En caso de que este importe sea distinto de cero, Sumar "1" al elemento de datos Abonos, Número (S-74) o a Cargos, Número (S-76), según se trate de una Devolución o Venta.

Sumar Importe de Transacciones (P-4) al elemento de datos Abonos, Importe (S-86) o a Cargos, Importe (S-88), según se trate de una Devolución o Venta

Generar respuesta apropiada hacia el Terminal. Si por cualquier causa no se pudiera encaminar la respuesta al Terminal o éste no pudiera completar la transacción, siendo ésta afirmativa, se deberá generar un mensaje de Comunicación de anulación (1420) con otro RTS y con el Código de Razón de Mensaje P-25 con el valor "4007". Ver Evento/Acción (9) Cancelar Temporizador TN1.

EVENTO/ACCIÓN (3). TIME-OIT PETICIÓN CONTABLE.

Temporizador TN1 expirado.

--

Realizar proceso de Resolución Local. Generar respuesta apropiada hacia el Terminal.

Si se autoriza la transacción generar con otro RTS un mensaje de comunicación contable (1220) con Código de Razón (P-25) igual a "1002". Ver evento (5). Enviar mensaje de comunicación de anulación (1420) con otro RTS y con el valor "4006" en el Código de Razón de Mensaje (P-25). Ver evento/Acción (9).

EVENTO/ACCIÓN (4). RESPUESTA PET. CONTABLE (1210) FUERA DE TIEMPO.


--

Ignorar su recepción.

EVENTO/ACCIÓN (5). ENVIÓ DE COMUNICACIÓN CONTABLE (1220).

Se asigna este RTS a un mensaje 1220 a enviar, como consecuencia de la Resolución Local de una operación de Venta o Confirmación de preautorización. Al utilizar para el tratamiento de este tipo de mensajes un procedimiento de Envío Controlado de Comunicaciones, antes de enviar un mensaje 1220 debemos asegurarnos que no están en proceso más de cinco transacciones de comunicación (1220/1/1230) o de anulación (1420/1/1430).

--

Inicializar el Temporizador de 24 horas. Inicializar el Temporizador TN2. Inicializar Contador de "repeticiones" a cero. Sumar "1" al elemento de datos Abonos, Número (S-74) o a Cargos, Número (S-76), según se trate de una Devolución o Venta autorizada en local. Sumar Importe de Transacciones (P-4) al elemento de datos Abonos, Importe (S-86) o a Cargos, Importe (S-88), según se trate de una Devolución o Venta autorizada local. Enviar el mensaje 1220.




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

EVENTO/ACCIÓN (6). RECEPCIÓN RESPUESTA COM. CONTABLE (1230).


--

Procesar el mensaje 1230. Cancelar Temporizador TN2.

EVENTO/ACCIÓN (7). TIME-OUT 1220/1, 1420/1, 1520/1 O RESPUESTA CON P-39 = 947

Temporizador TN2, TN3 o TN4 expirado o Código de Acción (P-39) de mensaje respuesta con valor 947 y Contador de "repeticiones" no múltiplo de diez.

--

Cambiar Identificador de Tipo de Mensaje a 1221, 1421 o 1521.

Incrementar Contador de "repeticiones". Inicializar Temporizador TN4. Re-Enviar mensaje.

EVENTO/ACCIÓN (8). TIME-OUT 1220/1, 1420/1, 1520/1 O RESPUESTA CON P-39 = 947

Temporizador TN2, TN3 o TN4 expirado o Código de Acción (P-39) de mensaje respuesta con valor 947 y Contador de "repeticiones" múltiplo de diez.

--

Notificar situación al Centro de Gestión de Red del HE.

Si se considera oportuno y previa comunicación con el Centro Procesador, liberar manualmente el mensaje que está

siendo re-enviado, finalizando el bucle de repeticiones. En el Anexo G se describe el procedimiento de envío y los datos necesarios a informar a los Centros de Proceso en caso de ser necesario liberar manualmente el mensaje. Si no se produce la liberación manual:

Cambiar Identificador de Tipo de Mensaje a 1221, 1421 o 1521. Incrementar Contador de "repeticiones". Inicializar Temporizador TN4.

Re-Enviar mensaje.

EVENTO/ACCIÓN (9). ENVIÓ DE ANULACIÓN (1420).

Se asigna este RTS a un mensaje 1420 a enviar, como consecuencia de la recepción de una operación de "cancelación" (1) del terminal, por imposibilidad de finalizar correctamente una respuesta de petición contable afirmativa o por vencimiento del temporizador TN1 de un mensaje 1200. Al utilizar para el tratamiento de este tipo de mensajes un procedimiento de Envío Controlado de Comunicaciones, antes de enviar un mensaje 1420 debemos asegurarnos que no están en proceso más de cinco transacciones de comunicación (1220/1/1230) o de anulación (1420/1/1430).

--

Inicializar el Temporizador de 24 horas. Inicializar el Temporizador TN2. Inicializar Contador de "repeticiones" a cero. Sumar "1" al elemento de dato Abonos, Número de Anulaciones (S-75) o al elemento de dato Cargos, Número de Anulaciones (S-77), según se trate de una Anulación de Venta o de Devolución y Sumar Importe de Transacciones (P-4) al elemento de dato Abonos, Importe de Anulaciones (S-87) o Sumar Importe de Transacciones (P-4) al elemento de dato Cargos, Importe de Anulaciones (S-89), según se trate de Anulación de Venta o de Devolución; ambas sumas sólo se realizarán cuando el Código de Razón de Mensaje (P-25) sea distinto de "4006". Enviar el mensaje 1420.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

EVENTO/ACCIÓN (10). RECEPCIÓN RESPUESTA ANULACIÓN (1430).


--

Procesar el mensaje 1430 Cancelar Temporizador TN2.

EVENTO/ACCIÓN (11). ENVIÓ COMUNICACIÓN DE CONCILIACIÓN (1520).

Se asigna este RTS a un mensaje 1520 a enviar, como consecuencia de la necesidad de realizar la conciliación de la sesión contable cerrada.

--

Abrir una nueva sesión asignando una nueva Fecha y Número de Conciliación.

Cerrar la sesión anterior dejando de utilizar la Fecha y Número de Conciliación que la identifica.

Comprobar que no hay mensajes con Fecha y Número de Conciliación pendientes de ser enviados o respondidos. En caso de no ser así, proceder a su envío. Inicializar Temporizador de 24 horas.

Inicializar el Temporizador TN3. Inicializar el Contador de "repeticiones" a cero. Enviar mensaje 1520.

EVENTO/ACCIÓN (12). RECEPCIÓN RESPUESTA CONCILIACIÓN (1530).


--

Cancelar Temporizador de 24 horas. Cancelar Temporizador TN3.

Almacenar información sobre totales netos, dando por finalizado el cierre de la sesión contable en curso.

EVENTO/ACCIÓN (13). ENVIÓ DE SOLICITUD DE ACTUALIZACIÓN DE LISTA NEGRA (1644)

Se asigna este RTS a un mensaje 1644 a enviar solicitando una actualización de Lista Negra.

--

Inicializar el Temporizador de 24 horas.

Inicializar el Temporizador TN6. Enviar el mensaje 1644.

EVENTO/ACCIÓN (14). RECEPCIÓN PETICIÓN ACTUALIZACIÓN (1304).

Recepción de un mensaje 1304/5 con distinto RTS al del 1644 inicial.

--

Cancelar temporizador TN6 Actualizar apropiadamente el fichero de Listas Negras.

Generar respuesta (1314) indicando el resultado de la actualización.

EVENTO/ACCIÓN (15). ENVIÓ PETICIÓN ADMINISTRATIVA (1604).

Se asigna este RTS a un mensaje 1604 a enviar, para solicitar información al HCP.

--

Iniciar el temporizador de 24 horas

Iniciar el temporizador TN6 Enviar el mensaje 1604




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

EVENTO/ACCIÓN (16). RECEPCIÓN RESPUESTA PET. ADMINISTRA. (1614).

Recepción de un mensaje 1614 con este RTS

--

Realizar acciones que se consideren oportunas con la información recibida. Cancelar temporizador TN6.

EVENTO/ACCIÓN (17). TIME-OUT PETICIÓN ADMINISTRATIVA O SOLICITUD DE ACTUALIZACIÓN DE LISTA NEGRA

Temporizador TN6 expirado

--

Enviar, si se desea, un nuevo (1604) o un nuevo 1644 (como Solicitud de Actualización de Lista Negra).

EVENTO/ACCIÓN (18). FINALIZACIÓN TEMPORIZADOR 24 HORAS.

Temporizador de 24 horas expirado

--

Ninguna acción.

(1) Una "cancelación" de un terminal generará una anulación con Código de Razón de Mensaje (P-25) "4007", sólo cuando se haya recibido una respuesta afirmativa a la petición enviada. En caso de no recibirse respuesta se generará una anulación por Time-Out exista o no una "cancelación" en el terminal.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

6.5 Descripción del Procedimiento de Notificación de Mensajes no Reconocibles Como consecuencia de la recepción de un mensaje "no reconocible" o "inesperado", las aplicaciones dialogantes enviarán un mensaje de notificación administrativa (1644).

La tipificación de estas situaciones se expone con detalle en el epígrafe 6.4.

El flujo de mensajes será:

APLICACIÓN HCP o HE APLICACIÓN HE o HCP

Tiempo

(1) xxxx

1644

(2)

(1) La aplicación del HCP o HE envía cualquier clase de mensaje.

(2) La aplicación del HE o HCP realiza las validaciones de reconocimiento expuestas en el epígrafe 6.4, no siendo superadas. Ante esta situación se envía un mensaje de notificación administrativa (1644) reportando el error y se ignora el mensaje recibido.

Siempre que se genere o reciba un mensaje 1644, se informará al Centro de Gestión de Red para corregir las posibles deficiencias y, en su caso, resolver la operación de forma manual.




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

6.6 Descripción del Procedimiento de Solicitud de Lista Negra Como consecuencia de la recepción en el HE de un mensaje de respuesta del HCP, Autorizando una Petición/Comunicación Contable o aceptando una Comunicación de Conciliación o Administrativa, en el que se le indique que debe Solicitar una Actualización de Lista Negra, el HE enviará un mensaje (1644) de Solicitud de Actualización de Lista Negra.


APLICACIÓN HCP APLICACIÓN HE

(1)

xxxx

Tiempo

1644 (2)

Tiempo

(3) 1304

1314

(4)

(1) La aplicación del HCP envía un mensaje de respuesta Autorizando una Petición/Comunicación Contable o

aceptando una Comunicación de Conciliación o Administrativa, en el que se le indica al HE que debe Solicitar una Actualización de Lista Negra

(2) El HE enviará un mensaje (1644) de Solicitud de Actualización de Lista Negra. A continuación, activará una

temporización de espera de respuesta del HCP enviando la actualización de Lista Negra (1304). En caso de vencimiento de time-out sin respuesta de HCP, el HE podrá enviar un nuevo 1644.

(3) El HCP una vez recibido el 1644 enviado por el HE solicitando la Actualización de Lista Negra, generara un mensaje

1304 con la Actualización de Lista Negra

(4) Tras la recepción en el HE del mensaje 1304, este devolverá el mensaje de respuesta 1314. En caso vencimiento de temporización sin respuesta del HE, el HCP podrá enviar un nuevo 1304

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

6.7 Descripción del Test del Dialogo En cualquier momento y siempre que exista un enlace permanente de los Hosts, se puede enviar un mensaje de test

para conocer si existe enlace entre los Niveles de Aplicación. Este mensaje de test sólo podrá ser desde el HE al HCP

cuando se trate de enlace tipo "Pequeño Comercio" (enlace conmutado).

Este mensaje también sirve para que la aplicación de un Host conozca el estado del otro Host. Por ello recomendamos

el envío de un mensaje de Test por cualquiera de los dos Host ante sospecha de cambio de estado (activo, suspendido,

caído) del otro.

Se hará mediante el envío de un mensaje 1804 con Código de Función (P-24) "831", siendo la respuesta un mensaje 1814 con Código de Acción (P-39) "800".

La no recepción de la respuesta en el tiempo predefinido por el tempori zador provocará la comunicación de la incidencia al operador del Centro de Gestión de Red.

Estos mensajes sólo tienen sentido cuando exista un enlace permanente entre los ordenadores del HE y HCP.


APLICACIÓN HE o HCP APLICACIÓN HCP o HE

Tiempo

(1) 1804

1814

(2)

(1) La aplicación del HCP o HE envía un mensaje de test.

(2) La aplicación del HE o HCP genera la respuesta correspondiente, verificándose la existencia de conexión entre las

aplicaciones.

También se podrá producir el siguiente flujo de mensajes:


Tiempo

(1) 1804

1814

X (2)

o bien


Tiempo (1) 1804

X

(2)

(1) La aplicación del HCP o HE envía un mensaje de test.

(2) Independientemente de donde se haya producido el error la aplicación del HE o HCP detecta la ausencia de respuesta comunicándose tal circunstancia al Centro de Gestión de Red.




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

6.8 Descripción de la Suspensión/Reanudación del Dialogo Estas funciones de control de diálogo sólo tienen sentido cuando exista un enlace permanente entre los ordenadores del HE y HCP, es decir, enlaces tipo "Grandes Clientes".

La detección de errores graves en el diálogo establecido, por parte del Centro Procesador, provocará de forma automática o manual que la aplicación del HCP pase al estado de Diálogo Suspendido, enviando para que esta transición sea ordenada, un mensaje de comunicación control de diálogo (1824) con Código de Función (P-24) "888" al HE. Ante la recepción de este mensaje la aplicación del HE enviará una respuesta (1834) con Código de Acción (P-39) "800".

Con el fin de permitir que la suspensión de diálogo sea ordenada la aplicación del HCP efectuará las siguientes acciones:

• Enviar mensaje de comunicación de "suspensión" (1824). • Continuar procesando mensajes de petición y/o comunicación que reciba.

• Ante la recepción del mensaje de respuesta de control de diálogo (1834) o vencimiento del temporizador (TC2), dar

por suspendido el diálogo no aceptando ninguna clase de mensaje, salvo mensajes de petición de control de diálogo

(1804).

Por su parte la aplicación del HE realizará las siguientes acciones, ante la recepción de un mensaje de comunicación de control de diálogo "suspensión": • Antes de enviar el mensaje de respuesta debe cortar el envío de mensajes de petición (1200) y comunicación

(1220/1, 1520/1, 1420/1). • Debe esperar a no tener peticiones o comunicaciones pendientes de respuesta. Se entiende que una petición o

comunicación deja de estar pendiente de respuesta en el momento en que se recibe la respuesta o vence el temporizador.

• Generar respuesta de comunicación de control de diálogo (1834), dándose por realizada la suspensión de diálogo.

Una vez subsanados los problemas que originaron la suspensión de diálogo (circunstancia que será comunicada al Centro de Gestión de Red del HCP), la aplicación del HCP transitará al estado de Diálogo Activo, solicitando previamente confirmación a la aplicación del HE, para lo cual enviará un mensaje de petición de control de diálogo (1804) con Código de Función (P-24) "891".

El flujo normal de mensajes de control de diálogo:


Tiempo

(1) 1824

1834

(2)

(1) La aplicación del HCP comunica su transición al estado de Diálogo Suspendido mediante un mensaje de comunicación de control de diálogo con Código de Función (P-24) "888".

(2) El HE normalmente enviará una respuesta con Código de Acción (P-39) "800", quedando suspendido el diálogo.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6



Tiempo

(1) 1824

1834

X (2)

o bien


Tiempo

(1) 1824

X

(2)

(1) La aplicación del HCP envía un mensaje de comunicación de control de diálogo con Código de Función (P-24) "888".

(2) Independientemente de donde se haya producido el error la aplicación del HCP detecta la no recepción de una respuesta en el tiempo predefinido. Ante esta circunstancia, completa su transición al estado de Diálogo Suspendido.

El diálogo suspendido, una vez subsanados los problemas que lo originaron será restablecido por la aplicación del HCP,

siendo el flujo de mensajes:


Tiempo

(1) 1804

1814

(2)

(1) La aplicación del HCP solicita confirmación al HE, para iniciar su transición al estado Diálogo Activo, mediante un mensaje de petición de control de diálogo con Código de Función (P-24) "891".

(2) La aplicación del HE normalmente enviará una respuesta con Código de Acción (P-24) "800", quedando restablecido el diálogo.




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6



Tiempo

(1) 1804

1814

X (2)

o bien


Tiempo

(1) 1804

X

(2)

(1) La aplicación del HCP envía un mensaje de petición de control de diálogo con Código de Función (P-24) "891".

(2) Independientemente de donde se haya producido el error la aplicación del HCP detecta la no recepción de una

respuesta en el tiempo predefinido, no realizándose la transición al estado de Diálogo Activo.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

RECEPCIÓN PETICIONES TPV’S -- SE ENVIAN MENSAJES AL

HCP

DIALOGO

ACTIVO

6.9 Diagrama de Estados de Dialogo En la Aplicación del HE, cuando exista Enlace

Permanente Son estados de diálogo que solo tienen sentido existiendo un enlace permanente (Enlace tipo "Grandes Clientes").

La aplicación del HE deberá contemplar tres estados: ACTIVO, SUSPENDIDO e INACTIVO, transitando de uno a otro según el siguiente esquema.

60 MENSAJES SIN RESPUESTA -- SUPRIMIR EN VIO MEN. PET./COM.

RESOLVER EN LOCAL NO INICIAR 1520 INICIALIZAR TN4 ENVIAR TEST CADA MINUTO

RECEPCION SUSPENSION -1824-

-- SUPRIMIR EN VIO MEN. PET./COM. RESOLVER EN LOCAL NO INICIAR O SUSPENDER 1520

ESPERAR RESOLUCIÓN PENDIENTES RESP. ENVIAR RESPUESTA -1834-

RESPUESTA A TEST --

RECEPCION REANUDACION - 1804- -- ENVIAR RESPUESTA -1814-

RECEPCION PETICIONES TPV’S -- RESOLVER EN MODO LOCAL

DIALOGO INACTIVO

RECEPCION PETICIONES TPV’S --

RESOLVER EN MODO LOCAL

DIALOGO

SUSPENDIDO




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

7. Diccionario de Elementos de Datos

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

A continuación, se describen los elementos de datos, ordenados por el número de bit que llevan asociados.

De cada uno de los elementos de datos se describe:

• Nombre y bit asociado, donde "P" indica que corresponde al primer Mapa de Bits y "S" a secundarios.

• Formato, utilizándose las abreviaturas descritas con anterioridad.

• Descripción, ofreciéndose una definición ampliada

• Presencia, indicando el Tipo de Mensajes en el que viaja y Código de Condición (ver 5.1)

• Contenido del elemento de dato

• Validaciones que se deben realizar con el contenido del elemento de dato

• Comentarios, resaltando su forma correcta de utilización o características de su contenido.




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.1 Identificador de Tipo de Mensaje

Identificador de Tipo de Mensaje n4

Descripción Identifica el mensaje en los términos expuestos en 4.3.1

Presencia O Todos los mensajes

Contenido El valor requerido según tipo de mensaje

Validación Estructura Lógica de acuerdo al Formato y Contenido definidos

Comentarios

7.2 Mapa de Bits Primario

Mapa de Bits Primario b8

Descripción Indica la presencia o ausencia de elementos de dato desde el 1 al 64

Presencia O Todos los mensajes

Contenido 64 bits que indican la existencia o ausencia del elemento de dato que representan

Validación Se validara que la estructura es lógica conforme a lo expuesto.

Comentarios El primer bit del Mapa de Bits no está asociado a un elemento de dato, se utiliza para indicar la existencia de un mapa de bits adicional (Extensión del Mapa de Bits). Este bit toma el valor "1" cuando

existe un el elemento de dato 'Extensión del Mapa e Bits'

7.3 Extensión del Mapa de Bits (P-1)

(P-1) Extensión del Mapa de Bits b8

Descripción Indica la presencia o ausencia El primer bit del Mapa de Bits no está asociado a un elemento de dato:

se utiliza para indicar la existencia de un mapa de bits adicional. Este bit toma el valor "1" cuando existe un Mapa de Bits adicional

Presencia O 1304 1305 1314

1520 1521 1530

1604 1614

1804 1824 1814 1834

Contenido 64 bits que indican la existencia o no de los bits secundarios (S) en el mensaje

Validación Se validara que la estructura es lógica conforme a lo expuesto.

Comentarios El mapa de Bits primario (bits 1 a 64) estará siempre presente. La existencia del mapa de Bits secundario se indicará poniendo a "1" el bit 1 del mapa de Bits primario.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.4 PAN, Número de Tarjeta (P-2)

(P-2) PAN, Número de Tarjeta n..19

LLVAR Descripción Conjunto de dígitos utilizados para identificar la Cuenta del titular o una relación con ésta.

Presencia O 1100 1200 1220 1221

OI 1110 1210 1230 1430

03 1420

Contenido Viajará: • De forma obligatoria en operaciones realizadas sin cifrado de pistas • Opcionalmente en operaciones realizadas con cifrado de Pistas en cuyo caso deberá validarse el

contenido con el que viaja en la Pista 2 Cifrado que se envía en el campo P-48 código ’35 o la ‘Referencia de la operación’ en el campo P-48 campo 40.

Validación Se validará Formato, Contenido y coherencia según tecnología y marca de la tarjeta

Comentarios Se utilizara en transacciones realizadas desde Entrada Manual, Banda Magnética o desde el Chip EMV

7.5 Código de Proceso (P-3)

(P-3) Código de Proceso n6

Descripción Conjunto de dígitos utilizados para describir el efecto de la transacción sobre la cuenta del titular

Presencia O 1100 1200 1220 1221

OI 1110 1210 1230

1430

03 1420 1421

Contenido Este campo está dividido, de forma lógica, en tres subcampos de dos dígitos cuyo significado y valores

posibles especificamos a continuación:

Dígitos 1-2 Identifican una transacción específica

Cargos al Titular 00 Bienes y Servicios (Venta)

Abonos al Titular 20 Devoluciones

Dígitos 3-4 Se utilizan para comunicar, en caso de que la transacción se lleve a cabo con pago aplazado, el número de meses en que se realiza. Valores posibles para este subcampo son:

00 (Valor por defecto), no especificado

33 3 meses

34 6 meses

35 9 meses

36 12 meses

37 24 meses

Dígitos 5-6 no se utilizan, siempre irán a ceros


Comentarios




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.6 Importe de la Transacción (P-4)

(P-4) Importe de la Transacción n12

Descripción Importe solicitado por el titular en EUROS con dos decimales

Presencia O 1100 1200 1220 1221

O 1110 1210 1230 1430

03 1420 1421

Contenido Importe expresado en Euros con dos decimales


Comentarios En los mensajes de respuesta de preautorización (1110), petición contable (1210), comunicación

contable (1230) y anulación (1430) es obligatorio

En los mensajes respuesta de preautorización (1110), Petición Contable (1210) irá a cero cuando la respuesta deniegue, rechace o indique imposibilidad de proceso, siendo su valor igual al del mensaje pregunta cuando la respuesta apruebe o acepte la transacción, excepto operativa AFD.

En los mensajes de respuesta de Comunicación Contable (1230) y de Anulación (1430) será igual al del mensaje de pregunta En los mensajes de respuesta cuando la respuesta autorice la preautorización 1100 por importe parcial, tratamiento AFD, con P39 = 010, contendrá el importe realmente preautorizado

En mensajes AVS de verificación de tarjeta el importe será de 0 Euros

7.7 Número de Identificación de Transacción

(P-11)

(P-11) Número de Identificación de Transacción n6

Descripción Número asignado por el iniciador de la transacción para identificar de forma unívoca una transacción.

Este elemento de dato forma parte de la Referencia de Transacción (RTS)

Presencia O 1100 1200 1220 1221

1304 1305

1420 1421

1520 1521

1604 16441804 1814

OI 1110 1210 1230

1315

1430

1530

1614

1824 1834

Contenido Identificador de la transacción


Comentarios • Este número es el mismo para todos los mensajes de una transacción

• Se recomienda su generación de forma secuencial y creciente sin que se duplique en el periodo de 24 horas.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.8 Fecha y Hora Local de Transacción (P-12)

(P-12) Fecha y Hora Local de Transacción n12

AAMMDDhhmmss

Descripción Fecha y hora local del punto de servicio en el que la transacción de autorización tiene lugar.


Presencia O 1100 1200 1220 1221

1304 1305

1420 1421

1520 1521

1604 1644 1804 1814

OI 1110 1210 1230

1315

1430

1530

1614 1824 1834

Contenido Fecha y Hora Local de la transacción con formato AAMMDDhhmmss


Comentarios • Este número es el mismo para todos los mensajes de una transacción

• Se debe garantizar que las transacciones incluidas en una sesión contable, tengan una Fecha y Hora

Local inferior a la informada en el mensaje de comunicación de conciliación (1520), que inicia el cierre

de dicha sesión

• En los mensajes de petición y comunicación contable (1200, 1220), el valor de este elemento de

datos coincidirá (sin segundos) con el impreso en el recibo justificativo de la operación. En los

mensajes de anulación y conciliación, su valor indicará la Fecha y Hora de generación

7.9 Fecha de Caducidad (P-14)

(P-14) Fecha de Caducidad n4

AAMM

Descripción Año y mes en que la tarjeta caduca

Presencia 02 1100 1200 1220 1221

Contenido Cuatro dígitos numéricos que indican la fecha de caducidad de la tarjeta en formato AAMM


Comentarios • Sólo será necesario en operaciones con captura manual de datos de la tarjeta, si está disponible

• La fecha de caducidad podrá no viajar en algunos sectores de actividad, cuando no se disponga del dato, no se pueda capturar en el punto de servicio y el Centro Procesador lo autorice (Ej.: Venta por Correo).

• Campo obligatorio en operativa AVS si no se envía P48.38




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.10 Datos del Punto de Servicio (P-22)

(P-22) Datos del Punto de Servicio an12

Descripción Identificación de las características del Terminal. Especifica las condiciones en las que la transacción

tiene, o tuvo, lugar

Presencia 02 1100 1200 1220 1221

Contenido Serie de doce (12) Códigos que identifican capacidades del terminal, entorno operativo y presentación de datos de seguridad. Se utilizará para indicar las condiciones específicas en las que tiene, o tuvo, lugar la transacción en el terminal.


Comentarios La estructura de este elemento de dato es la siguiente:

1ª Posición Capacidad de captura de Datos del terminal. Indica el principal medio de captura de datos de tarjeta

1 2 5 6

M N U

Manual (no terminal)

Lectura de Banda Magnética Tarjeta Chip EMV Tecleo de datos en el terminal

Contactless (EMV + Banda) + EMV (clásico) + Banda magnética. Contactless Banda+ EMV (clásico) + Banda magnética. Contactless (los transportes tendrán este tipo de operativa)

2ª Posición Capacidad de autentificar al cliente en el terminal. Indica el principal medio de autentificar el cliente

0 1 J U X Y

Z

Ninguna Identificación Electrónica PIN (On-Line u Off-Line o Pass Code)) Operación V.me

Comercio seguro Visa Comercio seguro MasterCard

Autenticación previa en operaciones de comercio electrónico seguro. Última operación. Autenticación previa en operaciones de comercio electrónico seguro.

3 ª Posición Capacidad de retención de tarjeta

0 1

No tiene Capacidad de Captura Tiene Capacidad de Captura

4ª Posición Terminal Atendido o no 0 1 2 M

No se utiliza terminal Terminal Atendido Terminal No Atendido Terminal MPOS Atendido

5ª Posición Presencia de Cliente 0 1 2 3 4 5

Presente No presente No presente, correo No presente, Teléfono

No presente, autorización periódica No presente, CE

6ª Posición Presencia de tarjeta 0 1

Tarjeta No presente Tarjeta presente

7ª Posición Método utilizado para

capturar los datos de la tarjeta en el terminal

1 2 5 6

N M S T L K

Manual sin terminal

Lectura de Banda Magnética Tarjeta Chip EMV Entrada manual del relieve

Banda contactless EMV contactless

Lectura de Banda Magnética Fallback del Chip EMV Entrada Manual del Relieve Fallback del Chip EMV Entrada de datos en teléfono móvil (EMV Contactless Mobile) Entrada de datos en teléfono móvil (Banda Contactless Mobile)

8ª Posición Modo de Autentificación del Cliente

0 1 5 J K L U X Z

No Autentificado PIN (On u Off Line) Verificación de firma Operación V.me Operación V.me con Autenticación OTP Pass Code (Contactless Movile) Comercio electrónico 3D Secure Comercio electrónico 3D Secure para MasterCard PUCE

9ª Posición Dispositivo o Entidad que debe autentificar al cliente

0 1 3 4 5 F

No autentificado Tarjeta Chip EMV El CPD o el Emisor El Establecimiento Autenticado en dispositivo de usuario (ej: móvil) Pago por referencia (COF). Pago One Click.

10ª Posición Datos suministrados al HCP para la identificación del cliente

0 1

Ninguno PIN On-Line

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

11º Posición Dispositivos del terminal que

permiten imprimir o mostrar caracteres

0 2 3 4

Desconocido

Impresora Display Impresora y Display

12ª Posición Longitud máxima de PIN que

el terminal es capaz de tratar

0 1

4..C

El terminal no tiene capacidad de captura de PIN Desconocido Cuatro a doce dígitos




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.11 Número de Secuencia de la Tarjeta (P-23)

(P-23) Número de Secuencia de la Tarjeta n3

Descripción Número utilizado para diferenciar tarjetas EMV con el mismo PAN

Presencia -- 1100 1200 1220 1221 1420 1421

Obligatorio en todos los mensajes 12xx y 14xx enviados por el HE, cuando se opere con tarjetas EMV y esté disponible la información

Contenido Contendrá el 'Application PAN Sequence Number' (Tag 5F34), si está presente en el Chip EMV

Validación Estructura Lógica de acuerdo al Formato y Contenido definidos y que el rango de este campo está entre

000 y 099 Comentarios Se utilizará solo en caso de transacciones EMV realizadas con el Chip

7.12 Código de Función (P-24)

(P-24) Código de Función n3

Descripción Código que indica el específico propósito del mensaje dentro de su clase

Presencia O 1100 1200 1220 1221 1304 1305

1420 1421

1604 1644 1804 1814

Contenido Puede tomar los siguientes valores:

100 Usado en peticiones de autorización no contables

101 Usado en Transacción de primera preautorización. 103 Usado en Transacción de preautorizaciones sustitutivas

150 Usado en Operativa AVS de verificación de tarjeta (0 Euros)

200-299 Usado en mensaje 1200, 1220, 1221 200 Transacción financiera original. 201 Transacción financiera con importe igual o mayor a una autorización realizada previamente. Válido sólo para 1220/1

202 Transacción financiera con importe inferior a una autorización previa. Válido sólo para 1220/1

300-399 Usados en los mensajes de actualización de ficheros (1304/1305) para indicar tipo de actualización a realizar 300 Sin determinar. Se informará de la acción a tomar en elemento de dato Registro de Datos (S-72) 380 Petición de Lista Negra rechazada por tamaño de Lista Negra incorrecta

381 Fin de actualización de Lista Negra

400-499 Usados en mensajes de anulación automática (1420/1) para indicar la razón de su envío 400 Anulación por importe total 481 Anulación de preautorización

482 Anulación de Confirmación de preautorización

600-699 Usado en los mensajes (16xx) para indicar el tipo de información que se intercambia 689 Mensaje no reconocible. Usado únicamente en los mensajes 1644 690 Consulta de los datos de conciliación de una sesión.

691 Solicitud de Actualización de Lista Negra

800-899 Usados en mensajes de control de diálogo (1804, 1824) para indicar la función precisa del mensaje 831 Mensaje de Test 888 Suspensión 891 Reanudación

Validación Estructura Lógica de acuerdo al Formato y Contenido definidos y coherente con el Tipo de Mensaje

Comentarios

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.13 Código de Razón de Mensaje (P-25)

(P-25) Código de Razón de mensaje n4

Descripción Facilita al Centro Procesador el motivo de la comunicación

Presencia O 1220 1221

1420 1421


1000-1499 Usados en mensajes 1220/1

1000 Resolución en HE por recepción de respuesta de petición contable (1210) con Código de Acción (P-39) '912' 1002 No recibirse respuesta en el tiempo predefinido (time-out).Resolución en HE 1003 Resolución en HE por HCP no disponible 1004 Resolución en el terminal por HE no disponible o no recibirse respuesta del HE en el tiempo predefinido 1006 Resolución Off-Line, por debajo de Floor Limit, en operativa EMV y de acuerdo a normativa EMV

1007 Resolución en el HE por solicitud del HCP

1376 Devolución resuelta en HE 1377 Existencia de una autorización previa de importe igual o superior 1378 Resolución Off-Line en el TPV, por debajo de Floor Limit, en operativa EMV conforme a criterios acordados con el HCP

1379 Existencia de una Preautorización previa de importe inferior

4000/4499 Usados en mensajes 1420/1 4001 Anulación de una Preautorización o venta por importe Total 4006 Respuesta recibida demasiado tarde. Vencimiento de Temporizador de Petición Contable (TNI) o Cancelación manual antes de recibir respuesta. Valor no permitido en caso de Cierre gestionado por el HCP. 4007 Terminal punto de servicio incapaz de completar la transacción aprobada (en operaciones con tarjeta EMV, el terminal debe ser capaz de finalizar la operación con la tarjeta, ver código 4352) o Cancelación manual después de recibir respuesta 4352 Transacción denegada por la tarjeta Chip en 2º Criptograma tras recibir respuesta de aceptación del HCP 4353 Terminal punto de servicio incapaz de completar la transacción aprobada (fallo de tarjeta o alimentación o extracción de tarjeta). Solo utilizado en operaciones con tarjeta EMV cuando no pueda finalizar la operación con la tarjeta (ver código 4007) En caso de transacciones realizadas con tarjetas EMV, el mensaje de anulación no incluirá el Criptograma de Anulación ni los datos EMV requeridos (P-55)


Comentarios

7.14 Fecha de Conciliación (P-28)

(P-28) Fecha de Conciliación n6

AAMMDD Descripción Identificación de la Fecha de la sesión contable a la que pertenece la transacción contable (1200, 1220)

o la anulación (1420). En mensajes de comunicación de conciliación (1520) identifica la sesión contable que se concilia. Este campo junto con el (P-29) identifica la sesión contable


OI 1530

313 1220 1221

1200 1220 1221

1420 1421

1604 1814

314 1210 1230

1430 1614

Contenido Fecha de la sesión contable en formato AAMMDD


Comentarios • Cuando el establecimiento gestione las sesiones contables estará presente en los mensajes de petición, comunicación y anulación (1200, 1220, 1420), permitiendo de esta forma al HCP identificar la sesión contable a la que pertenecen las transacciones.

• Si la gestión de sesiones contables es realizada por el HCP, este elemento de dato estará presente en los mensajes de respuesta (1210, 1230, 1430), informando al HE la sesión contable a la que pertenecen las transacciones.




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.15 Número de Conciliación (P-29)

(P-29) Número de Conciliación n3

Descripción Identificación del número de la sesión contable a la que pertenece la transacción contable (1200, 1220)

o la anulación (1420). En los mensajes de comunicación de conciliación (1520) identifica la sesión

contable que se concilia. Este campo junto con el (P-28) identifica la sesión contable


OI 1530

313 1220 1221 1200 1220 1221

1420 1421

1604 1814

314 1210 1230

1430 1614

Contenido Número de la sesión contable


Comentarios • Toma valor inicial 1, incrementándose por cada sesión, de forma ascendente en una unidad. Valores permitidos 001 a 999

• Cuando el establecimiento gestione las sesiones contables estará presente en los mensajes de petición, comunicación y anulación (1200, 1220 y 1420), permitiendo de esta forma al HCP identificar la sesión contable a la que pertenecen las transacciones.

• Si la gestión de sesiones contables es realizada por el HCP, este elemento de dato estará presente en los mensajes de respuesta (1210, 1230 y 1430), informando al HE la sesión contable a la que pertenecen las transacciones.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.16 Importe Original de la Transacción (P-30)

(P-30) Importe Original de la Transacción n24

Descripción Indica el importe original y el importe contable la petición contable, cuando los mensajes de respuesta

denieguen, no procesan, rechazan o ignoran la petición contable (1200)

Presencia 21 1100

1110

1210

1220

1221

Contenido Solo viajará en los siguientes casos:

• En los mensajes de respuesta de petición de autorización y contable • En los mensajes de petición de autorización sustitutiva y comunicación contable • En los mensajes de Anulación de Preautorización

• En respuestas autorizadas con P39 = 010 (Operativa por importe parcial AFD)

Importe original: Importe contable:

Importe (P-4) del mensaje pregunta (1200)

Valor ceros

n12

n12


Comentarios Se utilizará de la siguiente forma:

• En los mensajes de respuesta cuando la respuesta autorice la petición 1100 por importe parcial, contendrá el importe original

• En los mensajes de respuesta, cuando las respuestas denieguen, no procesan, rechazan o ignoran la petición 1100 o 1200. Tendrá el siguiente formato:

o a) Importe original: Importe (P-4) del mensaje pregunta (1100) n12

o b) Importe contable: Valor ceros n12

• En los mensajes de petición 1100 o comunicación contable 1220 para indicar el importe de la preautorización que sustituyen o confirman. No viajará en Preautorizaciones originales

• En los mensajes de Anulación de Preautorización el importe de la preautorización que anulan




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.17 Código de Identificación de Adquirente (P-32)

(P-32) Código de Identificación de Adquirente n..11

LLVAR Descripción Identifica el origen del mensaje de petición contable, comunicación contable y anulación.


Presencia O 1100 1200 1220 1221

1520 1521 1604

OI 1110 1210 1230

1430

1530

1614

03 1420 1421

Contenido Este elemento de dato está dividido, de forma lógica, en tres subcampos cuyo significado y valores posibles, son asignados por el HCP, especificándose a continuación:

Dígitos 1-2 Tomará los valores indicados a continuación, dependiendo del HCP

REDSYS Dígito 1

Dígito 2

1 2 3 4 5

6

6 7 8 9

Abono a nivel de Sesión Abono a nivel de Establecimiento (P-42) Abono a nivel de Sesión y Entorno Multibancario Abono a nivel de Establecimiento (P-42) y Entorno Multibancario Abono a nivel de Identificati vo de Cuadre (P-48)

Abono a nivel de Identificativo de Cuadre (P-48) y Entorno Multibancario

Control de sesión del HE. No se gestiona LN Control de sesión del HCP. No se gestiona LN Control de sesión del HE. Se gestiona LN Control de sesión del HCP. Se gestiona LN

REDSYS Dígitos 1-2 13 43

Circuitos Permanentes

Circuitos conmutados

CecaBank Dígitos 1-2 00

Dígitos 3-11 Su estructura y contenido dependerá del tipo de conexión

• Conexión de Grandes Clientes. Abono a nivel de Sesión (P-32)

Contendrá un código de cuatro dígitos acordado entre el HE y el HCP. El rango de posibles valores es el siguiente: • REDSYS 4000-4999

• REDSYS 5000-5999 • CECABANK 6000-6999

• Conexión de Pequeños Comercios. Abono a nivel de (P-42)

Contendrá un código de 9 dígitos coincidiendo con el valor de Código de Comercio (FUC) asignado al HE


Comentarios La conciliación se realizará por el conjunto de mensajes con igual campo Id. del Host del P-32

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.18 Nuevo campo P34 Datos de comercio electrónico. En el caso de utilizarse MPI del HCP de Redsys o Cecabank,,este campo no será necesario incluirlo en la autorización pues ya se habrá notificado en tiempo de autenticación y cuando se realice la autorización se recupera de lo enviado en autenticación.

(P-34) Datos asociados a exenciones de CE ansb..255

LLLVAR Descripción Informa datos específicos EMV cuando se realizan transacciones con ecommerce

Presencia -- 1100 1200 1220 1221 1110 1210

Contenido Este Elemento de Dato puede estar formado por uno o más subcampos referenciados en este documento por P-34 (“hh”) o P-34 (“hhhh”), donde (“hh”) y (“hhhh”) es el Código de subcampo. Este Código, que coincide con la etiqueta (Tag) asignada al subcampo en especificaciones de comercio electrónico, puede estar formado por 2 o 4 semicaracteres, con representación Hex.

La estructura general del Elemento de dato P-34 es la siguiente:

“LLL” “VAR” hasta 255 bytes

Longitud Área de Datos

Uno o más Subcampos en formato TLV

2 bytes

1 o 2 bytes

1 byte

longitud variable

La longitud total del Elemento de dato P-34 se codifica en dos caracteres, usando formato BCD

Cada Subcampo se estructurará en formato TLV -Tag (etiqueta-código), Longitud, Valor (datos)- como

se indica a continuación:

Etiqueta: Uno o dos caracteres binarios que identifican el Código del Subcampo. Se corresponde con la etiqueta (Tag) asignada al campo en las Especificaciones de datos de comercio electrónico. Solo se requerirá codificar el segundo byte cuando los cinco bits menos significativos del primer byte sean todos igual a “1”. Longitud: Un carácter binario donde se especifica la longitud (en bytes) de los Datos (valor) del Subcampo

Datos (valor): Contenido del subcampo identificado por la Etiqueta (Tag). Codificado en binario o BCD,

según corresponda al tipo de dato, y con la longitud especificada

Texto: Contenido del Dato Adicional identificado previamente por el Código

Validación Se validará que la estructura es lógica conforme a lo expuesto.

Comentarios • Cada subcampo presente, aporta a la longitud total del P-34, la longitud de cada una de las

componentes que lo forman (Etiqueta, Longitud y Datos) • Los subcampos pueden aparecer en cualquier orden.

• Se recomienda un tratamiento abierto de este campo, es decir, se debe contemplar la posibilidad de recibir algún subcampo no presente en este documento, por tanto el HE que reciba un subcampo que no reconozca, simplemente saltará la etiqueta y las posiciones indicadas y lo ignorará, pasando a tratar el siguiente. De esta forma se evita el tener que hacer actualizaciones en el caso de inclusión de nuevos campos, hasta que sea necesario su tratamiento por parte de la Entidad.

Ejemplos En el valor "`00`08`9F`/C`01`00`9F`7D`01`01" `00`08` (dos bytes en BCD) longitud total del P-34 (En realidad ocupa 10 posiciones) `9F`7C (dos bytes, en hexadecimal) etiqueta del subcampo 1 que viene a continuación `01` (un byte binario) que indica la longitud del campo Dato que viaja a conti nuación 0 (un byte, en numérico). que contiene el campo Dato asociado a la Etiqueta

`9F`7D (dos bytes, en hexadecimal) etiqueta del subcampo 2 que viene a continuación `01` (un byte binario) que indica la longitud del campo Dato que viaja a conti nuación

`01` (un byte binario). que contiene el campo Dato asociado a la etiqueta

Longitud del Elemento de

Dato P-34

Código del Subcampo Longitud del

Subcampo

Datos del Subcampo




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Indicador de exención por bajo importe (P-34 Tag’9F7C’)

P-34

(‘9F7C’) Indicador de exención por bajo importe b1

Descripción Indicador de Exención por bajo importe.

Codificado según Especificaciones y con estructura TLV: Etiqueta (“Tag”), Longitud, Valor.

Dato suministrado por el Comercio. Este subcampo proporciona a P-34 una longitud de 2 + 1 + 1 bytes.

Presencia -- 1100 1200 1220 1221 Solo en caso de transacciones ecommerce.

Contenido Indicador codificado en BCD

Validación La establecida en el protocolo para este tipo de dato

Comentarios Se utilizará en mensajes de petición y comunicación contable en operaciones ecommerce

Precediendo al dato, aparece la longitud (01) en un byte. Al ser un campo numérico de un dígito, ocupa una posición.

Valores posibles: 0 no aplica exención

1 transacción exenta de SCA determinado por el comercio

Indicador de exención por análisis de riesgo (P-34 Tag’9F7D’)

P-34 (‘9F7D’) Indicador de exención por análisis de riesgo b1

Descripción Indicador de Exención por cumplimiento de análisis de riesgo de la PSD2. Codificado según Especificaciones y con estructura TLV: Etiqueta (“Tag”), Longitud, Valor. Dato suministrado por el Comercio. Este subcampo proporciona a P-34 una longitud de 2 + 1 + 1 bytes.




Comentarios Se utilizará en mensajes de Petición y Comunicación Contables en operaciones ecommerce. Precediendo al dato, aparece la longitud (01) en un byte. El Dato ocupara 1 bytes



[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Indicador de exención por protocolos de pago corporativo seguro (P-34 Tag’9F7F’)

P-34 (‘9F7F’) Indicador de exención por protocolos de pago

corporativo seguro b1

Descripción Indicador de Exención por protocolos de pago corporativo seguro. Codificado según Especificaciones y con estructura TLV: Etiqueta (“Tag”), Longitud, Valor. Dato suministrado por el Comercio. Este subcampo proporciona a P-34 una longitud de 2 + 1 + 1 bytes.







Indicador de exención por MIT (pago iniciado por comercio) (P-34 Tag’9F91’)

P-34 (‘9F91’)

Indicador de exención por pago iniciado por el

comercio

b1

Descripción Indicador de Exención por pago iniciado por el comercio.

Codificado según Especificaciones y con estructura TLV: Etiqueta (“Tag”), Longitud, Valor.

Dato suministrado por el Comercio. Este subcampo proporciona a P-34 una longitud de 2 + 1 + 1 bytes.




Comentarios Se utilizará en mensajes de Petición y Comunicación Contables en operaciones ecommerce.

Precediendo al dato, aparece la longitud (01) en un byte. El Dato ocupara 1 bytes

Valores posibles: 0 no aplica exención 1 transacción exenta de SCA determinado por el comercio




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Indicador de exención por autenticación delegada (P-34 Tag’9F92’)

P-34

(‘9F92’) Indicador de exención por autenticación

delegada b1

Descripción Indicador de Exención por autenticación delegada.

Codificado según Especificaciones y con estructura TLV: Etiqueta (“Tag”), Longitud, Valor. Dato suministrado por el Comercio. Este subcampo proporciona a P-34 una longitud de 2 + 1 + 1 bytes.





Valores posibles: 0 no aplica exención 1 transacción exenta de SCA determinado por el comercio

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.19 Datos de Pista 2 (P-35)

(P-35) Datos de Pista 2 z..37

LLVAR

Descripción Datos de Pista 2 extraídos de la Banda magnética de la Tarjeta de acuerdo a ISO 7813, incluyendo el campo separador ('3D' en ASCII) y excluyendo los centinelas de principio y fin y los caracteres LRC o Pista 2 equivalente extraída del Chip EMV, incluido el campo separador ('3D' en ASCII).

Presencia 06 1100 1200 1220 1221

Contenido Contendrá uno de los siguientes valores: • En caso de transacciones realizadas con Banda magnética, los Datos de Pista 2 extraídos de la

Banda magnética de la Tarjeta de acuerdo a ISO 7813, incluyendo los campos separadores ('3D' en ASCII) y excluyendo los centinelas de principio y fin y los caracteres LRC

• En caso de transacciones realizadas con el Chip EMV, la Pista 2 equivalente (EMV Tag 57) extraída del Chip EMV, si existe.

• En caso de pista cifrada se utilizará el P48.35

Validación Se validara que el contenido de esta campo se ajusta a la definición realizada: • Los caracteres anteriores al primer separador “3D” son numéricos

• El número de caracteres antes del separador “3D” no es superior a 19

La recepción en la aplicación del HI de una Pista 2 no conforme a estas validaciones, provocara el

envío de un mensaje con cabecera de rechazo. Estas validaciones deberán hacerse sin perjuicio que en caso de autorización local se tienen que realizar las validaciones que se describen en el Anexo D

Comentarios Se utilizara en transacciones realizadas desde la Banda Magnética o desde el Chip EMV, cuando se haya obtenido el dato, siendo obligatorio cuando se requiera realizar validación de PIN en el HCP

7.20 Número de Referencia (P-37)

(P-37) Número de Referencia anp12

Descripción Identificación escrita en los documentos asociados con la operación (recibo impreso) y que tiene por fin ayudar en su localización.

Presencia O 1100 1200 1220 1221

Contenido Se informará con un Número de operación del terminal (se inicializa en el proceso de Apertura de

Negocio/Proveedor de servicio) de cuatro dígitos Tiene el siguiente formato:

Número de operación

Resto discrecional

n4

an8

Información complementaria a la transacción o "spaces"


Comentarios El Número de Operación presente en este elemento de dato, conforma la Referencia de Transacción

para el Cliente (RTC) junto con: • Número de tarjeta (P-2) • Identificación del Establecimiento (P-42).

• Fecha y Hora local de Transacción (P-12) (sin considerar segundos) El Número de Operación debe ser impreso en el recibo de la operación,




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.21 Código de Autorización (P-38)

(P-38) Código de autorización anp6

Descripción Número de autorización asignado a la aprobación de la transacción por la institución autorizadora


303 1110 1210

Contenido Código alfanumérico asignado por la entidad autorizadora o su agente, cuando se apruebe la

transacción


Comentarios Este número figurará en los documentos acreditativos de la transacción del cliente

7.22 Código de Acción (P-39)

(P-39) Código de Acción n3

Descripción Código que identifica la acción a tomar, o tomada, así como la razón de la misma.

Presencia O 1110 1210 1220 1221 1230 1314 1430 1530 1614 1624 1625 1634 1644 1824 1834

Contenido Puede tomar los siguientes valores: 000-099 Usados en mensaje 1110, 1210, 1220 y 1221 para indicar que la transacción ha sido aprobada 000 Aprobada 010 Aprobada por importe inferior para tratamiento AFD. Solo en mensajes 1110. 060 Aprobada. Encadenar con Solicitud de Lista Negra (solo 1210) 085 Aprobada para operativa AVS de verificación de tarjeta (0 Euros). Solo en mensajes 1110. 100-199 Usados en, 1210, para indicar que la transacción ha sido procesada y ha sido denegada, no requiriéndose retirada de tarjeta 101 Tarjeta caducada 102 Tarjeta en Lista Negra o sospechosa de fraude, incluir en fichero de Lista Negra 106 Excedido el número de intentos del PIN 107 Llamar al Emisor 112 Pin obligatorio 117 PIN incorrecto 126 Bloque de PIN erróneo 160 Denegada. Operación con datos de tarjeta en claro en comercio SNCP (Escenarios 1 y 2) 180 Tarjeta no soportada por el sistema 190 Denegada por diversos motivos 192 Denegada. No es posible verificar autenticación por Referencia 193 Denegada. Excedido importe de la autenticación 195 En operativa presencial significará que repita operación con lectura CHIP, utilizando contactos, o si el dispositivo lo permite puede realizarse doble TAP más PIN. (2 TAP) En E-commerce que se requiere autenticación adicional. 196 En operativa presencial significará que repita operación con lectura CHIP, utilizando contactos, o si el dispositivo lo permi te solicitar solo PIN al titular. (1 TAP) En E-commerce que se requiere autenticación adicional. 200-299 Usados en 1110, 1210, para indicar que la transacción ha sido procesada y ha sido denegada, requiriéndose retirada de tarjeta e inclusión en Lista Negra 201 Tarjeta caducada 202 Tarjeta en Lista Negra o sospechosa de fraude 206 Excedido el número de intentos del PIN 290 Denegada diversos motivos 300-399 Usados en mensajes de actualización de ficheros 300 Realizada 380 Fichero completo 400-499 Usados en 1430 para indicar que la anulación ha sido aceptada 400 Aceptada 480 Aceptación de la anulación. El HCP no encontró la operación que se quiere anular por no estar procesada o autorizada. Se puede dar este valor en las respuestas de anulaciones iniciadas por vencimiento del temporizador 481 Aceptación de la anulación. El HCP no encontró la operación que se quiere anular. Se dará este código como respuesta a una anulación generada por causa distinta a temporización (ver valor 914). Por ejemplo, se enviara este código cuando se quiera aceptar la anulación de una operación antigua que ya no figura en los ficheros del HCP.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

500-599 Usados en 1530 para indicar el resultado de la conciliación 500 Conciliación en acuerdo 501 Conciliación en desacuerdo 503 Totales no disponibles 560 Conciliación en acuerdo. Encadenar con Solicitud de Actualización de Lista Negra

561 Conciliación en desacuerdo. Encadenar con Solicitud de Actualización de Lista Negra 563 Totales no disponibles. Encadenar con Solicitud de Actualización de Lista Negra 580 Datos de Abono Erróneos

581 Datos de Abono Erróneos. Encadenar con Solicitud de Actualización de Lista Negra

600-699 Usados en mensajes 1614y 1644 600 Aceptada 604 No es posible encontrar los totales que se solicitan. Usado en mensajes 1614 660 Aceptada. Encadenar con solicitud de Actualización de Lista Negra

687 No es posible reconocer el mensaje recibido. Usado en mensajes 1644

800-899 Usados en mensajes de control de diálogo (1814/1834) 800 Aceptado/Activo

882 Suspendido

900-901 Usado en mensajes de respuesta de comunicación (1230) para indicar que ha sido aceptada 900 Comunicación aceptada 901 Comunicación aceptada. Incluir tarjeta en Lista Negra (solo 1230)

902-949 Usados en mensajes de respuesta (1210/1230/1314/1430/1530) para indicar que la transacción no será procesada. La generación de respuestas con estos valores a mensajes tipo 1X3X producirá un descuadre en los casos en que la operación es contabilizada por el HE ya que el HCP nunca la contabiliza 904 Formato de mensaje erróneo 909 Error de sistema. (solo en 1210).

912 Centro Resolutor no disponible. Autorización local. (solo en 1210)

913 Recibido mensaje 1X2X duplicado (ya ha sido procesado otro mensaje con el mismo RTS). 914 No se acepta la anulación. El HCP no encontró la operación que se quiere anular . Se dará este mensaje como expuesta a

una anulación generada por causa distinta a temporización (ver valor 481) 915 Rechazada la Colecta. No encontrada alguna de las operaciones originales referenciadas. 916 MAC erróneo 940 Recibido 1200 a una operación ya anulada a la que se contestó con 914 o 481. 944 Sesión no permitida 947 Recepción en el HCP de un mensaje de comunicación (1X2X) cuando aún se está procesando una previa (1X2X/X). Solo

se puede dar como respuesta a mensajes de repetición y es el único caso, junto con la no recepción de respuesta, en que se debe seguir enviando la comunicación mediante los mensajes de repetición correspondiente. Es decir, el HE ignorará esta respuesta. 948 Fecha y Hora no sincronizada. Se producirá cuando se reciban en la aplicación del HCP, peti ciones contables con una

Fecha y Hora local superior o inferior en más de dos horas a la del HCP.

949 Fecha de Caducidad de la tarjeta no coincide con la que el Emisor tiene en sus archivos

950-999 Usados en mensajes de respuesta de comunicación contable (1230) para indicar la razón del rechazo. El HCP no contabilizará la operación, lo que producirá descuadre con el HE 950 Violación de las normas existentes para realizar una autorización local 965 Violación de norma existentes para realizar una devolución


Comentarios A continuación, se definen los textos a visualizar por el Terminal ante la recepción de los distintos Códigos de Acción

Código Texto Acción

000 OPERACIÓN ACEPTADA Autorizada

101 TARJETA CADUCADA, OPERACIÓN DENEGADA Denegada

102 OPERACIÓN DENEGADA Denegada

106 EXCESO ERRORES NUMERO SECRETO Denegada

117 ERROR NUMERO SECRETO Solicitar

Secreto

anotación Número

180 TARJETA NO VALIDA Denegada


201 TARJETA CADUCADA, CAPTURE TARJETA Denegada, Capturar

202 CAPTURE TARJETA, OPERACIÓN DENEGADA Denegada, Capturar

206 ERROR NUMERO SECRETO, CAPTURE TARJETA Denegada, Capturar

290 OPERACIÓN DENEGADA, CAPTURE TARJETA Denegada, Capturar

902-949 SU OPERACIÓN NO PUEDE SER REALIZADA EN ESTE MOMENTO No autorizada




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.23 Identificación del Terminal (P-41)

(P-41) Identificación del Terminal ans8

Descripción Identificación del Terminal donde se origina la transacción.

Presencia O 1100 1200 1220 1221

-- 1110 1210 1230 1430

03 1420 1421

316 1604

317 1614

Contenido • Contendrá el valor que identifica al Terminal dentro del Establecimiento. La estructura de este campo dependerá del HCP al que se conecte el HE



7.24 Identificación del Establecimiento (P-42)

(P-42) Identificación del Establecimiento ans15

Descripción Identificación del Establecimiento donde se origina la transacción.

Presencia O 1100 1200 1220 1221

OI 1110 1210 1230 1430

03 1420 1421

316 1604

317 1614

Contenido Siempre se informará con el código FUC asignado al establecimiento o a un centro concreto en el caso

de grandes cadenas comerciales. Validación Estructura Lógica de acuerdo al Formato y Contenido definidos


7.25 Datos Adicionales de la Respuesta (P-44)

(P-44) Datos Adicionales de la Respuesta ans..99

LLVAR Descripción Mensaje informativo a incluir en el recibo.

Presencia -- 1110 1210

Contenido Texto Libre con una longitud máxima de 64 caracteres


Comentarios Este campo se utilizará para enviar mensajes a imprimir en el recibo, por ejemplo 2 líneas de 32 caracteres

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.26 Datos Privados Adicionales (P-48)

(P-48) Datos Privados Adicionales ansb..999

LLLVAR Descripción Información adicional a una transacción. Su contenido deberá ser acordado entre el HE y el HCP para

cada tipo de conexión.

Presencia -- 1100 1200 1220 1221 1110 1210 1230

1420 1421

O 1520 1521 1530

316 1604

317 1614

Contenido Este Elemento de Dato puede estar formado por uno o más subcampos (Datos Adicionales) con la siguiente estructura



Uno o más Datos Adicionales en formato Longitud/Código/Texto

2 bytes 3 byte 2 bytes longitud variable

Cada Dato Adicional se estructura como: Longitud-Código-Texto según se indica a continuación:

Longitud: Tres caracteres numéricos (002-999) donde se especifica la longitud del Dato Adicional, incluyendo Código y Texto

Código: Dos caracteres numéricos (00-99) que indican el tipo de Dato Adicional. Valores:

00-69 01 02 03 04 05 06 11 12 13 14 15 16 35 37 38 39

40

07..69 65

70..79

80..89

90..99

De uso Nacional Código de Banco Cuenta de Abono Identificación de Cuadre/Abono Datos de Abono 1 Posición en Lista negra Datos de Abono en Entorno Multibancario

CVV2/CVC2 Dato de Autenticación del Titular CAVV XID. Dato adicional de Autenticación del Titular UCAF. Universal Cardholder Authentication Versión de Parámetros EMV

Información de Control del PIN/Pad EMV-TDES Datos Cifrados de Pista 2 PAN, Número de Tarjeta. Mascara a Impresora o PAN Real Mobipay Datos Cifrados de tarjeta obtenidos mediante entrada Manual Longitud del PIN Tecleado

Referencia de Operación Libre Código de Razón de Solicitud de Autenticación adicional en V.me

De uso privado para REDSYS


De uso privado para CecaBank



Comentarios • Este campo se utilizará para informar de datos específicos no contemplados por ISO 8583

• Cada Dato Adicional aporta a la longitud total del Elemento de Dato (P-48), su propia longitud, más

las tres posiciones donde se indica la misma

Ejemplos En el valor '0340060111110220211112222334444444444'

• '034' corresponde a la longitud total de (P-48) (este elemento de dato ocupará en transmisión 37 posiciones)

• '006' corresponde a la longitud del 1er Dato Adicional que viaja a conti nuación, con código '01' y texto '1111'

• '022' corresponde a la longitud del 2º Dato Adicional, con código '02' y texto '11112222334444444444'

Hay por tanto dos Datos Adicionales, el '01' y el '02', de longitudes '006' y '022', por tanto la longitud total del Elemento de Dato (P-48) será: 6+3+22+3 = 34, ocupando 37 posiciones en transmisión

Longitud del Elemento de Dato P-48

Longitud del Dato Adicional

Código del Dato Adicional

Texto del Dato Adicional




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Código de Banco (P-48 Código '01')

(P-48)

'01' Código de Banco n4

Descripción Permite informar al HCP el Código del Banco que actúa como Merchant en una Transacción cuando se trabaja en entorno Multibancario

Presencia -- 1100 1200 1220 1221

1420 1421

Obligatorio en todos los mensajes 11xx, 12xx y 14xx enviados por el HE,

cuando se trabaje en entorno Multibancario

Contenido Tendrá la siguiente estructura:

BBBB Código Banco según C.S.B


Comentarios Este Dato Adicional proporciona al Elemento de Dato (P-48) una longitud de 3+2+4 posiciones

Cuenta de Abono (P-48 Código '02')

(P-48)

'02' Cuenta de Abono n20

Descripción Permite al HE informa al HCP los datos de la cuenta en que se ha de realizar el abono (único) de las

transacciones intercambiadas en la sesión

Presencia -- 1100 1200 1220 1221

1520

Obligatorio en mensajes 12xx/1520 enviados por el HE cuando el abono se realice a nivel de Sesión y se aplique una única comisión (en caso de existir varios comercios todos pertenecen al mismo sector de actividad)

Obligatorio en mensajes 1520 enviados por el HE cuando el abono se

realice a nivel de Establecimiento y se aplique una única comisión

OI 1530 Será un eco del mensaje de pregunta


BBBB

SSSS

DC CCCCCCCCCC

Código Banco según C.S.B

Código de Sucursal

Dígitos de control. Valor 00 Número de Cuenta



Identificativo de Cuadre (P-48 Código '03')

(P-48)

'03' Identificativo de Cuadre n10

Descripción Aporta la información acordada de forma bilateral entre HE y HCP, necesaria para identificar la transacción en curso a nivel de cuadre y bono

Presencia -- 1100 1200 1220 1221

1420 1421

Obligatorio en mensajes 12xx/14xx enviados por el HE cuando el abono se

realiza a nivel de Identificati vo de Cuadre

Contenido A acordar entre HE y HCP


Comentarios • El HE utilizará para este Dato Adicional el formato indicado por el HCP

• Este Dato Adicional proporciona al Elemento de Dato (P-48) una longitud de 3+2+10 posiciones

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Datos de Abono (P-48 Código '04')

(P-48)

'04' Datos de Abono ans75..349

Descripción Aporta la información acordada de forma bilateral entre HE y HCP, necesaria para realizar los procesos de cuadre y abono, cuando el abono se realice a nivel de Sesión y existan dentro de ella comercios pertenecientes a distintos sectores de actividad (distintas comisiones) o cuando el abono se realiza a nivel de establecimiento En caso de Abono a nivel de Sesión se informara el Importe del Descuento y el Importe Neto a abonar al HE por parte del Banco Merchant, existiendo un único Abono.

En caso de Abono a nivel de Establecimiento se informará el Importe del Descuento, el Importe neto a abonar por parte del Banco Merchant, existiendo tantos abonos como subtotales con un máximo de 5

Presencia -- 1520 Obligatorio en mensajes 1520 enviados por el HE cuando el abono se realice a nivel de sesión y existan dentro de ella comercios pertenecientes a distintos sectores de acti vidad (disti ntas comisiones) o cuando el abono se realiza a nivel de establecimiento

-- 1530 Obligatorio en los mensajes 1530 de respuesta del HCP cuando se produzca descuadre informando los subtotales del HCP


Campo Formato Comentarios

Número de ocurrencias (Subtotales) n2 Número de elementos (1 a 5) que componen el Dato Adicional

Nivel de Enlace n2 Informa el modo de realizar el abono: 1 Abono a nivel de Sesión (nº de ocurrencias será 1) 2 Abono a nivel de Establecimiento. (nº de ocurrencias podrá ser de 1 a 5)

Para cada ocurrencia

• Identificativo de Establecimiento ans15 Tomará el valor "spaces" cuando el abono se realice a nivel de Sesión.

• Cuenta de Abono n20 Datos de la Cuenta de Abono del HE. Tendrá la siguiente

estructura: BBBB Código Banco según CSB SSSS Código de Sucursal DC Dígitos de control. Valor 00 CCCCCCCCCC Número de Cuenta

• Importe de Comisión X+n16 Importe de la Comisión a cargar/abonar al HE. El primer carácter indicará la acción a realizar: 'D' Abonar, 'C' Cargar El importe se expresará en Euros con dos decimales

• Importe Neto X+n16 Importe Neto que el Banco Merchant abonará/cargará al HE como resultado de las transacciones realizadas durante la sesión contable que se esté cerrando (IMPORTE NETO = IMPORTE TOTAL - IMPORTE COMISIÓN) El primer carácter indicará la acción a realizar: 'D' Abonar, 'C' Cargar El importe se expresará en Euros con dos decimales


Comentarios • Este Dato Adicional queda sustituido por el Dato Adicional Código '06' quedando sin efectividad para todas las conexiones realizadas a partir de la versión de especificaciones de protocolo de fecha 07.03.97

• Este Dato Adicional proporciona al Elemento de Dato (P-48) una longitud de 3+2+2+2+(Nx69)

posiciones, siendo 'N' el número de ocurrencias (1 a 5)




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Posición en Lista Negra (P-48 Código '05')

(P-48)

'05' Posición en Lista negra n6

Descripción Informa de la posición en el fichero de Lista Negra donde se debe incluir la tarjeta

Presencia -- 1110 1210 1230 Obligatorio en mensajes 12xx enviados por el HCP en los que se requiera incluir la tarjeta en Lista Negra

Contenido Seis caracteres numéricos indicando la posición que ocupa la tarjeta en el fichero de Lista Negra


Comentarios • Este Dato Adicional viajará siempre que el campo (P-39) tome valores: '102' '200 a 299' y '901'

• Este Dato Adicional proporciona al Elemento de Dato (P-48) una longitud de 3+2+6 posiciones

Datos de Abono Entorno Multibancario (P-48 Código '06')

(P-48)

'06' Datos de Abono Entorno Multibancario ans36..828

Descripción Aporta la información acordada de forma bilateral entre HE y HCP, necesaria para realizar los procesos

de cuadre y abono, cuando el abono se realiza a nivel de sesión, operando en entorno Multibancario y

pudiendo coexistir en la sesión comercios pertenecientes a igual o diferente sector de actividad.

Se informara el Importe del Descuento y el Importe Neto a abonar al Negocio por cada Banco Merchant

(máximo 25), existiendo tantos abonos como Bancos Merchant.

Presencia -- 1520 Obligatorio en mensajes 1520 enviados por el HE cuando el abono se realice a nivel de sesión, operando en entorno Multibancario y pudiendo coexistir en la sesión comercios pertenecientes a igual o diferente sector de actividad



Número de ocurrencias (Subtotales)

n2 Número de elementos (1 a 25) que componen el Dato Adicional


• Identificativo de Cuadre n10 Informa los datos necesarios para realizar los procesos de Cuadre y Abono

• Cuenta de Abono n20 Datos de la Cuenta de Abono del HE. Tendrá la siguiente estructura: BBBB Código Banco según CSB SSSS Código de Sucursal DC Dígitos de control. Valor 00 CCCCCCCCCC Número de Cuenta

• Signo de la comisión ans1 Indicará la acción a realizar: 'D' Abonar, 'C' Cargar

• Importe de Comisión n16 Importe de la Comisión a cargar/abonar al HE expresado en Euros con dos decimales

• Signo del Importe Neto ans1 Indicará la acción a realizar: 'D' Abonar, 'C' Cargar

• Importe Neto n16 Importe Neto que el Banco Merchant abonará/cargará al HE como resultado de las transacciones realizadas durante la sesión contable que se esté cerrando El importe se expresará en Euros con dos decimales


Comentarios • En caso de conexiones en las que se requiera la utilización de más de 25 Subtotales, se utilizará de forma complementaria el Elemento de Dato (P-62) para enviar los subtotales suplementarios

• Los campos de tipo numérico que forman parte del 'Texto' (Numero de Ocurrencias, Identificativo de Cuadre, Datos de Abono, Importe de Comisiones e Importe Neto) se enviarán compactados

• Este Dato Adicional proporciona al Elemento de Dato (P-48) una longitud de 3+2+1+(Nx33) posiciones, siendo 'N' el número de ocurrencias (1 a 25)

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

CVV2 o CVC2 (P-48 Código 11’)

(P-48) ‘11’ CVV2 o CVC2 n3..4

Descripción Datos adicionales para apoyo a la validación de la tarjeta utilizada en la operación

Presencia -- 1100 1200 1220 1221

1420 1421

Obligatorio en transacciones realizadas en Centros de Voz, por Correo, Teléfono y Comercio Electrónico

Contenido Contendrá el valor del CVV2 o CVC2 capturado en la operación:


Comentarios • Para la mayoría de las tarjetas la longitud de este dato es de 3 dígitos

• Este Dato Adicional proporciona al Elemento de Dato (P-48) una longitud de 3+2+(3 o 4) posiciones • Campo opcional aunque debería llegar en operativa AVS cuando no se envía P48.38

Dato de Autenticación del Titular CAVV (P-48 Código 12’)

(P-48) '12' Dato de Autenticación del Titular CAVV b 20

Descripción Permite trasladar al HCP el dato encriptado de verificación del titular en transacciones realizadas con tarjetas Visa en Operativa de Comercio Electrónico.

Presencia -- 1100 1120 1121

1200 1220 1221 1420 1421

Obligatorio en todos los mensajes de solicitudes en operativa de comercio electrónico iniciados en el servicio V.me si el dato está disponible.

Contenido El establecimiento debe hacer progresar el dato de autenticación al procesador con la siguiente estructura y formato:

Longitud del subcampo: 022

Valor del subcampo 12 Valor CAVV : 20 posiciones en binario



XID. Dato adicional de Autenticación del Titular (P-48 Código 13’)

(P-48) '13'

XID. Dato adicional en Autenticación de Titular b 20

Descripción Permite trasladar al HCP el dato encriptado de verificación del titular en transacciones realizadas con tarjetas Visa en Operativa de Comercio Electrónico.

Dato adicional junto a CAVV.

Presencia -- 1100 1120 1121

1200 1220 1221

1420 1421

Obligatorio en todos los mensajes de solicitudes en

operativa de comercio electrónico iniciados en el servicio

V.me si el dato está disponible.

Contenido El establecimiento debe hacer progresar el dato de autenticación al procesador con la siguiente estructura y formato:

Longitud del subcampo : 022

Valor del subcampo 13 Valor CAVV : 20 posiciones en binario






Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

UCAF. Universal Cardholder Authentication (P-48 Código '14')

(P-48)

'14'

UCAF

Universal Cardholder Authentication

ans32 Descripción Permite trasladar al HCP el dato encriptado de verificación del titular en transacciones realizadas con

tarjetas MasterCard en Operativa de Comercio Electrónico.

Presencia -- 1100 1120 1121

1200 1220 1221

1420 1421

Obligatorio en todos los mensajes de solicitudes en operativa de comercio electrónico iniciados en el servicio V.me si la tarjeta es MasterCard y el dato está disponible.

Contenido El establecimiento debe hacer progresar el dato de autenticación al procesador sin manipular con la siguiente estructura y formato :

Longitud del subcampo : 34

Valor del subcampo 14 Valor CAVV : 32 posiciones



Versión de Parámetros EMV (P-48 Código '15')

(P-48)

'15' Versión de Parámetros EMV nb7

Descripción Identificación del grado de actualización de Parámetros EMV en el terminal con que se realiza la transacción

Presencia -- 1100 1200 1220 1221 Obligatorio en mensajes 1200 enviados por HE iniciados en terminales con capacidad EMV (la 1ª posición del P-22 toma valor '5')


Versión n3 Versión de la Tabla de Parámetros del HE

Capacidades del Terminal b3 Contenido del Tag '9F33'

Tipo de Terminal b1 Contenido del Tag '9F35'


Comentarios • Los Parámetros EMV se estructurarán, para cada terminal con capacidad EMV, en forma de Tabla indexada por AID, debiendo el HE mantener un control de versiones por terminal/tabla de parámetros. Cada AID tendrá asociados los siguientes parámetros:

• TAC's

• Límites de Riesgo

• Parámetros de Aleatorización

• Etiqueta privada • Este Dato Adicional proporciona al Elemento de Dato (P-48) una longitud de 3+2+7 posiciones

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Información de Control del PIN/Pad EMV-TDES (P-48 Código '16')

(P-48)

'16' Información de Control PIN/Pad EMV-TDES

anb30 o anb31 o and34 o anb35

Descripción Proporciona información relativa al PIN/Pad en el que se ha iniciado la operación

Presencia -- 1100 1200 1220 1221

1420 1421

1600

Pasa a ser obligatorio en mensajes 11xx, 12xx y 14xx enviados por HE iniciados en terminales con PIN/Pad EMV-TDES

Obligatorio en mensajes 16xx enviados por HE que utilizan PIN/Pads EMV- TDES con versión PUP igual o superior a la 1.6.0


Número de serie n11 Número de serie del PIN/Pad asignado por el fabricante. Dado un modelo, el número de serie tiene que ser único para cada PIN/Pad de un mismo fabricante.

Fabricante n2 Informa del fabricante del PIN/Pad. El CPD asignará el valor de este campo a cada fabricante.

Modelo n2 Informa el modelo de PIN/Pad. Para cada modelo de PIN/Pad que se homologue, el CPD asignará el valor para este campo y lo comunicará a cada fabricante.

Nombre del Programa de Software

an8 Se informará del nombre del programa de software del PIN/Pad. Tiene que coi ncidir con el nombre del programa de software homologado por el CPD.

Versión del Programa de

software

n4 Se informará de la versión de programa de software del PIN/Pad. Tiene

que coincidir con la versión de software homologada por el CPD. A partir de la versión PUP 1.6.0, el contenido de este campo estará estructurado de la siguiente forma: 1er dígito: indica la configuración Sw instalada en el comercio de acuerdo al Escenario PCI utilizado. Debe coi ncidir con el contenido del campo “Escenario PCI” 2ª-4ª dígitos: indican la Versión Sw del PIN/Pad

Kernel EMV n1 Los valores posibles son 0 y 1, co n el siguiente significado:

0: Kernel EMV fuera del PIN/Pad. 1: Kernel EMV en PIN/Pad.

VCTC b1 Informa la versión de Clave CTC cargada por el HCP. Se enviará a ceros si el PIN/Pad no dispone de la clave CTC. No usados

VCPIN b1 Informa la versión de Clave de PIN cargada por el HCP. Se enviará a ceros si el PIN/Pad no dispone de la clave CPIN. No usados

VCPistas b1 Informa la versión de Clave de Cifrado de Pistas. Viajará a ceros si el PIN/Pad no dispone de las claves de Cifrado de Pistas. Y podrá no viajar en caso de PIN/Pads con Sw ajustado a versiones de PUP inferiores a la 1.2.1 (1.1)

Versión PUP n3 Versión de Especificaciones PUP implementada No viajará en PIN/Pads con versión de Sw ajustadas a versiones PUP anteriores a 1.5.0

Escenario PCI n1 En este campo se informará del escenario escogido por el comercio, y por lo tanto del tipo de aplicación:

1 : La aplicación cumple con el escenario 1 2 : La aplicación cumple con el escenario 2 3 : La aplicación cumple con el escenario 3

La información que se intercambiará en el resto de mensajes deberá

ser siempre coherente con esta definición.

No viajará en PIN/Pads con versión de Sw ajustadas a versiones PUP anteriores a 1.6.0


Comentarios • Su uso será acordado entre el HE y el HCP

• Los campos de tipo numérico que forman parte del 'Texto' (Número de serie, Fabricante, Modelo, Versión del Programa Sw y Kernel EMV) se enviarán compactados

• Este Dato Adicional proporciona al Elemento de Dato (P-48) una longitud de 3+2+30 o 31 o 34 o 35 posiciones




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Indicador de que el terminal soporta single TAP y si se realiza operación SCA con 1 TAP, (P-48 Código ‘22’)

(P-48) ‘22’ Indicador capacidad del TPV 1 TAP y de

repetición de mismos datos EMV (ATC) de operación anterior

a2

Descripción Este indicador proporciona información de si el terminal soporta 1 TAP, y además de si la operación que se realiza se trata de una operación a la que se ha solicitado solo el PIN (1 TAP) de forma que el emisor sepa que los datos EMV son los mismos de una operación previa a la que se ha añadido solo el bloque de PIN, tras haber contestado P39 = 196

Presencia -- 1100

1200

Opcional, de no recibirse indica que el terminal no soporta 1 TAP

Contenido Campo con dos indicadores, que contiene la información relativa a la posibilidad de realizar

autenticación reforzada en un único acercamiento por parte del adquirente En el caso que soportar un único acercamiento también se utilizará para indicar si los datos EMV se envían duplicados entre la transacción original y la segunda transacción con SCA.

Longitud del subcampo: 004

Valor del subcampo : 22

Indicador de capacidad 1 TAP: (0-no soporta single TAP)

(1- Soporta single TAP)

Indicador de mismos datos EMV de una operación anterior: (0 -no, 1 Si)



[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Operativas adicionales. Campo P48.25

(P-

48)

25

Datos Operativas Adicionales ans..999

LLLVAR

Descripción

Información adicional a una transacción. Su contenido deberá ser

acordado entre el HE y el HCP para cada tipo de conexión.

Presencia -- 1100 1120 1121 1200 1220 1221 1110 1130 1210 1230

1420 1421

Contenido

Este Elemento de Dato puede estar formado por uno o más subcampos

(Datos Adicionales) con la siguiente estructura:

“VAR” hasta 999 bytes

Área de Datos


3

bytes 2 bytes

longitud variable

Cada Dato Adicional se estructura como: Longitud-Código-Texto según se

indica a continuación:

Longitud: Tres caracteres numéricos (002-512) donde se especifica la

longitud del Dato Adicional, incluyendo Código y Texto

Código: Dos caracteres numéricos (00-99) que indican el tipo de Dato

Adicional. Valores:

01: EMV 3D SECURE 2.0

Resto: RUF


Validación Estructura Lógica de acuerdo con el Formato y Contenido definidos

Comentarios

Cada Dato Adicional de dicha operativa aporta a la longitud total del

Código del Subelemento P48.25.

• Este Dato Adicional proporciona al Elemento de Dato (P-48) una longitud de

3+2+(1..999) posiciones

Estructura LLL 25 LLL código+texto LLL código+texto ………………..

Longitud del

Dato Adicional

Código

del Dato

Adicional





Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Datos 3D Secure (P-48.25 Código '01') Los datos 3DS pueden venir en este campo o en el P48.61

(P48.25)

'01' Datos EMV 3D Secure 2.0 Ans..37

Descripción Permite informar al HCP la versión y dato 3DS 2.0

Presencia -- 1100 1200 1220 1221 1420 1421

Obligatorio en todos los mensajes 11xx, 12xx y 14xx enviados por el HE


Código 01 Datos obligatorios si versión 3DS 2.0:

• Para operativa Master:

o 1 byte indicando la versión de protocolo y método de autenticación

o 36 bytes indicando el Identificador único de transacción que asigna el DS

• Para operativa Visa:

o 1 byte indicando la versión de protocolo


Comentarios Este Dato Adicional proporciona al Elemento de Dato (P-48.25) una longitud de 3+2+37 posiciones

Ejemplos Subcódigo 01.

Ejemplo VISA:

008 25 003 01 X

Donde X es la versión del protocolo

Ejemplo MasterCard:

044 25 039 01 XYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY

Donde X es la versión del protocolo y YYYYYYYYYYYYYYYYYYYYYYYYY es el dato

identificador del DS

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Datos Cifrados de Pista 2 (P-48 Código '35')

(P-48)

‘35’ Datos de Pista 2 Cifrados b..40

Descripción Datos Cifrados de Pista 2 extraídos de la Banda magnética de la Tarjeta de acuerdo a ISO 7813, incluyendo el campo separador (“7E” en EBCDIC) y excluyendo los centinelas de principio y fin y los caracteres LRC o Pista 2 equivalente extraída del Chip EMV, incluido el campo separador (“7E” en EBCDIC)

Presencia -- 1100 1200 1220 1221

1420 1421

Solo si existe en el mensaje de Pregunta

Contenido Solo viajará y será obligatorio, en caso de utilizarse cifrado de datos de Tarjeta, conteniendo: • En caso de transacciones realizadas con tecnología de Banda Magnética, los Datos cifrados de Pista

2 extraídos de la Banda magnética de la Tarjeta de acuerdo a ISO 7813, incluyendo los campos separadores (“7E” en EBCDIC) y excluyendo los centinelas de principio y fin y los caracteres LRC.

• En caso de transacciones realizadas con tecnología Chip EMV y si existe, la Pista 2 equivalente (EMV Tag 57) extraída del Chip EMV y cifrada


Comentarios • Se utilizará en transacciones realizadas desde Banda Magnética o desde el Chip EMV cuando se realiza cifrado de datos de tarjeta

• Para cifrar la Pista 2, independientemente del modo de obtenerla, se seguirá el siguiente proceso:

• Leer la Pista2 y excluir los centinelas de principio y fin y el LRC

• Anteponer la longitud en 1 byte y completar por la derecha con ceros binarios hasta obtener un múltiplo de 8

• La cadena obtenida se cifrará TDES y el resultado será lo que se envíen en el P-48.35

• Junto con este subcampo se deberán enviar al HCP en los campos P-48.16 y P-53 los datos utilizados por el PIN- Pad para el cifrado de eta información.

• Este subcampo imputa a P-48 una longitud de 3+2+(1+longitud Pista2+longitud de relleno Pista2)

PAN, Número de Tarjeta. Mascara a Impresora o PAN Real (P-48 Código ‘37’)

(P-48)

‘37’

PAN, Número de Tarjeta. o Mascara a impresora

ans.19

LLVAR Descripción String de caracteres alfanuméricos conteniendo el PAN a imprimir en el recibo y protegido por mascara,

según normativa de marcas internacionales

Presencia -- 1110 1210 1230 Obligatorio en mensajes 1210/1230 en caso de utilizarse cifrado de datos de Tarjeta y la operación esté autorizada y no se haya recibido el campo P-02

Contenido Solo viajará y será obligatorio, en caso de utilizarse cifrado de datos de Tarjeta y la operación esté autorizada y no se haya recibido el campo P-02

Contendrá el PAN a imprimir en recibo y protegido mediante mascará


Comentarios




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Datos Cifrados de Tarjeta obtenidos mediante Entrada Manual (P-48 Código '38')

(P-48)

‘38’

Datos Cifrados de tarjeta obtenidos mediante Entrada Manual

b..32

Descripción Datos Cifrados de tarjeta cuando estos se han obtenido mediante entrada. Estos campos son: PAN, Fecha de Caducidad y CVV2/CVC2

Presencia -- 1100 1200 1220 1221

1420 1421


Contenido Solo viajará y será obligatorio, en caso de utilizarse cifrado de datos de Tarjeta,


Campo obligatorio en operativa AVS si no se envía P14 ni p48.11

Comentarios • Se utilizará en transacciones realizadas con Entrada Manual y cuando se realiza cifrado de datos de tarjeta

• Para cifrar los datos de Tarjeta, se seguirá el siguiente proceso:

• Obtener el PAN y anteponer la longitud en 1 byte en BCD

• Concatenar la Fecha de Caducidad y el CVV2/CVC2. Estos campos, en caso de no existir, tomarán respectivamente los siguientes valores por defecto ‘0000’ para la Fecha de Caducidad y ‘FFFFF’ para el CVV2/CVC2

• Si se teclea CVV2/CVC2, no deberá ser ni inferior a 3 ni superior a 5 posiciones. Se rellenará con ‘X’ por la izquierda si el CVV2/CVC2 introducido es inferior a 5 posiciones.

• Completar por la derecha con ceros binarios hasta obtener un múltiplo de 8

• La cadena obtenida se cifrará TDES y el resultado será lo que se envíen en el P-48.38

• Este subcampo imputa a P-48 una longitud de: 3+2+(1+longitudelPAN(..19)+4 bytes de fecha de Caducidad(MMAA)+5 bytes de CVV2/CVC2)

Longitud de PIN tecleado (P-48 Código '39')

(P-48)

‘39’ Longitud de PIN Tecleado a1

Descripción Longitud de PIN Tecleado

Presencia -- 1100 1200 Obligatorio cuando la validación de PIN se realice por el HCP (On-Line) y el bit 12 del P-22 indique capacidad de entrada de PIN superior a 4

Contenido Solo viajará y será obligatorio, cuando la validación de PIN se realice por el HCP (On-Line) y el bit 12 del P-22 indique capacidad de entrada de PIN superior a 4

Validación Se validará Formato, Contenido y coherencia

Comentarios Este subcampo imputa a P-48 una longitud de 3+2+1

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Referencia de la Operación (P-48 Código '40')

(P-48)

‘40’ Referencia de la Operación b..24

Descripción Parte inicial de los datos Cifrados de Pista 2 extraídos de la Banda magnética de la Tarjeta de acuerdo a ISO 7813, incluyendo el campo separador (“7E” en EBCDIC) y excluyendo los centinelas de principio y fin y los caracteres LRC o Pista 2 equivalente extraída del Chip EMV, incluido el campo separador (“7E” en EBCDIC), utilizada para ajustes sobre operaciones previamente en HCP.

Presencia -- 1220 1221

1420 1421


Contenido Solo viajará y será obligatorio, en caso de utilizarse cifrado de datos de Tarjeta sustituyendo al PAN (P- 02), conteniendo: • En caso de transacciones realizadas con tecnología de Banda Magnética, 24 primeros bytes de los

Datos cifrados por el PIN-Pad de Pista 2 extraídos de la Banda magnética de la Tarjeta de acuerdo a ISO 7813, incluyendo los campos separadores (“7E” en EBCDIC) y excluyendo los centinelas de principio y fin y los caracteres LRC.

• En caso de transacciones realizadas con tecnología Chip EMV y si existe, 16 primeros bytes de la

Pista 2 equivalente (EMV Tag 57) extraída del Chip EMV y cifrada por el PIN-Pad Validación Se validará Formato, Contenido y coherencia según tecnología y marca de la tarjeta

Comentarios • Se utilizará en transacciones realizadas desde Banda Magnética o desde el Chip EMV cuando se realiza operaciones de Devolución, Preautorización Sustitutiva y Confirmación cuando se realicen sin presencia del cliente o por ajuste sobre una operación previamente gestionada en el HCP con cifrado de datos de tarjeta.

• Para cifrar la Pista 2, independientemente del modo de obtenerla, el PIN-Pad seguirá el siguiente proceso:

• Leer la Pista2 y excluir los centinelas de principio y fin y el LRC

• Anteponer la longitud en 1 byte y completar por la derecha con ceros binarios hasta obtener un múltiplo de 8

• La cadena obtenida será cifrada TDES y los 16 o 24 primeros bytes del resultado será lo que se envíe en el P-

48.40

• Junto con este subcampo se deberán enviar al HCP en los campos P-48.16 y P-53 los datos utilizados por el PIN- Pad para el cifrado de eta información.

• Este subcampo imputa a P-48 una longitud máxima de 3+2+(24)

P48.48 INDICADOR AFD

(P-48)

’48’ Campo indicador de AFD Ans1

Descripción Flag que indicara el comercio al host que el terminal está adaptado para el tratamiento AFD

Presencia -- 1100


Contenido Solo viajará y será obligatorio, en caso de utilizarse operativa AFD •


Comentarios • Valores posibles

• 0.- no admite AFD

• 1.- Admite AFD • Este subcampo imputa a P-48 una longitud máxima de 3+2+(1)




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Datos de credenciales en archivo P48 (52)

(P-48)

‘52’ Credenciales en archivo ans...21

Descripción Este campo aporta información adicional en relación con transacciones realizadas con credenciales en archivo.

Presencia -- 1100 1200 1220 1221

1420 1421 1110 1230 1430

Contenido Estará formado por tres campos, que pueden contener los siguientes valores:

1. Uso. Para realizar transacciones de tipo:

R (Recurrente)

I (Installments)

C (Compra única)

D (Delayed)

E (Resubmision)

H (Reautorización)

M (Incremental)

N (No show)

2. Identificación de la 1ª transacción

Valor S (1ª transacción)

Valor N

3. Sólo en transacciones con emisor de tarjeta extranjero si se recibió en respuesta previa (resto

a espacios)

Identificación de la 1ª transacción en operativas recurrentes o instalments

LLans…15 posiciones justificadas a la izquierda.

Su presencia viene determinada por la longitud total del subcampo 52.

Validación Estructura lógica de acuerdo con lo expuesto.

Comentarios

Ejemplo

Primera transacción en petición. Dos posibles casos:

1. Transacción que sólo guarda la credencial de importe 0:

P04 = 0

P22.5 = 5

P24=150

P48.52 = 004 de longitud + ‘52 + R/I/C + S

En respuestas (1110), si es internacional mandaremos el campo3 con identificación de

operación.

2. Transacción que guarda la credencial y es la primera compra:

P4 > 0

P22.5 = 5

P22.9 = F

P48.52 = 004 de longitud + ‘52’ + R/I/C + S

En respuestas (1110 1210), si es internacional mandaremos el campo3 con identificación de

operación.

Siguientes transacciones.

P4 > 0

P22.9 = F

P48.52 = 004 de longitud + ‘52’ + (‘R’ o ‘I’ o ‘C’) + identificativo de primera operación o

espacios.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Payment account reference (PAR) (P-48.58)

(P48)

58 PAR ans..29

Descripción Informa de la referencia de pago de la cuenta. Elemento que identifica unívocamente al titular que puede realizar pagos con los distintos dispositivos medios de pago asociados a un único PAN real

Presencia -- 1100 1200 1220 1221 1110 1210

Contenido Este Elemento de Dato puede estar formado por dos subcampos

La estructura general del Elemento de dato P-48-58 es la siguiente:

Posición Descripción 1-4 Identificador Controlador de BIN – asignado por EMVco 5-29 25 caracteres alfanuméricos únicos generados que se asignan al PAN


Comentarios Se trata de un dato único de 25 caracteres alfanuméricos PAR (Payment Account Reference) (9F24) (opc./ var 29 pos alfanuméricas)[an 1 a 29]

Ejemplos




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Datos 3D Secure (P-48.61) Los datos 3DS pueden venir en este campo, o en el P48.25.01

(P48)

‘61’ Datos EMV 3D Secure 2.0 Ans..37

Descripción Permite informar al HCP la versión y dato 3DS 2.0

Presencia -- 1100 1200 1220 1221 1420 1421

Obligatorio en todos los mensajes 11xx, 12xx y 14xx enviados por el HE


Código 01 Datos obligatorios si versión 3DS 2.0:

• Para operativa Master:

o 1 byte indicando la versión de protocolo y método de autenticación

o 36 bytes indicando el Identificador único de transacción que asigna el DS

• Para operativa Visa:

o 1 byte indicando la versión de protocolo


Comentarios Este Dato Adicional proporciona al Elemento de Dato (P-48.25) una longitud de 3+2+37 posiciones

Ejemplos Subcódigo 01.

Ejemplo VISA:

008 25 003 01 X

Donde X es la versión del protocolo

Ejemplo MasterCard:

044 25 039 01 XYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY

Donde X es la versión del protocolo y YYYYYYYYYYYYYYYYYYYYYYYYY es el dato

identificador del DS

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Código de Razón de Solicitud de Autenticación adicional en V.me (P-48 Código '65')

(P-48)

'65' Código de Razón de Solicitud de Autenticación adicional en V.me

an2

Descripción Permite informar al HCP el Código de razón de solicitud de autenticación adicional en operativa

V.me.

Presencia -- 1100 1120 1121 Obligatorio en todos los mensajes de solicitudes en operativa de 1200 1220 1221 comercio electrónico iniciados en el servicio V.me.

1420 1421

Contenido Se adjunta tabla con posibles valores y su significado.

Estos valores corresponden al valor que recibe el comercio de V.me sin manipular.



1er

uso

V.me

no disponible

Solicitado

Por V.me

Solicitado por Titular Solicitado por Comercio No solicitado Valor P48.65

X 01

X 02

X 03

X X 04

X 05

X X 06

X X 07

X X X 08

X 09

X X 0A

X X 0B

X X X 0C

X X 11

X X 12

X X 13

X X X 14

X X 15

X X X 16

X X X 17

X X X X 18

X X X 19

X X X 1A

X X X 1B

X X X X 1C




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.27 Bloque de PIN (P-52)

(P-52) Bloque de PIN b8

Descripción Valor cifrado derivado del PIN introducido por el cliente en el punto de servicio

Presencia 301 1100 1200

Contenido Bloque de PIN Cifrado


Comentarios Será obligatorio en peticiones contables (1200), siempre que sea introducido por el cliente y deba ser verificado por el HCP o la entidad emisora de la tarjeta.

• Se deberá indicar en elemento de dato 'Información de Control y Seguridad' (P-53) toda la información requerida para la verificación en el HCP (Formato de Seguridad, Algoritmo de Cifrado, Formato de Bloque de PIN y el Índice de la clave utilizada)

• Y en caso de que en el P-22 bit 12, tome valor superior a 4 (capacidad del PIN/Pad para aceptar un PIN de longitud superior a 4), se deberá indicar la longitud del PIN (P-48, Cod 39)

7.28 Información Control y Seguridad (P-53)

(P-53) Información de Control y Seguridad n16

Descripción Información de seguridad para cifrado/descifrado de PIN y/o generación/verificación del Código de Autentificación del Mensaje (P-64/S-128)

Presencia O

--

1100 1200 1220 1221

1304

1420 1421

1604

Contenido Este campo está dividido, de forma lógica, en seis subcampos cuyo significado y valores posibles

especificamos a continuación:

Dígitos 1-2 Código de Formato de Seguridad

01

2x

8x 9x

Formato EMV

Cifrado de Pistas H2H

Formato EMV, con cifrado de Pistas y sin derivación de clave (‘x’ indica el número de clave) Formato EMV, con cifrado de Pistas y derivación de clave (‘x’ indica el número de clave)

Dígitos 3-4 Algoritmo de Cifrado

02 TDES

Dígitos 5-6 Código de Formato de Bloque de PIN

00 Sin PIN

01 ANSI

10 ISO 0

11 ISO 1

25 PIN ya verificado (PIN Off) o dispositivo cliente

Dígitos 7-8 Índice de Clave de PIN

00 Sin PIN

01 Clave 1

02 Clave 2

Dígitos 9-10 Índice de Clave de MAC

01 Clave 1

02 Clave 2

Dígitos 11-16 Datos de seguridad. Número aleatorio (generado en el PIN/Pad) utilizado como elemento de Seguridad para los procesos de cifrado de datos de tarjeta. Tomará el valor "000000" cuando no se utilice cifrado de datos de tarjeta


Comentarios • En el ANEXO-A se describen los mecanismos de seguridad del MAC • En el ANEXO-A se describe el procedimiento de generación del Código de Autentificación del

Mensaje (P-64/S-128)

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.29 Datos asociados al Chip EMV (P-55)

(P-55) Datos asociados al Chip EMV ansb..300

LLLVAR Descripción Informa datos específicos EMV cuando se realizan transacciones con tarjeta Chip EMV

Presencia -- 1100 1200 1220 1221 1110 1210

Contenido Este Elemento de Dato puede estar formado por uno o más subcampos referenciados en este

documento por P-55 (“hh”) o P-55 (“hhhh”), donde (“hh”) y (“hhhh”) es el Código de subcampo. Este Código, que coincide con la etiqueta (Tag) asignada al subcampo en especificaciones EMV, puede

estar formado por 2 o 4 semicaracteres, con representación Hex.

La estructura general del Elemento de dato P-55 es la siguiente:

“LLL” “VAR” hasta 300bytes


Uno o más Subcampos en formato TLV

2 bytes

1 o 2 bytes

1 byte

longitud variable

La longitud total del Elemento de dato P-55 se codifica en dos caracteres, usando formato BCD

Cada Subcampo se estructurará en formato TLV -Tag (etiqueta-código), Longitud, Valor (datos)- como se indica a continuación:

Etiqueta: Uno o dos caracteres binarios que identifican el Código del Subcampo. Se corresponde con la

etiqueta (Tag) asignada al campo en las Especificaciones EMV. Solo se requerirá codificar el segundo byte cuando los cinco bits menos significativos del primer bytes sean todos igual a “1”. Longitud: Un carácter binario donde se especifica la longitud (en bytes) de los Datos (valor) del Subcampo

Datos (valor): Contenido del subcampo identificado por la Etiqueta (Tag). Codificado en binario o BCD,

según corresponda al tipo de dato, y con la longitud especificada



Comentarios • Cada subcampo presente, aporta a la longitud total del P-55, la longitud de cada una de las componentes que lo forman (Etiqueta, Longitud y Datos)

• Los subcampos pueden aparecer en cualquier orden. • Se recomienda un tratamiento abierto de este campo, es decir, se debe contemplar la posibilidad de

recibir algún subcampo no presente en este documento, por tanto el HE que reciba un subcampo que no reconozca, simplemente saltará la etiqueta y las posiciones indicadas y lo ignorará, pasando a tratar el siguiente. De esta forma se evita el tener que hacer actualizaciones en el caso de inclusión de nuevos campos, hasta que sea necesario su tratamiento por parte de la Entidad.

Ejemplos En el valor "`00`12`5F`2A`02`09`78`95`05`80`28`30`C0`90" `00`12` (dos bytes en BCD) longitud total del P-55 (En realidad ocupa 14 posiciones) `5F`2A (dos bytes, en hexadecimal) etiqueta del subcampo 1 que viene a conti nuación `02` (un byte binario) que indica la longitud del campo Dato que viaja a conti nuación `09`78` (dos bytes, en BCD).que contiene el campo Dato asociado a la Etiqueta

`95 (un byte, en hexadecimales) etiqueta del subcampo 2 que viene a conti nuación `05` (un byte binario) que indica la longitud del campo Dato que viaja a conti nuación `80`28`30`C0`90` (ci nco bytes binarios).que contiene el campo Dato asociado a la etiqueta Hay por tanto dos subcampos de tipo EMV presentes, el ‘5F2A’ y el ‘95’, de longitudes 005 (2 + 1 + 2) y 007 (1 + 1 + 5), por tanto la longitud total será 005 + 007 = 012, ocupando físicamente 14 posiciones.


Código del Subcampo Longitud del Subcampo

Datos del Subcampo




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Script Template 1 del Emisor (P-55 Tag’71’)

P-55 (‘71’) Script Template 1 del Emisor b..128

Descripción Script Enviado por el Emisor a la Tarjeta para su actualización. Codificado según Especificaciones EMV y con estructura TLV. Dato suministrado por el Emisor. Este subcampo proporciona a P-55 una longitud máxima de 1 + 1 + 128 bytes.

Presencia -- 1110 1210 Solo en caso de transacciones EMV

Contenido Datos a actualizar en el Chip de la Tarjeta, incluyendo comandos a enviar al mismo, más la información

requerida en dichos comandos. Validación La establecida en el terminal para este tipo de dato

Comentarios Se utilizará opcionalmente en mensajes de respuesta a peticiones contables para operaciones con

tarjeta EMV.

Precediendo al dato, aparece la longitud, ocupando un byte, e indicando un máximo de longitud de Dato de 128 (codificado como `80’).

Script Template 2 del Emisor (P-55 Tag’72’)

P-55 (‘72’) Script Template 2 del Emisor b..255

Descripción Script Enviado por el Emisor a la Tarjeta para su actualización.

Codificado según Especificaciones EMV y con estructura TLV

Dato suministrado por el Emisor. Este subcampo proporciona a P-55 una longitud máxima de 1 + 1 + 255 bytes.


Contenido Datos a actualizar en el Chip de la Tarjeta, incluyendo comandos a enviar al mismo, más la información requerida en dichos comandos.

Validación La establecida en el terminal para este tipo de dato

Comentarios Se utilizará opcionalmente en mensajes de respuesta a peticiones contables para operaciones con tarjeta EMV. Precediendo al dato, aparece la longitud, ocupando un byte, e indicando un máximo de longitud de Dato de 255 (codificado como `FF’).

Perfil de Intercambio de la Aplicación (AIP) (P-55 Tag’82’)

P-55 (‘82’) Perfil de Intercambio de la Aplicación (AIP) b2

Descripción Indica la Capacidad del Chip de la Tarjeta para soportar funciones específicas.


Dato suministrado por el Chip de la Tarjeta.

Este subcampo proporciona a P-55 una longitud de 1 + 1 + 2 bytes.

Presencia -- 1100 1200 1220 1221 1420 1421

Solo en caso de transacciones EMV.

Contenido Perfil de Intercambio de la Aplicación (AIP). Capacidad de la Tarjeta en cuanto a autenticaciones, verificación del Titular y manejo de riesgo.


Comentarios Se utilizará en mensajes de petición y comunicación Contable en operaciones con tarjeta EMV. Precediendo al dato, aparece la longitud (02) en un byte.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Código de Respuesta (P-55 Tag’8A’)

P-55 (‘8A’) Código de Respuesta an2

Descripción Código de Respuesta dado a la transacción. Codificado según Especificaciones EMV y con estructura TLV Dato suministrado por el Emisor, o por el Terminal. Este subcampo proporciona a P-55 una longitud de 1 + 1 + 2 bytes.

Presencia -- 1110 1220 1221 1210

1420 1421

Solo en caso de transacciones realizadas con Chip EMV, siendo obligatorio en mensajes enviados por el terminal y opcional en mensajes enviados por el HCP. En este último caso, si el HCP lo envía, el terminal utilizará el valor recibido y en caso contrario, el terminal lo generará según normativa EMV

Contenido Código de Respuesta a la Transacción. En operativa Online, este dato lo facilita el Emisor o su agente. En operativa Offline, el Código de Respuesta viene dado por el Terminal.


Comentarios Se utilizará en mensajes de respuesta a Petición Contable y en los de Comunicación Contable de operaciones realizadas con tarjeta EMV. Precediendo al dato, aparece la longitud (02) en un byte.

Datos del Emisor para su Autentificación (P-55 Tag’91’)

P-55 (‘91’) Datos del Emisor para su Autentificación b..16

Descripción Información aportada por el Emisor como dato que permite la Autenticación del mismo, una vez

presentada a la Tarjeta. Codificado según Especificaciones EMV y con estructura TLV Dato suministrado por el Emisor. Este subcampo proporciona a P-55 una longitud máxima de 1 + 1 + 16 bytes


Contenido Dos campos:

• Criptograma de Respuesta (ARPC). 8 bytes binarios.

• Código de Respuesta de la Autorización. 2 bytes. En el futuro podrán contemplarse otros datos opcionales.


Comentarios Se utilizará en mensajes de respuesta a Peticiones Contables para operaciones realizadas con tarjeta EMV.

Precediendo al dato, aparece la longitud, ocupando un byte, e indicando un máximo de longitud de Dato de 16, normalmente solo se utilizaran 10 codificado como h`10’.




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Resultado de la Verificación del Terminal (TVR) (P-55 Tag’95’)

P-55 (‘95’)

Resultado de Verificación del Terminal (TVR)

b5

Descripción Indica el Resultado de las Verificaciones efectuadas entre el Terminal y el Chip de la Tarjeta, desde el punto de vista del Terminal. Codificado según Especificaciones EMV y con estructura TLV

Dato suministrado por el Terminal Este subcampo proporciona a P-55 una longitud de 1 + 1 + 5 bytes

Presencia -- 1100 1200 1220 1221

1420 1421


Contenido Resultado de las Verificaciones realizadas en el Terminal. Referencia diversos aspectos como: Autenticación de la Tarjeta, Control de Versiones de Aplicación, Verificación de Usuario, Control de Riesgos, Tratamiento de Scripts precedentes, ..


Comentarios Se utilizará en mensajes de Petición y Comunicación Contables en operaciones con tarjeta EMV. Precediendo al dato, aparece la longitud (05) en una byte.

Fecha de la Transacción (P-55 Tag’9A’)

P-55 (‘9A’) Fecha de la Transacción n6

Descripción Fecha de la Transacción.



Presencia -- 1100 1200 1220 1221

1420 1421


Contenido Fecha de la Transacción, con formato AAMMD y codificado en BCD


Comentarios Se utilizará en mensajes de Petición y Comunicación Contables en operaciones con tarjeta EMV. Precediendo al dato, aparece la longitud (03) en un byte. El Dato ocupara 3 bytes codificados en BCD

Tipo de Transacción (P-55 Tag’9C’)

P-55 (‘9C’) Tipo de Transacción n2

Descripción Indica el Tipo de Transacción. Normalmente coincide con los dos primeros dígitos del Código de Proceso.

Codificado según Especificaciones EMV y con estructura TLV Dato suministrado por el Terminal Este subcampo proporciona a P-55 una longitud de 1 + 1 + 1 bytes

Presencia -- 1100 1200 1220 1221 1420 1421


Contenido Tipo de Transacción, codificado en BCD


Comentarios Se utilizará en mensajes de Petición y Comunicación Contables en operaciones con tarjeta EMV. Precediendo al dato, aparece la longitud (01) en un byte. El Dato ocupara 1 byte codificados en BCD

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Código de Moneda (P-55 Tag’5F2A’)

P-55 (‘5F2A’) Código de Moneda n3

Descripción Código de Moneda de la Transacción. Codificado según Especificaciones EMV, y con estructura TLV: Etiqueta (“Tag”), Longitud, Valor. Dato suministrado por el Terminal. Este subcampo proporciona a P-55 una longitud de 2 + 1 + 2 bytes.

Presencia -- 1100 1200 1220 1221

1420 1421


Contenido Código de Moneda según NORMA ISO 4217. En formato BCD, tres dígitos, y relleno con ‘0’ a la izquierda.


Comentarios Se utilizará en mensajes de petición y comunicación contable en operaciones con tarjeta EMV.

Precediendo al dato, aparece la longitud (02) en una posición. Al ser un campo numérico de tres dígitos y estar comprimido en BCD, ocupa dos posiciones.

Importe de la Transacción (P-55 Tag’9F02’)

P-55 (‘9F02’)

Importe de la Transacción n12

Descripción Importe de la Transacción para su autorización.



Presencia -- 1100 1200 1220 1221

1420 1421


Contenido Importe de la Transacción, codificado en BCD


Comentarios Se utilizará en mensajes de Petición y Comunicación Contables en operaciones con tarjeta EMV.

Precediendo al dato, aparece la longitud (06) en una byte. El Dato ocupara 6 bytes codificados en BCD




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Datos de Aplicación del Emisor (P-55 Tag’9F10’)

P-55 (‘9F10’) Datos de Aplicación del Emisor b..32

Descripción Contiene los Datos de Aplicación almacenados por el Emisor en el Chip de la tarjeta. Codificado según Especificaciones EMV y con estructura TLV Dato suministrado por el Chip de la tarjeta. Este subcampo proporciona a P-55 una longitud máxima de 2 + 1 + 32 bytes

Presencia -- 1100 1200 1220 1221

1420 1421


Contenido Datos de Aplicación del Emisor.

Está formado por unos datos discrecionales propietarios de la marca de la Tarjeta más, opcionalmente, datos discrecionales del Emisor. Dentro de los Datos obligatorios se incluyen, como más destacados, los siguientes:

• Índice de Clave de Diversificación

• Número de Versión del Criptograma • Resultado de Verificación de la Tarjeta (CVR)


Comentarios Se utilizará en mensajes de Petición y Comunicación Contables en operaciones con tarjeta EMV. Precediendo al dato, aparece la longitud, ocupando un byte, e indicando un máximo de longitud de Dato de 32 (codificado como `20’).

Código de País del terminal (P-55 Tag’9F1A’)

P-55

(‘9F1A’) Código de País del Terminal n3

Descripción Código ISO del País donde está el terminal Codificado según Especificaciones EMV y con estructura TLV


Presencia -- 1100 1200 1220 1221

1420 1421


Contenido Código de País del Terminal según norma ISO 3166



Precediendo al dato, aparece la longitud (02) en un byte El Dato ocupara 2 bytes codificados en BCD

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Criptograma de Petición (P-55 Tag’9F26’)

P-55 (‘9F26’) Criptograma de Petición b8

Descripción Contiene el Criptograma generado por la Tarjeta para el proceso de Autentificación Codificado según Especificaciones EMV y con estructura TLV Dato suministrado por el Chip de la Tarjeta Este subcampo proporciona a P-55 una longitud de 2 + 1 + 8 bytes

Presencia -- 1100 1200 1220 1221

1420 1421


Contenido Criptograma de Aplicación. Existen dos tipos de criptogramas a enviar al HCP:

• Criptograma de pregunta ARQC

• Criptograma de Confirmación Positiva TC • Criptograma de Anulación (AAC) (solo en mensajes de Anulación)


Comentarios Se utilizará en mensajes de Petición y Comunicación Contables en operaciones con tarjeta EMV. Precediendo al dato, aparece la longitud (08) en un byte

Datos de Información del Criptograma (P-55 Tag’9F27’)

P-55 (‘9F27’) Datos de Información del Criptograma b1

Descripción Contiene información sobre el tipo de Criptograma utilizado, así como indicaciones realizadas por la Tarjeta al terminal sobre acciones a realizar por éste. Codificado según Especificaciones EMV y con estructura TLV

Dato suministrado por el Chip de la Tarjeta Este subcampo proporciona a P-55 una longitud de 2 + 1 + 1 bytes

Presencia -- 1100 1200 1220 1221

1420 1421


Contenido Datos de Información del Criptograma. Informa sobre el tipo de Criptograma, exigencia de comunicación de la transacción y el motivo de la comunicación o no autorización.



Capacidades del Terminal (P-55 Tag’9F33’)

P-55 (‘9F33’) Capacidades del Terminal b3

Descripción Contiene el perfil indicativo de la Capacidades del Terminal con referencia a la entrada de datos, métodos de verificación del terminal (CVM) y seguridad

Codificado según Especificaciones EMV y con estructura TLV Dato suministrado por el terminal Este subcampo proporciona a P-55 una longitud de 2 + 1 + 3 bytes

Presencia -- 1100 1200 1220 1221 1429 1421


Contenido Se compone de tres bytes, cada uno de los cuales hace referencia a un aspecto. Byte 1: Capacidad de Entrada de Datos de la Tarjeta.

Byte 2: Capacidad de CVM (Métodos de Verificación del Titular) Byte 3: Capacidad de Seguridad






Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Resultado del Método de Verificación del Titular (P-55 Tag’9F34’)

P-55 (‘9F34’)

Resultado del Método de Verificación del Titular

b3

Descripción Indica el Resultado de los Métodos para verificar al titular de la tarjeta (CVM) utilizados Codificado según Especificaciones EMV y con estructura TLV Dato suministrado por el Terminal Este subcampo proporciona a P-55 una longitud de 2 + 1 + 3 bytes

Presencia -- 1100 1200 1220 1221 1420 1421


Contenido Se compone de tres bytes, cada uno de los cuales hace referencia a un aspecto.

Byte 1: CVM realizado, de la lista de posibles. Byte 2: Código de Condición del CVM. Byte 3: Resultado del CVM.



Tipo de Terminal (P-55 Tag’9F35’)

P-55 (‘9F35’) Tipo de Terminal b1

Descripción Identifica el escenario de funcionamiento del terminal, sus capacidades de comunicación y quien

controla su operativa Codificado según Especificaciones EMV y con estructura TLV Dato suministrado por el terminal (los valores serán previamente acordados entre HE y HCP) Este subcampo proporciona a P-55 una longitud de 2 + 1 + 1 bytes

Presencia -- 1100 1200 1220 1221 1420 1421


Contenido El establecido por EMV para el Tipo de Terminal donde se originó la transacción



Contador de Transacción de la Aplicación (ATC) (P-55 Tag’9F36’)

P-55 (‘9F36’)

Contador de Transacción de la Aplicación (ATC)

b2

Descripción Contiene el contador de transacción dentro de la aplicación

Codificado según Especificaciones EMV y con estructura TLV Dato suministrado por el Chip de la tarjeta Este subcampo proporciona a P-55 una longitud de 2 + 1 + 2 bytes

Presencia -- 1100 1200 1220 1221

1420 1421


Contenido Valor inicial cero. Cada vez que se realiza una transacción se incrementa en 1.



Precediendo al dato, aparece la longitud (02) en un byte

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Número Aleatorio para el Criptograma (P-55 Tag’9F37’)

P-55 (‘9F37’) Número Aleatorio para el Criptograma b4

Descripción Número Aleatorio generado por el terminal y que es utilizado por la tarjeta para generar el Criptograma. Codificado según Especificaciones EMV y con estructura TLV Dato suministrado por el Terminal Este subcampo proporciona a P-55 una longitud de 2 + 1 + 4 bytes

Presencia -- 1100 1200 1220 1221

1420 1421


Contenido Número Aleatorio generado por el terminal en cada transacción



Precediendo al dato, aparece la longitud (04) en un byte

Form Factor Indicator (FFI) (P-55 Tag‘9F6E’)

P-55 (‘9F6E’) Form Factor Indicator (FFI) b..32

Descripción Identifica características de los dispositivos contactless (terminales y tarjetas) utilizado en la operación Codificado según Especificaciones EMV y con estructura TLV Dato suministrado por el terminal Este subcampo proporciona a P-55 una longitud máxima de 2 + 1 + 32 bytes

Presencia -- 1100 1200 1220 1221 1420 1421

Solo en caso de transacciones Contactless.

Contenido El establecido por las Marcas de productos contactless para el Tipo de dispositivos intervinientes en la transacción.

• En operativa PayPass Mchip se corresponde con el campo “Third Party Data” de longitud máxima de 64 caracteres

• En operativa Paywave se corresponde con el campo “Form factor Indicator” de longitud 8 caracteres


Comentarios Se utilizará opcionalmente en mensajes de petición y comunicación contables para operaciones realizadas con tecnología contactless. Precediendo al dato, aparece la longitud, ocupando un byte, e indicando un máximo de longitud de Dato de 32 (codificado como `20’).




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

P-55 (‘84’) Datos del AID b..16

Descripción Información aportada por el Emisor Codificado según Especificaciones EMV y con estructura TLV Dato suministrado por el Emisor. Este subcampo proporciona a P-55 una longitud máxima de 1 + 1 + 16 bytes

Presencia -- 1100 1200 1220 1221

1420 1421

Solo en caso de transacciones EMV

Contenido AID de la aplicación con la que se realiza la operación


Comentarios Se utilizará en mensajes de Petición y Comunicación Contables en operaciones con tarjeta EMV y contact less Precediendo al dato, aparece la longitud, ocupando un byte, e indicando un máximo de longitud de Dato

de 16, normalmente solo se utilizarán 10 codificado como h`10’.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.30 Elemento de Datos Adicionales (P-56)

(P-56) Elemento de Datos Adicionales n..35

LLVAR Descripción Elementos de datos contenido en el mensaje original necesarios para el emparejamiento de las

transacciones

Presencia O 1220 1221 1420 1421

Contenido Tendrá el siguiente formato • Identificador Tipo de Mensaje del mensaje original. • Número de Identificación de Transacción (P-11) del mensaje original.

• Fecha y Hora Local de Transacción (P-12) del mensaje original. • Código de Identificación del Adquirente (P-32) del mensaje original

Validación Estructura Lógica de acuerdo al Formato y Contenido definidos, además de las validaciones propias de los subcampos que la forman

Comentarios Estos cuatro Elementos de Datos serán los requeridos para realizar la búsqueda de la transacción

original referenciada.




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.31 Datos Privados Adicionales 2 (P-62)

(P-62) Datos Privados Adicionales 2 ans..999

LLLVAR Descripción Información adicional a una transacción, complementaria a la que se envía en el elemento de dato (P-

48). Su contenido deberá ser acordado entre el HE y el HCP para cada tipo de conexión

Presencia -- 1520





2 bytes

1 byte

2 bytes

longitud variable

Cada Dato Adicional se estructurara en formato Longitud, Código, Texto como se indica a continuación:

Longitud: Tres caracteres numéricos (002-999) donde se especifica la longitud del Dato Adicional,

incluyendo Código y Texto

Código: Dos caracteres numéricos (00-99) que indican el tipo de Dato Adicional. Valores:

00-69 00..05

06

07..69

70..79

80..89

90..99

De uso Nacional Libre Datos de Abono en Entorno Multibancario 2 Libre






Comentarios • Este campo se utilizará para informar de datos específicos no contemplados por ISO 8583

• Cada Dato Adicional aporta a la longitud total del Elemento de Dato (P-48), su propia longitud, más

las tres posiciones donde se indica la misma

Ejemplos


Longitud del Dato Adicional



[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Datos de Abono Entorno Multibancario 2 (P-62 Código '06')

(P-62)

'06' Datos de Abono Entorno Multibancario ans36..828

Descripción Aporta la información complementaria al Elemento de Dato (P-48) Código '06', acordada de forma

bilateral entre HE y HCP y necesaria para realizar los procesos de cuadre y abono en conexiones con

abono a nivel de sesión y en entorno Multibancario, cuando se requiera utilizar más de 25 Subtotales

Se informara el Importe del Descuento y el Importe Neto a abonar al Negocio por cada Banco Merchant (máximo 25), existiendo tantos abonos como Bancos Merchant.

Presencia -- 1520 Obligatorio en mensajes 1520 enviados por el HE cuando el abono se

realice a nivel de sesión y en entorno Multibancario, cuando se requiera utilizar más de 25 Subtotales



Número de ocurrencias (Subtotales)

n2 Número de elementos (1 a 25) que componen el Dato Adicional


• Identificativo de Cuadre n10 Informa los datos necesarios para realizar los procesos de Cuadre y Abono

• Cuenta de Abono n20 Datos de la Cuenta de Abono del HE. Tendrá la siguiente estructura: BBBB Código Banco según CSB SSSS Código de Sucursal DC Dígitos de control. Valor 00 CCCCCCCCCC Número de Cuenta

• Signo de la comisión ans1 Indicará la acción a realizar: 'D' Abonar, 'C' Cargar

• Importe de Comisión n16 Importe de la Comisión a cargar/abonar al HE expresado en Euros con dos decimales

• Signo del Importe Neto ans1 Indicará la acción a realizar: 'D' Abonar, 'C' Cargar

• Importe Neto n16 Importe Neto que el Banco Merchant abonará/cargará al HE como resultado de las transacciones realizadas durante la sesión contable que se esté cerrando El importe se expresará en Euros con dos decimales


Comentarios • Los campos de tipo numérico que forman parte del 'Texto' (Numero de Ocurrencias, Identificativo de Cuadre, Datos de Abono, Importe de Comisiones e Importe Neto) se enviarán compactados

• Este Dato Adicional proporciona al Elemento de Dato (P-48) una longitud de 3+2+1+(Nx33) posiciones, siendo 'N' el número de ocurrencias (1 a 25)




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.32 Código de Autentificación del Mensaje (P-64/S-128)

(P-64)

(S-128) Código de Autentificación del Mensaje b8

Descripción Se utiliza para validar el origen y ciertos datos del mensaje intercambiado entre el remitente y el receptor.

Debe ser el último campo del mensaje, indicándose su presencia con el último bit del último Mapa de Bits del mensaje. Por tanto, en caso de no existir Mapa de Bits Secundario (P-1) aparecerá como (P-64) y en caso de existir como (S-128)

Presencia O

--

1100 1200 1110 1210 1220 1221 1230

1304 1305 1314

1420 1421 1430

1604

Contenido Código de autentificación (MAC) del Mensaje calculado usando el algoritmo descrito en la norma ANSI X9.9 o X9.19. Los 32 bits de la derecha del elemento de dato no serán usados.

Con el fin de mejorar tiempos de proceso solamente los elementos de datos considerados críticos en los mensajes son utilizados en el cálculo de este código de autentificación. Consideramos que los elementos críticos son:

• PAN, Número de Tarjeta (P-2). Cuando exista • Código de Proceso (P-3) • Importe Transacción (P-4)

• Número de Identificación Transacción (P-11) • Fecha de Caducidad (P-14) • Datos Punto de Servicio (P-22)

• Código de Razón de Mensaje (P-25) • Código de Identificación del Adquirente (P-32) • Código de Autorización (P-38)

• Código de Acción (P-39)

• Datos Adicionales (P-48 Cod.35) En mensajes de pregunta cuando se realicen procesos de cifrado

de datos de tarjeta • Datos Adicionales (P-48 Cod.37). En mensajes de Respuesta cuando se realicen procesos de

cifrado de datos de tarjeta

• Datos Adicionales (P-48 Cod.38). En mensajes de pegunta cuando se realicen procesos de cifrado de datos de la tarjeta

• Datos Adicionales (P-48 Cod.40). En mensajes de pregunta cuando se realicen procesos de cifrado de datos de tarjeta. Cuando exista.

• Bloque de PIN (P-52) • Registro de Datos (S-72)


Comentarios • Cuando un dato tenga longitud variable, las posiciones donde se explícita la longitud también formarán parte de los datos fuente utilizados para calcular el MAC.

• En el ANEXO-A se describe el proceso de obtención del Código de Autentificación del Mensaje

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.33 Registro de Datos (S-72)

(S-72) Registro de Datos ansb..999

LLLVAR Descripción Información acordada de forma bilateral entre HE y HCP y requerida en mensajes administrativos o de

Solicitud de Actualización de Lista Negra (1644), en mensajes de actualización de ficheros (1304/5- 1314) y en datos de identificación (1600)

Presencia O 1304 1305 1314

1600 1614 1644





2 bytes

3 byte

longitud variable

Cada Dato Adicional se estructurara en formato Longitud, Código, Texto como se indica a continuación:

Longitud: Tres caracteres numéricos (003-999) donde se especifica la longitud del Dato Adicional, incluyendo Código y Texto

Código: Tres caracteres numéricos (000-990) que indican el tipo de Dato Adicional. Valores:

000-099 001 002 003 004 011

005-099

100..199

200..299

300..399

400-899

900-999 999

De uso Nacional

Datos de Solicitud de L.N 1

Datos de L.N Datos de Solicitud de L.N 2

Confirmación de L.N Datos de Identificación

Libres De uso privado para REDSYS



Usos Futuros

Uso Nacional Información de Mensaje No Reconocible



Comentarios • Este campo se utilizará para informar de datos específicos no contemplados por ISO 8583 • Cada Dato Adicional aporta a la longitud total del Elemento de Dato (P-48) su propia longitud

Ejemplos En el valor '0160019999990999999'

• '016' corresponde a la longitud total de (S-72) (este elemento de dato ocupará en transmisión 19 posiciones) e indica la longitud del Dato Adicional con código '001' y texto '9999990999999'







Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Datos de Solicitud de L.N 1 (P-72 Código '001')

(P-72)

'001' Datos de Solicitud de L.N 1 n13

Descripción Aporta la información acordada de forma bilateral entre HE y HCP y necesaria para realizar la Solicitud de Actualización de Lista Negra cuando el HE trabaje con una única Lista Negra (regionalizada o no).

Presencia -- 1644 Obligatorio en mensajes 1644 enviados por el HE, cuando se requiera

solicitar actuali zación de una única Lista Negra



Versión n6 Versión de Lista Negra del HE

Ocupación n1 Grado de ocupación del fichero de Lista Negra en el HE.

0 1

Quedan al menos 36 posiciones libres Contendrá en seis posiciones numéricas (n6) la Versión de Lista Negra del HE

Tamaño n6 Tamaño máximo de Lista Negra admitido por el HE


Comentarios • Todos los campos que forman parte del 'Texto' se enviarán compactados

• Este Dato Adicional proporciona al Elemento de Dato (S-72) una longitud de 3+7 posiciones

Datos de L.N (P-72 Código '002')

(P-72)

'002' Datos de L.N ans000..975

Descripción Aporta la información acordada de forma bilateral entre HE y HCP y necesaria para que el HCP realice la Actualización de Lista Negra cuando haya sido solicitada previamente por el HE.

Presencia O 1304 1305 Obligatorio en mensajes 1304/5 enviados por el HCP, cuando se requiera

actualizar Lista Negra



Versión n6 Versión de la Lista Negra que se está actualizando. No viajará en caso de no existir 'Datos de Lista Negra'

Datos de Lista Negra Contendrá la información específica del registro a incluir o borrar, pudiendo existir de 0 a 36 ocurrencias, utilizándose

el valor 0 para el caso en que se requiera dar por finalizada la actualización de L.N si n enviar ninguna tarjeta. Cada ocurrencia contendrá

• Tipo de Tarjeta n2 00 01 02 03 04 05

Visa MasterCard/Eurocard 4B

Amex Euro6000 Diners

• Posición en el fichero de L.N n6

• PAN, Número de Tarjeta ans19 En caso de que el PAN contenga solo parte de los caracteres que componen el número de una tarjeta (por ejemplo el BIN) y el resto sean spaces, se tomará como un rango de tarjetas, de forma que se considerarán incluidas en la Lista Negra todas aquellas tarjetas cuyos primeros caracteres coincidan con los contenidos en este PAN.

• Número de Secuencia ns3 Número de Secuencia de la Tarjeta. Aplicable solo para tarjetas EMV. Tomará por valor 'spaces' para indicar un rango completo


Comentarios • Los campos de tipo numérico que forman parte del 'Texto' (Versión, Tipo de Tarjeta, Posición en el Fichero de L.N) se enviarán compactados

• El número de registros que se están actualizando de forma simultánea, se calculará a partir de la longitud del elemento de dato completo.

• Este Dato Adicional proporciona al Elemento de Dato (S-72) una longitud de 3+(3+(Nx27)) posiciones, donde N toma valores entre 1 y 36

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Datos de Solicitud de L.N 2 (P-72 Código '003')

(P-72)

'003' Datos de Solicitud de L.N 2 n13

Descripción Aporta la información acordada de forma bilateral entre HE y HCP y necesaria para realizar la Solicitud de Actualización de Lista Negra cuando el HE trabaje con más de una Lista Negra (regionalizada).

Presencia -- 1644 Obligatorio en mensajes 1644 enviados por el HE, cuando se requiera

solicitar actuali zación de más de una Lista Negra



Versión n6 Versión de Lista Negra del HE

Filler n1 valor '0'

Tamaño n6 Tamaño máximo de Lista Negra admitido por el HE


Comentarios • Todos los campos que forman parte del 'Texto' se enviarán compactados

• Este Dato Adicional proporciona al Elemento de Dato (S-72) una longitud de 3+7 posiciones

Confirmación de L.N (P-72 Código '004')

(P-72)

'004' Confirmación de L.N n6

Descripción Aporta la información acordada de forma bilateral entre HE y HCP y necesaria para que el HE confirme

al HCP la recepción de Lista Negra.

Presencia O 1314 Obligatorio en mensajes 1314 enviados por el HE, confirmando la L.N recibida



Versión n6 Última Versión de Lista Negra recibida y procesada por el HE durante el actual proceso de Actuali zación.


Comentarios • Todos los campos que forman parte del 'Texto' se enviarán compactados • Este Dato Adicional proporciona al Elemento de Dato (S-72) una longitud de 3+3 posiciones

Datos de Identificación (P-72 Código '011')

(P-72)

'011' Datos de Identificación nb25

Descripción Aporta la información necesaria para identificar el PIN/Pad que solicita la Carga de

Claves inicial con protección mediante claves simétricas (TDES)

Presencia O 1600 Obligatorio en mensajes 1600 enviados por el HE, en

procesos de Carga de Claves protegidas con claves simétricas



INDP n3 Indicador de proceso. Valor “100”

IDPED n13 Identificador del PIN/Pad (fabricante y número de serie)

VCCCI b3 VCC de CI. Check control de la CI

VCMI b1 Versión de Clave de la CI y de la CA

Id. CMI n2 Nº de Cajón

VCCCA

b3 VCC de CA. Check control de la CA. No viajará en PIN/Pads con versión de Sw ajustadas a versiones PUP anteriores a 1.5.1


Comentarios Este Dato Adicional proporciona al Elemento de Dato (S-72) una longitud de 3+25 posiciones




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Información de Mensaje No Reconocible (P-72 Código '999')

(P-72)

'999' Información de Mensaje No Reconocible ans100

Descripción Informa las 100 primeras posiciones del mensaje no reconocible.

Presencia -- 1644 Obligatorio en mensajes 1644 enviados por el HE o por el HCP, cuando se requiera informar de la recepción de un mensaje no reconocible



Datos ans100 se informará de las 100 primeras posiciones del mensaje no reconocible.



[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.34 Abonos, Número (S-74)

(P-74) Abonos, Número n10

Descripción Número total de transacciones contables (12xx) con Código de Proceso (P-3) comprendido entre "20" y

"29" en sus dos primeras posiciones

Presencia O 1520

13 1530

315 1614

Contenido El Valor del campo


Comentarios La aplicación del HE sumará "1" a este elemento de dato en el momento de generar el mensaje

Contable (12xx) con Código de Proceso (P-3) "20" (Devolución) en sus dos primeras posiciones

7.35 Abonos, Número de Anulaciones (S-75)

(P-75) Abonos, Número de Anulaciones n10

Descripción Número total de anulaciones (14xx) con Código de Proceso (P-3) comprendido entre "00" y "19" en sus dos primeras posiciones

Presencia O 1520

13 1530

315 1614



Comentarios La aplicación del HE sumará "1" a este elemento de dato en el momento de generar el mensaje de

Anulación (14xx) con Código de Razón de Mensaje (P-25) igual "4007" o “4352” y Código de Proceso (P-3) "00" (Venta) en sus dos primeras posiciones

7.36 Cargos, Número (S-76)

(P-76) Cargos, Número n10

Descripción Número total de transacciones contables (12xx) con Código de Proceso (P-3) comprendido entre "00" y

"19" en sus dos primeras posiciones.

Presencia O 1520

13 1530

315 1614



Comentarios La aplicación del HE sumará '1' a este elemento de dato cuando: • Se reciba mensaje de Respuesta a Petición Contable (1210), sin vencer la temporización, con Código

de Proceso (P-3) "00" (Venta) y valor del campo Importe (P-4) distinto de cero.

• En el momento de generar el mensaje de Comunicación Contable (1220) con Código de Proceso (P- 3) "00" (Venta) en sus dos primeras posiciones.




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.37 Cargos, Número de Anulaciones (S-77)

(P-77) Cargos, Número de Anulaciones n10

Descripción Número total de Anulaciones Contables (14xx) con Código de Proceso (P-3) comprendido entre "20" y

"29" en sus dos primeras posiciones.

Presencia O 1520

13 1530

315 1614



Comentarios La aplicación del HE sumará "1" a este elemento de dato en el momento de generar un mensaje de

Anulación con Código de Razón de Mensaje (P-25) igual "4007" o “4352” y Código de Proceso (P-3)

"20" (Devolución) en sus dos primeras posiciones.

7.38 Abonos, Importe (S-86)

(P-86) Abonos, Importe n16

Descripción Importe total de transacciones contables (12xx) con Código de Proceso (P-3) comprendido entre "20" y "29" en sus dos primeras posiciones

Presencia O 1520

13 1530

315 1614



Comentarios La aplicación del HE sumará el Importe de Transacción (P-4) a este elemento de dato en el momento de generar el mensaje de comunicación contable (1220) con Código de Proceso (P-3) "20" (Devolución) en sus dos primeras posiciones

7.39 Abonos, Importe de Anulaciones (S-87)

(P-87) Abonos, Importe de Anulaciones n16

Descripción Importe total de anulaciones (14xx) con Código de Proceso (P-3) comprendido entre "00" y "19" en sus

dos primeras posiciones

Presencia O 1520

13 1530

315 1614



Comentarios La aplicación del HE sumará el Importe de Transacción (P-4) a este elemento de dato en el momento de generar el mensaje de anulación (14xx) con Código de Razón de Mensaje (P-25) igual "4007" o “4352” y con Código de Proceso (P-3) "00" (Venta) en sus dos primeras posiciones

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.40 Cargos, Importe (S-88)

(P-88) Cargos, Importe n16

Descripción Importe total de transacciones contables (12xx) con Código de Proceso (P-3) comprendido entre "00" y

"19" en sus dos primeras posiciones

Presencia O 1520

13 1530

315 1614



Comentarios La aplicación del HE sumará el Importe de Transacción (P-4) a este elemento de dato cuando:

• Se reciba mensaje de Respuesta a Petición Contable (1210), sin vencer temporización, con Código de Proceso (P-3) "00" (Venta) en sus dos primeras posiciones.

• En el momento de generar el mensaje de Comunicación Contable (1220) con Código de Proceso (P- 3) "00" (Venta) en sus dos primeras posiciones

7.41 Cargos, Importe de Anulaciones (S-89)

(P-89) Cargos, Importe de Anulaciones n16

Descripción Importe total de Anulaciones (14xx) con Código de Proceso (P-3) comprendido entre "20" y "29" en sus dos primeras posiciones

Presencia O 1520

13 1530

315 1614



Comentarios La aplicación del HE sumará el Importe de Transacción (P-4) a este elemento de dato en el momento de generar el mensaje de Anulación (14xx) con Código de Razón de Mensaje (P-25) igual "4007" o “4352” y con Código de Proceso (P-3) "20" (Devolución) en sus dos primeras posiciones




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.42 Código de Identificación Destino (S-93)

(P-93) Código de Identificación Destino n..11

LLVAR Descripción Identifica la Aplicación dentro del mensaje de petición/comunicación, en aquellas clases de mensajes en

que no existe PAN, Número de Tarjeta (P-2)


1644

1804 1824

OI 1314

1814 1834

Contenido Se fija su longitud a seis (6) posiciones, conteniendo

Mensaje 1304/5, 1644, 1804, 1824 iniciados por el HCP y con destino el HE


Iniciado por REDSYS Dígito 1

Dígito 2

1 2

Abono a nivel de Sesión Abono a nivel de Establecimiento (P-42)

Sin Significado

Iniciado por REDSYS Dígitos 1-2 13 43

Circuitos Permanentes Circuitos conmutados

Iniciado por CECABANK Dígitos 1-2 00

Dígitos 3-6 Tomará los valores indicados a continuación, acordados por HCP-HE Iniciado por REDSYS Valores entre 4000 y 4999

Iniciado por REDSYS Valores entre 5000 y 5999

Iniciado por CECABANK Valores entre 6000 y 6999

Mensaje 1644, 1804 iniciados por el HE y con destino el HCP

Dígitos 1-6 Tomará los valores indicados a continuación, acordados por HCP-HE Con Destino REDSYS Valor 000444

Con Destino REDSYS Valores 138000 y 438000

Con Destino CECABANK Valor 002000


Comentarios

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.43 Código de Identificación Origen (S-94)

(P-94) Código de Identificación Origen n..11

LLVAR Descripción Identifica la aplicación origen de un mensaje de petición/comunicación en aquellos mensajes que no

existe Código de Identificación de Adquirente (P-32)


1644

1804 1824

OI 1314

1814 1834

Contenido Se fija su longitud a seis (6) posiciones, conteniendo

Mensaje 1304/5, 1644, 1804, 1824 iniciados por el HCP y con destino el HE

Dígitos 1-6 Tomará los valores indicados a continuación, acordados por HCP-HE Iniciado por REDSYS Valor 000444

Iniciado por REDSYS Valores 138000 y 438000

Iniciado por CECABANK Valor 002000

Mensaje 1644, 1804 iniciados por el HE y con destino el HCP


Con Destino REDSYS Dígito 1

Dígito 2

1 2

Abono a nivel de Sesión Abono a nivel de Establecimiento (P-42)

Sin Significado

Con Destino REDSYS Dígitos 1-2 13 43

Circuitos Permanentes Circuitos conmutados

Con Destino CECABANK Dígitos 1-2 00

Dígitos 3-6 Tomará los valores indicados a continuación, acordados por HCP-HE Con Destino REDSYS Valores entre 4000 y 4999

Con Destino REDSYS Valores entre 5000 y 5999

Con Destino CECABANK Valores entre 6000 y 6999


Comentarios

7.44 Importe Total (S-97)

(P-97) Importe Total X+n16

Descripción Importe total de las transacciones contables intercambiadas durante la sesión contable que se está

conciliando.

Presencia O 1520

13 1530

315 1614

Contenido Resultado de aplicar la fórmula: S-97 = S-86 + S-87 - S-88 - S-89


Comentarios El signo tomará valor "D" cuando el resultado sea negativo y "C" cuando sea positivo o nulo




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

7.45 Nombre del Fichero (S-101)

(P-101) Nombre del Fichero ans..17

LLVAR Descripción Este campo identifica el fichero que contiene las tarjetas que se encuentran en Lista Negra


Contenido Nombre del fichero de Lista Negra que se actualiza. Este nombre consta de: Campo Formato Comentarios

Identificación del Tipo fichero an2 Valor "LN"

Identificación del Origen an4 Valor asignado por el HCP


Comentarios

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

8. ANEXOS




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

8.1 Anexo A. Mecanismos de Seguridad del MAC Definición de la Tipología de Seguridad del HE Todos los Establecimientos Adaptados a EMV, utilizarán Tipología TDES (Triple DES). Tanto las Claves como los procesos Criptográficos que se lleven a cabo con ellas serán TDES. En esta tipología las claves tendrán una longitud de 128 bits distribuidas en parte izquierda (64 bits) y parte derecha (64 bits)

Generación y Gestión de Claves de MAC

8.1.1.1 Definición de Claves Las claves y Campos de Control utilizados, diferentes por cada HCP al que se conecte el HE, son los siguientes:

CMn Claves de MAC. Claves utilizadas por las aplicaciones para Generar/Verificar el MAC.

Podrán existir hasta dos claves diferentes por HCP permitiendo cambios periódicos de Clave. El HE indicará al HCP el número de clave utilizada mediante el campo 'Índice de Claves de Zona e MAC' presente en el elemento de dato Información de Control y Seguridad (P-53).

Los HCP comunicarán estas claves cifradas con la Clave de Transporte CT y acompañadas de un Campo de Control para su verificación El HE recuperará estas claves mediante descifrado con la Clave de Transporte CT recibida del HCP y verificación del resultado mediante comprobación del Campo de Control

CT Clave de Transporte Claves utilizada para distribuir las claves CMn.

Los HCP comunicarán esta clave mediante tres1 componentes y acompañada de un Campo de Control para su verificación

El HE recuperará esta clave mediante XOR. de las componentes recibidas y verificación del resultado mediante comprobación del Campo de Control.

8.1.1.2 Descripción de los Procesos a realizar

Proceso en el HCP

1. Generar las claves CMn y su Campo de Control • Las claves se generarán aleatoriamente con tipología o TDES • El Campo de Control estará formado por los 6 dígitos más significativos del resultado obtenido de cifrar ceros

binarios con la clave de MAC (CMn).

2. Generar la clave CT en tres componentes y su Campo de Control • Las tres componentes de la clave se generarán aleatoriamente con tipología TDES

• El Campo de Control estará formado por los 6 dígitos más significativos del resultado obtenido de cifrar ceros

binarios con la clave de Transporte (CT).

3. Cifrar las claves CMn con la clave CT El proceso de Cifrado se realizará según tipología TDES

4. Enviar al HE las tres componentes de la Clave CT.

• Las componentes se enviarán a dos o tres personas diferentes previamente designadas por el HE. • El Campo de Control se enviará junto con la tercera componente o con cada componente

5. Enviar al HE las Claves CMn cifradas.

Las claves y su Campo de Control se enviarán a las personas previamente designadas por el HE y tras

confirmación de la clave CT por el HE.

1 Serán dos componentes si HE así lo solicita.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Procesos en el HE 1. Confirmar la recepción de la clave CT

2. Generar la clave CT y realizar su verificación • La clave CT se calculará realizando XOR de las tres componentes recibidas.

En caso de claves TDES hay que tener en cuenta que si cada una de las componentes de la clave consta de parte izquierda y parte derecha, por tanto realizar el XOR de las componentes equivale a realizar el XOR de la parte izquierda de todas las componentes y el XOR de la parte derecha de todas las componentes, obteniendo como resultado la parte izquierda de la CT y la parte derecha de la CT, en caso contrario, se realiza el XOR de los componentes recibidos

• La clave CT se verificará a través del Campo de Control. Para ello, una vez obtenida la clave CT, se cifrará un dato todo a ceros binarios con dicha clave y se comprarán los 6 dígitos más significativos con los recibidos del HCP El proceso de cifrado será TDES

3. Obtener las Claves CMn con la clave CT y realizar su verificación

• Las claves CMn se calcularán mediante descifrado con la clave CT de las claves CMn cifradas y recibidas del HCP.

• Las claves CMn se verificarán a través del Campo de Control. Para ello, una vez obtenida cada una de las claves CMn, se cifrará un dato todo a ceros binarios con la clave y se comprarán los 6 dígitos más significativos con los recibidos del HCP

Los procesos de cifrado serán TDES

4. Además el HE deberá:

• Custodiar convenientemente las tres componentes de la CT y su Campo de Control • Almacenar las claves CMn cifradas de forma segura y sus Campos de Control

8.1.1.3 Formato de la Información de Claves remitida por el HCP

Los Centros Procesadores (HCP) comunicarán a los Establecimientos las nuevas claves de MAC TDES, siguiendo los procedimientos establecidos actualmente

8.1.1.4 Cálculo/Verificación de MAC El MAC (Message Authentication Code) es el sistema utilizado para la protección de mensajes ante posibles

manipulaciones que pueden sufrir a lo largo de los diferentes elementos de comunicaciones.

Este sistema solo garantiza la integridad de los datos elegidos como "críticos", por lo que es importante una adecuada selección de los mismos.

Los datos fuente a someter al proceso de Calculo/Verificación del MAC, se obtienen como concatenación de los datos expuestos en la descripción del campo (P-64) y que existen en el mensaje.

El proceso de Calculo/Verificación de MAC será el siguiente:

• Tipología TDES

Una vez se dispone de los datos fuente, se inicia el proceso de Calculo/Verificación de MAC que consta de los siguientes pasos:

• Aplicar padding a los datos fuente de acuerdo a ISO/IEC 9797-1 método 2. Este proceso consiste en añadir por la derecha a los datos fuente el byte 80hex y en caso de que la longitud resultante del proceso anterior no sea

múltiplo de 8, se añadirán tantos ceros binarios como sea necesario para conseguirlo • Los datos fuente resultantes se agrupan en bloques de 64 bits. • Una vez están formado los bloques se inicia el proceso de cálculo/verificación de MAC utilizando el

procedimiento descrito en la norma ISO/IEC 9797-1 Algoritmo 3. Se tomará como MAC los 32 bits más a la izquierda




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

8.2 Anexo B. Actualización de Claves Públicas RSA de CA (Emisor) Descripción de los Procesos a realizar

Proceso en el HCP

1. Generar la información de claves a remitir al HE El HCP deberá generar información que se remitirá en papel (ver 8.2.2.).

2. Remitir la Información de Claves al HE

Procesos en el HE 5. Confirmar la recepción de claves RSA de CA

6. Cargar las Claves y realizar su verificación

• El HE deberá realizar la carga de las claves recibidas en un periodo máximo de 4 meses desde su recepción

• Las claves se verificarán a través del Campo 'Secure Hash Algorithm-1 hash'

7. • Además el HE deberá custodiar convenientemente las Claves recibidas

Formato de la Información de Claves remitida por el HCP

Las Claves se remitirán por carta conteniendo el siguiente formulario tipo según CA:

Visa CA Public Keys for 'VSDC'

xxxx1 BIT VSDC Production Key

The Visa CA Public xxxx bit key will expire on 'Fecha de

Expiración' 2

This key is de Visa CA Public xxxx bit PRODUCTION key

MasterCard CA Public Keys for 'MCDC'

xxxx1 BIT MCDC Production Key

The MasterCard CA Public xxxx bit key will expire on 'Fecha de

Expiración' 2

This key is the MasterCard CA Public xxxx bit PRODUCTION key

Component Value Component Value

Registered Application Provider Identifier (RID) A0 00 00 00 03 Registered Application Provider Identifier (RID) A0 00 00 00 04

Index3 00-FF Index 00-FF

Modulus4 Valor de la Clave Pública Modulus Valor de la Clave Pública

Exponent5 03 o 216+1 Exponent 03 o 216+1

Secure Hash Algorithm-1 hash6 Hash SHA1 Secure Hash Algorithm-1 hash Hash SHA1

1 'xxxx' indica la longitud de la clave que podrá tomar valores: 896,…., 1984 Bits

2 La 'Fecha de Expiración' se expresará en formato 'Mes-Día-Año' 3 Número de Clave a cargar. Podrá tomar valores entre 00 y FF

4 Valor de la clave. Podrá contener desde 224 caracteres Hex (112 Bytes o 896 Bits) a 496 caracteres Hex (248 Bytes o 1984 Bits) 5 Valor del Exponente de la Clave. Podrá tomar valores '03' o 216+1

6 Campo de Verificación de la Clave. Contendrá 40 caracteres Hex. (20 Bytes o 160 Bits). HASH de los datos anteriores

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

8.3 Anexo C. Actualización de Parámetros EMV Estructura de la Información

Para cada Merchant y Tipo de Terminal con capacidad EMV, el HE deberá ser capaz de mantener una Tabla de Parámetros EMV indexada por AID (producto EMV). Cada AID tendrá asociados los siguientes parámetros:

• TAC's

• Límites de Riesgo

• Parámetros de Aleatorización (Floor Limit, Target Percent, Threshold value, Maximum Target)

• Etiqueta Privada

El HE deberá mantener un control de versiones por Merchant - Tipo de Terminal - Tabla de Parámetros.

Descripción de los Procesos a realizar

Procesos en el HE 1. Confirmar la recepción de Parámetros EMV

2. Cargar los Parámetros EMV

El HE deberá realizar la carga de los parámetros recibidos por Merchant - Tipo de Terminal - Producto EMV. Esta actualización se deberá realizar en un periodo máximo de 1semana desde su recepción

Formato de la Información de Parámetros EMV remitida por el HCP

Los Parámetros EMV serán remitidos por los HCP's a los HE's mediante carta.

Esta carta contendrá el siguiente formulario tipo por Merchant - Tipo de Terminal:

Solicitud de Actualización de Parámetros EMV

Merchant:

Centro Procesador:

Tipos de Terminales Afectados:

Productos EMV Afectados:

'Identificación del Banco Merchant solicitante de la actualización'

'Red Procesadora ligada al Merchant'

'Código de Sector de Actividad afectado por la actualización'

'Tipos de Tarjeta afectados por la actualización'

Para cada uno de los 'Tipo de Terminales Afectados', se definirán los parámetros EMV de cada uno de los 'Productos EMV' que requieren actualización. El HE, además de los parámetros EMV, deberá actualizar el campo 'Versión' de la tabla de Parámetros que se actualiza (existe una tabla para cada Merchant - Tipo de Terminal)

Esta información se estructurará de la siguiente forma

Proceso en el HCP

1. Generar la información de Parámetros EMV a remitir al HE El HCP deberá generar información que se remitirá en papel (ver 8.3.3.).

2. Remitir la Información de Parámetros al HE




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

:

Parámetros EMV para Tipo de Terminal 'x'

Versión de Parámetros: 6 caracteres numéricos que indican la Versión de Tabla de Parámetros que se está actualizando para el Tipo de Terminal 'x'

Producto EMV 'x' Parámetros Valor

Acción Literal indicativo de la acción a realizar por el HE con el Producto EMV 'x' (AID) y sus parámetros EMV asociados: • Modificar parámetros EMV ya existentes

• Incorporar nuevos parámetros EMV • Borrar parámetros EMV existentes

AID Identificación del Producto EMV (hasta 16 caracteres)

TAC Valor de TAC Denial, TAC On-Line y TAC Defaul, asociados al

Producto EMV 'x' (cada uno de ellos ocupará 10 caracteres

Hexadecimales correspondientes a 5 bytes) Floor Limit 4 caracteres numéricos

Target Percent Valor de los Parámetros de Riesgo 2 caracteres numéricos

Threshold value asociados al Producto EMV 'x' 4 caracteres numéricos

Maximum Target 4 caracteres numéricos

Etiqueta Privada Literal indicativo del producto utilizado, que se deberá mostrar en pantalla e imprimir en los recibos emitidos en operaciones de Venta y Devolución realizadas con Chip EMV, cuando el Application Preferred Name (T9F12) no pueda ser presentado en pantalla e impreso en recibo o no exista y tampoco exista el Application Label (T50)

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

8.4 Anexo D. Formatos y Validaciones a realizar con Tarjetas de Banda Magnética Formato de Pista 2 de Tarjetas

8.4.1.1 Tarjeta 4B

CAMPO POS LON TIPO CONTENIDOS 1 C Centinela de comienzo 2 17 N Nº de la tarjeta (PAN), empezando por 5859XX 19 1 C Separador 20 4 N Fecha de caducidad (AAMM) 24 3 N Código de servicio 27 11 C Datos discrecionales 38 2 C Centinela final y LRC

8.4.1.2 Tarjeta MasterCard

CAMPO POS LON TIPO CONTENIDOS 1 C Centinela de comienzo ..19 N Nº de la tarjeta 1 C Separador 4 N Fecha de caducidad (AAMM) 3 N Código de servicio (*) C Datos discrecionales 2 C Centinela final y LRC

8.4.1.3 Tarjeta VISA

CAMPO POS LON TIPO CONTENIDOS 1 C Centinela de comienzo ..19 N Nº de la tarjeta (PAN) 1 C Separador 4 N Fecha de caducidad (AAMM) 3 N Código de servicio (*) C Datos discrecionales 2 C Centinela final y LRC

8.4.1.4 Tarjeta Maestro

CAMPO POS LON TIPO CONTENIDOS 1 C Centinela de comienzo ..19 N Número de la tarjeta (PAN). 1 C Separador 4 N Fecha de caducidad de la tarjeta (AAMM) 3 N Código de servicio Var C Datos discrecionales 2 C Centinela final y LRC




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Reconocimiento del Tipo de Tarjeta

8.4.1.5 Tarjeta 4B

Datos obtenidos lectura pista 2 • Datos de Pista 2 conforme con el formato expuesto

• El PAN de la tarjeta estará compuesto por 17 dígitos.

• El BIN de la tarjeta (6 primeros dígitos del PAN) deberán corresponder a una entrada en la tabla de BINES ISO de Tarjetas 4B

• El dígito de control (último dígito del PAN), ajustado a la formula Luhn.

Datos obtenidos manualmente a partir del relieve • El Número de Tarjeta coincide con el de pista 2 y se realizan las mismas validaciones.

• La fecha de caducidad será lógica (AAMM)

8.4.1.6 Tarjeta 4B/MasterCard



• El primer dígito (por la izquierda) del PAN deberá ser siempre "5" y el segundo comprendido entre "1" y "5" y el BIN de la tarjeta (6 primeros dígitos del PAN) deberán corresponder a una entrada en la tabla de BINES de Tarjetas 4B/MasterCard


• La fecha de caducidad será lógica (AAMM)

8.4.1.7 Tarjeta 4B/Maestro

Datos obtenidos lectura pista 2 • Datos de Pista 2 conforme al formato expuesto


• El BIN de la Tarjeta (6 primeros dígitos del PAN), se corresponde con un valor dentro del rango asignado a esta tarjeta.

• El dígito de control (último dígito del PAN), ajustado a la fórmula de Luhn.

Tecleando los datos del relieve de la tarjeta • El Número de Tarjeta coincide con el de pista 2 y se realizan las mismas validaciones.

• La fecha de caducidad sea lógica (AAMM).

8.4.1.8 Tarjeta MasterCard/EuroCard

Datos obtenidos lectura pista 2 • Datos de Pista 2 conforme con el formato expuesto.


• El primer dígito (por la izquierda) del PAN deberá ser siempre "5" y el segundo comprendido entre "1" y "5"




[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6



• El PAN de la tarjeta estará compuesto por 13 ó 16 dígitos.

• El primer dígito (por la izquierda) del PAN deberá ser siempre "4".




8.4.1.10 Tarjeta VISA Electrón

Datos obtenidos lectura pista 2: • Se realizarán las validaciones establecidas para las tarjetas VISA, reconociéndose que es una Visa Electrón por su

código de servicio que podrá ser 120, 121, 220, 221.

Datos obtenidos manualmente a partir del relieve: • El Número de Tarjeta coincide con el de pista 2 y se realizan las mismas validaciones.


8.4.1.11 Tarjeta Maestro Se tomarán como Maestro, aquellas que el HE no sea capaz de identificar según los procesos de reconocimiento anteriores más aquellos privados del HE, y que pasen correctamente los siguientes procesos de validación:

Datos Obtenidos con lector de PISTA 2 • Datos de Pista 2 conforme con el formato expuesto.

• El PAN de la tarjeta estará compuesto por 1 a 19 dígitos.

• El dígito de control (último dígito del PAN), ajustado a la fórmula de Luhn.

Datos obtenidos manualmente a partir del relieve No se permite realizar operaciones de Venta con introducción manual de datos de tarjeta para las tarjetas Maestro

Validaciones previas a una Autorización Local

8.4.1.12 Tarjeta 4B

Datos obtenidos lectura pista 2 Además de las validaciones descritas en el nivel anterior para este tipo de tarjeta, se deberá comprobar:

• La Tarjeta no está caducada.

• El PAN no se encuentra en el fichero de Lista Negra.

• El campo Código de Servicio toma valor “101"

Datos obtenidos manualmente a partir del relieve (solo Devoluciones) Se realizarán todas las validaciones descritas en el nivel anterior para este tipo de tarjeta




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

8.4.1.13 Tarjeta 4B/MasterCard




• El campo Código de Servicio de la pista 2 tome el valor "101" ó "102".


8.4.1.14 Tarjeta 4B/Maestro

Datos obtenidos lectura PISTA 2 Además de las validaciones descritas en el nivel anterior para este tipo de tarjeta, se deberá comprobar:



• El campo Código de Servicio de la pista 2 tome el valor "101".


8.4.1.15 Tarjeta MasterCard/EuroCard




• El campo Código de Servicio de la pista 2 tome el valor 101, 102, 201 Y 202.

Datos obtenidos manualmente a partir del relieve (solo Devoluciones) Se realizarán todas las validaciones descritas en el nivel anterior para este tipo de tarjeta.





• El campo Código de Servicio de la pista 2 tome el valor 101, 102, 201 Y 202.


8.4.1.17 Tarjeta VISA Electrón La Tarjeta Visa Electrón NO admite autorización local.

8.4.1.18 Tarjeta Maestro La Tarjeta Maestro NO admite autorización local.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

8.5 Anexo E. Aplicación de Fallback Introducción El presente documento recoge los principios de utilización de Fallback en los terminales ajenos EMV.

Fallback. Principios Generales

Se entenderá como Fallback el uso de cierta tecnología cuando una previa no está disponible por alguna razón. En este caso el Fallback consistirá en la posibilidad de utilizar la Banda magnética para completar una transacción cuando se ha producido algún problema en el Chip.

Este apartado presenta los principios básicos que gobernarán el modo en el que los terminales deben realizar Fallback a Banda magnética.

• En cualquiera de las posibilidades de Fallback, el terminal deberá señalizar en el mensaje que construye hacia su centro de autorización que se trata de una operación Fallback.

• Las transacciones Fallback tienen un Floor Limit cero y por lo tanto deberán ser autorizadas on-line.

• Hay que indicar que si una tarjeta tiene Chip, el terminal deberá siempre intentar llevar a cabo la transacción con la tecnología Chip en primera instancia.

• El Fallback queda totalmente prohibido en los siguientes casos: tarjeta bloqueada, aplicación Chip bloqueada, manipulación errónea durante la operación y finalización de la transacción con un TC o AAC. Por manipulación errónea se entenderá retirada prematura de la tarjeta o fallos de alimentación en el terminal o alguno de sus dispositivos.

• En el ámbito de terminales de venta, el Fallback es obligatorio en POS no siendo permitido en terminales CAT.

A continuación se presenta el diagrama de flujos que considera las decisiones del terminal en el proceso de Fallback:




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

NO Intención

usuario? No EMV

SI

SI Aplicación

bloqueada?

NO

Fallback a transacción con Banda

Banda no puede ser usada

Fuera de ámbito

SI 2XX o 6XX?

NO

Transacción Banda

normal

Lector de Chip

Lector de Banda

Error antes de la selección?

Intención

usuario?

No EMV

Tarjeta

bloqueada?

SI

NO

Aplicación

correctamente

seleccionada?

SI

ATM o TPV

ATM Primera Respuesta ARQC o Final con TC

o AAC?

NO

TPV Primera Respuesta ARQC o Final con TC

o AAC?

SI Transacción completada

Tarjeta no puede ser

usada

Fallback a transacción con Banda

Fuera de ámbito

Flujos

8.5.1.1 Terminal con Lector Combinado.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Transacción completada

Intento lectura Chip

8.5.1.2 Terminal con Lectores Separados

Error antes de

la selección? Intención

usuario?

No EMV

Tarjeta

bloqueada?

SI

NO

Aplicación correctamente seleccionada?

SI

Primera respuesta con ARQC o Final con TC o AAC?

SI

Tarjeta no puede ser usada

Lector de Chip

NO Intención

usuario? No EMV

SI

SI Aplicación

bloqueada?

NO NO Fallback a transacción

con Banda

Banda no puede ser usada

Fuera de ámbito

NO SI

Fallback? Código Servicio 2XX o 6XX?

SI (insercción NO previa en Chip)

Fallback a transacción con Banda magnética

Transacción Banda normal

Lector de Banda

Fallback a transacción

con Banda

Fuera de ámbito




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

8.5.1.3 Comentarios a los Flujos En este apartado se enumeran algunos comentarios que ayudan a la comprensión de los Flujogramas mostrados en las

páginas anteriores, si bien, sólo se trata de un resumen de las indicaciones proporcionadas por las marcas internacionales en sus normas.

• Error antes de la selección: Puede producirse un error antes de que cualquier comando SELECT pueda ser correctamente respondido por la tarjeta; por ejemplo falta de ATR o ATR inválido.

• Desde la selección de la aplicación hasta la respuesta al último GENERATE AC cualquier respuesta incoherente no será motivo de Fallback. Se considerará respuesta incoherente la existencia de códigos de respuesta de tarjeta no existentes o información del Criptograma de la aplicación no existentes.

• Si algún error ocurre en las primeras fases de la operación, el terminal analiza la intención del usuario en la transacción, para conocer si la Especificación es aplicable: se puede elegir usar una aplicación particular.

• El terminal conoce, a través de la respuesta de la tarjeta al comando de selección, si la tarjeta está bloqueada.

• La posible aplicación de indica en la respuesta al comando SELECT su posible situación de bloqueo.

• Si la transacción finaliza con un ARQC, TC o AAC, la decisión inicial ha sido tomada por la aplicación Chip. La tecnología Chip funciona; en este caso el Fallback a Banda magnética no está permitido, incluso si la transacción ha finalizado con AAC.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

8.6 Anexo F. Formato del fichero de Tarjeta en Lista Negra

Código EBCDIC, sin etiqueta

Densidad 6.250 b.p.i.

Longitud de Registro 275 caracteres

Tamaño del bloque 70 registros (19.259 caracteres)

Registro de Cabecera

Campo Posició n

Longitud Tipo Contenidos

Tipo de registro 1 2 N Valor 00

Entidad origen 3 10 N Identificativo del Centro Procesador. Tomará

los siguientes valores: REDSYS "0000000444"

REDSYS "0000138000" CECABANK "0000002000"

Entidad destino 13 10 N Identificativo del establecimiento. Los HCP fijarán el valor para cada HE.

Fecha de la cinta 23 8 N Formato: AAAAMMDD

Hora de la cinta 31 4 N Formato: HHMM

Nombre de la cinta 35 35 C Este campo contendrá el literal 'Lista Negra

por Regiones'

Filler 70 206 a 275 C Información no significativa. Se rellenará con 'espacios'

Registro de Totales

Campo Posició

n



Entidad origen 3 10 N Igual al registro de cabecera

Entidad destino 13 10 N Igual al registro de cabecera

Fecha de la cinta 23 8 N Formato: AAAAAMMDD

Hora de la cinta 31 4 N Formato: HHMM

Nombre de la cinta 35 25 C Este campo contendrá el literal 'Lista Negra

por Regiones' Nº de registros 70 10 N Nº de registros contenidos en la cinta, sin

incluir el de CABECERA y el TOTALES

Filler 80 196 a 275 C Información no significativa. Se rellenará con 'espacios'




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Registro de Movimientos

Campo Posició n



Tipo tarjeta 3 2 N Valores:

00 VISA 01 MasterCard/Eurocard/Maestro 02 4B 01 AMEX

04 6000 05 DINERS

Tarjeta inicial 5 19 C Número de la tarjeta inicial alineado a la izquierda con espacios a la derecha

Número de secuencia inicial 24 2 C Viajará con 'espacios' en caso de no existir

Tarjeta final 26 19 C Número de la tarjeta Final alineado a la izquierda con espacios a la derecha

Número de secuencia final 45 2 C Viajará con 'espacios' en caso de no existir

Fecha de caducidad 47 4 N Fecha de Caducidad del Registro AAMM

Filler 51 2 N Valor '00'

Versión 53 6 N Versión actual de la LN

Filler 59 217 a 275 C Información no significativa rellena con

'spaces'

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

8.7 Anexo G. Formato del fichero de Operaciones que han originado Descuadre Introducción

A continuación se relacionan los aspectos más relevantes a tener en cuenta en el protocolo PUC para la conciliación de sesiones en diferido.

Formato del Archivo de Conciliación

El establecimiento generará el archivo hacia su Centro Operador de Medios de Pago automáticamente, tan pronto como tenga conocimiento del descuadre, y solamente en estos casos, aunque esto no impide que, en paralelo, realice los procesos normales de solicitud de cobro a su entidad merchant. A su vez el Centro Operador de Medios de Pago también continuará con sus tratamientos habituales.

Observaciones:

1/ Los campos que componen cada mensaje tendrán las mismas normas de utilización y contenido que los mensajes originales que viajaron en On-Line, y cuyos formatos figuran en el capítulo 7.

2/ Los mensajes 1200, 1220, 1420 se enviarán con el formato “Mensaje de Movimiento Contable en Diferido” • El formato de estos registros es una conjunción de los campos intercambiados en la pregunta-

respuesta de la transacción On-Line. Es decir, para cada transacción se tiene en cuenta tanto el mensaje de pregunta (por ejemplo, 1200) como el mensaje de respuesta (en el ejemplo anterior, 1210).

• La transacción se identifica por el mensaje de pregunta (por ejemplo, 1200).

3/ El mensaje de Totalización 1520 se enviará con el formato “Mensaje de Conciliación en Diferido” • Los datos deben reflejar el contenido del lote informado, considerando las operaciones autorizadas o

aceptadas por el que envía el archivo.

• Los datos del mensaje de conciliación deben reflejar los datos que se han comunicado en el mensaje

On-Line. Si no fuera así, debe comunicarlo al receptor antes de enviar el archivo.

Características de la Información a Intercambiar Para el envío y recepción de archivos se pueden utilizar dos procedimientos claramente diferenciados:

1/ Transferencia electrónica de archivos, mediante alguno de los productos: • "PELICAN"

• "EDITRAN"

2/ Mediante soporte magnético. Sólo excepcionalmente se admitirá la opción 2.

Sea cual sea el procedimiento de envío físico de la información, el tratamiento lógico de la misma es idéntico, por lo que

es igualmente válido para ambos sistemas (en lo que a estructura de archivos respecta) las especificaciones que se

indican en los apartados siguientes referentes a: • Características técnicas de los soportes

• Estructura global de los soportes




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Características Técnicas de los Soportes Los archivos de información tendrán las siguientes características:

Código EBCDIC, sin etiqueta

Densidad 6.250 b.p.i.

Longitud de Registro 550 caracteres

Tamaño del bloque 40 registros (22.000 caracteres)

8.7.1.1 Registro de Cabecera

Campo Longitud Tipo Contenido

Tipo de registro 2 N Valor 00

Entidad origen 6 o 11 N Código asignado al HE por el HCP según valor del campo (P-94)

Entidad destino 6 N Identificativo del HCP según valor del campo (P-93). Tomará los valores: REDSYS: 000444 REDSYS: 138000 CECABANK: 002000

Fecha del fichero 6 N Formato: AAMMDD

Hora del fichero 4 N Formato: HHMM

Fecha de Conciliación 6 N Formato: AAMMDD. De acuerdo al valor de elemento de dato (P-28)

Número de Conciliación 3 N De acuerdo al valor del elemento de dato (P-29)

Filler .. C Hasta completar 550 caracteres

8.7.1.2 Registro de Detalle

Campo Elemento de dato


Tipo de registro 2 N Valor: 10

Tipo de Mensaje 4 N Identificación del mensaje. Valores: 1200: Petición Contable (Ventas) 1220: Comunicación Contable (Venta y Devolución) 1420: Comunicación de Anulación (Venta y Devolución)

Tipo de tarjeta 2 N Valores: VISA = 00 MASTERCARD/EUROCARD/MAESTRO=01 4B=02 AMEX=03 6000=04 DINERS=05 INDETERMINADA=99

PAN (P-2) 19 C Contendrá el PAN de la tarjeta, con lo que se reactiva la operación. Relleno a blancos si son datos cifrados

Código de Operación (P-3) 6 N Valores: 00XXXX Venta 20XXXX Devolución

Importe de la operación (P-4) 12 N En Euros

Identificación de la transacción (P-11) 6 N Número asignado por el iniciador de la transacción para identificarla de forma unívoca

Fecha y Hora de la transacción (P-12) 12 N Formato: AAMMDD hhmmss

Datos Punto Servicio (P-22) 12 C

Código de Identificación Adquirente (P-32) 11 N Relleno a la derecha con spaces

Número de Referencia (P-37) 12 C Contendrá el Número de operación completando la longitud con spaces

Código de Autorización (P-38) 6 C

Identificación del terminal (P-41) 8 C Identificación del terminal donde se originó la transacción

Identificación del Establecimiento (P-42) 15 C Identifica el Establecimiento donde se originó la transacción

Código de Banco Merchant (P-48) 4 N En caso de que no exista, viajara con valor 0000

Tipo de reedites 1 N 1. En 1200/1220 3. En 1420

Tipo 1

Datos asociados al Chip EMV (P-55) ..300 C Longitud variable según transacción Relleno a blancos si tarjeta no EMV

Tipo de Token 1 N 0. Captura manual cifrada 1. Token de 16 o 24 bytes 2. Token de operación no enviada a HCP

Longitud 2 N Longitud del token

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Campo Elemento

de dato Longitud Tipo Contenidos

Token (P-48) 16, 24, 32 ó

40

X 16 bytes si tarjeta EMV

24 bytes si tarjeta banda 32 bytes si captura manual cifrada 40 bytes si operación no fue enviada a HCP

Código de Fabricante (P-48) 1 X Código del fabricante del PIN-Pad.

Núm. Serie del PIN-Pad (P-48) 6 X 11 dígitos del número de serie del PIN-Pad con padeo de un cero

Versión claves del PIN-Pad (P-48) 1 X

Índice de clave 1 X

Núm. ‘random’ del PIN-Pad 3 X Dato aleatorio generado por el PIN-Pad para el cifrado de la operación.


Tipo 3

Tipo mensaje Op. Original (P-56) 4 N

Id. Transacción Op. Original (P-56) 6 N

Fecha/Hora Op. Original (P-56) 12 N

Datos asociados al Chip EMV (P-55) ..300 C Longitud variable según transacción Relleno a blancos si tarjeta no EMV

Tipo de Token 1 N 0. Captura manual cifrada 1. Token de 16 o 24 bytes 2. Token de operación no enviada a HCP

Longitud 2 N Longitud del token

Token (P-48) 16, 24, 32 ó

40

X 16 bytes si tarjeta EMV

24 bytes si tarjeta banda 32 bytes si captura manual cifrada40 bytes si operación no fue enviada a HCP

Código de Fabricante (P-48) 1 X Código del fabricante del PIN-Pad.

Núm. Serie del PIN-Pad (P-48) 6 X 11 dígitos del número de serie del PIN-Pad con padeo de un cero

Versión claves del PIN-Pad (P-48) 1 X

Índice de clave 1 X

Núm. ‘random’ del PIN-Pad 3 X Dato aleatorio generado por el PIN-Pad para el cifrado de la operación.

Filler ..65 C Hasta completar 550 caracteres

8.7.1.3 Registro de Totales

Campo Longitud Tipo Contenido

Tipo de registro 2 N Valor "90"

Entidad origen 6 o 11 N Código asignado al HE por HCP

Entidad destino 6 N Identificación del HCP. Toma los valores: REDSYS:000444 REDSYS: 138000 CECABANK: 002000

Número de operaciones 6 N Número total de operaciones

Número de Ventas 6 N

Importe total de Ventas 16 N

Número anulaciones de Venta 6 N

Importe anulaciones de Venta 16 N

Número devoluciones 6 N

Importe devoluciones 16 N

Número anulaciones de devolución 6 N

Importe anulaciones de devolución 16 N

Importe Neto 16 N Total Devoluciones - Total Anulaciones de Venta - Total Ventas - Total Anulaciones de Devolución

Signo de importe 1 C D=Negativo; C=Positivo





Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

8.8 Anexo H. Mecanismos de Seguridad para PIN On-Line en ePOS operando en modo No

Atendido Introducción Se describe en este anexo los mecanismos de seguridad requeridos para PIN online en terminales EPOS no atendidos, que pueden ser gestionados por diferentes centros procesadores de forma independiente.

No es objeto de este documento el procedimiento de carga en fábrica de las claves iniciales para transporte de claves de protección del PIN, así como tampoco la gestión de estas claves y los procesos de cifrado que se realizan con ellas. Detalle de estos procedimientos puede verse en el Documento de especificaciones del Protocolo PUP a partir de la versión 1.4.0 de 01/11/07

Definición de la Tipología de Seguridad Todos los PIN/Pads instalados en Establecimientos Adaptados a EMV operando en modo No Atendido, utilizarán Tipología TDES (Triple DES) para Securización del PIN On-Line, esto quiere decir que tanto las Claves para Securización del PIN como los procesos Criptográficos que se lleven a cabo con ellas serán TDES.

Estas Claves de Securización del PIN se cargarán en todos los PIN/Pad del HE, de forma On-Line desde los HCP’s. El procedimiento de Carga de estas Claves dependerá del modelo de seguridad para protección de las Claves a Cargar elegido por el HE y que puede ser: protección con claves simétricas o TDES o protección con claves asimétricas o RSA y que deberá ser acordado entre el HE y el HCP.

Definición de los Procesos

8.8.1.1 Inicialización o Carga de Claves El proceso de inicialización se realiza en la instalación del PIN/Pad. La ejecución de este proceso será dependiente del método de protección utilizado

8.8.1.1.1 Con protección mediante Claves Simétricas (TDES)

A continuación se presenta un gráfico con el proceso de carga inicial de claves protegidas con claves simétricas

H E

1600 Petición de Identificación (P-24, 693)

1610 Respuesta a Identificación (P-39, 670)

1600 Petición de Inicialización (P-24, 694)

1610 Respuesta a Iniciali zación (P-39, 671)

H C P

8.8.1.1.2 Con protección mediante Claves Asimétricas (RSA)

A continuación se presenta un gráfico con el proceso de carga inicial de claves protegidas con claves asimétricas

H E

1600 Petición de Inicio de Carga de Claves (P-24,696)

1610 Respuesta Inicio de Carga de Claves (P-39,674)

1600 Continuación de carga de Claves (P-24, 697)

1610 Respuesta a Continuación de Carga(P-39,675)

H C P

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

8.8.1.2 Renovación de Claves Las claves cargadas en el PIN/Pad desde el HCP se podrán renovar de forma automática mediante el protocolo PUC

por indicación del Procesador que, siguiendo sus criterios de renovación de claves, podrá forzar de forma automática dicho proceso de renovación de claves en el PIN/Pad.

En concreto el Procesador, dentro de la respuesta a un mensaje de petición de venta con PIN On-line, podrá enviar al PIN/Pad una orden o indicación para que inicie de forma automática un proceso de renovación de claves en el PIN/Pad.

Al igual que en el proceso de inicialización, en todos los casos se incluirá los valores de control de las nuevas claves para que el PIN/Pad pueda realizar su verificación antes de cargarlas.

A continuación se presenta un gráfico con el proceso de Renovación de claves

H E

1200 Petición de Autorización con PIN on-line

1210 Respuesta + Indicación de Renovación P-48.20

1600 Petición de Renovación(P-24, 695)

1610 Respuesta a Renovación(P-39,672 o 673)

H C P




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Formato de los mensajes

8.8.1.3 Mensaje de Petición 1600



Identificador de Tipo de Mensaje O Debe tener valor '1600' Mapa de Bits Primario O

1 Mapa de Bits secundario O

11 Número de Identificación Transacción O Identifica la Petición de Control de Dialogo permaneciendo invariable

12 Fecha/Hora Local de Transacción O Fecha y Hora en la que inicia la Petición Tendrá el formato: AAMMDDhhmmss

24 Código de Función O Identifica la función del mensaje de Petición

32 Código de Identificación Adquirente O Identificación dada al HE por los HCPs

48 Información adicional -- Información adicional a la operación. 72 Registro de Datos O Datos específicos del proceso

8.8.1.4 Mensaje de Respuesta a Petición 1610



Identificador de Tipo de Mensaje O Debe tener valor '1610' Mapa de Bits Primario O

1 Mapa de Bits secundario O

11 Número de Identificación Transacción OI Identifica la Petición de Control de Dialogo permaneciendo invariable

12 Fecha/Hora Local de Transacción OI Fecha y Hora en la que inicia la Petición Tendrá el formato: AAMMDDhhmmss

32 Código de Identificación Adquirente OI Identificación dada al HE por los HCPs 39 Código de Acción O

72 Registro de Datos O Datos específicos del proceso

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Elementos de Dato Se definen en este apartado los elementos de dato que sufren modificación con respecto a la definición general dada en el apartado 7 de este documento. Los nuevos valores se marcan en rojo.

8.8.1.5 Código de Función (P-24)


Descripción Código que indica el específico propósito del mensaje dentro de su clase

Presencia O 1200 1220 1221 1304 1305 1420 1421 1600 1604 1644 1804 1814


200-299 Usado en mensaje 1200, 1220, 1221 200 Transacción financiera original. Único valor permitido para los mensajes 1200. Transacción financiera con importe igual a 201 una autorización realizada previamente. Válido sólo para 1220/1 Transacción financiera con importe inferior a una

202 autorización previa. Válido sólo para 1220/1

300-399 Usados en los mensajes de actualización de ficheros (1304/1305) para indicar tipo de actualización a realizar 300 Sin determinar. Se informará de la acción a tomar en elemento de dato Registro de Datos (S-72) 380 Petición de Lista Negra rechazada por tamaño de Lista Negra incorrecta

381 Fin de actualización de Lista Negra

400-499 Usados en mensajes de anulación automática (1420/1) para indicar la razón de su envío

400 Anulación por importe total

600-699 Usado en los mensajes (16xx) para indicar el tipo de información que se intercambia 689 Mensaje no reconocible. Usado únicamente en los mensajes 1644 690 Consulta de los datos de conciliación de una sesión. 691 Solicitud de Actualización de Lista Negra 693 Identificación para procesos de carga de claves con protección mediante claves simétricas (TDES) 694 Inicialización para procesos de carga de claves con protección mediante claves simétricas (TDES) 695 Renovación para procesos de carga de claves con protección mediante claves simétricas (TDES) 696 Solicitud de inicio de carga de claves con protección mediante claves asimétricas (RSA)

697 Solicitud de continuación de carga de claves con protección mediante claves asimétricas (RSA)

800-899 Usados en mensajes de control de diálogo (1804, 1824) para indicar la función precisa del mensaje 831 Mensaje de Test 888 Suspensión 891 Reanudación


Comentarios




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

8.8.1.6 Código de Acción (P-39)


Descripción Código que identifica la acción a tomar, o tomada, así como la razón de la misma.

Presencia O 1110 1210 1220 1221 1230 1314 1430 1530 1610 1614 1624 1625 1634 1644 1824 1834

Contenido Puede tomar los siguientes valores: 000-099 Usados en mensaje 1110 1210, 1220 y 1221 para indicar que la transacción ha sido aprobada 000 Aprobada 060 Aprobada. Encadenar con Solicitud de Lista Negra (solo 1110 1210) 100-199 Usados en, 1110 1210, para indicar que la transacción ha sido procesada y ha sido denegada, no requiriéndose retirada de tarjeta 101 Tarjeta caducada 102 Tarjeta en Lista Negra o sospechosa de fraude, incluir en fichero de Lista Negra 106 Excedido el número de intentos del PIN 107 Llamar al Emisor 117 PIN incorrecto 126 Bloque de PIN erróneo 180 Tarjeta no soportada por el sistema 190 Denegada por diversos motivos 192 Denegada. No es posible verificar autenticación por Referencia 193 Denegada. Excedido importe de la autenticación 200-299 Usados en 1110 1210, para indicar que la transacción ha sido procesada y ha sido denegada, requiriéndose retirada de tarjeta e inclusión en Lista Negra 201 Tarjeta caducada 202 Tarjeta en Lista Negra o sospechosa de fraude 206 Excedido el número de intentos del PIN 290 Denegada diversos motivos 300-399 Usados en mensajes de actualización de ficheros 300 Realizada 380 Fichero completo 400-499 Usados en 1430 para indicar que la anulación ha sido aceptada 400 Aceptada 480 Aceptación de la anulación. El HCP no encontró la operación que se quiere anular por no estar procesada o autorizada. Se puede dar este valor en las respuestas de anulaciones iniciadas por vencimiento del temporizador 481 Aceptación de la anulación. El HCP no encontró la operación que se quiere anular. Se dará este código como respuesta a una anulación generada por causa distinta a temporización (ver valor 914). Por ejemplo, se enviara este código cuando se quiera aceptar la anulación de una operación antigua que ya no figura en los ficheros del HCP. 500-599 Usados en 1530 para indicar el resultado de la conciliación 500 Conciliación en acuerdo 501 Conciliación en desacuerdo 503 Totales no disponibles 560 Conciliación en acuerdo. Encadenar con Solicitud de Actualización de Lista Negra 561 Conciliación en desacuerdo. Encadenar con Solicitud de Actualización de Lista Negra 563 Totales no disponibles. Encadenar con Solicitud de Actualización de Lista Negra 580 Datos de Abono Erróneos 581 Datos de Abono Erróneos. Encadenar con Solicitud de Actualización de Lista Negra 600-699 Usados en mensajes 1610, 1614y 1644

Aceptada No es posible encontrar los totales que se solicitan. Usado en mensajes 1614

Aceptada. Encadenar con solicitud de Actualización de Lista Negra Respuesta a Identificación en carga de claves con protección mediante claves simétricas (TDES) Respuesta a Inicialización en carga de claves con protección mediante claves simétricas (TDES) Respuesta a Petición de Renovación de Claves cuando se renuevan la clave de PIN y la de Transporte (TDES) Respuesta a Petición de Renovación de Claves cuando se renuevan la clave de PIN (TDES) Respuesta a inicio de carga de claves con protección mediante claves asimétricas (RSA) Respuesta a continuación de carga de claves con protección mediante claves asimétricas (RSA) No es posible reconocer el mensaje recibido. Usado en mensajes 1644

600 604 660 670 671 672 673 674 675 687 800-899 Usados en mensajes de control de diálogo (1814/1834) 800 Aceptado/Activo 882 Suspendido 900-901 Usado en mensajes de respuesta de comunicación (1230) para indicar que ha sido aceptada 900 Comunicación aceptada 901 Comunicación aceptada. Incluir tarjeta en Lista Negra (solo 1230)

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

902-949 Usados en mensajes de respuesta (1110 1210/1230/1314/1430/1530) para indicar que la transacción no será procesada. La generación de respuestas con estos valores a mensajes tipo 1X3X producirá un descuadre en los casos en que la operación es contabilizada por el HE ya que el HCP nunca la contabiliza 904 Formato de mensaje erróneo 909 Error de sistema. (solo en 1110 1210).

912 Centro Resolutor no disponible. Autorización local. (solo en 1110 1210) 913 Recibido mensaje 1X2X duplicado (ya ha sido procesado otro mensaje con el mismo RTS). 914 No se acepta la anulación. El HCP no encontró la operación que se quiere anular . Se dará este mensaje como expuesta a

una anulación generada por causa distinta a temporización (ver valor 481) 915 Rechazada la Colecta. No encontrada alguna de las operaciones originales referenciadas. 916 MAC erróneo 940 Recibido 1200 a una operación ya anulada a la que se contestó con 914 o 481. 944 Sesión no permitida 947 Recepción en el HCP de un mensaje de comunicación (1X2X) cuando aún se está procesando una previa (1X2X/X). Solo

se puede dar como respuesta a mensajes de repetición y es el único caso, junto con la no recepción de respuesta, en que se debe seguir enviando la comunicación mediante los mensajes de repetición correspondiente. Es de cir, el HE ignorará esta respuesta. 948 Fecha y Hora no sincronizada. Se producirá cuando se reciban en la aplicación del HCP, peticiones contables con una

Fecha y Hora local superior o inferior en más de dos horas a la del HCP. 949 Fecha de Caducidad de la tarjeta no coincide con la que el Emisor tiene en sus archivos

950-999 Usados en mensajes de respuesta de comunicación contable (1230) para indicar la razón del rechazo. El HCP no contabilizará la operación, lo que producirá descuadre con el HE 950 Violación de las normas existentes para realizar una autorización local

965 Violación de norma existentes para realizar una devolución


Comentarios A continuación se definen los textos a visualizar por el Terminal ante la recepción de los distintos Códigos de Acción

Código Texto Acción

000 OPERACIÓN ACEPTADA Autorizada

101 TARJETA CADUCADA, OPERACIÓN DENEGADA Denegada


106 EXCESO ERRORES NUMERO SECRETO Denegada

117 ERROR NUMERO SECRETO Solicitar

Secreto

anotación Número

180 TARJETA NO VALIDA Denegada


201 TARJETA CADUCADA, CAPTURE TARJETA Denegada, Capturar

202 CAPTURE TARJETA, OPERACIÓN DENEGADA Denegada, Capturar

206 ERROR NUMERO SECRETO, CAPTURE TARJETA Denegada, Capturar

290 OPERACIÓN DENEGADA, CAPTURE TARJETA Denegada, Capturar

902-949 SU OPERACIÓN NO PUEDE SER REALIZADA EN ESTE MOMENTO No autorizada




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

8.8.1.7 Datos Privados Adicionales (P-48)

8.8.1.7.1 Información de Control del PIN/Pad EMV-TDES (P-48 Código '16')

(P-48)

'16' Información de Control PIN/Pad EMV-TDES

anb30 o anb31 o anb34 o anb35

Descripción Proporciona información relativa al PIN/Pad en el que se ha iniciado la operación

Presencia -- 1200 1220 1221

1420 1421

1600

Opcional en mensajes 12xx y 14xx enviados por HE iniciados en terminales

con PIN/Pad EMV-TDES

Obligatorio en mensajes 16xx enviados por HE que utilizan PIN/Pads EMV- TDES con versión PUP igual o superior a la 1.6.0


Número de serie n11 Número de serie del PIN/Pad asignado por el fabricante. Dado un

modelo, el número de serie tiene que ser único para cada PIN/Pad de un mismo fabricante.

Fabricante n2 Informa del fabricante del PIN/Pad. El CPD asignará el valor de este campo a cada fabricante.

Modelo n2 Informa el modelo de PIN/Pad. Para cada modelo de PIN/Pad que se

homologue, el CPD asignará el valor para este campo y lo comunicará a cada fabricante.

Nombre del Programa de

Software

an8 Se informará del nombre del programa de software del PIN/Pad. Tiene

que coi ncidir con el nombre del programa de software homologado por el CPD.

Versión del Programa de software

n4 Se informará de la versión de programa de software del PIN/Pad. Tiene que coincidir con la versión de software homologada por el CPD. A partir de la versión PUP 1.6.0, el contenido de este campo estará

estructurado de la siguiente forma:

1er dígito: indica la configuración Sw instalada en el comercio de acuerdo al Escenario PCI utilizado. Debe coi ncidir con el contenido del campo “Escenario PCI” 2ª-4ª dígitos: indican la Versión Sw del PIN/Pad

Kernel EMV n1 Los valores posibles son 0 y 1, con el siguiente significado: 0: Kernel EMV fuera del PIN/Pad. 1: Kernel EMV en PIN/Pad.

VCTC b1 Informa la versión de Clave CTC cargada por el HCP. Se enviará a ceros si el PIN/Pad no dispone de la clave CTC. No usados

VCPIN b1 Informa la versión de Clave de PIN cargada por el HCP. Se enviará a ceros si el PIN/Pad no dispone de la clave CPIN. No usados

VCPistas b1 Informa la versión de Clave de Cifrado de Pistas. Viajará a ceros si el PIN/Pad no dispone de las claves de Cifrado de Pistas. Y podrá no viajar en caso de PIN/Pads con Sw ajustado a versiones de PUP inferiores a la 1.2.1 (1.1)

Versión PUP n3 Versión de Especificaciones PUP implementada


Escenario PCI n1 En este campo se informará del escenario escogido por el comercio, y por lo tanto del tipo de aplicación:

1 : La aplicación cumple con el escenario 1 2 : La aplicación cumple con el escenario 2 3 : La aplicación cumple con el escenario 3

La información que se intercambiará en el resto de mensajes deberá ser siempre coherente con esta definición.



Comentarios • Su uso será acordado entre el HE y el HCP

• Los campos de tipo numérico que forman parte del 'Texto' (Número de serie, Fabricante, Modelo, Versión del Programa Sw y Kernel EMV) se enviarán compactados

• Este Dato Adicional proporciona al Elemento de Dato (P-48) una longitud de 3+2+30 o 31 o 34 o 35 posiciones

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

8.8.1.7.2 Indicador de Renovación (P-48 Código '20')

(P-48)

'20' Indicador de Proceso nb9

Descripción Permite al HCP solicitar una renovación de claves

Presencia -- 1110 1210 Opcional en mensajes 1110 1210 cuando el HCP solicite al HE que realice una renovación de claves

Contenido Tendrá la siguiente estructura


INDp n3 Indicador de proceso en el HCP. Valores:201 o 501 (ver 8.8.6)

RN1 b4 Número aleatorio 1

Id.CM1 n2 Número de cajón asignado al HCP para la CMI


Comentarios Este Dato Adicional proporciona al Elemento de Dato (P-48) una longitud de 3+9 posiciones

8.8.1.8 Registro de Datos (S-72)

8.8.1.8.1 Datos de Identificación (P-72 Código '011')

(P-72)

'011' Datos de Identificación nb25

Descripción Aporta la información necesaria para identificar el PIN/Pad que solicita la Carga de Claves inicial con protección mediante claves simétricas (TDES)

Presencia -- 1600 Obligatorio en mensajes 1600 enviados por el HE, en procesos de Carga de

Claves protegidas con claves simétricas



INDP n3 Indicador de proceso. Valor “100”

IDPED n13 Identificador del PIN/Pad (fabricante y número de serie)

VCCCI b3 VCC de CI. Check control de la CI

VCMI b1 Versión de Clave de la CI y de la CA


VCCCA

b3 VCC de CA. Check control de la CA.




8.8.1.8.2 Datos Respuesta a Identificación (P-72 Código '012')

(P-72)

'012' Datos de respuesta a la Identificación nb9

Descripción Aporta la información necesaria para identificar al HCp contra el que se realiza el proceso de Carga de Claves inicial con protección mediante claves simétricas (TDES)

Presencia -- 1610 Obligatorio en mensajes 1610 enviados por el HCP, en procesos de Carga de Claves protegidas con claves simétricas



INDP n3 Indicador de proceso en HCP: Valor “101” (OK) Valor ‘191’ ó ‘195’ (NOK)

RN1 b4 Número Aleatorio, generado por el HCP







Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

8.8.1.8.3 Datos para Inicializar/Renovar (P-72 Código '013')

(P-72)

'013' Datos para la Inicializar/Renovar nb29

Descripción Aporta la información necesaria para iniciar el proceso de Carga de Claves inicial con protección mediante claves simétricas (TDES)o el proceso de Renovación de Claves

Presencia -- 1600 Obligatorio en mensajes 1600 enviados por el HE, en procesos de Carga de Claves protegidas con claves simétricas o de renovación de Claves



INDp n3 Indicador de proceso. Valor “200” para petición de Inicialización y “500”

para petición de Renovación (apartado 8.8.6) IDPED n13 id PIN/Pad

RN2 b4 Número Aleatorio, generado por el PIN/Pad


VCCCTC b3 Valor de Control de Clave de la CTC

MAC1 b4 MAC calculado con la clave CA. A ceros si error.



8.8.1.8.4 Datos respuesta a Iniciar/Renovar (P-72 Código '014')

(P-72)

'014' Datos de respuesta a Iniciar/Renovar nb49

Descripción Datos de respuesta a la solicitud de inicialización durante el proceso de Carga de Claves Inicial con

protección mediante claves simétricas (TDES) o durante el proceso de renovación de todas las claves

Presencia -- 1610 Obligatorio en mensajes 1610 enviados por el HCP, en respuesta inicialización con protección mediante claves simétricas o a renovación



INDP n3 Indicador de proceso en HCP: Para respuesta a petición de Iniciali zación:

Valor ‘201’ (OK) Valor ‘211’ ó ‘291’ (NOK)

Para respuesta a petición de renovación (apartado 8.8.6): Valor ‘301’ (OK)

{CTC} CI o {CTC} CTC-1 b16 Clave de transporte de Claves : {CTC} CI para el caso de Inicialización,, {CTC} CTC-1 para una renovación de la clave CTC y de la CPIN y

«espacios» si solo se quiere renovar la CPIN que viajará cifrada con la CTC actual


{CPIN}CTC b16 Clave de PIN, cifrada con CTC

VCCCPIN b3 Valor de Control de Clave de la CPIN


MAC2 b4 MAC de los datos anteriores

IZCP n2 Índice de Zona de Clave de PIN



[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

8.8.1.8.5 Datos para Inicio Carga de Claves (P-72 Código '015')

(P-72)

'015' Datos para Inicio de Carga de Claves nb275

Descripción Aporta la información necesaria para iniciar el proceso de Carga de Claves inicial con protección mediante claves asimétricas (RSA)

Presencia -- 1600 Obligatorio en mensajes 1600 enviados por el HE, en procesos de Carga de Claves protegidas con claves asimétricas



INDP n3 Indicador de Proceso en el PIN/Pad. Valor 600 (apartado 8.8.6)

IDPED n13 Identificador del PIN/Pad y su número de serie

Id CMI n2 Nº de cajón asignado al procesador para la CMI

VCRSAFAB n3 Versión de Claves RSA del Fabricante

VCRSAP n3 Versión de Claves RSA del Procesador

LCCPPED n3 Longitud del certificado de la clave pública RSA

CCPPED b248 Certificado de la claves Publica de PIN/Pad compactado



8.8.1.8.6 Datos respuesta Inicio Carga Claves (P-72 Código '016')

(P-72)

'016' Datos respuesta Inicio Carga Claves nb13

Descripción Datos de respuesta a la solicitud de inicio de Carga de Claves Inicial con protección mediante claves

asimétricas (RSA)

Presencia -- 1610 Obligatorio en mensajes 1610 enviados por el HCP, en respuesta a inicio de carga con protección mediante claves asimétricas



INDP n3 Indicador de Proceso en el HCP. Valor 601 (apartado 8.8.6)


RN1 b8 Número aleatorio generador por el HCP



8.8.1.8.7 Datos respuesta a Renovar (P-72 Código '017')

(P-72)

'017' Datos de respuesta a Renovar nb30

Descripción Datos de respuesta a la solicitud de renovación cuando solo se envía la clave de PIN

Presencia -- 1610 Obligatorio en mensajes 1610 enviados por el HCP, en respuesta a renovación



INDP n3 Indicador de proceso en HCP: Para respuesta a petición de renovación con solo actualización de la

clave CPIN (aparatado 8.8.6): Valor ‘401’ (OK) Valor ‘511’ ó ‘561’ (NOK)




MAC2 b4 MAC de los datos anteriores







Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

8.8.1.8.8 Datos para Continuar Carga de Claves (P-72 Código '018')

(P-72)

'018' Datos para Continuar Carga de Claves nb157

Descripción Aporta la información necesaria para continuar con el proceso de Carga de Claves inicial con protección mediante claves asimétricas (RSA)

Presencia -- 1600 Obligatorio en mensajes 1600 enviados por el HE, en conti nuación de

procesos de Carga de Claves protegidas con claves asimétricas



INDP n3 Indicador de Proceso en el PIN/Pad. Valor 700 (apartado 8.8.6)

IDPED n13 Identificador del PIN/Pad y su número de serie


RN2 b8 Número aleatorio generador por el PIN/Pad

LFPPED n3 Longitud de la firma generada por el PIN/Pad

FPPED b128 Firma generada por el PIN/Pad conforme a PKCS1 V1.5



8.8.1.8.9 Datos respuesta continuar Carga Claves (P-72 Código '019')

(P-72)

'019' Datos respuesta continuar Carga Claves nb436

Descripción Datos de respuesta a la continuación de Carga de Claves con protección mediante claves asimétricas (RSA)

Presencia -- 1610 Obligatorio en mensajes 1610 enviados por el HCP, en respuesta a

conti nuación de carga con protección mediante claves asimétricas



INDP n3 Indicador de proceso en el HCP. Valor 701 (apartado 8.8.6)


VCI n3 Versión de clave CI

CheckCI n6 Check de la clave CI

Longitud Datos Cifrados n3

{CI}CPRSA b128 Clave CI cifrada con Clave Publica de PIN/Pad

Longitud de Firma n3

FirmaP b248 Firma con clave privada del procesador dela clave CI cifrada

{CTC}CTC-1 b16 Clave de Transporte de Claves, cifrada con CTC anterior







[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Indicadores de PIN/Pad y de Procesador El indicador de proceso será un campo de 3 bytes que proporcionará información sobre el proceso de carga de claves que se va o se está realizando, del resultado del mismo y del proceso de cifrado llevado a cabo con las claves cargadas. De izquierda a derecha, cada byte tiene el siguiente significado:

Byte 1: Indica el tipo de proceso a realizar. Puede tener los siguientes valores:

0 Venta con PIN online

1 Identificación en inicio de carga de claves protegidas con claves simétricas

2 Inicialización de claves protegidas con claves simétricas

3 Renovación de la CTC y la CPIN

4 Renovación de la CPIN

5 Renovación de claves

6 Carga de Claves protegidas con claves asimétricas (Inicio)

7 Carga de Claves protegidas con claves asimétricas (Continuación)

Byte 2: Estado. Puede tener los siguientes valores:

0 Proceso normal

1 Error en la validación del Certificado/Firma o MAC generado por el PIN/Pad

2 Error en la validación de la Firma o MAC generada por el Procesador

3 Error en la verificación del valor de control de la CTC

4 Error en la verificación del valor de control de la CPIN

5 Error en la verificación del valor de control de la CI

6 Desincronización de las claves del Procesador y del PIN/Pad

7 Error en la verificación del valor de control de la CA

8 Error de datos

9 Error en el Identificador de la clave maestra inicial (Id. CMI)

Byte 3: Referencia al extremo que genera el mensaje. Puede tener los siguientes valores:

0 PIN/Pad

1 Procesador

La siguiente tabla recoge una descripción de los posibles valores de los indicadores de proceso que pueden utilizar el PIN/Pad y el Procesador en su diálogo para la carga de claves.

Indicador de Proceso

Descripción

PIN/Pad

000 Venta

100 Identificación

190 Rechazo de la Identificación por error en el Id. CMI

200 Petición de Inicialización de claves

320 Error en la verificación del MAC2 generado por el Procesador en un proceso de

renovación de la CTC y CPIN 330 Error en la verificación del VCCCTC en un proceso de renovación de la CTC y CPIN

340 Error en la verificación del VCCPIN en un proceso de renovación de la CTC y CPIN

420 Error en la verificación del MAC2 generado por el Procesador en un proceso de renovación de la CPIN

440 Error en la verificación del VCCPIN en un proceso de renovación de la CPIN

500 Petición de renovación de claves (por el PIN/Pad)

600 Carga de Claves protegidas con claves asimétricas (Inicio)

700 Carga de Claves protegidas con claves asimétricas (Continuación)

Procesador

101 Aceptación de la identificación

151 Error en la verificación del valor de control de la CI

191 No hay cargadas Claves iniciales en el procesador

201 Aceptación de la inicialización de claves (envío de claves al PIN/Pad)

211 Error en la verificación del MAC1 generado por el PIN/Pad en un proceso de inicialización de claves

261 Orden de inicialización por desincronismo de claves entre PIN/Pad y Procesador

291 No hay cargadas Claves iniciales en el procesador

301 Renovación de la CTC y la CPIN (envío de dichas claves al PIN/Pad)

401 Renovación de la CPIN (envío de dicha clave al PIN/Pad)

501 Orden de renovación de claves

511 Error en la verificación del MAC1 generado por el PIN/Pad en un proceso de renovación de claves

601 Respuesta a Carga de Claves protegidas con claves asimétricas (Inicio)

701 Respuesta Carga de Claves protegidas con claves asimétricas (Continuación)




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

8.9 Anexo I. Conectividad IP Introducción Se recogen en este documento las adaptaciones que se deben realizar al actual protocolo PUC-EMV para dotarlo, a nivel de red, de la capacidad de conectividad IP.

No se define en este documento la arquitectura de conectividad ya que esta es específica de cada Procesador y por

tanto han de acordarse entre el HE y el HCP

Esquemáticamente, las adaptaciones a realizar afectan a los siguientes conceptos:

Formato de Mensajes La adaptación es necesaria debido a que en TCP es necesario especificar la longitud de los mensajes enviados para que tras el envío troceado por la red IP el receptor pueda controlar que tiene completo el mensaje recibido.

Todos los mensajes de aplicación incorporarán dos bytes delante como cabecera donde se especificará la longitud en

binario del mensaje (sin incluir esta cabecera)

Byte 1 : byte más significativo de la longitud del mensaje Byte 2 : byte menos significativo de la longitud del mensaje

Ejemplo una longitud de 845 bytes seria x03 x4D

La comunicación siempre se establece por el HE que actúa como proceso cliente y por tanto el Front-end del Centro Procesador actúa como servidor.

Las sesiones TCP, por tanto las inicia el comercio contra la dirección IP y puerto especificado por el Centro Procesador y es por tanto el responsable de reintentar la conexión en caso de caída.

En función del tráfico el cliente puede definir que la conexión permanezca establecida de forma permanente o que se

cierre cuando no haya tráfico en x minutos y se inicie de nuevo cuando haya transacciones.

En función del volumen de tráfico se puede acordar, entre el HE y el HCP, el establecimiento de más de una sesión TCP de forma simultánea.

Si el Front-end recibe mensajes con incongruencia entre la longitud de los datos recibidos y lo especificado en el campo longitud procederá a resetear la conexión

Mensajes de Control Se utilizan mensajes de control (de acuerdo con las estructuras definidas en PUC, 1804 y 1814).

El uso de estos mensajes es opcional dependiendo de los requerimientos de conectividad definidos por cada Procesador y por ello han de ser establecidos y acordados entre el HE y el HCP en base a la topología de conexión y configuración que se va a utilizar. Por ejemplo cuando por la topología de conexión y configuración queda unívocamente identificado el otro extremo podría no requerirse el uso de los mensajes de control. o bien podría ser sustituido por un procedimiento propio de identificación del HE

Mensaje de Test de Actividad Utilizado por el HCP para controlar que no se quedan en el servidor sesiones IP no utilizadas por el cliente que las estableció.

Consiste en el envío de un mensaje que solo tiene el campo longitud (2 Bytes) todo a ceros (no lleva mensaje) cuando

por una conexión establecida no hay tráfico de datos durante un tiempo parametrizado.

El Cliente que estableció la conexión debe contestar al mensaje con un mensaje idéntico para confirmar que quiere mantener el socket. Si no contesta se reintenta 3 veces y en caso de no recibir contestación el Front-end del HCP cierra la conexión.

Los clientes no deben controlar que reciben este mensaje solo contestarlos en caso de recibirlos.

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Mensaje Autenticación Dado que habrá clientes que utilicen IPs dinámicas con el objeto de poder identificar por parte de los HCPs quien está

estableciendo conexiones y por tanto requiriendo recursos, es necesario que tras el establecimiento del socket se

identifique correctamente procediendo a la liberación de la conexión en caso contrario.

El cliente una vez establecida la conexión enviará un mensaje de identificación con código mensaje 1804 y en el mensaje de OK de respuesta aceptada a este mensaje que recibirá el Centro Procesador puede incluir datos opcionales de cambio de configuración.

El Front-end del HCP controla, para aquellos clientes en los que se requiera que después de establecerse una conexión en un tiempo inferior a 90 segundos llega este mensaje Identificativo. En caso contrario cierra la conexión al igual que si con la información recibida no identifica al que la pretende establecer.

Mediante configuración se podrá definir de forma individual si una conexión se va a controlar o no con este mensaje. Por ejemplo para conexiones permanentes a través de circuitos propietarios no es necesario utilizar este mensaje de control.

Requerimientos de Seguridad

La estructura de los mensajes de aplicación es independiente del tipo de red IP y seguridad utilizados que son manejados por niveles inferiores.

Siempre que la información sensible de las tarjetas viaje a través de redes no seguras es obligatorio el cifrado de pistas en el PIN/PAD EMV




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Estructura de los mensajes

Los mensajes intercambiados entre HE y HCP tienen la siguiente estructura:

Cabecera de

Control Datos de Aplicación

La Cabecera de Control informará, en binario, la longitud de los datos de Aplicación (mensaje) y estará estructurada de la siguiente forma:

Cabecera de Control b2 Byte 1 Byte más significativo de la longitud del mensaje

Byte 2 Byte menos significativo de la longitud del mensaje

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

Definición de Mensajes de Control de Dialogo

8.9.1.1 Petición de Control de Dialogo -1804-

Ruta De HE a HCP

De HCP a HE

Propósito Conexiones X25 e IP ▪ Realizar un test del diálogo de aplicación

▪ o solicitar la reanudación del diálogo previamente suspendido

Se utilizan para controlar las condiciones de diálogo entre aplicaciones, excepto el mensaje de test iniciado por el HE que puede ser utilizado por cualquier tipo de enlace (Permanentes o Conmutados), el resto sólo existirá en enlaces permanentes entre HCP y HE.

Conexiones IP ▪ Mensaje de Autenticación. Permite Identificar al HE Cliente conectado En caso de IPs dinámicas y una vez establecida la conexión, el HE Cliente deberá identificarse enviando este mensaje al HCP. El HCP en caso de no recibir este mensaje con la información correcta en el P-48 x segundos después de la conexión puede proceder a la desconexión de la misma.


Comentarios Se enviarán siempre que se desee.

Los mensajes de Control de Diálogo referente a reanudación de diálogo, sólo pueden ser iniciados por el HCP

Los mensajes de Control de Diálogo referente la autenticación de una conexión IP tienen que ser

iniciados por el HE, un tiempo x (a definir en certificación) después de establecerse la conexión y en

caso de no recibirse o recibirse con información incorrecta, el HCP puede proceder a la desconexión.





11 Número Transacción

de Identificación O O Identifica la Petición de Control de Dialogo permaneciendo invariable

12 Fecha/Hora Local de Transacción O O Fecha y Hora en la que inicia la Petición Tendrá el formato: AAMMDDhhmmss

24 Código de Función O O Identifica la función del mensaje de Petición de Control de Dialogo (asignamos nuevo valor ‘’889’ indicando autenticación conexión IP para mensajes de autenticación)

48 Datos Adicionales -- -- Solo viajará en mensajes de autenticación enviados por el HE para contener información necesaria en la conexión

93 Código de Identificación Destino O O Identificación mensaje.

del Host que recibirá el





Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

8.9.1.2 Respuesta a Petición de Control de Dialogo -1814-

Ruta De HE a HCP De HCP a HE

Propósito Responder a la petición de control de diálogo y al mismo tiempo enviar información: ▪ Valor de la sesión más actual ▪ Y/o nueva dirección IP

Respuesta Ninguna.

Comentarios Los elementos de datos que deben permanecer invariables en el mensaje de respuesta son: • Número de Identificación de Transacción (P-11)

• Fecha y Hora Local de Transacción (P-12) • Código de Identificación Destino (S-93) • Código de Identificación Origen (S-94)

Siendo los elementos de datos S-94, P-12 y P-11 los utilizados para realizar el emparejamiento con

la petición

En este mensaje de respuesta se incluyen la Fecha y Número de Conciliación de la sesión más

actual





11 Número Transacción

de Identificación OI OI Identifica la Petición de Control de Dialogo permaneciendo invariable

12 Fecha/Hora Local de Transacción OI OI Fecha y Hora en la que inicia la Petición Tendrá el formato: AAMMDDhhmmss

28 Fecha de Conciliación O O Solo usado de mensajes de Test

forma obligatoria en los

29 Número de Conciliación O O Solo usado de mensajes de Test

forma obligatoria en los

39 Código de Acción O O Indica aceptación, imposibilidad de proceso o acción a realizar (se pueden reutilizar los valores ‘800’ aceptador/conexión activa y ‘882’ conexión suspendida)

48 Datos Adicionales -- -- Solo viajará y de forma opcional, en mensajes de respuesta a mensajes de autenticación enviados por el HE para informar la nueva dirección IP

93 Código de Identificación Destino OI OI

94 Código de Identificación Origen OI OI

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

8.9.1.3 Mensaje de Test de Actividad de la Conexión

Ruta De HE a HCP De HCP a HE

Propósito Se define un mensaje de control de actividad que será enviado por el HCP para controlar que no se quedan conexiones establecidas sin ser utilizadas por el cliente que las ha establecido.

Este mensaje es idéntico en cuanto a su funcionalidad al que tiene implementado Visa

Internacional y que denomina ‘Idle link query’. Consiste en el envío de un mensaje que solo tiene el campo longitud (4 Bytes) todo a ceros (no lleva mensaje) cuando por una conexión establecida no hay tráfico de datos durante un tiempo parametrizado.

Respuesta El Host Cliente que estableció la conexión debe contestar al mensaje con un mensaje idéntico para confirmar que quiere mantener el socket. Si no contesta se reintenta un número establecido de veces y en caso de no recibir contestación el HCP cierra la conexión.

Comentarios Los clientes no deben controlar que reciben este mensaje solo contestarlos en caso de recibirlos.




Fecha abril 2019

Página: 20 de 203

ESP-TEC-PUC

Versión: 5.5.6

Elementos de Dato

8.9.1.4 Información de Control (P-48 Código ‘17’)

(P-48)

‘17’ Información de Control ans..20

Descripción Permite al HE informar datos de relativos al sistema

Presencia -- 1804

Contenido Campo Formato Comentarios

Identificativo de conexión PUC en el HCP

an8 Código asignado por el HCP a esta conexión PUC

Versión Sw an4 Código asignado a la versión de PUC utilizada en la conexión

Identificativo de configuración de acceso al HCP

an4 Código asignado en el HCP a la configuración de acceso (primario, backup y contingencia) a esa conexión PUC

Versión de configuración de acceso al HCP

an4 Número asignado en el HCP a la versión para la configuración de acceso indicada en el campo anterior


Comentarios Este elemento adicional proporciona al Elemento de Dato (P-48) una longitud de 3+2+20

8.9.1.5 Actualización de Direcciones IP (P-48 Código ‘18’)

(P-48)

‘18’ Actualización de Direcciones IP ans..xx

Descripción

Presencia -- 1814 Solo si se requiere actualizar direcciones IP

Contenido Campo Formato Comentarios

Identificativo de configuración de acceso al HCP

an4 Código asignado en el HCP a la configuración de acceso (primario, backup y contingencia) a esa conexión PUC

Nueva versión de configuración de acceso al HCP

an4 Número asignado en el HCP a la versión para la configuración de acceso indicada en el campo anterior

Punto acceso HCP Primario an21 IP.Puerto formato xxx.xxx.xxx.xxx.ppppp

Punto acceso HCP BackUp an21 IP.Puerto formato xxx.xxx.xxx.xxx.ppppp

Punto acceso HCP Contingencia an21 IP.Puerto formato xxx.xxx.xxx.xxx.ppppp


Comentarios Este elemento adicional proporciona al Elemento de Dato (P-48) una longitud de 3+2+71

[Escriba texto]



Fecha abril 2019

Página: 19 de 203

ESP-TEC-PUC

Versión: 5.5.6

8.10 Anexo J. Tabla conversión ASCII-EBCDIC En aquellos casos en los que se deba traducir la cinta de descuadre a EBCDIC, se deberá utilizar la siguiente tabla de

conversión de caracteres, a la hora de formar el fichero de descuadre del ANEXO G, que se envía al procesador.

Documents

PUC / PRICE Manual Redsys de Integración a EMV v 5.5...ademdum “Control de Clave CA En PUC adaptación a EMV V5.0” emitido conjuntamente con reléase 5.0 de Especificaciones PUC