Integración Host2Host – Protocolo POI-Switch

  • Versión: 1.22

Introducción

Esta guía describe el protocolo entre el Punto de Interacción (POI o POS, de ahora en adelante) y el Punto de Entrada (EP, de ahora en adelante). El EP es parte del Switch, aunque de ahora en adelante nos referiremos como EP. En este documento se detalla la estructura de los mensajes, campos, intercambio de datos y mecanismos de recuperación de fallos. 

La información de esta guía pretende ser utilizada por los desarrolladores de POI y EP para implementar los procedimientos de comunicación desde el punto de vista de ambas partes.

¿Qué hay en esta guía?

  • En principio, las transacciones tratadas son financieras o están relacionadas con actividades financieras, pero sería posible agregar funcionalidades no financieras si es necesario, teniendo en cuenta la flexibilidad de ISO8583, que permite crear solicitudes y respuestas genéricas a medida.

¿Qué no hay en esta guía?

  • Los parámetros de configuración del POI no formarán parte de ningún mensaje ISO8583 de este documento.
  • Tampoco se admitirá la carga de firmas del titular de la tarjeta.
  • No se admite la repetición del mensaje de solicitud.

Glosario de términos y de normas ISO

A continuación tienes algunos de los términos que veremos en esta guía:

  • STR: Referencia de transacción en el sistema. Identificador único de la transacción en el nivel POI.
  • EP: Punto de entrada.
  • POI/POS: Punto de interacción. Combinación de hardware y software que procesa conjuntamente una transacción financiera con tarjeta. Corresponde a la parte del cliente del protocolo descrito en este documento.
  • SWITCH: Puerta de enlace de múltiples proveedores que autoriza el procesamiento de tarjetas de crédito o pagos directos para empresas en línea, minoristas en línea, etc. Corresponde a la parte del servidor del protocolo descrito en este documento.
  • PAN: Número de Cuenta Principal (PAN, por sus siglas en inglés). El número que está en relieve y/o codificado en una tarjeta plástica que identifica al emisor y la cuenta específica del titular de la tarjeta.
  • BIN: Número de Identificación Bancaria (BIN, por sus siglas en inglés). Los cuatro a seis números iniciales que aparecen en una tarjeta de crédito. El número de identificación bancaria identifica de manera única a la institución que emite la tarjeta.
  • Adquirente: Institución financiera (o su agente) que adquiere del aceptante de tarjetas los datos relacionados con una transacción e ingresa esos datos en un sistema de intercambio.
  • Aceptante de tarjetas: Parte que acepta la tarjeta y presenta los datos de la transacción a un adquirente.
  • Emisor de tarjetas: Institución financiera (o su agente) que emite la tarjeta de transacciones financieras al titular de la tarjeta.
  • Captura de datos: Acto de recopilar los detalles de una transacción financiera.
  • Transacción: Uno o más mensajes relacionados dentro de la misma clase de mensajes diseñados para completar (en la medida de lo posible) la intención del remitente del mensaje original.
  • Recibo: Documento impreso en papel en el que se detallan los datos de la transacción, ya sea para el titular de la tarjeta o el aceptante de tarjetas.
  • Fallback: Tecnología alternativa (de menor seguridad) utilizada para recopilar datos de una tarjeta, por ejemplo, de una transacción con tarjeta de circuito integrado a una transacción con banda magnética.
  • TF: Flujo de la transacción.
  • NTF: Flujo normal de la transacción.
  • CTF: Flujo de cancelación de la transacción.
  • UTF: Flujo de la transacción no reconocido.
  • TTF: Flujo de la transacción de tiempo excedido.
  • TIN: Número de identificación de la transacción. 

A continuación, tienes el glosario de las normativas ISO:

  • ISO 3166: Códigos de países y sus subdivisiones.
  • ISO 8583-1: Mensajes originados de las transacciones con tarjetas financieras – Especificaciones de intercambio de mensajes.
  • EMV: La Especificación de Tarjetas de Circuito Integrado para Sistemas de Pagos, también conocida como EMV. 
  • ISO 4217: Códigos de representación de monedas y fondos.
  • ISO 7813: Tarjetas de transacciones financieras.
  • ISO 639: Estándares para identificar idiomas.

Arquitectura del protocolo de transporte

Esta sección describe el procedimiento que los clientes (POI) deben seguir para comunicarse con el servidor (EP). Se trata de una comunicación sincrónica orientada a mensajes entre el cliente y el servidor mediante sockets TCP.

Establecer conexión

El POI siempre iniciará la conexión; se seguirá el procedimiento normal de establecimiento de conexión TCP utilizando los parámetros presentes en su configuración (dirección IP/nombre de host y puerto). Normalmente, el POI tendrá diferentes conjuntos de datos de acceso para llegar a los EP, al menos uno principal y otro alternativo. Si la conexión a través de los datos de acceso principales no es posible, el POI utilizará los parámetros alternativos, volviendo al principal si también falla el secundario; este proceso se repetirá un número fijo de veces, también configurado como parte de los parámetros del POI, al igual que el intervalo entre intentos.

Transferencia de datos

A nivel de red, la longitud del mensaje se incluirá como encabezado de 32 bytes:

  • ENCABEZADO (HEAD)
  • MENSAJE (MESSAGE)

El encabezado tiene una longitud fija de 32 bytes siguiendo este formato:

  • Longitud del mensaje (message length): 4 bytes en formato little endian. 
  • Versión de protocolo (protocol version): 4 bytes en formato ASCII.
  • RFU: 24 bytes para usos futuros. 

El mensaje está formateado según la norma ISO 8583-1:

  • MGID
  • BITMAP1/BITMAP2
  • ELEMENTOS DE LOS DATOS (DATA ELEMENTS)

Este es un ejemplo de transferencia de datos para:

  • Mensaje (Message): 01 20 80 00 00 00 00 00 00 01 01 01 02 03 04 05 06 07 08
  • Longitud del mensaje (Length of the message): 19 bytes
  • Versión del protocolo (Version of protocol): 0001

Terminar la conexión

Como regla general, el elemento que mande el último mensaje esperará al elemento que cierra el enlace de comunicación. Normalmente, el POI cerrará la comunicación.

En caso de que se dé la notificación «Mensaje no válido» o «Invalid Message Notification», el elemento que realiza el último envío puede ser tanto el cliente como el servidor, ya que este no requiere una respuesta.

Formato del mensaje

La estructura de los mensajes a intercambiar se basa en la norma ISO 8583, pero con las modificaciones necesarias para coincidir con la funcionalidad esperada. No hay ninguna limitación de tipo o tamaño en los datos que se pueden procesar. El enfoque consiste en utilizar la estructura según el estándar, pero con la adaptación necesaria en la definición de mensajes y contenido de los campos.

El mensaje está formado por tres partes:

  • MGID
  • BITMAP1/BITMAP2
  • ELEMENTOS DE LOS DATOS (DATA ELEMENTS)

ID del mensaje (MGID)

Construido con 4 bytes (ASCII numérico).

PosiciónNombreDescripción
1ºNúmero de versión1: ISO 8583:1993
2ºTipo de mensaje– 1: Autorización
– 2: Financiero
– 3: Acciones de archivo
– 4: Cancelaciones
– 5: Reconciliación
– 6: Administrativo
3ºFunción del mensaje– 0: Petición
– 1: Respuesta
– 2: Consejo
– 3: Respuesta al consejo
– 4: Notificación
4ºIndicador de transacción– 0: Adquiriente
– 1: Repetir
– 4: Otros

Estos son los distintos mensajes que se incluyen en la interfaz POI-EP. 

MGIDDescripción del mensaje
1100/1101Solicitud de autorización
1110Respuesta de autorización
1200/1201Solicitud financiera
1210Respuesta financiera
1220/1221Solicitud de asesoramiento financiero
1230Respuesta de asesoramiento financiero
1304Solicitud de acciones de archivo
1314Respuesta de acciones de archivo
1420Solicitud de asesoramiento de cancelación
1430Respuesta de asesoramiento de cancelación
1520Solicitud de asesoramiento de reconciliación
1530Respuesta de asesoramiento de reconciliación
1600Solicitud administrativa 2
1610Respuesta administrativa 2
1644Notificación administrativa

BITMAPs

El protocolo de transporte requiere de uno o dos BITMAPs, cada uno compuesto por 8 bytes binarios. La presencia del segundo se indica mediante el bit más significativo en el BITMAP 1 (P1).

Elementos de los datos

Estos son los diferentes campos de datos que se encuentran en el mensaje según se ha configurado en los BITMAPs.

Los formatos permitidos en los campos de datos son:

  • AN: Caracteres numéricos y alfabéticos.
  • ANP: Caracteres numéricos, alfabéticos y en blanco.
  • ANS: Caracteres numéricos, alfabéticos y especiales.
  • ANSB: Caracteres numéricos, alfabéticos, especiales y binarios.
  • N: Caracteres numéricos.
  • B: Datos binarios.

Estos son los tipos de campos que encontrarás:

TipoCodificaciónDescripción
FijoTipo + longitudLos campos de longitud fijas son indicados por una longitud y un tipo: N16, AN12, ANS15
Variable 2 bytes longitud LLVARTipo + longitud mínima + .. + longitud máxima
(ambas longitudes son opcionales)
Campos de longitud variable hasta 99 bytes: B..16, N..11, ANS10..17
Variable 3 bytes longitud LLLVARTipo + longitud mínima + … + longitud máximaCampos de longitud variable hasta 999 bytes: ANSB…300, B…, B…255
Variable 4 bytes longitud LLLLVARTipo + longitud mínima + …. + longitud máximaCampos de longitud variable hasta 9999 bytes: ANSB…2350, B…, B…1255

Flujos de comunicación

En las siguientes sub-secciones encontrarás los distintos flujos de comunicación según el caso

Flujo de Transacción Normal (NTF)

El Flujo de Transacción Normal (NTF) se aplica a las siguientes transacciones: 1100/1101-1110, 1200/1201-1210, 1220/1221-1230, 1304-1314, 1420-1430, 1600-1610.

Este es un ejemplo de flujo de una única transacción (petición y respuesta)

El Flujo de Transacción Normal (NTF) sigue estos pasos:

  1. El POI establece la conexión con el Switch.
  2. El POI envía los datos del mensaje al Switch.
  3. El Switch envía los datos del mensaje recibidos al POI.
  4. El POI cierra la conexión.

En general para todos los tipos de transacciones, tras la recepción y validación correcta de la respuesta, el procedimiento de comunicación finalizará y la transacción podrá continuar localmente en el POI.

Si se requiere una acción adicional que necesite conexión con el EP, como una cancelación, se iniciará otro proceso de comunicación completo e independiente como una transacción separada.

Flujo de Transacción No Reconocida (UTF)

El Flujo de Transacción No Reconocida (UTF) se aplica a las siguientes transacciones: 1100/1101-1110, 1200/1201-1210, 1220/1221-1230, 1304-1314, 1420-1430, 1600-1610.

Este flujo (UTF) está construido en dos partes. La primera parte corresponde a la transacción petición / mensaje de respuesta; y la segunda parte corresponde a la petición de Notificación Administrativa (1644).

El flujo de la Transacción  No Reconocida (UTF) sigue estos pasos:

Primera parte: petición / mensaje de respuesta

  1. El POI establece la conexión con el Switch.
  2. El POI envía los datos del mensaje al Switch.
  3. El Switch envía los datos del mensaje recibidos al POI.
  4. El POI cierra la conexión. En este punto el mensaje no es reconocido por el POI.

Segunda parte: petición de Notificación Administrativa (1644)

  1. El POI establece la conexión con el Switch.
  2. El POI manda el MGID = 1644 al Switch.
  3. El POI cierra la conexión.

Si el elemento que recibe el mensaje determina que este no es válido, notificará la situación al elemento que se lo mandó mediante un mensaje 1644 que incluirá la información que explicará por qué se activó esa notificación.

Estos datos podrían ser utilizados por el elemento notificado para llevar un registro de fallos de comunicación, siguiendo el siguiente flujo:

  1. El POI establece la conexión con el Switch.
  2. El POI envía los datos del mensaje al Switch. En este punto el mensaje no es reconocido por el Switch.
  3. El Switch envía el MGID = 1644 al POI.
  4. El POI cierra la conexión.

Este mecanismo de notificación se aplica a las dos partes del flujo de intercambio de información de la misma manera. Si el EP no entiende una petición, la respuesta será un mensaje 1644 que incluirá la información original de la petición.

Un mensaje se considerará no reconocible si:

  • No sigue el protocolo de especificación ISO 8583.
  • El ID del mensaje no está cubierto por la especificación ISO 8583.
  • Los BITMAPs no están o no se han construido de forma correcta.
  • Los campos presentes en el mensaje no se corresponden con el contenido de los BITMAPs.
  • Alguno de los campos obligatorios no está presente en el mensaje.

Flujo de Transacción de Cancelación (CTF)

El Flujo de Transacción de Cancelación (CTF) se aplica únicamente a estas transacciones financieras: 1100/1101-1110, 1200/1201-1210, 1220/1221-1230

Este flujo está compuesto por dos flujos de transacciones normales (NTF). El primer flujo para la petición de transacción financiera / mensaje de respuesta; y el segundo flujo para la petición de cancelación / mensaje de respuesta.

El Flujo de la Transacción  de Cancelación (CTF) sigue estos pasos:

Primera parte: petición de transacción financiera

  1. El POI establece la conexión con el Switch.
  2. El POI envía el mensaje financiero al Switch.
  3. El Switch envía los datos del mensaje financiero recibido al POI.
  4. El POI cierra la conexión. En este punto, la respuesta financiera ha sido aceptada por el Switch

Segunda parte: petición de cancelación / mensaje de respuesta

  1. El POI establece la conexión con el Switch.
  2. El POI envía el MGID = 1420 al Switch.
  3. El Switch envía el MGID = 1430 recibido al POI.
  4. El POI cierra la conexión.

El mensaje de cancelación se debe construir y enviar para eliminar la transacción registrada en el Switch en estos casos:

  • Communication Timeout: El Switch no responde al mensaje de petición.
  • Communication MAC Error: Respuesta del Switch con el MAC incorrecto.
  • Communication Format Error: Respuesta del Switch con algún error de formato.
  • Transaction declined in GAC2: El Switch autoriza la Transacción EMV* pero el POI la rechaza en el segundo paso al generar AC (ARPC erróneo u otro caso).
  • Transaction declined Remove Card: El Switch autoriza la Transacción EMV* pero el titular de la tarjeta retira la tarjeta antes de que se realice el segundo Generar AC.
  • Transaction declined Others: El Switch autoriza la Transacción EMV* pero el POI la declina por alguna razón.

* Se considera que la Transacción EMV está autorizada desde el SWITCH cuando se cumplen las siguientes dos condiciones:

  • BIT 39 está presente en el mensaje de respuesta y su valor es igual a ‘000’.
  • Tag 8A está presente en el mensaje de respuesta (BIT55) y el valor es un código válido autorizado de acuerdo a «Especificación de la Tarjeta de Circuito Integrado EMV para el Sistema de Pagos POI» (por ejemplo, ’00’).

Flujo de la Transacción de Tiempo de Espera (TTF)

El Flujo de la Transacción de Tiempo de Espera (TTF) se aplica únicamente a estas transacciones financieras: 1200/1201-1210, 1220/1221-1230.

Este flujo tiene dos partes. La primera parte para la petición de transacción financiera; y la segunda parte para la petición de cancelación / mensaje de respuesta.

*n=0 para la fase 1

El Flujo de la Transacción de Tiempo de Espera (TTF) sigue estos pasos:

Primera parte: petición de transacción financiera

  1. El POI establece la conexión con el Switch.
  2. El POI envía el mensaje financiero al Switch.
  3. El POI espera la respuesta, que nunca llega, y agota el tiempo de espera.
  4. El POI cierra la conexión y procede a repetir la petición el número de veces especificado en la configuración del terminal.

Segunda parte: petición de cancelación / mensaje de respuesta

  1. El POI establece la conexión con el Switch.
  2. El POI envía el MGID = 1420 al Switch.
  3. El Switch envía el MGID = 1430 recibido al POI.
  4. El POI cierra la conexión.

Cuando la respuesta no se ha recibido en el tiempo de espera establecido o se pierde la conexión, se determina un mensaje de repetición para todas estas transacciones que se manda y espera por la respuesta.

Este proceso se repite el número de veces especificado en los parámetros de la configuración del terminal. Cuando el ciclo termina, la transacción se considerará como fallida.

En ese momento se construirá y mandará el mensaje de cancelación para eliminar la transacción registrada en el Switch. La transacción puede ser procesada o no por el Switch (el POI es incapaz de saberlo), pero en cualquier caso el mensaje de cancelación se mandará.

Transacciones POI-EP

Estas son las transacciones que se incluyen en la interfaz POI-EP:

Nombre de la transacciónMGIDs
Pre-Autorización1100/1101 (Petición de autorización)
1110 (Respuesta de autorización)
Pre-Autorización DCCFlujo de dos transacciones combinadas:
– Primera pre-autorización (obtiene info DCC)
– Segunda pre-autorización
Venta1200/1221 (Solicitud financiera)
1210 (respuesta financiera)
Venta DCCFlujo de dos transacciones combinadas:
– Primera venta (obtiene info DCC)
– Segunda venta
Devolución1220/1221 (Solicitud de asesoramiento financiero)
1230 (Respuesta de asesoramiento financiero)
Captura de pre-autorización1220/1221 (Solicitud de asesoramiento financiero)
1230 (Respuesta de asesoramiento financiero)
Cancelaciones1420 (Solicitud de asesoramiento de cancelación)
1430 (Respuesta de asesoramiento de cancelación)
Mensaje de notificación no válido1644 (Notificación Administrativa)
Identificación de clave1600 (Solicitud administrativa 2)
1610 (Respuesta administrativa 2)
Carga de claveFlujo de dos transacciones combinadas:
– Identificación de clave
– 1600 (Solicitud administrativa 2)
1610 (Respuesta administrativa 2)
Renovación de claveFlujo de dos transacciones combinadas:
– Identificación de clave
– 1600 (Solicitud administrativa 2)
1610 (Respuesta administrativa 2)
Carga de transacción offline1220/1221 (Solicitud de asesoramiento financiero)
1230 (Respuesta de asesoramiento financiero)
Subida de datos EMV de Transacciones Anteriores Fallidas1304 (Solicitud de acciones de archivo)
1314 (Respuesta de acciones de archivo)
Obtener token1600 (Solicitud administrativa 2)
1610 (Respuesta administrativa 2)
Verificación DCC1220/1221 (Solicitud de asesoramiento financiero)
1230 (Respuesta de asesoramiento financiero)
Retiro de efectivo1220/1221 (Solicitud de asesoramiento financiero)
1230 (Respuesta de asesoramiento financiero)
Liquidación1520/1521 (Solicitud de asesoramiento de reconciliación)
1530 (Respuesta de asesoramiento de reconciliación)
IPP cargo comercioFase 2
IPP cargo tarjetaFase 2
Tax FreeFase 2
Tax Free Diva Fase 2
PremiaFase 2
IPP ajenas Fase 2
Crédito al consumoFase 2
Recarga de móviles Fase 2
Recarga de tarjetas prepagoFase 2
Operaciones por referenciaFase 2

Transacción de Pre-Autorización

Esta es una Transacción de Autorización con petición MSGID = 1100 (1101 si es un mensaje repetido).

Formato del Mensaje de la Petición (MSGID = 1100/1101)

BITNombre del campoTipoRequerido/OpcionalDescripción
2BINN8RBIN de la tarjeta
3Código de procesoN6RCualificadores adicionales de transacción
4Monto de la transacciónN12RMonto a ser debitado
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS)
19Código del paísN3RCódigo del país del comercio/terminal
22Modo de entrada del Point of Service (POS/POI)AN12RDetalles de la transacción y el terminal (capacidad de captura de datos de la tarjeta, método de captura de datos de la tarjeta, método de autenticación del titular de la tarjeta, …). Formato específico en el ANEXO I.
23Secuencia del número de tarjetaN3OSólo tarjetas EMV contactless: Número de secuencia PAN.
Si está en EMV, la etiqueta 5F34 de la tarjeta contactless se incluirá aquí.
24Código de funciónN3ODetermina el objetivo del mensaje. Valor fijo: 100.
Consulta el Anexo 1 para ver los valores
35Datos de tarjetaB..99ODatos cifrados de la pista 2 para tarjetas EMV, de banda magnética y sin contacto.
Importante: Obligatorio cuando no se envía un token.
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
46Número original de referenciaANP12ONúmero original de la transacción de pre-autorización. Es generado por el SWITCH.
Sólo se incluye en la actualización de la pre-autorización para referirse a la pre-autorización original que se está actualizando.
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de identificaciones
– Estado y configuración
– Indicadores de transacciones
– Entrada manual de datos de transacciones (sólo si los datos de la tarjeta se capturan manualmente)
– Datos adicionales del POI
49Código de divisa de la transacciónN3RCódigo de la divisa usada en la transacción
52PinBlockB8ORequerido sólo si hay verificación de PIN online
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
55Datos EMV ICCB..255OSólo EMV, tarjeta contactless EMV. Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos EMV ICC/Cless Data
No es requerido si se envía el token
56Datos adicionales B..99ODatos adicionales de la transacción
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
64MAC B8OCódigo de autenticación del mensaje

Formato del Mensaje de la Respuesta (MSGID = 1110)

BITNombre del campoTipoRequerido/OpcionalDescripción
3Código de procesoN6RCualificadores adicionales de transacción
4Monto de la transacciónN12RMonto a ser debitado. Mismo valor que en la petición si la transacción se aprueba. Si no, se establecerá como 0.
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N. Mismo valor que en la petición
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS). El SWITCH genera este valor, está en el ticket.
37Número de referenciaANP12ORequerido si el código de respuesta es aprobado. El SWITCH genera la identificación de la transacción, estará en el ticket.
Consulta el anexo 3 para más información.
38Número de autorizaciónANP6ORequerido si el código de respuesta es aprobado. Código de autorización, este dato estará en el ticket.
39Código de respuestaN3RCódigo de la transacción. Valores en el anexo 1. Los válidos son:
– Código de respuesta genérico
– Código de respuesta de autorización
– Código de respuesta DCC (ver la pre-autorización DCC).
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de respuesta de la transacción
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
55Datos EMV ICCB..255OSólo tarjeta EMV. Requerido si se aprueban datos CHIP relacionados por el emisor. Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos EMV de respuesta
56Datos adicionales B..99ODatos adicionales de la transacción. Formato específico en el anexo 1.
Datos en formato TLV:
– Datos de características especiales
60Datos de la transacciónANS..99999ODatos de la transacción
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
64MAC B8OCódigo de autenticación del mensaje

Los flujos válidos para estas transacciones son:

  • NTF
  • CTF: Si la venta es aceptada por el Switch pero ocurre algo incorrecto en el POI (por ejemplo, la impresora no puede procesar el ticket).
  • UTF: Si el mensaje de respuesta de la venta está mal formateado.
  • TTF: Si la respuesta nunca llega al POI.

En cualquier caso, el BIT11 (Número de Identificación de la Transacción) tiene el mismo valor durante el flujo. Una vez que el flujo se completa correctamente, el POI aumenta su secuencia, nunca antes de que el flujo esté completo.

Esto es especialmente importante en los flujos CTF y TTF porque si falla la petición de cancelación / mensaje de respuesta, el POI no aumentará el número de secuencia y enviará en la siguiente transacción el mismo número de secuencia. El Switch debe eliminar la transacción anterior en este caso. Consulta el Anexo 2 de esta guía para más información.

Transacción de Pre-Autorización con DCC

La transacción de Pre-Autorización con DCC es una transacción financiera en dos pasos:

  1. Verificación de la Transacción DCC: El terminal envía los datos de la tarjeta para verificar si la tarjeta se puede procesar por DCC. En caso afirmativo, el Switch responde con la información y el titular de la tarjeta elegirá la divisa de la transacción (local o de la tarjeta) que desee.
  2. Transacción de Pre-Autorización con DCC: Cuando el titular de la tarjeta selecciona la divisa (local o el titular de la tarjeta), el POI envía la Transacción de Pre-Autorización DCC con la divisa seleccionada.

Segundo paso. Formato del mensaje de la petición (MSGID = 1100/1101)

BITNombre del campoTipoRequerido/OpcionalDescripción
2BINN8RBIN de la tarjeta
3Código de procesoN6RCualificadores adicionales de transacción
4Monto de la transacciónN12RMonto a ser debitado
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS)
19Código del paísN3RCódigo del país del comercio/terminal
22Modo de entrada del Point of Service (POS/POI)AN12RDetalles de la transacción y el terminal (capacidad de captura de datos de la tarjeta, método de captura de datos de la tarjeta, método de autenticación del titular de la tarjeta, …). Formato específico en el ANEXO I.
23Secuencia del número de tarjetaN3OSólo tarjetas EMV contactless: Número de secuencia PAN.
Si está en EMV, la etiqueta 5F34 de la tarjeta contactless se incluirá aquí.
24Código de funciónN3RDetermina el objetivo del mensaje. Valores válidos:
– 185: DCC en la divisa del titular de la tarjeta.
– 187: DCC en la moneda local
Consulta el Anexo 1 para ver los valores
35Datos de tarjetaB..99ODatos cifrados de la pista 2 para tarjetas EMV, de banda magnética y sin contacto.
Importante: Obligatorio cuando no se envía un token.
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
46Número original de referenciaANP12ONúmero original de la transacción de pre-autorización. Es generado por el SWITCH.
Sólo se incluye en la actualización de la pre-autorización para referirse a la pre-autorización original que se está actualizando.
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de identificaciones
– Estado y configuración
– Indicadores de transacciones
– Entrada manual de datos de transacciones (sólo si los datos de la tarjeta se capturan manualmente)
– Datos adicionales del POI
49Código de divisa de la transacciónN3RCódigo de la divisa usada en la transacción
52PinBlockB8ORequerido sólo si hay verificación de PIN online
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
55Datos EMV ICCB..255OSólo EMV, tarjeta contactless EMV. Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos EMV ICC/Cless Data
No es requerido si se envía el token
56Datos adicionales B..99RPrimer paso en la verificación DCC del identificador de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de la transacción original.
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
64MAC B8OCódigo de autenticación del mensaje

Segundo paso. Formato del mensaje de la respuesta (MSGID = 1110)

BITNombre del campoTipoRequerido/OpcionalDescripción
3Código de procesoN6RCualificadores adicionales de transacción
4Monto de la transacciónN12RMonto a ser debitado. Mismo valor que en la petición si la transacción se aprueba. Si no, se establecerá como 0.
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N. Mismo valor que en la petición
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS). El SWITCH genera este valor, está en el ticket.
37Número de referenciaANP12ORequerido si el código de respuesta es aprobado. El SWITCH genera la identificación de la transacción, estará en el ticket.
Consulta el anexo 3 para más información.
38Número de autorizaciónANP6ORequerido si el código de respuesta es aprobado. Código de autorización, este dato estará en el ticket.
39Código de respuestaN3RCódigo de la transacción. Valores en el anexo 1. Los válidos son:
– Código de respuesta genérico
– Código de respuesta de autorización
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
48Información adicional AN…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de respuesta de la transacción
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
55Datos EMV ICCB..255OSólo tarjeta EMV. Requerido si se aprueban datos CHIP relacionados por el emisor. Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos EMV de respuesta
56Datos adicionales B..99ODatos adicionales de la transacción. Formato específico en el anexo 1.
60Datos de la transacciónANS..99999ODatos de la transacción
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
64MAC B8OCódigo de autenticación del mensaje

Los flujos válidos para la primera transacción de venta son:

  • NTF
  • UTF: Si el mensaje de respuesta de la venta está mal formateado.

Los flujos válidos para la segunda transacción de venta son:

  • NTF
  • CTF: Si la venta es aceptada por el Switch pero ocurre algo incorrecto en el POI (por ejemplo, la impresora no puede procesar el ticket).
  • UTF: Si el mensaje de la respuesta de la venta está mal formateado.
  • TTF: Si la respuesta de venta nunca llega.

En cualquier caso, el BIT11 (Número de Identificación de la Transacción) tiene el mismo valor durante el flujo. Una vez que el flujo se completa correctamente, el POI aumenta su secuencia, nunca antes de que el flujo esté completo.

Esto es especialmente importante en los flujos CTF y TTF porque si falla la petición de cancelación / mensaje de respuesta, el POI no aumentará el número de secuencia y enviará en la siguiente transacción el mismo número de secuencia. El Switch debe eliminar la transacción anterior en este caso. Consulta el Anexo 2 de esta guía para más información.

Transacción de Venta

La Transacción de Venta es una transacción financiera con petición MSGID = 1200 (1201 si es un mensaje repetido)

Formato del mensaje de la petición (MSGID = 1200/1201)

BITNombre del campoTipoRequerido/OpcionalDescripción
2BINN8RBIN de la tarjeta
3Código de procesoN6RCualificadores adicionales de transacción
4Monto de la transacciónN12RMonto a ser debitado
5Monto de la donaciónN12OMonto a ser donado
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS)
19Código del paísN3RCódigo del país del comercio/terminal
22Modo de entrada del Point of Service (POS/POI)AN12RDetalles de la transacción y el terminal (capacidad de captura de datos de la tarjeta, método de captura de datos de la tarjeta, método de autenticación del titular de la tarjeta, …). Formato específico en el ANEXO I.
23Secuencia del número de tarjetaN3OSólo tarjetas EMV contactless: Número de secuencia PAN.
Si está en EMV, la etiqueta 5F34 de la tarjeta contactless se incluirá aquí.
24Código de funciónN3ODetermina el objetivo del mensaje. Valor fijo: 200.
Consulta el Anexo 1 para ver los valores
35Datos de tarjetaB..99ODatos cifrados de la pista 2 para tarjetas EMV, de banda magnética y sin contacto.
Importante: Obligatorio cuando no se envía un token.
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de identificaciones
– Estado y configuración
– Indicadores de transacciones
– Entrada manual de datos de transacciones (sólo si los datos de la tarjeta se capturan manualmente)
– Datos adicionales del POI
49Código de divisa de la transacciónN3RCódigo de la divisa usada en la transacción
52PinBlockB8ORequerido sólo si hay verificación de PIN online
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
55Datos EMV ICCB..255OSólo EMV, tarjeta contactless EMV. Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos EMV ICC/Cless Data
No es requerido si se envía el token
56Datos adicionales B..99ODatos adicionales de la transacción
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
111Datos sin procesarB..99999ODatos sin procesar QR-Código de barras.
Es obligatorio si el método de captura de datos de la tarjeta es «QR» o «Barcode» (Ver BIT 22).
Los datos de entrada QR-Barcode se informarán en «QR entry transaction data» (Ver BIT 48)
128MACB8OCódigo de autenticación del mensaje

Formato del mensaje de la respuesta (MSGID = 1210)

BITNombre del campoTipoRequerido/OpcionalDescripción
3Código de procesoN6RCualificadores adicionales de transacción
4Monto de la transacciónN12RMonto a ser debitado. Mismo valor que en la petición si la transacción se aprueba. Si no, se establecerá como 0.
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N. Mismo valor que en la petición
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS). El SWITCH genera este valor, está en el ticket.
37Número de referenciaANP12ORequerido si el código de respuesta es aprobado. El SWITCH genera la identificación de la transacción, estará en el ticket.
Consulta el anexo 3 para más información.
38Número de autorizaciónANP6ORequerido si el código de respuesta es aprobado. Código de autorización, este dato estará en el ticket.
39Código de respuestaN3RCódigo de la transacción. Valores en el anexo 1. Los válidos son:
– Código de respuesta genérico
– Código de respuesta de autorización
– Código de respuesta DCC (ver la pre-autorización DCC).
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de respuesta de la transacción
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
54Monto adicionalAN..120OPagos parciales:
– Monto de la transacción original
55Datos EMV ICCB..255OSólo tarjeta EMV. Requerido si se aprueban datos CHIP relacionados por el emisor. Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos EMV de respuesta
56Datos adicionales B..99ODatos adicionales de la transacción. Formato específico en el anexo 1.
Datos en formato TLV:
– Datos de características especiales
60Datos de la transacciónANS..99999ODatos de la transacción
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
64MAC B8OCódigo de autenticación del mensaje

Los flujos válidos para esta transacción son:

  • NTF
  • CTF: Si la venta es aceptada por el Switch pero ocurre algo incorrecto en el POI (por ejemplo, la impresora no puede procesar el ticket).
  • UTF: Si el mensaje de la respuesta de la venta está mal formateado.
  • TTF: Si la respuesta de venta nunca llega.

En cualquier caso, el BIT11 (Número de Identificación de la Transacción) tiene el mismo valor durante el flujo. Una vez que el flujo se completa correctamente, el POI aumenta su secuencia, nunca antes de que el flujo esté completo.

Esto es especialmente importante en los flujos CTF y TTF porque si falla la petición de cancelación / mensaje de respuesta, el POI no aumentará el número de secuencia y enviará en la siguiente transacción el mismo número de secuencia. El Switch debe eliminar la transacción anterior en este caso. Consulta el Anexo 2 de esta guía para más información.

Transacción de Venta con DCC

La Transacción de Venta con DCC es una transacción financiera construida en dos pasos:

  1. Verificación de la Transacción DCC: El terminal envía los datos de la tarjeta para verificar si la tarjeta se puede procesar por DCC. En caso afirmativo, el Switch responde con la información y el titular de la tarjeta elegirá la divisa de la transacción (local o de la tarjeta) que desee.
  2. Transacción de Venta con DCC: Cuando el titular de la tarjeta selecciona la divisa (local o el titular de la tarjeta), el POI envía la Transacción de Venta DCC con la divisa seleccionada.

Segundo paso. Formato del mensaje de la petición (MSGID = 1200/1201)

BITNombre del campoTipoRequerido/OpcionalDescripción
2BINN8RBIN de la tarjeta
3Código de procesoN6RCualificadores adicionales de transacción
4Monto de la transacciónN12RMonto a ser debitado
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS)
19Código del paísN3RCódigo del país del comercio/terminal
22Modo de entrada del Point of Service (POS/POI)AN12RDetalles de la transacción y el terminal (capacidad de captura de datos de la tarjeta, método de captura de datos de la tarjeta, método de autenticación del titular de la tarjeta, …). Formato específico en el ANEXO I.
23Secuencia del número de tarjetaN3OSólo tarjetas EMV contactless: Número de secuencia PAN.
Si está en EMV, la etiqueta 5F34 de la tarjeta contactless se incluirá aquí.
24Código de funciónN3ODetermina el objetivo del mensaje:
– 285: DCC en la divisa del titular de la tarjeta
– 287: DCC en la divisa local
Consulta el Anexo 1 para ver los valores
35Datos de tarjetaB..99ODatos cifrados de la pista 2 para tarjetas EMV, de banda magnética y sin contacto.
Importante: Obligatorio cuando no se envía un token.
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de identificaciones
– Estado y configuración
– Indicadores de transacciones
– Entrada manual de datos de transacciones (sólo si los datos de la tarjeta se capturan manualmente)
– Datos adicionales del POI
49Código de divisa de la transacciónN3RCódigo de la divisa usada en la transacción
52PinBlockB8ORequerido sólo si hay verificación de PIN online
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
55Datos EMV ICCB..255OSólo EMV, tarjeta contactless EMV. Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos EMV ICC/Cless Data
No es requerido si se envía el token
56Datos adicionales B..99OPrimer paso en la verificación DCC del identificador de la transacción. Se especifica el formato en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la transacción original
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
64MACB8OCódigo de autenticación del mensaje

Segundo paso. Formato del mensaje de la respuesta (MSGID = 1210)

BITNombre del campoTipoRequerido/OpcionalDescripción
3Código de procesoN6RCualificadores adicionales de transacción
4Monto de la transacciónN12RMonto a ser debitado. Mismo valor que en la petición si la transacción se aprueba. Si no, se establecerá como 0.
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N. Mismo valor que en la petición
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS). El SWITCH genera este valor, está en el ticket.
37Número de referenciaANP12ORequerido si el código de respuesta es aprobado. El SWITCH genera la identificación de la transacción, estará en el ticket.
Consulta el anexo 3 para más información.
38Número de autorizaciónANP6ORequerido si el código de respuesta es aprobado. Código de autorización, este dato estará en el ticket.
39Código de respuestaN3RCódigo de la transacción. Valores en el anexo 1. Los válidos son:
– Código de respuesta genérico
– Código de respuesta de autorización
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de respuesta de la transacción
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
55Datos EMV ICCB..255OSólo tarjeta EMV. Requerido si se aprueban datos CHIP relacionados por el emisor. Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos EMV de respuesta
56Datos adicionales B..99ODatos adicionales de la transacción. Formato específico en el anexo 1.
60Datos de la transacciónANS..99999ODatos de la transacción
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
64MAC B8OCódigo de autenticación del mensaje

Los flujos válidos para la primera transacción de venta son:

  • NTF
  • UTF: Si el mensaje de respuesta de la venta está mal formateado.

Los flujos válidos para la segunda transacción de venta son:

  • NTF
  • CTF: Si la venta es aceptada por el Switch pero ocurre algo incorrecto en el POI (por ejemplo, la impresora no puede procesar el ticket).
  • UTF: Si el mensaje de la respuesta de la venta está mal formateado.
  • TTF: Si la respuesta de venta nunca llega.

En cualquier caso, el BIT11 (Número de Identificación de la Transacción) tiene el mismo valor durante el flujo. Una vez que el flujo se completa correctamente, el POI aumenta su secuencia, nunca antes de que el flujo esté completo.

Esto es especialmente importante en los flujos CTF y TTF porque si falla la petición de cancelación / mensaje de respuesta, el POI no aumentará el número de secuencia y enviará en la siguiente transacción el mismo número de secuencia. El Switch debe eliminar la transacción anterior en este caso. Consulta el Anexo 2 de esta guía para más información.

Transacción de Devolución

La Transacción de Devolución es una transacción de asesoramiento financiero con la petición MSGID = 1220 (1221 si el mensaje es repetido).

Formato del mensaje de petición (MSGID = 1220/1221)

BITNombre del campoTipoRequerido/OpcionalDescripción
2BINN8RBIN de la tarjeta
3Código de procesoN6RCualificadores adicionales de transacción
4Monto de la transacciónN12RMonto a ser debitado
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS)
19Código del paísN3RCódigo del país del comercio/terminal
22Modo de entrada del Point of Service (POS/POI)AN12RDetalles de la transacción y el terminal (capacidad de captura de datos de la tarjeta, método de captura de datos de la tarjeta, método de autenticación del titular de la tarjeta, …). Formato específico en el ANEXO I.
23Secuencia del número de tarjetaN3OSólo tarjetas EMV contactless: Número de secuencia PAN.
Si está en EMV, la etiqueta 5F34 de la tarjeta contactless se incluirá aquí.
24Código de funciónN3RDetermina el objetivo del mensaje:
– 200: Devolución normal
– 202: Devolución con referencia y 4 últimos dígitos del PAN
Consulta el Anexo 1 para ver los valores
35Datos de tarjetaB..99ODatos cifrados de la pista 2 para tarjetas EMV, de banda magnética y sin contacto.
Importante: Obligatorio cuando no se envía un token.
37Número de referenciaANP12OSwitch original identificador de transacción para operaciones online, y Número de referencia POI en el caso de operaciones offline.
Requerido para devoluciones con referencia .
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de identificaciones
– Estado y configuración
– Indicadores de transacciones
– Entrada manual de datos de transacciones (sólo si los datos de la tarjeta se capturan manualmente)
– Datos adicionales del POI
49Código de divisa de la transacciónN3RCódigo de la divisa usada en la transacción
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
55Datos EMV ICCB..255OSólo EMV, tarjeta contactless EMV. Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos EMV ICC/Cless Data
No es requerido si se envía el token. Una devolución se puede hacer usando referencia + token
56Datos adicionales B..99ODatos adicionales de la transacción
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
111Datos sin procesarB..99999ODatos sin procesar QR-Código de barras.
Es obligatorio si el método de captura de datos de la tarjeta es «QR» o «Barcode» (Ver BIT 22).
Los datos de entrada QR-Barcode se informarán en «QR entry transaction data» (Ver BIT 48)
128MACB8OCódigo de autenticación del mensaje

Formato del mensaje de respuesta (MSGID = 1230)

BITNombre del campoTipoRequerido/OpcionalDescripción
3Código de procesoN6RCualificadores adicionales de transacción
4Monto de la transacciónN12RMonto a ser debitado. Mismo valor que en la petición si la transacción se aprueba. Si no, se establecerá como 0.
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N. Mismo valor que en la petición
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS). El SWITCH genera este valor, está en el ticket.
37Número de referenciaANP12ORequerido si el código de respuesta es aprobado. El SWITCH genera la identificación de la transacción, estará en el ticket.
Consulta el anexo 3 para más información.
39Código de respuestaN3RCódigo de la transacción. Valores en el anexo 1. Los válidos son:
– Código de respuesta genérico
– Código de respuesta de asesoramiento financiero
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de respuesta de la transacción
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
56Datos adicionales B..99ODatos adicionales de la transacción. Formato específico en el anexo 1.
60Datos de la transacciónANS..99999ODatos de la transacción
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
64MAC B8OCódigo de autenticación del mensaje

Los flujos válidos para esta transacción son:

  • NTF
  • CTF: Si la transacción es aceptada por el Switch pero ocurre algo incorrecto en el POI (por ejemplo, la impresora no puede procesar el ticket).
  • UTF: Si la respuesta de la transacción está mal formateado.
  • TTF: Si la respuesta de la transacción nunca llega.

En cualquier caso, el BIT11 (Número de Identificación de la Transacción) tiene el mismo valor durante el flujo. Una vez que el flujo se completa correctamente, el POI aumenta su secuencia, nunca antes de que el flujo esté completo.

Esto es especialmente importante en los flujos CTF y TTF porque si falla la petición de cancelación / mensaje de respuesta, el POI no aumentará el número de secuencia y enviará en la siguiente transacción el mismo número de secuencia. El Switch debe eliminar la transacción anterior en este caso. Consulta el Anexo 2 de esta guía para más información.

Transacción de captura de Pre-autorización

La Transacción de captura de Pre-autorización es una transacción de asesoramiento financiero con petición MSGID = 1220 (1221 si es un mensaje repetido).

Formato del mensaje de la petición (MSGID = 1220/1221)

BITNombre del campoTipoRequerido/OpcionalDescripción
2BINN8RBIN de la tarjeta
3Código de procesoN6RCualificadores adicionales de transacción
4Monto de la transacciónN12RMonto a ser debitado
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS)
19Código del paísN3RCódigo del país del comercio/terminal
22Modo de entrada del Point of Service (POS/POI)AN12RDetalles de la transacción y el terminal (capacidad de captura de datos de la tarjeta, método de captura de datos de la tarjeta, método de autenticación del titular de la tarjeta, …). Formato específico en el ANEXO I.
23Secuencia del número de tarjetaN3OSólo tarjetas EMV contactless: Número de secuencia PAN.
Si está en EMV, la etiqueta 5F34 de la tarjeta contactless se incluirá aquí.
24Código de funciónN3ODetermina el objetivo del mensaje. Valor fijo: 201.
Consulta el Anexo 1 para ver los valores
35Datos de tarjetaB..99ODatos cifrados de la pista 2 para tarjetas EMV, de banda magnética y sin contacto.
Importante: Obligatorio cuando no se envía un token.
37Número de referencia ANP12RIdentificación de la transacción original generada por el SWITCH
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de identificaciones
– Estado y configuración
– Indicadores de transacciones
– Entrada manual de datos de transacciones (sólo si los datos de la tarjeta se capturan manualmente)
– Datos adicionales del POI
49Código de divisa de la transacciónN3RCódigo de la divisa usada en la transacción
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.

No es requerido si se envía el token
55Datos EMV ICCB..255OSólo EMV, tarjeta contactless EMV. Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos EMV ICC/Cless Data
No es requerido si se envía el token
56Datos adicionales B..99ODatos adicionales de la transacción. Consulta el anexo 1 para formatos específicos.
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
64MAC B8OCódigo de autenticación del mensaje

Formato del mensaje de la respuesta (MSGID = 1230)

BITNombre del campoTipoRequerido/OpcionalDescripción
3Código de procesoN6RCualificadores adicionales de transacción
4Monto de la transacciónN12RMonto a ser debitado. Mismo valor que en la petición si la transacción se aprueba. Si no, se establecerá como 0.
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N. Mismo valor que en la petición
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS). El SWITCH genera este valor, está en el ticket.
37Número de referenciaANP12ORequerido si el código de respuesta es aprobado. El SWITCH genera la identificación de la transacción, estará en el ticket.
Consulta el anexo 3 para más información.
39Código de respuestaN3RCódigo de la transacción. Valores en el anexo 1. Los válidos son:
– Código de respuesta genérico
– Código de respuesta de asesoramiento financiero
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de respuesta de la transacción
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
56Datos adicionales B..99ODatos adicionales de la transacción.
60Datos de la transacciónANS..99999ODatos de la transacción
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
64MAC B8OCódigo de autenticación del mensaje

Los flujos válidos para esta transacción son:

  • NTF
  • CTF: Si la transacción es aceptada por el Switch pero ocurre algo incorrecto en el POI (por ejemplo, la impresora no puede procesar el ticket).
  • UTF: Si el mensaje de la transacción está mal formateado.
  • TTF: Si la respuesta de la transacción nunca llega.

En cualquier caso, el BIT11 (Número de Identificación de la Transacción) tiene el mismo valor durante el flujo. Una vez que el flujo se completa correctamente, el POI aumenta su secuencia, nunca antes de que el flujo esté completo.

Esto es especialmente importante en los flujos CTF y TTF porque si falla la petición de cancelación / mensaje de respuesta, el POI no aumentará el número de secuencia y enviará en la siguiente transacción el mismo número de secuencia. El Switch debe eliminar la transacción anterior en este caso. Consulta el Anexo 2 de esta guía para más información.

Transacción de Identificación de Clave

La Transacción de Identificación de Clave es una transacción administrativa con petición MSGID = 1600.

Formato del mensaje de la petición (MSGID = 1600)

BITNombre del campoTipoRequerido/OpcionalDescripción
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS)
24Código de funciónN3RDetermina el objetivo del mensaje. Valor fijo:
– 690
Consulta el Anexo 1 para ver los valores
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de identificaciones
– Estado y configuración
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
72Registro de datosB…999RDatos para identificar claves presentes en el POI. Formato específico en el anexo 1.
Datos incluidos en formato TLV
– Datos de identificación de claves
128MACB8OCódigo de autenticación del mensaje

Formato del mensaje de respuesta (MSGID = 1610)

BITNombre del campoTipoRequerido/OpcionalDescripción
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N. Mismo valor que en la petición
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS). El SWITCH genera este valor, está en el ticket.
39Código de respuestaN3RCódigo de la transacción. Valores en el anexo 1. Los válidos son:
– Código de respuesta genérico
– Código de respuesta de clave
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
72Registro de datosB…999RDatos que contienen información del challenge del servidor. Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Respuesta a los datos de identificación de clave
128MAC B8OCódigo de autenticación del mensaje

Los flujos válidos para esta transacción son:

  • NTF
  • UTF: Si el mensaje de la respuesta está mal formateado.

Transacción de Carga de clave

La Transacción de Carga de clave es una transacción administrativa que sigue dos pasos:

  1. Transacción de Identificación de Clave: El terminal envía los datos de la clave y recibe un fragmento de la información (un challenge).
  2. Transacción de Carga de Clave: El terminal envía un MAC calculado con el challenge recibido en la Transacción de Identificación de la Clave (para el proceso de autenticación) y recibe las nuevas Claves de Carga si el challenge se calcula correctamente.

El segundo paso es una Transacción Administrativa con petición MSGID = 1600.

Segundo paso. Formato del mensaje de la petición (MSGID = 1600)

BITNombre del campoTipoRequerido/OpcionalDescripción
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS)
24Código de funciónN3RDetermina el objetivo del mensaje. Valor fijo:
– 691
Consulta el Anexo 1 para ver los valores
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de identificaciones
– Estado y configuración
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
72Registro de datosB…999RDatos para identificar claves presentes en el POI. Formato específico en el anexo 1.
Datos incluidos en formato TLV
– Datos de identificación de claves
128MACB8OCódigo de autenticación del mensaje

Segundo paso. Formato del mensaje de respuesta (MSGID = 1610)

BITNombre del campoTipoRequerido/OpcionalDescripción
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N. Mismo valor que en la petición
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS). El SWITCH genera este valor, está en el ticket.
39Código de respuestaN3RCódigo de la transacción. Valores en el anexo 1. Los válidos son:
– Código de respuesta genérico
– Código de respuesta de clave
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
72Registro de datosB…999RDatos que contienen información del challenge del servidor. Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Respuesta a los datos de identificación de clave
111Datos sin procesarB..999999OValor del token recibido
128MAC B8OCódigo de autenticación del mensaje

Los flujos válidos para esta transacción son:

  • NTF
  • UTF: Si el mensaje de la respuesta está mal formateado.

Transacción de Renovación de Clave

La Transacción de Renovación de Clave es una transacción administrativa que sigue dos pasos:

  1. Transacción de Identificación de clave: El terminal envía los datos y recibe un fragmento de la información (challenge).
  2. Transacción Administrativa: El terminal envía un MAC calculado con el challenge recibido de la Transacción de Identificación de Clave (por el proceso de autenticación) y recibe las nuevas claves de renovación.

El segundo paso es una Transacción Administrativa con petición MSGID = 1600.

Segundo paso. Formato del mensaje de la petición (MSGID = 1600)

BITNombre del campoTipoRequerido/OpcionalDescripción
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS)
24Código de funciónN3RDetermina el objetivo del mensaje. Valor fijo:
– 692
Consulta el Anexo 1 para ver los valores
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de identificaciones
– Estado y configuración
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
72Registro de datosB…999RDatos para identificar claves presentes en el POI. Formato específico en el anexo 1.
Datos incluidos en formato TLV
– Datos de actualización de claves
128MACB8OCódigo de autenticación del mensaje

Segundo paso. Formato del mensaje de respuesta (MSGID = 1610)

BITNombre del campoTipoRequerido/OpcionalDescripción
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N. Mismo valor que en la petición
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS). El SWITCH genera este valor, está en el ticket.
39Código de respuestaN3RCódigo de la transacción. Valores en el anexo 1. Los válidos son:
– Código de respuesta genérico
– Código de respuesta de clave
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
72Registro de datosB…999RDatos que contienen información del challenge del servidor. Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Respuesta a los datos de actualización de clave
128MAC B8OCódigo de autenticación del mensaje

Los flujos válidos para esta transacción son:

  • NTF
  • UTF: Si el mensaje de la respuesta está mal formateado.

Transacción de Eliminación de Clave

La Transacción de Eliminación de Clave es una transacción administrativa que sigue dos pasos:

  1. Transacción de Identificación de Clave: El terminal envía los datos de la clave y recibe un fragmento de la información (challenge).
  2. Transacción Administrativa: El terminar envía un MAC calculado con el challenge recibido en la Transacción de Identificación de Clave (por el proceso de autenticación) y recibe las referencias de las claves que deben ser eliminadas.

El segundo paso es una Transacción Administrativa con petición MSGID = 1600.

Segundo paso. Formato del mensaje de la petición (MSGID = 1600)

BITNombre del campoTipoRequerido/OpcionalDescripción
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS)
24Código de funciónN3RDetermina el objetivo del mensaje. Valor fijo:
– 693
Consulta el Anexo 1 para ver los valores
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de identificaciones
– Estado y configuración
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
72Registro de datosB…999RDatos que contienen los datos de autenticación y los del challenge del terminal. Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Actualización de clave de datos.
Para la generación de estos datos, es necesario utilizar la Respuesta de Datos de Identificación de Clave recibida en el Primer Paso.
128MACB8OCódigo de autenticación del mensaje

Segundo paso. Formato del mensaje de la respuesta (MSGID = 1610)

BITNombre del campoTipoRequerido/OpcionalDescripción
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N. Mismo valor que en la petición
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS). El SWITCH genera este valor, está en el ticket.
39Código de respuestaN3RCódigo de la transacción. Valores en el anexo 1. Los válidos son:
– Código de respuesta genérico
– Código de respuesta de clave
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
72Registro de datosB…999RDatos que contienen información del challenge del servidor. Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Respuesta a los datos de actualización de clave
128MAC B8OCódigo de autenticación del mensaje

Los flujos válidos para el segundo paso de la transacción son:

  • NTF
  • UTF: Si la respuesta es un mensaje mal formateado.

Transacción de Cancelaciones

La Transacción de Cancelaciones es una transacción de asesoramiento de cancelación con petición MSGID = 1420.

Formato del mensaje de la petición (MSGID = 1420)

BITNombre del campoTipoRequerido/OpcionalDescripción
3Código de procesoN6RCualificadores adicionales de transacción
4Monto de la transacciónN12RMonto a ser debitado
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS)
19Código del paísN3RCódigo del país del comercio/terminal
24Código de funciónN3ODetermina el objetivo del mensaje. Mismo valor que el de la transacción que se está cancelando.
Consulta el Anexo 1 para ver los valores
25Código del motivoN4OMotivo de la/las cancelación/es. Valores válidos:
– 4001: Cancelación de pre-autorización.
– 4006: Tiempo de comunicación agotado.
– 4007: Error MAC de comunicación
– 4008: Error de formato de comunicación
– 4009: Transacción declinada: ARPC
– 4010: Transacción declinada: AAC
– 4011: Transacción declinada: GAC2
– 4012: Transacción declinada: Retire la Tarjeta
– 4013: Transacción declinada: Otros
– 4020: Transacción declinada por el Cliente

IMPORTANTE: Campo requerido para transacciones de pre-autorización
37Número de referencia ANP12ORequerido para transacciones de pre-autorización.
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de identificaciones
– Estado y configuración
– Indicadores de transacciones
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de información de seguridad
55Datos EMV ICCB..255OObligatorio en cancelaciones EMV. Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos EMV ICC/Cless Data (datos del 2º GenAC)
No es requerido si se envía el token
56Datos adicionales B..99RID de la transacción original. Se incluye en formato TLV.
Consulta el anexo 1 para formatos específicos.
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
64MAC B8OCódigo de autenticación del mensaje

Formato del mensaje de la respuesta (MSGID = 1430)

BITNombre del campoTipoRequerido/OpcionalDescripción
3Código de procesoN6RCualificadores adicionales de transacción
11Número de identificación de la transacciónN6RIdentifica TF como una secuencia n. Mismo valor que en la petición.
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS).
39Código de respuestaN3RCódigo de la transacción. Valores en el anexo 1. Los válidos son:
– Código de respuesta genérico (El switch siempre procesará la cancelación (==000) salvo en casos donde no encuentre los datos de la transacción original)
– Código de respuesta de cancelación
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de respuesta de la transacción
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
60Datos de la transacciónANS..99999OEste campo está presente en la cancelación de la pre-autorización.
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
64MAC B8OCódigo de autenticación del mensaje

La Transacción de Cancelaciones forma parte de los flujos CTF o TTF para cancelar una transacción original previa.

Esta cancelación es automática y transparente para el titular de la tarjeta.

El procedimiento manual equivalente sería lanzar el proceso de una Transacción de Devolución.

Mensaje de notificación no válido

El Mensaje de notificación no válido es una transacción de notificación administrativa con petición MSGID = 1644.

Formato del mensaje de la petición (MSGID = 1644)

BITNombre del campoTipoRequerido/OpcionalDescripción
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS)
24Código de funciónN3ODetermina el objetivo del mensaje. Mismo valor que el de la transacción original.
Consulta el Anexo 1 para ver los valores
25Código del motivoN4OMotivo de la/las cancelación/es. Valores válidos:
– 4600: Error del formato
– 4601: Mensaje no reconocido
41Identificador de terminalANS8OId lógico del terminal
42Identificador del comercioAN15OId lógico del comercio
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Estado y configuración (Versión de la clave)
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de información de seguridad
56Datos adicionales B..99RID de la transacción original. Se incluye en formato TLV.
Consulta el anexo 1 para formatos específicos.
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
64MAC B8OCódigo de autenticación del mensaje

La Notificación de Mensaje no Válido es una transacción que forma parte del flujo UTF para notificar un formateado incorrecto / mensaje desconocido que el POI ha recibido previamente.

Esta notificación es automática y transparente para el titular de la tarjeta.

Carga de la Transacción Offline

La Carga de la Transacción Offline es una transacción de asesoramiento financiero con petición MSGID = 1220 (1221 si es un mensaje repetido).

Formato del mensaje de petición (MSGID = 1220)

BITNombre del campoTipoRequerido/OpcionalDescripción
2BINN8RBIN de la tarjeta
3Código de procesoN6RCualificadores adicionales de transacción
4Monto de la transacciónN12RMonto a ser debitado
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS)
19Código del paísN3RCódigo del país del comercio/terminal
22Modo de entrada del Point of Service (POS/POI)AN12RDetalles de la transacción y el terminal (capacidad de captura de datos de la tarjeta, método de captura de datos de la tarjeta, método de autenticación del titular de la tarjeta, …).
23Secuencia del número de tarjetaN3OSólo tarjetas EMV contactless: Número de secuencia PAN.
Si está en EMV, la etiqueta 5F34 de la tarjeta contactless se incluirá aquí.
24Código de funciónN3ODetermina el objetivo del mensaje. Valor fijo: 800.
Consulta el Anexo 1 para ver los valores
35Datos de tarjetaB..99ODatos cifrados de la pista 2 para tarjetas EMV, de banda magnética y sin contacto.
Importante: Obligatorio cuando no se envía un token.
37Número de referencia ANP12RIdentificación de la transacción original generada por el SWITCH
38Número de autorizaciónANP6RNúmero de autorización offline generado por el POI
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de identificaciones
– Estado y configuración
49Código de divisa de la transacciónN3RCódigo de la divisa usada en la transacción
52PinBlockB8OObligatorio si hay verificación de PIN online
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.

No es requerido si se envía el token
55Datos EMV ICCB..255OSólo EMV, tarjeta contactless EMV. Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos EMV ICC/Cless Data
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
64MAC B8OCódigo de autenticación del mensaje

Formato del mensaje de la respuesta (MSGID = 1230)

BITNombre del campoTipoRequerido/OpcionalDescripción
3Código de procesoN6RCualificadores adicionales de transacción
4Monto de la transacciónN12RMonto a ser debitado. Mismo valor que en la petición si la transacción se aprueba. Si no, se establecerá como 0.
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N. Mismo valor que en la petición
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS). Mismo valor que en la petición.
39Código de respuestaN3RCódigo de la transacción. Valores en el anexo 1. Los válidos son:
– Código de respuesta genérico
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
64MAC B8OCódigo de autenticación del mensaje

Los flujos válidos para esta transacción son:

  • NTF
  • UTF: Si el mensaje de la transacción está mal formateado.
  • TTF: Si la respuesta de la transacción nunca llega.

En cualquier caso, el BIT11 (Número de Identificación de la Transacción) tiene el mismo valor durante el flujo. Una vez que el flujo se completa correctamente, el POI aumenta su secuencia, nunca antes de que el flujo esté completo.

Esto es especialmente importante en el flujo TTF porque si falla la petición de cancelación / mensaje de respuesta, el POI no aumentará el número de secuencia y enviará en la siguiente transacción el mismo número de secuencia. El Switch debe eliminar la transacción anterior en este caso. Consulta el Anexo 2 de esta guía para más información.

Subida de datos EMV de Transacciones Anteriores Fallidas

La Subida de datos EMV de Transacciones Anteriores Fallidas es una transacción de acción de archivo con petición MSGID = 1304.

Formato del mensaje de petición (MSGID = 1304)

BITNombre del campoTipoRequerido/OpcionalDescripción
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS)
24Código de funciónN3ODetermina el objetivo del mensaje. Valor fijo: 802.
Consulta el Anexo 1 para ver los valores
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de identificaciones
– Estado y configuración
– Up/download datos (opcional)
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.

No es requerido si se envía el token
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
111Datos sin procesarB..99999RArchivo de datos offline. El formato de este archivo se incluye en el BIT48 (UP/DOWNLOAD DATA)
Formato específico en anexo 1.
128MAC B8OCódigo de autenticación del mensaje

Formato del mensaje de la respuesta (MSGID = 1314)

BITNombre del campoTipoRequerido/OpcionalDescripción
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N. Mismo valor que en la petición
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS). Este valor está en el ticket
39Código de respuestaN3RCódigo de la transacción. Valores en el anexo 1. Los válidos son:
– Código de respuesta genérico
– Código de respuesta de cancelación
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
48Información adicionalB…999RInformación adicional de la transacción. Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de respuestas de las transacciones
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
64MAC B8OCódigo de autenticación del mensaje

Los flujos válidos para esta transacción son:

  • NTF
  • UTF: Si la repuesta es un mensaje mal formateado.

Obtener Token

El mensaje «Conseguir Token» es un mensaje administrativo para obtener el token de autenticación.

Formato del mensaje de la petición (MSGID = 1600)

BITNombre del campoTipoRequerido/OpcionalDescripción
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS)
24Código de funciónN3RDetermina el objetivo del mensaje. Valor fijo: 900.
Consulta el Anexo 1 para ver los valores
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de identificaciones
– Estado y configuración
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
64MAC B8OCódigo de autenticación del mensaje

Formato del mensaje de la respuesta (MSGID = 1610)

BITNombre del campoTipoRequerido/OpcionalDescripción
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N. Mismo valor que en la petición
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS). Este valor está en el ticket
39Código de respuestaN3RCódigo de la transacción. Valores en el anexo 1. Los válidos son:
– Código de respuesta genérico
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
48Información adicionalB…999RInformación adicional de la transacción. Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de respuestas de las transacciones
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
111Datos sin procesarB..99999RValor del token recibido
128MAC B8OCódigo de autenticación del mensaje

Transacción de Verificación DCC

La Transacción de Verificación DCC es una transacción de asesoramiento financiero con petición MSGID = 1220 (1221 si es un mensaje repetido).

Formato del mensaje de la petición (MSGID = 1220)

BITNombre del campoTipoRequerido/OpcionalDescripción
2BINN8RBIN de la tarjeta
3Código de procesoN6RCualificadores adicionales de transacción
4Monto de la transacciónN12RMonto a ser debitado
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N
12 Fecha local de la transacciónN12RFecha y hora local de la transacción offline generada por el POI (AAMMDDHHMMSS)
19Código del paísN3RCódigo del país del comercio/terminal
22Modo de entrada del Point of Service (POS/POI)AN12RDetalles de la transacción y el terminal (capacidad de captura de datos de la tarjeta, método de captura de datos de la tarjeta, método de autenticación del titular de la tarjeta, …).
24Código de funciónN3RDetermina el objetivo del mensaje:
– 300
Consulta el anexo 1 para todos los valores
35Datos de tarjetaB..99ODatos cifrados de la pista 2 para tarjetas EMV, de banda magnética y sin contacto.
Importante: Obligatorio cuando no se envía un token.
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de identificaciones
– Estado y configuración
– Indicadores de transacciones
– Entrada manual de datos de transacciones (sólo si los datos de la tarjeta se capturan manualmente)
49Código de divisa de la transacciónN3RCódigo de la divisa usada en la transacción
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
64MACB8OCódigo de autenticación del mensaje

Formato del mensaje de la respuesta (MSGID = 1230)

BITNombre del campoTipoRequerido/OpcionalDescripción
3Código de procesoN6RCualificadores adicionales de transacción
4Monto de la transacciónN12RMonto a ser debitado. Mismo valor que en la petición si la transacción se aprueba. Si no, se establecerá como 0.
6Monto de la divisa extranjeraN12OImporte expresado en la moneda de la tarjeta. Obligatorio si la transacción es adecuada para el procesamiento de DCC
10Tasa de cambioN8OTipo de cambio de moneda local a extranjera. BIT6 = BIT4 x BIT10. El dígito más a la izquierda indica la posición decimal de izquierda a derecha; el resto de los dígitos representan el valor del tipo de cambio: 1,424209=61424209. Obligatorio si la transacción es adecuada para el procesamiento de DCC (Conversión Dinámica de Divisas).
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N. Mismo valor que en la petición
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS). Está en el ticket.
39Código de respuestaN3RCódigo de la transacción. Valores en el anexo 1. Los válidos son:
– Código de respuesta genérico
– Código de respuesta DCC
La transacción es apta para DCC si el código de respuesta es aprobado (000)
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
49Código de divisa localN3RCódigo de la divisa local usada en la transacción
51Código de divisa extranjeraN3OCódigo de la divisa de la tarjeta de la transacción. Requerido si la transacción es apta para ser procesada por DCC
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
56Datos adicionales B..99ODatos adicionales de la transacción. Formato específico en el anexo 1.
Datos incluidos en formato TLV:
– Datos de transacción DCC (incluido etiqueta de la divisa de la tarjeta)
Requerido si la transacción es apta para ser procesada por DCC.
60Datos de la transacciónANS..99999ODatos de la transacción
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
64MAC B8OCódigo de autenticación del mensaje

Los flujos válidos para esta transacción son:

  • NTF
  • UTF: Si la respuesta de la transacción está mal formateada.

Transacción de Retiro de Efectivo

La Transacción de Retiro de Efectivo es una transacción de asesoramiento financieron con petición MGID = 1220 (1221 si es un mensaje repetido).

Formato del mensaje de la petición (MSGID = 1220/1221)

BITNombre del campoTipoRequerido/OpcionalDescripción
2BINN8RBIN de la tarjeta
3Código de procesoN6RCualificadores adicionales de transacción
4Monto de la transacciónN12RMonto a ser retirado
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS)
19Código del paísN3RCódigo del país del comercio/terminal
22Modo de entrada del Point of Service (POS/POI)AN12RDetalles de la transacción y el terminal (capacidad de captura de datos de la tarjeta, método de captura de datos de la tarjeta, método de autenticación del titular de la tarjeta, …).
23Número de Secuencia de la TarjetaN3OSolo para tarjetas EMV y contactless: secuencia PANde la tarjeta.
Si está presente en tarjetas EMV o sin contacto, el número de secuencia PAN se incluirá aquí (usando la etiqueta 5F34).
24Código de funciónN3RDetermina el objetivo del mensaje:
– 310
Consulta el anexo 1 para todos los valores
35Datos de tarjetaB..99ODatos cifrados de la pista 2 para tarjetas EMV, de banda magnética y sin contacto.
Importante: Obligatorio cuando no se envía un token.
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
48Información adicional B…999RInformación adicional de la transacción. Formato específico en el anexo 1. Los datos se incluyen en formato TLV:
– Datos de identificaciones
– Estado y configuración
– Indicadores de transacciones
– Entrada manual de datos de transacciones (sólo si los datos de la tarjeta se capturan manualmente)
– Datos adicionales del POI
49Código de divisa de la transacciónN3RCódigo de la divisa usada en la transacción
52PinBlockB8OObligatorio si hay verificación de PIN online
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
55Datos EMV ICCB..255OSólo tarjetas contactless o EMV. Formato en el anexo 1.
Datos se incluyen en formato TLV:
– emv icc/cless data
56Datos adicionalesB..99ODatos adicionales de la transacción
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
64MACB8OCódigo de autenticación del mensaje

Formato del mensaje de la respuesta (MSGID = 1230)

BITNombre del campoTipoRequerido/OpcionalDescripción
3Código de procesoN6RCualificadores adicionales de transacción
4Monto de la transacciónN12RMonto a ser debitado. Mismo valor que en la petición si la transacción se aprueba. Si no, se establecerá como 0.
11Número de ID de la transacciónN6RIdentifica TF como una secuencia N. Mismo valor que en la petición
12 Fecha local de la transacciónN12RFecha y hora local (AAMMDDHHMMSS). Está en el ticket.
37Número de referencia ANP12ORequerido si el código de respuesta es aprobado Switch genera identificador de transacción. Los datos estarán en el ticket.
39Código de respuestaN3RCódigo de la transacción. Valores en el anexo 1. Los válidos son:
– Código de respuesta genérico
– Código de respuesta de asesoramiento financiero
41Identificador de terminalANS8RId lógico del terminal
42Identificador del comercioAN15RId lógico del comercio
48Información adicionalB…999RInformación adicional de la transacción. Formato anexo 1.
Datos se incluyen en formato TLV:
– Datos de respuesta de transacción
53Información del control de seguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN.
Formato específico en el anexo 1.
Los datos se incluyen en formato TLV:
– Datos de la información de seguridad.
55Datos emisor EMVB..255OSólo en tarjetas EMV.
Requerido si los datos relacionados con CHIP son aprobados por emisor.
Datos se incluyen en formato TLV.
56Datos adicionales B..99ODatos adicionales de la transacción. Formato específico en el anexo 1.
Datos incluidos en formato TLV:
– Datos de transacción DCC (incluido etiqueta de la divisa de la tarjeta)
Requerido si la transacción es apta para ser procesada por DCC.
60Datos de la transacciónANS..99999ODatos de la transacción
61Datos adicionales del negocioB..999ODatos adicionales incluidos por motivos comerciales
64MAC B8OCódigo de autenticación del mensaje

Los flujos válidos para esta transacción son:

  • NTF
  • CTF: Si la transacción es aceptada por el Switch pero ocurre algo incorrecto en el POI (por ejemplo, la impresora no puede procesar el ticket).
  • UTF: Si el mensaje de la transacción está mal formateado.
  • TTF: Si la respuesta de la transacción nunca llega.

En cualquier caso, el BIT11 (Número de Identificación de la Transacción) tiene el mismo valor durante el flujo. Una vez que el flujo se completa correctamente, el POI aumenta su secuencia, nunca antes de que el flujo esté completo.

Esto es especialmente importante en los flujos CTF y TTF porque si falla la petición de cancelación / mensaje de respuesta, el POI no aumentará el número de secuencia y enviará en la siguiente transacción el mismo número de secuencia. El Switch debe eliminar la transacción anterior en este caso. Consulta el Anexo 2 de esta guía para más información.

Transacción de Liquidación

La Transacción de Liquidación es una transacción de asesoramiento de reconciliación con petición MSGID = 1520.

Formato del mensaje de la petición (MSGID = 1520)

BITNombre del CampoTipoRequerido/OpcionalDescripción
11Número de ID de la TransacciónN6RIdentifica TF como una secuencia N
12Fecha y Hora Local de la TransacciónN12RFecha y hora local (AAMMHHMMSS)
24Código de FunciónN3RDetermina el propósito del mensaje. Valor fijo: 500. Ver Anexo I para todos los valores.
41Identificador del TerminalANS8RID lógico del terminal
42Identificador del ComercioAN15RID lógico del comercio
48Información AdicionalB…999RInformación adicional de la transacción. Formato específico en el Anexo 1. Los datos se incluyen en formato TLV:
– Datos de Identificación
– Estado y configuración
53Información de Control de SeguridadB..99RDetalles de los datos de seguridad utilizados para MAC. Formato específico en el ANEXO I. Datos incluidos en formato TLV:
– Datos de Información de Seguridad
61Datos Adicionales del NegocioB..999ODatos adicionales incluidos por motivos comerciales
64MACB8OCódigo de autenticación del mensaje

Formato del mensaje de la respuesta (MSGID = 1530)

BITNombre del CampoTipoRequerido/OpcionalDescripción
11Número de ID de la TransacciónN6RIdentifica TF como una secuencia N. Mismo valor que en la petición
12Fecha Local de la TransacciónN12RFecha y hora local (MMDDHHMMSS). Está en el ticket.
39Código de RespuestaN3RCódigo de la transacción. Valores en el Anexo 1. Los válidos son:
– Código de Respuesta Genérico
– Código de Respuesta de Reconciliación
41Identificador del TerminalANS8RID lógico del terminal
42Identificador del ComercioAN15RID lógico del comercio
48Información AdicionalB…999RInformación adicional de la transacción. Formato Anexo 1. Los datos se incluyen en formato TLV:
– Datos de respuesta de la transacción
53Información de Control de SeguridadB..99RDetalles de los datos de seguridad usados para el cifrado y MAC del PIN/TRACK/PAN. Formato específico en el Anexo 1. Los datos se incluyen en formato TLV:
– Datos de la Información de Seguridad
60Datos de la TransacciónANS..99999ODatos de la transacción
61Datos Adicionales del NegocioB..999ODatos adicionales incluidos por motivos comerciales
74Número de Transacciones de CréditoN10RNúmero total de transacciones de crédito
76Número de Transacciones de DébitoN10RNúmero total de transacciones de débito
86Importe de CréditosN16RImporte total de las transacciones de crédito
88Importe de DébitosN16RImporte total de las transacciones de débito
97Importe Neto de LiquidaciónX+N16RImporte Neto de Liquidación donde el primer byte es ‘C’ para indicar un valor positivo o de crédito, o ‘D’ para indicar un valor negativo o de débito, seguido del valor numérico (usando 16 dígitos) resultado de la siguiente operación: BIT97 = BIT86 – BIT88
128MACB8OCódigo de autenticación del mensaje

Los flujos válidos para esta transacción son:

  • NTF
  • UTF: Si el mensaje de la transacción está mal formateado.

Anexo 1

En esta sección encontrarás información específica sobre algunos elementos vistos en esta guía. 

Etiquetas propietarias

Esta es la lista de etiquetas propietarias usadas y sus especificaciones en formato TLV:

EtiquetaLongitudDescripción Formato
DF0145Identificación del Terminal. Concatenación de los siguientes campos:
– Código del Fabricante: an5 Código para identificar al fabricante del Punto de Interacción (POI).
– Código de Familia: an5 Código para identificar la familia del POI.
– Código de Modelo: an5 Código para identificar el modelo del POI.
– Número de Serie: an30 Número de serie del POI. Todos rellenados a la izquierda con el carácter de espacio (0x20).		An45
DF029..59Identificación del Software. Concatenación de los siguientes campos:
– Longitud del Nombre de la Aplicación: b1
– Nombre de la Aplicación: an…30
Nombre de la aplicación financiera en el Punto de Interacción (POI).
– Longitud de la Versión de la Aplicación: b1
– Versión de la Aplicación: an…10
Información de versión de la aplicación financiera.
– Longitud de la Publicación de la Aplicación: b1
– Publicación de la Aplicación: an…10
Información de publicación de la aplicación financiera.
– Fecha de la Aplicación: an6 (AAMMDD)
Información de fecha de la aplicación financiera.		An9..59
DF0310Identificación GSM_SIM. Concatenación de los siguientes campos:
– ICCID: n20.		N20
DF042Original Message ID (BIT1).N4
DF053Número de Identificación de Transacción Original (BIT11). Este campo será:
– OPCIONAL para cancelaciones de pre-autorización (bit25=4001)
REQUERIDO para cualquier otro motivo en el código de cancelación.		N6
DF066Marca de tiempo local de la Transacción Original (BIT12).N12
DF0719Datos de Seguridad del PIN. Concatenación de los siguientes campos:
– KSN: b10 Número de serie de la clave.
– Número aleatorio: b8 Número aleatorio utilizado en los procesos criptográficos, si no se utiliza, se establecerá en 0x00.
– Longitud del PIN: b1 Determina la longitud del PIN introducido para la verificación en línea, 0 si no hay PIN, 4 a 12 si se introduce.		B19
DF086Información de Moneda. Concatenación de los siguientes campos:
– Código de Moneda: n3. Rellenado a la izquierda con Hex ‘0‘.
– Exponente de la Moneda: n1
Rellenado a la izquierda con Hex ‘0‘.
– Etiqueta de la Moneda: an3		B6
DF0918Datos de Seguridad de MAC. Concatenación de los siguientes campos:
– KSN: b10 Número de serie de clave.
– Número aleatorio: b8 Número aleatorio utilizado en los procesos criptográficos, si no se utiliza, se establecerá en 0x00.		B18
DF1018Datos de Seguridad de Cifrado. Concatenación de los siguientes campos:
– Número de serie de clave (KSN): b10.
– Número aleatorio: b8. Número aleatorio utilizado en los procesos criptográficos, si no se utiliza, se establecerá en 0x00.		B18
DF1125Versión de Claves. Concatenación de los siguientes campos:
– Versión de KEK: b2 Versión del KEK BDK.
– KEK KCV: b3 Valor de verificación de clave KEK.
– Versión de KAUT: b2 Versión del KAUT BDK.
– KAUT KCV: b3 Valor de verificación de clave KAUT.
– Versión de KPIN: b2 Versión del KPIN BDK.
– KPIN KCV: b3 Valor de verificación de clave KPIN.
– Versión de KPAN: b2 Versión del KPAN BDK.
– KPAN KCV: b3 Valor de verificación de clave KPAN.
– Versión de KMAC: b2 Versión del KMAC BDK.
– KMAC KCV: b3 Valor de verificación de clave KMAC. Si una clave no está presente, tanto la versión como el KCV se establecerán en 0x00.		B25
DF122Versión de Parámetros.
Determina las versiones de los parámetros cargados en la memoria del Punto de Interacción (POI).		N4
DF136Funcionalidades. Concatenación de los siguientes campos:
– DCC: Bandera que indica las capacidades DCC del POI:
– 0: Sin soporte para DCC
– 1: Funcionalidad de DCC basada en datos impresos
– 2: Funcionalidad de DCC basada en datos mostrados
– Captura de firma digital: Bandera con las capacidades del POI respecto a la captura de firma:
– 0: No compatible
– 1: Compatible
– EMV OFF: Bandera que informa si es posible el procesamiento predeterminado EMV offline estándar:
– 0: Sin procesamiento predeterminado
– 1: Procesamiento predeterminado que permite aprobación offline
– Magstripe OFF: Determina la capacidad del POI para respaldar transacciones basadas en banda magnética offline.
– 0: Sin soporte
– 1: Soporte
– Ticket de plantilla: Determina la capacidad del POI para admitir tickets de plantilla.
– 0: Sin soporte
– 1: Soporte
– Retiro de efectivo: Determina la capacidad del POI para admitir la funcionalidad de retiro de efectivo.
– 0: Sin soporte
– 1: Soporte
– PSD2: Determina la capacidad del POI para admitir la funcionalidad PSD2 (SCA Simple y Double Tap).
– 0: Sin soporte
– 1: Soporte
– Código QR-Código de barras (Aún no soportado):
– 0: Sin soporte
– 1: Soporte
– Donaciones: Determina la capacidad del POI para admitir la funcionalidad de donaciones.
– 0: Sin soporte
– 1: Soporte
– Alipay: Determina la capacidad del POI para admitir la funcionalidad de Alipay.
– 0: Sin soporte
– 1: Soporte
– Aprobaciones Parciales: Determina la capacidad del POI para admitir aprobaciones de pagos parciales.
– 0: Sin soporte
– 1: Soporte
– RFU (Reservado para uso futuro):		N12
DF143Código de idioma según ISO639-3: an3
Rellenado a la derecha con espacios.		An3
DF15..5Abreviatura de zona horaria: an..5 Determina el código actual de la zona horaria del Punto de Interacción (POI).An..5
DF166Datos de configuración EMV. Concatenación de los siguientes campos:
– Versión de claves públicas de EMV CA. Tipo: b2
Parámetro general EMV almacenado en el Punto de Interacción (POI).
Ejemplos: 0001
– Capacidades del Terminal EMV. Tipo: b3
Parámetro general EMV almacenado en el POI.
Ejemplos: E0F088
– Tipo de Terminal EMV. Tipo: b1
Parámetro general EMV almacenado en el POI.
Ejemplos: 22		B6
DF182Código de entidad adquirente. Se incluye en los mensajes de respuesta para indicar el código de entidad adquirente que procesó finalmente la transacción. Ejemplo: 2100.N4
DF198ID del terminal adquirente. Se incluye en los mensajes de respuesta para indicar la identificación del terminal dentro del sistema del procesador.
Nota: Si el comerciante tiene capacidad para varias entidades adquirentes, este campo podría ser diferente del bit 41. DF19 debe imprimirse en el recibo.		An8
DF202Indicador de Firmas: Número de firmas capturadas y almacenadas en el Punto de Interacción (POI) (aún no cargadas).N4
DF212Indicador de Transacciones Offline: Número de transacciones offline almacenadas en el Punto de Interacción (POI) (aún no cargadas).N4
DF222Indicador de Transacciones EMV Fallidas Anteriores: Número de transacciones EMV fallidas previas no cargadas aún.N4
DF232Indicador de Características Especiales:
Informa sobre las características especiales realizadas/permitidas por el Punto de Interacción (POI) o SWITCH.
2 bytes en orden de red (MSB-LSB), donde el bit 1 será el bit más a la derecha en el byte LSB.

– Bit 1: La funcionalidad de retiro de efectivo está permitida por SWITCH.
– Bit 2: Se realizó la funcionalidad de SCA Simple Tap por el POI.
– Bit 3: Se realizó la funcionalidad de SCA Double Tap por el POI.
– Bit 4: Se realizó el proceso de donación por el POI.
– Bit 5: RFU (Reservado para uso futuro).
– Bit 6: RFU.
– Bit 7: RFU.
– Bit 8: RFU.
– Bit 9: RFU.
– Bit 10: RFU.
– Bit 11: RFU.
– Bit 12: RFU.
– Bit 13: RFU.
– Bit 14: RFU.
– Bit 15: RFU.
– Bit 16: RFU.		B2
DF245Datos de Liquidación. Concatenación de los siguientes campos:
– Fecha de Liquidación: n6 Fecha de liquidación en formato AAMMDD.
– ID del Número de Liquidación: n4 Identificación del número de liquidación.		N10
DF258Datos de Retiro de Efectivo. Concatenación de los siguientes campos:
– Tipo de comisión del adquirente: n2
Ejemplos: 01
– Moneda de comisión del adquirente: n4
Moneda del monto de la comisión del adquirente
Ejemplos: 0978 -> EURO
– Monto de la comisión del adquirente: n4
Monto de la comisión en la moneda del terminal
Ejemplos: 0100 -> 1,00
0000 -> Sin comisión
– Tipo de comisión adicional: n2
Ejemplos: 01
– Monto de la comisión adicional: n4
Monto de la comisión adicional en la moneda del terminal
Ejemplos: 0100 -> 1,00 EUR
0000 -> Sin comisión		N16
DF264Datos de DCC (Dynamic Currency Conversion). Concatenación de los siguientes campos:
– Tipo de DCC: n2
– 00 -> Desconocido
– 01 -> Visa
– 02 -> MasterCard
– Porcentaje de recargo: n6
Ejemplos: 000101 -> 1,01 %
010000 -> 100 %
000000 -> 0 %		N8
DF27..22Datos de ID de consulta de donación anterior.
Ejemplo: caritas00001		An..22
DF2836ID de transacción del ticket de Comercia – referencia del ticket electrónico. Para ser utilizado en Comercia Portal obtener de Cloud el ticket electrónico para una operación específica.
Esta referencia de ticket electrónico tiene el siguiente formato de Identificador Único Universal (UUID):
El identificador está en dígitos hexadecimales, es decir, utiliza los números del 0 al 9 y las letras de la A a la F. Los dígitos hexadecimales se agrupan como 32 caracteres hexadecimales con cuatro guiones: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.
Para obtener del portal el ticket almacenado en la nube, es obligatorio llamar utilizando «https://ticketdigital.in/receipt/»+ «Merchant ticket transaction id(DF28)»
An36
DF3032Datos de tarjeta ingresados manualmente. Si los datos de tarjeta ingresados manualmente contienen el PAN completo, la fecha de vencimiento y el CVV2, entonces este bloque se cifrará según lo especificado por la criptografía del Punto de Interacción (POI). Si los datos de la tarjeta ingresados manualmente contienen los últimos 4 dígitos del PAN, entonces este bloque no se cifrará.
Los últimos 4 dígitos del PAN (para compatibilidad con el bloque normal) se rellenarán con ceros hasta llegar a 19. Por ejemplo, si los últimos 4 dígitos son 8118, el bloque se verá así: 00000000000000000000008118 cuando: Fecha de vencimiento: 0000 (no ingresada) CVV2: 000 (no ingresado) PAN: 000000000000008118		B32
DF311Datos de información de códigos QR-códigos de barras. Valores válidos:

– 00 -> Formato Desconocido
– 01 -> Formato de Código de Barras EAN25
– 02 -> Formato de Código de Barras EAN39
– 03 -> Formato de Código de Barras EAN128
– 04 -> Formato de Código de Barras PDF417
– 05 -> Formato QR Alipay		N2
DF402Indicador de carga. Mapa de bits que indica los datos del Punto de Interacción (POI) que deben cargarse, con 2 bytes en orden de red (MSB-LSB), donde el bit 1 será el bit más a la derecha en el byte LSB.

– Bit 1: Transacciones offline
– Bit 2: Firmas
– Bit 3: RFU (Reservado para uso futuro)
– Bit 4: RFU
– Bit 5: RFU
– Bit 6: RFU
– Bit 7: RFU
– Bit 8: RFU
– Bit 9: RFU
– Bit 10: RFU
– Bit 11: RFU
– Bit 12: RFU
– Bit 13: RFU
– Bit 14: RFU
– Bit 15: RFU
– Bit 16: RFU		B2
DF52–COF (Card-on-File). Solo aplicable para compra, preautorización y confirmación de preautorización. Concatenación de los siguientes campos:

– Uso: an1
– R – Recurrente
– I – Cuotas
– C – Compra única
– D – Diferido
– E – Reenvío
– H – Reautorización
– M – Incremental
– N – No presentación
– Indicador de primera transacción: an1
– S – Sí
– N – No
– TID: an15
15 caracteres alineados a la izquierda
Ejemplos:
– Primera transacción: CS
– Respuesta de la primera transacción: CS123456789123456, CS123456789
– Segunda transacción: CN123456789123456
– Respuesta de la segunda transacción: CN123456789123456		An..17
DF600..42Datos del procesador. Datos específicos del procesador utilizados para la resolución de la transacción.

– ID del Procesador/Adquirente: an…42
Cadena con el nombre o descripción de la entidad adquirente.		An…42
DF7020Datos de Información de Archivo. Concatenación de los siguientes campos:

– Nombre del Archivo: an15
Rellenado a la izquierda con el carácter de espacio (0x20).
– Extensión del Archivo: an4
Rellenado a la izquierda con el carácter de espacio (0x20).
– Comprimido: an1
1 – Archivo Comprimido (Formato GZIP)
0 – Archivo No Comprimido		an19
DF731Modo de carga: lote o uno por uno
– 0x00: Lote
– 0x01: Uno por uno		B1
DF904Indicador de Carga/Renovación de Claves
Datos que contienen información de desafío indicando que se solicita una carga/renovación de claves:
– RND: b4; Número aleatorio		B4
DF914Indicador de Cálculo de MAC
Datos que contienen el MAC calculado con KAUTH incluyendo RND:
– MAC: b4; Cálculo de MAC		B4
DF9280Valores de Carga/Renovación de Claves:
– Valor de KEK: b16
– Valor de KAUT: b16
– Valor de KPIN: b16
– Valor de KPAN: b16
– Valor de KMAC: b16
Si una clave no está presente, se establecerá en 0x00.		B80
DF934Indicador de Eliminación de Clave
Datos que contienen información de desafío indicando que se solicita la eliminación de una clave:
– RND: b4; Número aleatorio		B4
DF942Indicador de Eliminación de Clave
Mapa de bits que indica las claves que deben eliminarse, con 2 bytes en orden de red (MSB-LSB), donde el bit 1 será el bit más a la derecha en el byte LSB.

– Bit 1: Eliminación de KEK
– Bit 2: Eliminación de KAUT
– Bit 3: Eliminación de KPIN
– Bit 4: Eliminación de KPAN
– Bit 5: Eliminación de KMAC
– Bit 6: RFU (Reservado para uso futuro)
– Bit 7: RFU
– Bit 8: RFU
– Bit 9: RFU
– Bit 10: RFU
– Bit 11: RFU
– Bit 12: RFU
– Bit 13: RFU
– Bit 14: RFU
– Bit 15: RFU		B2
DF9578Información de Derivación de Claves. Concatenación de los siguientes campos:
– KEK IV: b8 Vector de Inicialización de KEK.
– KEK DD1: b8 Datos de Derivación 1 de KEK.
– KEK DD2: b8 Datos de Derivación 2 de KEK.
– KAUT IV: b8 Vector de Inicialización de KAUT.
– KAUT DD1: b8 Datos de Derivación 1 de KAUT.
– KAUT DD2: b8 Datos de Derivación 2 de KAUT.
– KPIN KSN: b10 Datos de Derivación Inicial de KSN de KPIN.
– KPAN KSN: b10 Datos de Derivación Inicial de KSN de KPAN.
– KMAC KSN: b10 Datos de Derivación Inicial de KSN de KMAC.		B78

Formatos de elementos de datos

En esta sección vamos a ver el formato de los distintos elementos de datos.

Código de procesamiento (BIT3)

El código de procesamiento (BIT3) determina el efecto que tiene la transacción en la cuenta del titular de la tarjeta. Este campo está construido con 3 bytes en formato BSD (N6).

Posición del ByteValor
1Tipo de proceso:
– 00: Débitos
– 20: Devoluciones
2RFU (reservado para usos futuros)
3RFU

Modo de entrada del point of service (BIT22)

El modo de entrada de punto de servicio determina las características del terminal y especifica las condiciones bajo las que la transacción tuvo lugar.

Este campo consiste de 12 caracteres alfanuméricos que siguen el siguiente formato:

Posición del ByteValor
1Capacidades de captura de datos de tarjeta:

1: Manual (Sin terminal)
2: Banda magnética
5: Chip EMV
6: Manual (Ingresado)
M: Sin contacto (EMV + Banda magnética) + EMV (chip) + Banda magnética
N: Sin contacto con banda magnética + EMV (chip) + Banda magnética
U: Sin contacto
2Capacidades de autenticación del titular de la tarjeta:

0: Ninguna
1: PIN (Online/offline)
2: Terminal Punto de Venta Móvil (MPOS) Basado en Software con PIN en PANTALLA
3Capacidades de captura de tarjeta:
0: No captura
1: Captura
4Atendido o no atendido:
0: Sin terminal (Sólo para Token) (*)
1: Atendido
2: No atendido
M: Terminal de Punto de Venta Móvil (MPOS) Asistido o Funcionamiento Móvil en la Aplicación
N: Terminal MPOS con lector integrado
5Titular presente:
0: Titular no presente
1: Titular presente
6Tarjeta presente:
0: Tarjeta no presente
1: Tarjeta presente
7Método de captura de datos de tarjeta:
1: Manual sin terminal
2: Banda magnética
3: Código QR o de barras
4: Entrada manual de PAN parcial
5: Chip EMV
6: Entrada manual
N: Sin contacto con banda magnética
M: Sin contacto con chip EMV
S: Respaldo de banda magnética para chip EMV
T: Respaldo de entrada manual para chip EMV
L: Sin contacto con chip EMV para dispositivos móviles
K: Sin contacto con banda magnética para dispositivos móviles
8Método de autenticación del titular de la tarjeta n:
0: No autenticado
1: PIN online
2: PIN offline
3: Firma
4: Código de acceso
5: PIN offline y Firma
9Entidad de autorización:
0: Por defecto (calculado por el servidor)
F: Pago por referencia (COF)
10Datos de autorización:
0: Por defecto (calculado por el servidor).
11Puntos de Interacción (POIs) con pantalla/impresora en terminal:

0: Desconocido
2: Impresora
3: Pantalla
4: Impresora y pantalla
12Longitud máxima del PIN
0: Sin captura de PIN
4..C-4 a 12 dígitos

* Para las transacciones de pagos (pre-autorizaciones, ventas y devoluciones) con un token ya generado, se deben mandar estos valores:

  • POSICIÓN 1:1 – Manual – Sin terminal
  • POSICIÓN 2:0 – Ninguna
  • POSICIÓN 4:0 – Sin terminal
  • POSICIÓN 5:4 – No presente, pago recurrente
  • POSICIÓN 6:0 – Tarjeta no presente
  • POSICIÓN 7:1 – Manual sin terminal
  • POSICIÓN 8:0 – No autenticado
  • POSICIÓN 9:F Pago por referencia (COF)

Código de función (BIT24)

Estos son los códigos de función y su descripción:

Valor Descripción
100Transacción de Preautorización
150Transacción AVS. Preautorización de monto cero
185Transacción de Preautorización DCC con moneda del titular de la tarjeta
187Transacción de Preautorización DCC con moneda local
200Transacción normal. Venta (1200) (primera o única solicitud) y Reembolso (1220)
201Transacción de captura de pre-autorización
202Reembolso sin referencia
285Transacción de Venta DCC con moneda del titular de la tarjeta
287Transacción de Venta DCC con moneda local
300Transacción de Verificación DCC
310Transacción de Retiro de Efectivo
481 Cancelación de pre-autorización
500Transacción de Liquidación
690Transacción de Identificación de Clave
691Transacción de Carga de Clave
692Transacción de Renovación de Clave
693Transacción de Eliminación de Clave
800Transacción de Carga offline
802Transacción de Carga de Datos EMV
900Transacción de Obtención de Token

Tabla de códigos de respuesta (BIT39)

Los códigos de respuesta están agrupados para describirlos de manera simple en cada transacción.

Estos son los códigos de respuesta organizados por grupo:

Valor DescripciónCategoría
000Aprobado / Procesado Código de respuesta genérico
010Aprobado parcialmente / ProcesadoCódigo genérico
909Error del sistemaCódigo genérico
912Sistema no disponibleCódigo genérico
916MAC no válidoCódigo genérico
948Fecha y hora local del terminal no válidasCódigo genérico
100Procesamiento sin conexión en el terminalCódigo de respuesta de autorización
101Declinado: Tarjeta vencidaCódigo de respuesta de autorización
105DeclinadoCódigo de respuesta de autorización
106Declinado: Límite de PIN excedidoCódigo de respuesta de autorización
117Declinado: PIN incorrectoCódigo de respuesta de autorización
126Declinado: Bloque de PIN no válidoCódigo de respuesta de autorización
127Declinado: Datos de tarjeta cifrados no válidosCódigo de respuesta de autorización
180Declinado: Tarjeta no admitidaCódigo de respuesta de autorización
195Declinado: Realizar proceso de TAP doble SCACódigo de respuesta de autorización
196Declinado: Realizar proceso de TAP simple SCACódigo de respuesta de autorización
201No procesadoCódigo de respuesta de asesoramiento financiero
400 Procesado (por compatibilidad con la versión anterior)Código de respuesta de cancelación
401No encontradoCódigo de respuesta de cancelación
500Procesado (por compatibilidad con la versión anterior)Código de respuesta de reconciliación
501No procesado: Desajuste de datos de conciliaciónCódigo de respuesta de conciliación
610No procesado, error en el proceso de claveCódigo de respuesta de claves
621No hay información de DCC disponibleCódigo de respuesta de DCC

Datos adicionales (BIT48)

Los datos adicionales es información extra de cada transacción que se incluye en el BIT48 del mensaje de la petición / respuesta en formato TLV.

Las etiquetas de los datos adicionales están agrupadas para describirlas de manera simple en cada transacción. Si un grupo se incluye en una transacción, todas las etiquetas obligatorias deben ser incluidas.

Estas son las etiquetas de los datos adicionales posibles organizadas por grupo:

IdentificadorDescripciónRequerido/ObligatorioCategoría
DF01Identificación del TerminalRDatos de identificación
DF02Identificación del SoftwareRDatos de identificación
DF03Identificación de GSM_SIMODatos de identificación
DF11Versión de ClavesRDatos de estado y configuración
DF12Versión de ParámetrosRDatos de estado y configuración
DF13FuncionalidadesRDatos de estado y configuración
DF14Código de LenguajeRDatos de estado y configuración
DF15Abreviatura de Zona HorariaRDatos de estado y configuración
DF16Versión de Claves Públicas EMV CARDatos de estado y configuración
DF20Indicador de FirmasRDatos de indicadores de transacciones
DF21Indicador de Transacciones OfflineRDatos de indicadores de transacciones
DF22Indicador de Transacciones EMV Fallidas AnterioresRDatos de indicadores de transacciones
DF23Características Especiales Realizadas por el POI
Requerido si la característica especial fue realizada por el POI (SCA, por ejemplo).		RDatos de indicadores de transacciones
DF27Datos de la ID de consulta de donación.ODatos de transacciones de donación
DF30Datos de la tarjeta ingresados manualmente (PAN completo o los últimos 4 dígitos).RDatos de transacciones de entrada manual
DF31Datos de Transacción de Entrada QRRDatos de transacciones de entrada QR
DF40Indicador de SubidaRDatos de respuesta de transacción
DF52COFODatos de respuesta de transacción
DF60Datos del ProcesadorRDatos de respuesta de transacción
DF90Indicador de Renovación de ClaveRDatos de respuesta de transacción
DF93Indicador de Eliminación de ClaveRDatos de respuesta de transacción
DF24Datos de liquidaciónODatos de respuesta de transacción
DF70Datos de Información de ArchivoRSubir/descargar datos
DF73Modo de Subida/DescargaOSubir/descargar datos

Información de control de seguridad (BIT53)

Los datos de la información de control de seguridad se incluyen en el mensaje BIT53 de la petición en formato TLV.

Las etiquetas de control de seguridad están agrupadas para describirlas de manera simple en cada transacción. Si un grupo se incluye en una transacción, todas las etiquetas obligatorias deben ser incluidas.

Estas son las etiquetas de control de seguridad posibles organizadas por grupo:

IdentificadorDescripciónRequerido/Obligatorio
DF07Datos del PIN de seguridadO
DF09Datos de seguridad MACO
DF10Daros del cifrado de seguridad O

Datos EMV ICC (BIT55)

Las etiquetas de datos EMV ICC BIT55 agrupadas para describirlas de manera simple en cada transacción. Si un grupo se incluye en una transacción, todas las etiquetas obligatorias deben ser incluidas.

Estas son las etiquetas de datos EMV ICC posibles organizadas por grupo:

EtiquetaDescripciónRequerido/ObligatorioCategoría
82AIPRDatos EMV ICC\CLess
95TVRRDatos EMV ICC\CLess
9ADatos de transacciónRDatos EMV ICC\CLess
9CTipo transacciónRDatos EMV ICC\CLess
5F2ACódigo divisaRDatos EMV ICC\CLess
9F02MontoRDatos EMV ICC\CLess
9F10Datos de aplicación del emisorRDatos EMV ICC\CLess
9F1ACódigo de país del terminalRDatos EMV ICC\CLess
9F26CriptogramaRDatos EMV ICC\CLess
9F27Info del criptograma RDatos EMV ICC\CLess
9F33Capacidades del terminalRDatos EMV ICC\CLess
9F34Resultado CVMRDatos EMV ICC\CLess
9F35Tipo de terminalRDatos EMV ICC\CLess
9F36ATCRDatos EMV ICC\CLess
9F37Número aleatorioRDatos EMV ICC\CLess
9F6EDatos de tercerosODatos EMV ICC\CLess
5F20Nombre titular tarjetaODatos EMV ICC\CLess
5F34Secuencia de números de tarjetaODatos EMV ICC\CLess
9F06Terminal AIDRDatos EMV ICC\CLess
50Etiqueta de aplicaciónODatos EMV ICC\CLess
9F12Nombre preferido de aplicaciónODatos EMV ICC\CLess
84Nombre DFODatos EMV ICC\CLess
9F66TTQ para Visa ContactlessODatos EMV ICC\CLess
71Scripts del emisorODatos respuesta EMV
72Scripts del emisorODatos respuesta EMV
89Número de autorización (mismo que BIT38)ODatos respuesta EMV
8ACódigo de respuesta de autorizaciónRDatos respuesta EMV
91Datos de autenticación del emisorODatos respuesta EMV

Datos adicionales (BIT56)

Los datos adicionales es información extra de cada transacción que se incluye en el BIT56 del mensaje de la petición / respuesta en formato TLV.

Las etiquetas de los datos adicionales están agrupadas para describirlas de manera simple en cada transacción. Si un grupo se incluye en una transacción, todas las etiquetas obligatorias deben ser incluidas.

Estas son las etiquetas de los datos adicionales BIT56 disponibles organizadas por grupo:

EtiquetaDescripciónRequerido/ObligatorioCategoría
DF04ID mensaje originalRDatos transacción original
DF05Número de identificación de la transacción originalRDatos transacción original
DF06Marca de tiempo local de la transacción originalRDatos transacción original
DF08Información DCC de la divisa del titularRDatos DCC de transacción
DF14Código de lenguaje DCCRDatos DCC de transacción
DF26Datos DCCRDatos DCC de transacción
DF23Funcionalidades Especiales permitidas por el SWITCH
Obligatorio si la funcionalidad especial está permitida por el SWITCH. (Por ejemplo, Retiro de Efectivo)		ODatos de características especiales
DF25Datos de retiro de efectivoODatos de transacción retiro de efectivo

Registro de datos (BIT72)

Estas son las etiquetas de los registros de datos (BIT72) disponibles organizadas por grupo:

EtiquetaDescripciónRequerido/ObligatorioCategoría
DF11Datos para identificar las claves presentes en el Punto de Interacción (POI)RDatos de identificación de clave
DF95Información de Derivación de Datos de Claves (presentes en el POI)RDatos de identificación de clave
DF90Datos que contienen información del challenge del servidor (RND1)RDatos de respuesta de identificación de clave
DF90Datos que contienen información del challenge del terminal (RND2)RDatos de actualización de clave
DF91MAC calculado con KAUTH incluyendo RND1RDatos de actualización de clave
DF11Datos para identificar nuevas versiones de actualizaciones de clavesRDatos de respuesta de actualización de clave
DF91MAC calculado con KAUTH incluyendo RND2RDatos de respuesta de actualización de clave
DF92Nuevos Valores de Clave para carga/renovaciónRDatos de respuesta de actualización de clave
DF94Referencias de Clave para eliminarRDatos de respuesta de actualización de clave
DF95Información de Derivación de Datos de ClavesRDatos de respuesta de actualización de clave

Anexo 2

En las transacciones que siguen un flujo CTF y TTF, el flujo de un mensaje de cancelación podría fallar (si se agota el tiempo de espera de la respuesta, el código de respuesta es incorrecto, etc). De cualquier forma, la integridad del mensaje del flujo se asegurará por un número secuencial entre el POI y el Switch que mantendrá todas las transacciones sincronizadas (Número de Identificación de las Transacciones BIT11).

Estos son los casos de cómo el POI y el Switch deben usar el número secuencial en cada caso.

  • Flujo de Transacción Normal
    (con cualquier código de respuesta)
  1. Se envía una transacción con BIT11 = x
  2. El POI establece conexión con el Switch y envía los datos del mensaje (BIT11 = x) y el Switch envía los datos del mensaje recibido al POI.
  3. El POI recibe y valida la respuesta correctamente (cualquier valor del BIT39). Después de eso, el POI aumenta su Número de Identificación de la Transacción (BIT11 = x + 1)
  4. El POI cierra la conexión.
  5. Una nueva transacción es enviada con BIT11 = x + 1
  6. El POI establece conexión con el Switch y envía los datos del mensaje (BIT11 = x + 1).
  7. El Switch recibe el Número de Identificación de la Transacción aumentado. De esta manera el Switch verifica que la transacción anterior se ha completado con éxito.
  • Flujo de Cancelación o Tiempo de espera:
  1. Una transacción con BIT11 = x no se completó correctamente y el mensaje de cancelación no se envió.
  2. El POI establece la conexión con el Switch y envía el MGID = 1420 (BIT11 = x)
  3. La respuesta de cancelación no se recibe (tiempo de espera) o su código de respuesta (BIT39) es erróneo.
  4. El POI cierra la conexión.
  5. El Número de Identificación de Transacción del POI no aumenta (BIT11 = x)
  6. El POI establece la conexión con el Switch y envía el mensaje financiero (BIT11 = x)
  7. El Switch evita la transacción porque el POI no aumentó su Número de Identificación de Transacción.

Anexo 3

Para que el Switch pueda identificar una transacción de forma única, se recomiendo que el Switch genere un Número de Referencia único por cada transacción y que el POI lo genere para cada comercio.

El número de referencia se usará como el parámetro de entrara para realizar devoluciones o completar pre-autorizaciones. Este número tiene que ser único durante el periodo de tiempo suficiente para que la solución sea operativa y no se repita para evitar conflictos.

Este es un ejemplo de por qué una transacción no puede ser única si el Número de Referencia lo genera el POI:

Ejemplo:

  1. Un comercio tiene dos POIs y un cliente realiza una venta en el POI 1. Se generarán los siguientes datos:
    • Número de Referencia generado por el POI = 1
    • Importe de la venta = 22,33€
    • Tarjeta del cliente = x
    • Fecha de la transacción = 08/09/2023
  2. El mismo cliente realiza una nueva venta en el POI 2, con la misma tarjeta y en la misma fecha. El Número de Referencia generado por el POI 2 es el mismo. Se generarán estos datos:
    • Número de Referencia generado por el POI = 1
    • Importe de la venta = 55,44€
    • Tarjeta del cliente = x
    • Fecha de la transacción = 08/09/2023
  3. Si el cliente realiza una devolución con la tarjeta x, Número de Referencia 1 y Fecha de la transacción 08/09/2023, el Switch no podrá identificar una transacción única para completar la devolución, ni aunque el importe sea distinto.
  4. El importe no puede ser un parámetro para identificar la transacción porque la devolución o reembolso podría ser parcial (importe inferior al importe original de la transacción).

Anexo 4

La integridad del mensaje se verificará con TLS HMAC o con MAC + TLS HMAC.

Desde la versión 1.22 el MAC es opcional, significa que si los bits 64 o 128 no están presentes dentro del mapa de bits, el switch no lo utilizará durante la comunicación. Desde la versión 1.22 recomendamos no utilizar el cálculo de MAC porque ha quedado obsoleto.

Cuando se use el MAC, todas las peticiones salientes del POI y todas las respuestas entrantes del EP incluirán un campo MAC en BIT 64 o BIT 128 con la única excepción de los mensajes de notificación, en los que no se usa ningún KMAC. Si la clave KMAC no está cargada como ocurre en la inicialización, la clave KAUTH no se usará. Consulta el algoritmo para generar el MAC en el documento «CGP_Security_Overwiew_v0.9».

Los datos usados para generar el MAC en los mensajes salientes / entrantes se extraen de los campos en esta tabla:

BITNombre del campoDescripción
2BINBIN de la tarjeta
3Código de procesoCualificadores adicionales de transacción
4Monto de la transacciónMonto a ser retirado
11Número de ID de la transacciónIdentifica TF como una secuencia N
12 Fecha local de la transacciónFecha y hora local (AAMMDDHHMMSS)
19Código del paísCódigo del país del comercio/terminal
22Modo de entrada del Point of Service (POS/POI)Detalles de la transacción y el terminal (capacidad de captura de datos de la tarjeta, método de captura de datos de la tarjeta, método de autenticación del titular de la tarjeta, …).
25Código de motivoMotivo de la cancelación
30Monto de la divisa localMonto expresado en divisa local
35Datos de tarjetaDatos cifrados de la pista 2 para tarjetas EMV, de banda magnética y sin contacto.
37Número de referenciaNúmero de referencia
38Número de autorizaciónNúmero de autorización
41Identificador de terminalId lógico del terminal
42Identificador del comercioId lógico del comercio
48Información adicional Información adicional de la transacción.
49Código de divisa de la transacciónCódigo de la divisa local usada en la transacción
50Código de divisa de conciliaciónCódigo de divisa de conciliación
51Código de divisa extranjeroCódigo de divisa extranjero
52PinBlockObligatorio si hay verificación de PIN online
72Registro de datosRegistro de datos
Comparte este documento
Tabla de Contenidos

Productos

Ventas

Cuéntanos cómo es tu negocio para ofrecerte la mejor solución.

Contacta con un experto

Soporte técnico

¿Ya eres cliente y necesitas ayuda? Contacta con nosotros, estamos a tu disposición.

Ayuda

Socios

Trabajamos con los mejores partners de soluciones in-store y eCommerce. ¿Quieres unirte?

Únete a nosotros

© Comercia Global Payments

Política de privacidad
Ejercicio de Derechos
Información a Clientes
Canal de denuncia
Aviso Legal
Política de cookies

Cyberpac

Consulta la documentación de Cyberpac. Aquí tienes las distintas secciones:

Canales

Módulos de integración

Integraciones a medida

Consulta la documentación de las distintas secciones de integraciones:

Comienza a integrar

undraw_add_to_cart_re_wrdo 1 (1) (1)

Plugins para CMS

Complementa la integración

SDKs

Métodos de pago

Herramientas

Addon Payments

Consulta la documentación de Addon Payments. Aquí tienes las distintas secciones:

Integraciones

Consultas frecuentes

Portal Backoffice

Pagos integrados en TPV

Crea una solución que te ayudará a automatizar procesos. Incluso, podrás agregar procesos de pago en terminales físicos.

Pago integrado con TPV Android

Pago integrado con Smartphone TPV

Fichas Técnicas TPVs