VTOL CRÉDITO DÉBITO ARGENTINA

Mensajería POS - VTOL

Cambios por revisiones

Fecha	Revisión	Cambios
02/11/2009	1.0	Generación del documento
04/11/2009	1.1	Indicación de campos obligatorios
26/04/2010	1.2	Actualización de gráfico manejo de PINPAD
22/03/2011	1.3	Incorporación mensajes MembershipQuery y VoidMembershipQuery para consulta membresía Club Personal y Club La Nación
03/06/2011	1.4	Agregado de definición de mensaje de cierre de lote
30/05/2012	1.5	Agrego Tabla de Respuestas al POS y mejoro explicación de Tercer Mensaje y Chequeo de Pendientes.
08/03/2013	1.6	Agrego nuevos campos relacionados con operador y vendedor en operaciones de pre-autorización, venta, devolución y anulación. Nuevo mensaje para consulta de configuración 'PosConfQuery'.
21/08/2013	1.7	Agregado de apartado de error del core.
09/09/2013	1.8	Agrego campos EMV en operaciones de Venta, Devolución y anulación. Incorporo mensaje RejectedEMVAdvice y flujo de datos EMV.
15/11/2013	1.9	Agregado de 'Formato Interface POS'
23/12/2013	2.0	Agregado de detalle de los mensajes ServicePayment y VoidServicePayment
13/02/2014	2.1	Agregado del campo bandera '164 – posEncryptedFields', que indica cuando los datos sensibles viajan encriptados.
29/05/2014	2.2	Aclaración sobre el uso de pre-autorizaciones.
22/08/2014	2.3	Agregado de campo pinpadAutoCode en Tercer Mensaje y RejectedEMVAdvice.
29/08/2014	2.4	Actualización del Formato Interface POS, agregando el campo 'Tarjeta que Encripta' a los prefijos.
11/09/2014	2.5	Incorporación de Bines de Excepción y nuevo mensaje CardInfoService.
09/12/2014	2.6	Agregado de mensaje de Anulación de Pre Autorización.
26/02/2015	2.7	Agregado de nuevos campos ServiceCode y ProviderPosCode.
27/02/2015	2.8	Agregado de nuevos mensajes propios a la funcionalidad Cash Back.
07/08/2015	2.9	Agregado de aclaraciones en el uso de la mensajería
09/09/2015	3.0	Incorporación de campo PinpadApplicationVersion en los mensajes Sale, VoidSale, Refund y VoidRefund
30/10/2015	3.1	El campo ProviderPosCode para a ser el número 147. Incorporación de campo trxReferenceNumber en las respuestas de VTOL. Corrección de formato esperado en campo 7 - Expiration. El formato correcto es: YYMM.
11/02/2016	3.2	Incorporación del campo 201 additionalMessageData en el requerimiento y respuesta y la posibilidad de incluir el número de Ticket original en una anulación (Campo 17 originalTrxTicketNr)
29/07/2016	3.3	Incorporación del apartado 1.9. Mecanismo en Tiendas Virtuales y del 1.3.13. Chequeo de Listado de Pendientes
19/04/2017	3.4	Actualización de la tabla Prefijo en el apartado Formato Interface POS
03/05/2017	3.5	Incorporación del apartado 1.3.10 Echo
05/05/2017	3.6	Incorporación del apartado 1.3.9 SynQuery y de la sección 1.7 Formato Datos Sincronización
06/06/2017	3.7	Actualización de la tabla Prefijo en el apartado Formato Interface POS. Mayor detalle del campo MasterKey Position, incluyendo el valor 99
07/07/2017	3.8	Agregado del campo promocional en Formato Interface POS para indicar que se aplica una promoción sobre un plan de pago
04/09/2018	3.9	Incorporación de la funcionalidad PEI en la mensajería
14/12/2018	4.0	Incorporación del apartado Antifraude e incorporación de la funcionalidad Antifraude en la mensajería
08/02/2019	4.1	Incorporación del apartado Tokenización e incorporación de la funcionalidad Tokenización en la mensajería
03/04/2019	4.2	Agregado del campo 0 (Compañía) en la mensajería de todos los tipos de transacciones.
28/082019	4.3	Incorporación de la funcionalidad Billeteras electrónicas en la mensajería.

Índice

1. Campos de los mensajes

1.1 Conexión con VTOL Server

VTOL Server expone únicamente una comunicación SSL del tipo servidor, por defecto en el puerto 3003. Esta comunicación utiliza Protocolo TLSv1.2 e intercambio de certificado de seguridad.
Para poder conectarse al servidor, la implementación de la comunicación Cliente debe crear un Socket SSL con el puerto 3003, teniendo en cuenta las siguientes propiedades de conexión:

Parámetro	Descripción
IP de VTOL Server	IP donde se encuentra VTOL Server.
Puerto SSL de VTOL Server	Es el puerto SSL sonde escucha VTOL Server. Valor por defecto: 3003
Almacén de certificados del servidor	Ruta donde se encuentra el almacén de certificados con los certificados del servidor.
Contraseña para acceder al almacén de certificados	Contraseña para acceder al almacén de certificados.
Algoritmo del almacén de certificados	Algoritmo del manejador del almacén de certificados. Valor por defecto: SunX509
Tipo de almacén de certificados	Indica el tipo de almacén de certificados. Valor por defecto: JKS

1.1.1 Ejemplo Comunicación Cliente SSL en JAVA

A continuación se puede ver un ejemplo de cómo crear una conexión cliente con VTOL Server a través de un socket SSL, teniendo en cuenta las propiedades mencionadas.

/**
* Create a connection with VTOL server using a client SSL socket
* @return a SSLSocket connected with VTOL Server
* @throws Exception
*/

public SSLSocket connectToVTOLServer() throws Exception {

try{

long init = System.currentTimeMillis();

/////////////////////////////////////////////////////////////////////////////////

// create de SSL Context

/////////////////////////////////////////////////////////////////////////////////

KeyStore keyStore = KeyStore.getInstance("JKS");

String keyStorePass = this.keyStorePassword; // key store password

keyStore.load(new FileInputStream(this.keyStorePath),keyStorePass.toCharArray()); //key store file

// Create key manager

KeyManagerFactory keyManagerFactory = KeyManagerFactory.getInstance("SunX509");

keyManagerFactory.init(keyStore, keyStorePass.toCharArray());

KeyManager[] km = keyManagerFactory.getKeyManagers();

// Create trust manager

TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance("SunX509");

trustManagerFactory.init(keyStore);

TrustManager[] tm = trustManagerFactory.getTrustManagers();

// TLSv1.2 Supports RFC 5246: TLS version 1.2 ; may support other versions

String protocol = (sslProtocol != null) ? sslProtocol : "TLSv1.2";

SSLContext sslContext = SSLContext.getInstance(protocol);

// Initialize SSLContext

sslContext.init(km, tm, null);

// Create socket factory

SSLSocketFactory sslSocketFactory = sslContext.getSocketFactory();

// Create socket with VTOL Server

SSLSocket sslSocket = (SSLSocket) sslSocketFactory.createSocket(this.hostIP, 3003);

sslSocket.setSendBufferSize(400);

sslSocket.setEnabledCipherSuites(sslSocket.getSupportedCipherSuites());

// Start handshake

sslSocket.startHandshake();

// Get session after the connection is established

SSLSession sslSession = sslSocket.getSession();

System.out.println("SSLSession. Protocol: "+ sslSession.getProtocol() + " Cipher suite: " + sslSession.getCipherSuite());

System.out.println("SSL client started Time: " + (System.currentTimeMillis() - init) + " milliseconds.");

return sslSocket;

} catch (Exception exception) {

throw new Exception("Error conectandose al host.\n" + exception.getMessage());

}

1.2 Protocolo de comunicación POS – VTOL Server

Synthesis establece un protocolo de comunicación para la interacción POS - VTOL, el cual se denomina "Protocolo VTOL". Dicho protocolo se basa en un esquema recursivo compuesto por campos y separadores. A continuación se provee una especificación detallada de su estructura junto con los consecuentes diagramas para un mejor entendimiento.
Para implementar esta mensajería, VTOL provee una librería en el cual se encuentra la declaración de funciones y las definiciones de constantes y tipos necesarias. La librería es en realidad un módulo cliente que se comunica vía TCP/IP con el servidor de transacciones VTOL. El cliente podrá implementar esta mensajería sin utilizar la librería, pero deberá respetar el formato de la misma.
El formato del protocolo VTOL se basa en la siguiente estructura:

Header		Mensaje
Longitud del mensaje (4 bytes)	Indica si el mensaje requiere respuesta o no (2 bytes)	Ejemplo: {25:20020426172836;1:5;2:1;27:00;26:ISO8583;28:Aprobado}

La estructura posee dos partes separadas que son el Header y el Mensaje propiamente dicho.

1.2.1 Header

Dentro del Header viaja información específica del mensaje que se encuentra a continuación del mismo, como ser su longitud y si requiere o no una respuesta. Para ello fueron destinados 6 bytes que se distribuyen de la siguiente manera: los primeros 4 bytes son destinados a la longitud (expresado en hexadecimal, con el último byte como el más significativo) y los últimos 2 indican la necesidad de recibir o no una respuesta (expresado en hexadecimal, con el último byte como el más significativo)
Longitud máxima representable por medio de este protocolo: 2047 MB (Mega Bytes) (cantidad máxima representable por un entero: 2147483647 bytes)
Un ejemplo de lo explicado anteriormente podría ser el siguiente:

HEADER
Longitud del mensaje	Requiere respuesta
A101	01

En este ejemplo la longitud del mensaje será:

0001 0000 0001 1010
1 0 1 A = 2¹² + 2⁴ + 2³ + 2¹ = 4122

NOTA: Se ordena la longitud A101 colocando el byte más significativo a la izquierda, con lo cual resulta: 101A.

1.2.1.1 Creación del Header

Ejemplo 1: Mensaje de 268 bytes de datos

Longitud (268) representada binario: 100001100, tiene 9 bits por lo tanto un byte no alcanza.

El header se representa en un arreglo de bytes, donde los primeros 4 bytes indican la longitud del área de datos:

byte[0] = longitud & 0xFF = 100001100 & 11111111 = 00001100 = 12

byte[1] = longitud >> 8 & 0xFF = 00000001 & 11111111 = 00000001 = 1 (>> 8 significa desplazar los bits 8 posiciones a la derecha)

byte[2] = longitud >> 16 & 0xFF = 00000000 & 11111111 = 00000000 = 0 (>> 16 significa desplazar los bits 16 posiciones a la derecha)

byte[3] = longitud >> 24 & 0xFF = 00000000 & 11111111 = 00000000 = 0 (>> 24 significa desplazar los bits 24 posiciones a la derecha)

Los últimos dos bytes indican si requiere respuesta. Ejemplo de un mensaje que requiere respuesta:

byte[4] = 0

byte[5] = 1

Header		Mensaje
Longitud del mensaje (4 bytes)	Indica si el mensaje requiere respuesta o no (2 bytes)	Campos de la operación con sus valores {campo1:valor1;campo2:valor2;…;campo3:valor3}

Finalmente sería:

Header completo: {12, 1, 0, 0, 0, 1}

Ejemplo 2:

El mensaje de “CheckPending” enviado a VTOL Client, tiene una longitud de datos de 43 bytes: {25:20161021172545;2:1;1:1;11:CheckPending}

43 en binario: 101011 tiene menos de 8 bytes, la longitud puede expresarse completamente en el 1er. byte del arreglo:

byte[0] = longitud & 0xFF = 00101011 & 11111111 = 00101011 = 43

byte[1] = longitud >> 8 & 0xFF = 00000000 & 11111111 = 00000000 = 0 (>> 8 significa desplazar los bits 8 posiciones a la derecha)

byte[2] = longitud >> 16 & 0xFF = 00000000 & 11111111 = 00000000 = 0 (>> 16 significa desplazar los bits 16 posiciones a la derecha)

byte[3] = longitud >> 24 & 0xFF = 00000000 & 11111111 = 00000000 = 0 (>> 24 significa desplazar los bits 24 posiciones a la derecha)

Header completo indicando que requiere respuesta: {43, 0, 0, 0, 0, 1}

Hexa DUMP del mensaje:

00000: 2b 00 00 00 00 01 7b 32 35 3a 32 30 31 36 31 31 |,.....{25:201611|

00010: 31 37 32 31 30 38 30 32 3b 32 3a 31 3b 31 3a 31 |17210802;2:1;1:1|

00020: 3b 31 31 3a 43 68 65 63 6b 50 65 6e 64 69 6e 67 |;11:CheckPending|

00030: 7d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |}...............|

1.2.1.2 Lectura del Header

Ejemplo: Mensaje de 268 bytes de datos.

Header completo {12, 1, 0, 0, 0, 1}

Para obtener la longitud de los datos enviados en el mensaje se toman los primero 4 bytes y se aplica la siguiente lógica:

byte[0] = 00001100 & 0xFF = 00001100 & 11111111 = 00101100 = 12

byte[1] = 00000001 & 0xFF << 8 = 00000001 & 11111111 = 00000001 << 8 = 1 00000000 = 256 (<< 8 significa desplazar los bits 8 posiciones a la izquierda)

byte[2] = 00000000 & 0xFF << 16 = 00000000 & 11111111 = 00000000 << 16 = 0 00000000 00000000 = 0 (<< 16 significa desplazar los bits 16 posiciones a la izquierda)

byte[3] = 00000000 & 0xFF << 24 = 00000000 & 11111111 = 00000000 << 24 = 0 00000000 00000000 00000000 = 0 (<< 24 significa desplazar los bits 24 posiciones a la izquierda)

Longitud obtenida a partir del arreglo de butes: 12 + 256 + 0 + 0 = 268

1.2.2 Mensaje

A continuación del Header se encuentra el Mensaje propiamente dicho, el cual contiene la información que el emisor desea transmitirle al sistema receptor.
Existen dos opciones para la estructura del Mensaje, las cuales se presentan a continuación:

Simple

El mensaje viajará encerrado entre "{ }" (llaves). Cada campo del mismo se compondrá de la siguiente manera: los primeros dígitos indicarán el número de campo y a partir de los ":" (dos puntos) se encontrará el valor del campo. Los campos viajan separados por ";" (punto y coma).

Ejemplo:

{1:5;2:1;26:ISO8583;27:00;28:Aprobado}

El mensaje anterior posee 5 campos, los cuales se identifican con los números 1, 2, 26, 27 y 28. A continuación de cada uno de ellos (luego del separador ":") se encuentra el valor de cada campo. En el ejemplo presentado, para el campo 1 el valor es "5", para el campo 2 el valor es "1" y así sucesivamente.

1.2.3 Escape de caracteres

Para realizar el escape de un caracter especial se deberá usar "\" inmediatamente antes del carácter a escapar.

Ejemplo:
A continuación se presenta un campo cuyo valor incluye el caracter ; y se muestra como escapar el mismo: {1:14\;56}

1.3 Mecanismo de "Tercer Mensaje"

1.3.1 Descripción

VTOL es un intermediario entre el POS y el Centro Autorizador. Cuando VTOL responde al POS un requerimiento a partir de la información recibida desde el Centro Autorizador, el mismo desconoce la interacción que se está teniendo entre el cliente y el operador y los problemas técnicos que pueda tener el POS (impresora, enlaces, etc). Es necesario cargar al POS con la responsabilidad de confirmar a VTOL cómo terminó la transacción, pudiéndose confirmar o reversar. Para ello existe el Tercer Mensaje del POS a VTOL.
Por lo tanto, el tercer mensaje es un mecanismo para asegurar la consistencia y concordancia de las transacciones realizadas que son registradas en VTOL.
A fines de simplificar el esquema de comunicación, suponiendo que el Centro Autorizador aprueba el requerimiento de VTOL, el flujo de mensajes entre el POS y VTOL es el siguiente:

El POS envía un requerimiento de autorización a VTOL.
VTOL responde al POS que el requerimiento fue autorizado y envía el ID de la transacción.
El POS informa a VTOL con el Tercer Mensaje si la transacción se debe confirmar o reversar (COMMIT / ROLLBACK)

Dicho esquema requiere que cada transacción aprobada deba ser confirmada o reversada con un tercer mensaje. Si VTOL responde al POS con la aprobación de una transacción y no se confirma o reversa, a la próxima transacción que el POS envíe VTOL responderá que aún existe una transacción pendiente y hasta que no se envíe el tercer mensaje correspondiente no se podrá tratar la transacción en curso.

El tercer mensaje puede enviarse embebido en un requerimiento. Así en una misma transacción se enviará un requerimiento y la confirmación o reverso de una transacción pendiente.
No siempre cada transacción en el POS se corresponde con un único pago electrónico. Una operación de venta en el POS podría tener una o más transacciones de pago electrónico validadas por intermedio de VTOL. En dicho escenario, para el envío del tercer mensaje debe establecerse una condición por la que se da por finalizada la venta en el POS. Esta condición podría ser el registro de la transacción o la impresión del comprobante, pero se deberá tener en cuenta que para confirmar una transacción, VTOL se tiene que asegurar que la venta que contiene esa transacción sea procesada por el POS, que se emitan los comprobantes correspondientes, etc.
Por otro lado, si la venta en el POS se registra como anulada o directamente no se registra (ya sea por pedido del operador, o por problemas técnicos) se debe asegurar que en el tercer mensaje de las transacciones correspondientes vaya la orden de ROLLBACK para esta transacción.

1.3.2 Control de operaciones pendientes (mensaje "CheckPending")

Los mensajes de confirmación no son respondidos por VTOL. Además estos mensajes pueden ser embebidos en futuros mensajes de pedido de autorización, lo que da lugar a que algunas operaciones queden pendientes de confirmación entre dos transacciones distintas. El cierre o la eventual caída del punto de venta podrían ocasionar dicha contingencia ya que no existiría un futuro mensaje de confirmación o pedido de autorización con la confirmación embebida.
Ante esta problemática, el esquema de comunicación entre el POS y VTOL posee un mecanismo para asegurar que ninguna transacción quede pendiente de confirmación en VTOL. El mecanismo consta de los siguientes pasos:

El punto de venta envía un mensaje de chequeo de pendientes "CheckPending" a VTOL. Para ello, el mensaje debe contar con el siguiente campo: 71:True.

2. VTOL verificará la existencia de transacciones pendientes y en caso de existir responderá con un mensaje que, entre otros campos, tendrá los siguientes:

Campo 24: ID de la Transacción pendiente.

Campo26: TrxIsPending.

3. El punto de venta envía la confirmación de dicha transacción (Commit/Rollback) y envía un nuevo mensaje de chequeo de pendientes. Esto se podría realizar en un solo paso, enviando un mensaje de chequeo de pendientes con la confirmación embebida.

4. Se deberá repetir el proceso hasta tanto existan transacciones pendientes en VTOL. Cuando ya no existan VTOL responderá APROBADA.

1.3.3 Tercer Mensaje con múltiples operaciones

También existe la posibilidad de deshabilitar el chequeo de pendientes (Campo 71:False). Esto permite realizar un conjunto de transacciones que podrán ser confirmadas o reversadas posteriormente haciendo que VTOL se dedique a la transacción en curso. Por ejemplo:

IMPORTANTE: La implementación del Tercer Mensaje y Mensajes de Control de Pendientes, dependerá del tipo de integración que se realiza en el Punto de Venta, y quedará a elección del cliente utilizar algunos, o todos los Mensajes descriptos.

1.4 Transacciones permitidas

En esta sección se detallarán las transacciones soportadas por VTOL así como los campos requeridos u opcionales de cada transacción.

1.4.1 Venta / Pre-autorización / Anulación / Anulación Pre-autorización / Cash Back / Anulación Cash Back

1.4.1.1 Requerimiento

#	FieldId	Tipo	Obligatorio	Descripción
0	company	Numérico	SI	Identificador de la compañía donde se generó la transacción
1	store	Alfanumérico	SI	Identificador del sitio originador de la transacción
2	node	Numérico	SI	Identificación del nodo, en el sitio originador, donde se generó la transacción
3	server	Alfanumérico	Compatibilidad atrás.	Identificador del Server que procesará la transacción. ('VTOL')
4	messageType	Alfanumérico	Compatibilidad atrás.	Tipo de Mensaje: Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server. Data = Mensaje de la Aplicación cliente.
6	cardNumber	Numérico	Obligatorio si es Manual	Número de tarjeta. Sólo presente si el modo de ingreso fue Manual.
7	expiration	Numérico	Obligatorio si es Manual	Formato YYYYMM Fecha de vencimiento de la tarjeta. Sólo presente si el modo de ingreso fue Manual.
8	Cvc	Numérico	Obligatorio si es Manual. Además es opcional según la tarjeta.	Código de seguridad de la tarjeta. Sólo presente si el modo de ingreso fue Manual.
9	track2	Alfanumérico	Obligatorio si es MSR	Track2 de la tarjeta entero (se envía todo el contenido del track2 en este campo) Este campo sólo está presente si la banda magnética / chip de la tarjeta pudo ser leído.
10	posInputMode	Alfanumérico	Obligatorio	Modo de Ingreso: MSR = Ingreso por banda magnética Manual = Ingreso manual Chip = EMV Chip MSR Chip = Fallback
11	trxType	Alfanumérico	Obligatorio	Tipo de Transacción: Sale = Compra. Opcionalmente puede acompañarse con una extracción de efectivo (CashBack) cuando se envía el campo monto adicional. PreAuthorization = Preautorización VoidSale= Anulación de venta. Opcionalmente puede acompañarse con una Anulación de extracción de efectivo, enviando el monto en el campo monto adicional. VoidPreAuthorization = Anulación de Preautorización. VoidRefund = Anulación de devolución CashBack = Extracción de efectivo solamente. NO incluye una Compra. VoidCashBack = Anulación de extracción de efectivo (No incluye una Compra).
12	amount	Importe	Obligatorio	Monto de la transacción. 12 dígitos como máximo. Se envía sin coma. Los dos últimos dígitos representan los decimales. Ej: 1000 equivale a 10.00
13	currencyPosCode	Alfanumérico	Obligatorio	Tipos de Moneda: $ = Pesos U$S = Dólares
14	payments	Numérico	Obligatorio	Cantidad de cuotas. 2 dígitos como máximo.
15	plan	Alfanumérico	Obligatorio	Plan. 1 caracter de longitud.
17	originalTrxTicketNr	Numérico	Opcional	Este campo es Opcional. Si viaja se debe precisar el número de ticket de la venta original para poder distinguir la transacción a anular. Se trata del número de ticket de la transacción original. 4 dígitos como máximo.
18	referedSale	Numérico	Condicional a tarjeta AMEX	Se usa para indicar si una venta se hizo de forma referida. SOLO para AMEX. Se debe encender este campo con el valor 1.
22	authorizationCode	Alfanumérico	Condicional a si fue realizada la autorización telefónica.	Código de autorización telefónica. 6 dígitos como máximo. Este campo se encuentra presente sólo si la transacción se autorizó off-line por teléfono.
23	authorizationMode	Alfanumérico	Opcional, default = Online	Modo de Autorización: Online = La autorización fue realizada por el Centro Autorizador. Offhost = La autorización fue realizada internamente por VTOL. Offline = La autorización fue realizada localmente por el POS.
25	dateTime	Numérico	Obligatorio	Fecha de generación de la trx en el POS. Formato YYYYMMDDHHmmss
53	paymentCondition	Alfanumérico	Opcional	Condición de pago. Sólo se encuentra presente si existe una condición de pago vinculada con la transacción.
54	additionalAmount	Alfanumérico	Opcional CASH BACK	Contiene el Importe del "Cash Back". Se usa en transacciones del tipo CashBack o Sale + CashBack. Debe contener 12 dígitos como máximo
56	pinblock	Alfanumérico	Condicional a PINPAD	PIN encriptado. Se emplea para tarjetas que tienen PIN. Ejemplo pinblock: D76484D688FE1826
57	accountType	Alfanumérico	Condicional a tarjeta de débito	Campo que se emplea para identificar el tipo de cuenta (ej: cta cte en pesos) Se usa para tarjetas de débito. Los valores posibles son: 1 = Caja de ahorros en pesos 2 = Cuenta corriente en pesos 3 = Caja de ahorros en dólares 4 = Cuenta corriente en dolares
66	track1	Alfanumérico	Opcional a su lectura	Track1 de la tarjeta entero (se envía todo el contenido del track1 en este campo) Este campo sólo está presente si la banda magnética / chip de la tarjeta pudo ser leído.
70	effectiveDate	Alfanumérico	Opcional AMEX	Fecha efectiva. Se usa para AMEX con formato yyMM
71	checkPendingString	Alfanumérico	Opcional, default = true	Indica si VTOL debe o no efectuar el chequeo de pendientes (se emplea para pagos parciales de tarjetas): true = activa chequeo de pendientes. false = desactiva chequeo de pendientes.
72	creditCardCondition	Alfanumérico	Opcional	Es una cadena de 3 de largo donde se indica una condición de la tarjeta. Se usa para las tarjetas regionales o propias donde los prefijos se superponen. Este valor es identificable en el TrackI de la tarjeta y si es manual se le pregunta al cajero.
73	interestAmount	Alfanumérico	Opcional	Este campo es por si se necesita enviar el monto de los intereses en el mensaje a Autorizar. Normalmente el monto que llega del POS ya contiene los intereses en el caso de pagar en cuotas. Existe algún caso de alguna tarjeta especial donde el monto hay que enviarlo libre de intereses y justamente el monto de los intereses viaja en este campo.
74	requestAccountNumber	Alfanumérico	Opcional, default = 0	Indica si puede recibir el número de cuenta (Visa y Posnet). Valores posible: 1 = activado 0 = desactivado
101	differDate	Alfanumérico	Opcional	Fecha diferida. Solo utilizada para AMEX.
102	chipTokens	Alfanumérico	Obligatorio para modo de ingreso Chip	Visa: Criptograma tarjetas EMV Posnet: Lista de Tags EMV
103	emvEncryptedType	Alfanumérico	Opcional	Tipo de encriptación utilizada entre Pinpad y Host Autorizador. Los campos 103, 104, 108 y 137 deben ser utilizados en conjunto. Valores posibles: D = DES T = 3DES
104	emvEncryptedData	Alfanumérico	Opcional	Paquete encriptado devuelto por el pinpad y que se enviará al Host Autorizador. Los campos 103, 104, 108 y 137 deben ser utilizados en conjunto.
105	cardSequenceNumber	Numérico	Opcional	Numero de secuencia del PAN
106	pinpadLogSerialNumber	Alfanumérico	Opcional	Número de serie lógico del pinpad
107	pinpadFisSerialNumber	Alfanumérico	Opcional	Número de serie Físico del pinpad
108	useEncryptedData	Alfanumérico	Opcional	Indica si se utiliza encriptación entre Pinpad y Host Autorizador (Visa, Posnet, etc). Los campos 103, 104, 108 y 137 deben ser utilizados en conjunto. Valores posibles: false = No se utiliza encriptación true = Se utiliza encriptación
118	terminalCapability	Alfanumérico	Opcional	Capacidad de captura. Valores 1 = Manual / 2 = Lectura de Banda / 5 = Lectura de Chip
130	posPeriod	Numérico	Opcional	Periodo enviado por el POS. Longitud 5
131	turn	Numérico	Opcional	Turno. Longitud 2
132	operatorCode	Alfanumérico	Opcional	Código de operador. Longitud 20
133	operatorName	Alfanumérico	Opcional	Nombre de operador. Longitud 50
134	sellerCode	Alfanumérico	Opcional	Código del vendedor. Longitud 20
135	sellerName	Alfanumérico	Opcional	Nombre del vendedor. Longitud 50
136	attentionMode	Alfanumérico	Opcional	Modalidad de atención (AU ó AS). Longitud 2
137	serviceCode	Numérico	Opcional	Código de Servicio, se envía cuando el mensaje esta encriptado (campo 108=true) y no se tiene acceso al Track2. Longitud 3. Los campos 103, 104, 108 y 137 deben ser utilizados en conjunto.
147	providerPosCode	Alfanumérico	Opcional	Código del Provider. Se utiliza en los casos donde VTOL Server no puede obtener unívocamente el Proveedor utilizando los prefijos (debido enmascaramiento de la tarjeta). Ejemplo VI (Visa). Longitud 20.
164	posEncryptedFields	Numérico	Opcional	Indica si se utiliza encripción entre Pinpad y VTOL (modo RSA). En este caso los datos sensibles se envían encriptados. Si está activo, los campos a enviar encriptados son: 6, 8, 9, 66 Valores posibles: 1 = activado 0 = desactivado (valor por defecto).
168	pinpadApplicationVersion	Alfanumérico	Opcional	Versión de la aplicación del software del PinPad
201	additionalMessageData	Alfanumérico	Opcional	Este campo tiene como finalidad que el POS, o cliente VTOL, pueda enviar un dato X y que el mismo esté presente en la respuesta. Cada módulo según implementación puede decidir qué hacer con dicho dato (Ejem Persistir en BBDD)
263	vtolToken	Alfanumérico	Opcional	Cuando se efectúa una transacción Sale, VoidSale, Refund o VoidRefund tokenizada, se puede enviar el Token VTOL
264	posChannelOrigin	Numérico	Opcional	Indica el canal de origen de la transacción. Es un código con los siguientes valores posibles: 0: Presencial 1: E-Commerce 2: Pago recurrente 3: IVR
266	cardHolderName	Alfanumérico	Opcional	Nombre del tarjetahabiente
270	posTicket	Alfanumérico	Opcional	Información del ticket en formato xml y posteriormente transformado en Base 64. Ver sección Estructura del campo posTicket
280	user	Alfanumérico	Opcional	Nombre de usuario que realizó la transacción
281	userIp	Alfanumérico	Opcional	IP de origen de donde se efectuó la transacción

1.4.1.1.1 Estructura del campo posTicket

El mensaje con la estructura del ticket estará en XML. El elemento raíz de ese mensaje XML deberá ser la etiqueta <message>, siendo la misma lo que se llamará encabezado.

La manera de ejecutar un comando es utilizando una etiqueta con la forma <elemento-comando>. El elemento "item" identifica a los artículos. De esta manera, si se desea, por ejemplo, agregar un nuevo artículo el comando a utilizar será <item-add>. En el cuerpo del mensaje podrá contener uno, ninguno o varios de estos comandos.

Cada uno de los comandos que se envían posee diversos atributos, los cuales identifican al elemento que se está enviando y definen diversas propiedades que poseen los mismos. Poseerá un número de secuencia, el cual identifica cada elemento unívocamente:

Propiedad	Tipo de dato	Descripción	Requerido
*seq*	Entero positivo	Número identificador único del elemento dentro de la transacción.	Sí

Cada comando posee una serie de atributos que definirán las distintas propiedades del elemento que se está agregando (además del número de secuencia antes mencionado).

Para el elemento ítem, los atributos serán los siguientes:

Elemento	Atributo	Tipo de dato	Descripción	Requerido	Valor ante ausencia
Ítem	*unitprice*	Numérico positivo	Precio unitario del artículo en cuestión.	Si
	*xprice*	Numérico positivo	Precio extendido del artículo en cuestión. Es igual a la cantidad por el precio unitario.	Si
	*qty*	Entero positivo	Cantidad de artículos en la línea.	Si
	*magnitude*	Numérico positivo	Si el artículo es mensurable por otro unidad que no sea la cantidad, deberá ser expresad en esta propiedad.	No	0
	*code*	Alfanumérico	Código propio del artículo.	No	"-"
	*brand*	Alfanumérico	Marca del artículo.	No	"-"
	*supplier*	Alfanumérico	Proveedor al que pertenece el artículo.	No	"-"
	*discountable*	Alfanumérico	Si el artículo es puede recibir descuentos o no.	No	"-"
	*level1*	Alfanumérico	Nivel 1 de categorización del artículo. Anteriormente este nivel se conocía con el nombre de Departamento.	No	"-"
	*level2*	Alfanumérico	Nivel 2 de categorización del artículo. Anteriormente este nivel se conocía como la Familia del artículo.	No	"-"
	*level3*	Alfanumérico	Nivel 3 de categorización del artículo. Anteriormente este nivel se conocía como la Categoría del artículo.	No	"-"
	*level4*	Alfanumérico	Nivel 4 de categorización del artículo. Anteriormente este nivel se conocía como la subcategoría del artículo.	No	"-"
	description	Alfanumérico	Descripción del ítem	Si
	currency	Alfanumérico	Moneda utilizada en el precio del ítem Nota: En el punto de venta se deberá informar la moneda de la cuenta vendedor de Mercado Pago (si el retailer posee una cuenta argentina en Mercado Pago entonces tendrá que informar la moneda $ -pesos argentinos-).	Si

Ejemplo

Importante: Esta estructura generada debe transformarse al formato Base 64 para informárselo a VTOL en el campo 270 posTicket.

1.4.1.2 Respuesta

#	FieldId	Tipo	Descripción
0	company	Numérico	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	Identificador del sitio originador de la transacción
2	node	Numérico	Identificación del nodo, en el sitio originador, donde se generó la transacción
22	authorizationCode	Alfanumérico	Código de autorización generado por el centro autorizador para la transacción.
23	authorizationMode	Alfanumérico	Modo de Autorización: Online = La autorización fue realizada por el Centro Autorizador. Offhost = La autorización fue realizada internamente por VTOL. Offline = La autorización fue realizada localmente por el POS.
24	lastTrxId	Numérico	Id de transacción. En caso que el Campo 26 sea TrxIsPending, contendrá el trxId de la transacción pendiente.
25	dateTime	Numérico	Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS.
26	responseCode	Alfanumérico	Puede contener uno de los siguientes valores: Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27 Error = ver sección Código de errores del CORE TrxIsPending: indica si existen transacciones pendientes de confirmar. En este caso, el ID de transacción a confirmar está en el campo 24.
27	isoCode	Numérico	Código de Respuesta ISO-8583 emitido por el centro autorizador. 2 dígitos como máximo
28	responseMessage	Alfanumérico	Mensaje de la Respuesta ISO-8583
29	serialNumber	Numérico	Número identificatorio de la terminal en la que se procesó la transacción.
30	businessNumber	Numérico	Número de comercio en el que se procesó la transacción.
31	lotNumber	Numérico	Número de lote en el que se registró la transacción
32	ticket	Numérico	Número de Ticket correspondiente a la transacción. 4 dígitos como máximo.
33	creditCardIssuerName	Alfanumérico	Nombre del Centro emisor de la tarjeta
34	hostName	Alfanumérico	Nombre del canal por el cual se autorizó la tarjeta.
35	errorDescription	Alfanumérico	Descripción de error. Sólo se encuentra presente si el valor del campo 26 es "Error".
42	lotDefinitionId	Numérico	Identificador de la definición de lote.
58	workingKey	Alfanumérico	VTOL devuelve este campo tal como lo entrega el CA. Representa la llave que el PINPAD deberá usar para generar el PINBLOCK en la próxima transacción.
68	rrn	Numérico	Reference referral number.
75	accountNumber	Alfanumérico	Número de cuenta. Este campo es devuelto si el campo 74- requestAccountNumber fue activado en el requerimiento. Longitud 28.
81	responseAuth	Alfanumérico	Mensaje de repuesta para ser mostrado en el diplay del POS donde se indican promociones. También es utilizado en la operación de Cash Back, cuando el autorizador responde con código de respuesta 98. En este campo se informará el importe máximo que puede solicitarse.
82	softwareVersion	Alfanumérico	Versión de la aplicación.
102	chipTokens	Alfanumérico	En las respuestas hacia el POS se actualiza con el valor que envió el CA
110	requeredAdvice	Alfanumérico	Con valor true si se requiere que se envíe el advice para la autorización. En este caso la terminal lógica queda en estado AdvicePending.
130	posPeriod	Numérico	Periodo enviado por el POS. Longitud 5
131	turn	Numérico	Turno. Longitud 2
132	operatorCode	Alfanumérico	Código de operador. Longitud 20
133	operatorName	Alfanumérico	Nombre de operador. Longitud 50
134	sellerCode	Alfanumérico	Código del vendedor. Longitud 20
135	sellerName	Alfanumérico	Nombre del vendedor. Longitud 50
136	attentionMode	Alfanumérico	Modalidad de atención (AU ó AS). Longitud 2
165	publicKey	Alfanumérico	Clave Pública utilizada en la encripción punto a punto POS - VTOL. Viaja cuando la clave expiró y se generó una nueva; o bien, cuando es necesario sincronizar claves entre POS y VTOL.
166	trxReferenceNumber	Numérico	Identificador único de la transacción en VTOL Server. Longitud entre 19 y 20 dígitos, debido a que utiliza el día como parte de formato.
201	additionalMessageData	Alfanumérico	Este campo tiene como finalidad que el POS, o cliente VTOL, pueda enviar un dato X y que el mismo esté presente en la respuesta. Cada módulo según implementación puede decidir qué hacer con dicho dato (Ejem Persistir en BBDD).
263	vtolToken	Alfanumérico	Cuando se efectúa una transacción Sale, VoidSale, Refund o VoidRefund tokenizada, se puede recibir el Token VTOL
267	vtolTokenExpire	Numérico	Fecha y hora de expiración del Token VTOL en formato YYYYMMDD

1.4.1.3 Pre-autorización

La pre-autorización es utilizada para validar y reservar un saldo de una tarjeta en vías de asegurarse que se podrá saldar la transacción de productos que primero se consumen y luego se pagan siendo difícil o imposible devolverlos en caso de no haber saldo.
Ejemplos en donde se podría utilizar éste tipo de transacción es el despacho de combustible, pago en restaurants con propina, etc.
El flujo normal de ésta operatoria es el siguiente:

Se realiza una pre-autorización por un monto X.
1. Se debe almacenar el código de autorización recibido en la respuesta
Se lleva a cabo la venta de los productos
finalizada la venta se procede a realizar una venta por el momento exacto e incorporando el código de autorización recibido en el paso 1. El sistema aprobará automáticamente ésta transacción.

1.4.1.4 Anulación de Pre-autorización

La anulación de Pre-Autorización sirve para anular completamente una Pre-autorización realizada previamente. Dado el caso de que un cliente se arrepienta de realizar la compra, por ejemplo, en una estación de servicio el cliente se arrepiente de cargar combustible, en este caso ,es necesario realizar una anulación de la Pre autorización para que el monto retenido por la pre autorización sea devuelto al cliente.
El flujo normal de ésta operatoria es el siguiente:

Se realiza una pre-autorización por un monto X.
Por algún motivo, como el expuesto mas arriba, es necesario anular la pre-autorización y reintegrar el monto retenido al cliente. Mientras se esté en el mismo periodo que la operación original, se puede enviar el mensaje de anulación de pre-autorización.

La Anulación de una pre-autorización no se incluirá en los archivos de cierre o TEF.

1.4.1.5 Cash Back / Anulación Cash Back

Los clientes de Visa pueden extraer efectivo en los negocios habilitados para este tipo de operación, previo a realizar una compra con su tarjeta o bien incluirla junto con la compra.
El flujo normal de ésta operatoria es el siguiente:
Compra + Cash Back (TrxType = Sale)

Se envía la compra desde el POS junto con el importe del Cash Back en el campo 54 - additionalAmount. El importe de la compra también debe viajar en el campo 12 - amount.

Tipo de mensaje Cash Back (trxType = CashBack).

Se envía el mensaje desde el POS. En este caso, el importe de Cash Back del campo 54 - additionalAmount y el importe total (campo 12 - amount) deben coincidir. Además el número de cuotas debe viajar con valor 1.

Anulación de Compra + Cash Back (trxType = VoidSale)
Esta opción se utilizará para anular una operación de Compra + Cash Back existente dentro del mismo periodo contable. Es decir, no se ha realizado el Cierre de Lote.

Anulación de Cash Back (trxType = VoidCashBack)
Esta operación se utiliza cuando se intenta anular un mensaje Cash Back enviado de manera explícita (trxType = CashBack). Es decir, cuando no se incluyó como parte de una compra.
Es necesario incluir el número de cupón del mensaje Cash Back original para poder identificar la operación a anular.
Importante: Todas las operaciones que involucran Cash Back solo pueden realizarse de manera "On-Line" y el importe otorgado es en la misma moneda.

1.4.1.6 Anulación

La anulación sirve para anular completamente una venta previa. La diferencia con una devolución, es que la cancelación se hace por el monto total de la venta, en cambio la devolución puede ser parcial.
Además la cancelación implica un reintegro instantáneo, mientras que la devolución puede tardar unos días (dependerá de la tarjeta).
Tener en consideración que la anulación solo se puede realizar mientras el lote de transacciones esté abierto en VTOL, esto es en el mismo día.

1.4.2 Devolución

La estructura del mensaje de devolución es igual al del mensaje de venta, con la diferencia que se agregan dos campos que identifican a la transacción original sobre la que se hace la devolución: originalDate y originalTrxTicketNr.

1.4.2.1 Requerimiento

Nota: A continuación se toma como base el tipo de mensaje de Sale y se agregan las diferencias.

#	FieldId	Tipo	Descripción
11	trxType	Alfanumérico	Tipo de Transacción: Refund = devolución
12	amount	Importe	Monto de la transacción. 12 dígitos como máximo. Se envía sin coma. Los dos últimos dígitos representan los decimales. Ej: 1000 equivale a 10.00 Nota: valor de la venta original
13	currencyPosCode	Alfanumérico	Tipos de Moneda: $ = Pesos U$S = Dólares Nota: valor de la venta original
14	payments	Numérico	Cantidad de cuotas. 2 dígitos como máximo. Nota: valor de la venta original
15	plan	Alfanumérico	Código de plan. Largo 1. Nota: valor de la venta original
16	originalDate	Fecha	Este campo debe viajar si el tipo de transacción es Refund. Se trata de la fecha de la transacción original en el formato YYYYMMDD.
17	originalTrxTicketNr	Numérico	Este campo debe viajar si el tipo de transacción es Refund. Se trata del número de ticket de la transacción original. 4 dígitos como máximo.
53	paymentCondition	Alfanumérico	Condición de pago. Sólo se encuentra presente si existe una condición de pago vinculada con la transacción. Nota: valor de la venta original
201	additionalMessageData	Alfanumérico	Este campo tiene como finalidad que el POS, o cliente VTOL, pueda enviar un dato X y que el mismo esté presente en la respuesta. Cada módulo según implementación puede decidir qué hacer con dicho dato (Ejem Persistir en BBDD).
263	vtolToken	Alfanumérico	Cuando se efectúa una transacción Sale, VoidSale, Refund o VoidRefund tokenizada, se puede enviar el Token VTOL
264	posChannelOrigin	Numérico	Indica el canal de origen de la transacción. Es un código con los siguientes valores posibles: 0: Presencial 1: E-Commerce 2: Pago recurrente 3: IVR

1.4.2.2 Respuesta

Nota: Tomar como referencia la respuesta del tipo de mensaje Sale

1.4.3 ServicePayment

Mensaje utilizado para el pago de resumen de cuenta de una tarjeta de crédito.

1.4.3.1 Requerimiento

#	FieldId	Tipo	Obligatorio	Descripción
0	company	Numérico	SI	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	SI	Identificador del sitio originador de la transacción
2	node	Numérico	SI	Identificación del nodo, en el sitio originador, donde se generó la transacción
3	server	Alfanumérico	Compatibilidad atrás.	Identificador del Server que procesará la transacción. ('VTOL')
4	messageType	Alfanumérico	Compatibilidad atrás.	Tipo de Mensaje: Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server. Data = Mensaje de la Aplicación cliente.
6	cardNumber	Numérico	Obligatorio si es Manual	Número de tarjeta. Sólo presente si el modo de ingreso fue Manual.
7	expiration	Numérico	Obligatorio si es Manual	Formato YYYYMM Fecha de vencimiento de la tarjeta. Sólo presente si el modo de ingreso fue Manual.
8	Cvc	Numérico	Obligatorio si es Manual. Además es opcional según la tarjeta.	Código de seguridad de la tarjeta. Sólo presente si el modo de ingreso fue Manual.
9	track2	Alfanumérico	Obligatorio si es MSR	Track2 de la tarjeta entero (se envía todo el contenido del track2 en este campo) Este campo sólo está presente si la banda magnética / chip de la tarjeta pudo ser leído.
10	posInputMode	Alfanumérico	Obligatorio	Modo de Ingreso: MSR = Ingreso por banda magnética Manual = Ingreso manual
11	trxType	Alfanumérico	Obligatorio	Tipo de Transacción: ServicePayment = Pago de Servicio
12	amount	Importe	Obligatorio	Monto de la transacción. 12 dígitos como máximo. Se envía sin coma. Los dos últimos dígitos representan los decimales. Ej: 1000 equivale a 10.00
13	currencyPosCode	Alfanumérico	Obligatorio	Tipos de Moneda: $ = Pesos U$S = Dólares
14	payments	Numérico	Obligatorio	Cantidad de cuotas. 2 dígitos como máximo.
15	plan	Alfanumérico	Obligatorio	Plan. 1 caracter de longitud.
22	authorizationCode	Alfanumérico	Condicional a si fue realizada la autorización telefónica.	Código de autorización telefónica. 6 dígitos como máximo. Este campo se encuentra presente sólo si la transacción se autorizó off-line por teléfono.
23	authorizationMode	Alfanumérico	Opcional, default = Online	Modo de Autorización: Online = La autorización fue realizada por el Centro Autorizador. Offhost = La autorización fue realizada internamente por VTOL. Offline = La autorización fue realizada localmente por el POS.
25	dateTime	Numérico	Obligatorio	Fecha de generación de la trx en el POS. Formato YYYYMMDDHHmmss
53	paymentCondition	Alfanumérico	Opcional	Condición de pago. Sólo se encuentra presente si existe una condición de pago vinculada con la transacción.
56	pinblock	Alfanumérico	Condicional a PINPAD	PIN encriptado. Se emplea para tarjetas de débito. Ejemplo pinblock: D76484D688FE1826
57	accountType	Alfanumérico	Condicional a tarjeta de débito	Campo que se emplea para identificar el tipo de cuenta (ej: cta cte en pesos) Se usa para tarjetas de débito. Los valores posibles son: 1 = Caja de ahorros en pesos 2 = Cuenta corriente en pesos 3 = Caja de ahorros en dólares 4 = Cuenta corriente en dolares
66	track1	Alfanumérico	Opcional a su lectura	Track1 de la tarjeta entero (se envía todo el contenido del track1 en este campo) Este campo sólo está presente si la banda magnética / chip de la tarjeta pudo ser leído.
70	effectiveDate	Alfanumérico	Opcional AMEX	Fecha efectiva. Se usa para AMEX con formato yyMM
71	checkPendingString	Alfanumérico	Opcional, default = true	Indica si VTOL debe o no efectuar el chequeo de pendientes (se emplea para pagos parciales de tarjetas): true = activa chequeo de pendientes. false = desactiva chequeo de pendientes.
72	creditCardCondition	Alfanumérico	Opcional	Es una cadena de 3 de largo donde se indica una condición de la tarjeta. Se usa para las tarjetas regionales o propias donde los prefijos se superponen. Este valor es identificable en el TrackI de la tarjeta y si es manual se le pregunta al cajero.
73	interestAmount	Alfanumérico	Opcional	Este campo es por si se necesita enviar el monto de los intereses en el mensaje a Autorizar. Normalmente el monto que llega del POS ya contiene los intereses en el caso de pagar en cuotas. Existe algún caso de alguna tarjeta especial donde el monto hay que enviarlo libre de intereses y justamente el monto de los intereses viaja en este campo.
74	requestAccountNumber	Alfanumérico	Opcional, default = 0	Indica si puede recibir el número de cuenta (Visa y Posnet). Valores posible: 1 = activado 0 = desactivado
101	differDate	Alfanumérico	Opcional	Fecha diferida. Solo utilizada para AMEX.
147	providerPosCode	Alfanumérico	Opcional	Código del Provider. Se utiliza en los casos donde VTOL Server no puede obtener unívocamente el Proveedor utilizando los prefijos (debido enmascaramiento de la tarjeta). Ejemplo VI (Visa). Longitud 20.
164	posEncryptedFields	Numérico	Opcional	Indica si se utiliza encripción entre Pinpad y VTOL (modo RSA). En este caso los datos sensibles se envían encriptados. Si está activo, los campos a enviar encriptados son: 6, 8, 9, 66 Valores posibles: 1 = activado 0 = desactivado (valor por defecto).
201	additionalMessageData	Alfanumérico	Opcional	Este campo tiene como finalidad que el POS, o cliente VTOL, pueda enviar un dato X y que el mismo esté presente en la respuesta. Cada módulo según implementación puede decidir qué hacer con dicho dato (Ejem Persistir en BBDD).

1.4.3.2 Respuesta

#	FieldId	Tipo	Descripción
0	company	Numérico	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	Identificador del sitio originador de la transacción
2	node	Numérico	Identificación del nodo, en el sitio originador, donde se generó la transacción
22	authorizationCode	Alfanumérico	Código de autorización generado por el centro autorizador para la transacción.
23	authorizationMode	Alfanumérico	Modo de Autorización: Online = La autorización fue realizada por el Centro Autorizador. Offhost = La autorización fue realizada internamente por VTOL. Offline = La autorización fue realizada localmente por el POS.
24	lastTrxId	Numérico	Id de transacción. En caso que el Campo 26 sea TrxIsPending, contendrá el trxId de la transacción pendiente.
25	dateTime	Numérico	Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS.
26	responseCode	Alfanumérico	Puede contener uno de los siguientes valores: Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27 Error = ver sección Código de errores del CORE TrxIsPending: indica si existen transacciones pendientes de confirmar. En este caso, el ID de transacción a confirmar está en el campo 24.
27	isoCode	Numérico	Código de Respuesta ISO-8583 emitido por el centro autorizador. 2 dígitos como máximo
28	responseMessage	Alfanumérico	Mensaje de la Respuesta ISO-8583
29	serialNumber	Numérico	Número identificatorio de la terminal en la que se procesó la transacción.
30	businessNumber	Numérico	Número de comercio en el que se procesó la transacción.
31	lotNumber	Numérico	Número de lote en el que se registró la transacción
32	ticket	Numérico	Número de Ticket correspondiente a la transacción. 4 dígitos como máximo.
33	creditCardIssuerName	Alfanumérico	Nombre del Centro emisor de la tarjeta
34	hostName	Alfanumérico	Nombre del canal por el cual se autorizó la tarjeta.
35	errorDescription	Alfanumérico	Descripción de error. Sólo se encuentra presente si el valor del campo 26 es "Error".
42	lotDefinitionId	Numérico	Identificador de la definición de lote.
58	workingKey	Alfanumérico	VTOL devuelve este campo tal como lo entrega el CA. Representa la llave que el PINPAD deberá usar para generar el PINBLOCK en la próxima transacción.
68	rrn	Numérico	Reference referral number.
75	accountNumber	Alfanumérico	Número de cuenta. Este campo es devuelto si el campo 74- requestAccountNumber fue activado en el requerimiento. Longitud 28.
81	responseAuth	Alfanumérico	Mensaje de repuesta para ser mostrado en el diplay del POS donde se indican promociones.
165	publicKey	Alfanumérico	Clave Pública utilizada en la encripción punto a punto POS - VTOL. Viaja cuando la clave expiró y se generó una nueva; o bien, cuando es necesario sincronizar claves entre POS y VTOL.
166	trxReferenceNumber	Numérico	Identificador único de la transacción en VTOL Server. Longitud entre 19 y 20 dígitos, debido a que utiliza el día como parte de formato.
201	additionalMessageData	Alfanumérico	Este campo tiene como finalidad que el POS, o cliente VTOL, pueda enviar un dato X y que el mismo esté presente en la respuesta. Cada módulo según implementación puede decidir qué hacer con dicho dato (Ejem Persistir en BBDD).

1.4.4 VoidServicePayment

Anulación de pago de resumen de tarjeta de crédito.

1.4.4.1 Requerimiento

Nota: A continuación se toma como base el tipo de mensaje de ServicePayment y se agregan las diferencias.

#

FieldId

Tipo

Obligatorio

Descripción

11

trxType

Alfanumérico

Obligatorio

Tipo de Transacción:

VoidServicePayment = Anulacion de Pago de Servicio

1.4.4.2 Respuesta

Nota: Tomar como referencia la respuesta del tipo de mensaje ServicePayment

1.4.5 Consulta Membresía/Anulación Consulta Membresía

Las transacciones de membresía sirven para validar que la tarjeta asociada a la transacción es miembro y/o está vigente.
Algunos ejemplos de tarjetas asociadas son:

Club La Nación
Clarín 365
Club Personal
Etc

1.4.5.1 Requerimiento

#	FieldId	Tipo	Obligatorio	Descripción
0	company	Numérico	SI	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	SI	Identificador del sitio originador de la transacción
2	node	Numérico	SI	Identificación del nodo, en el sitio originador, donde se generó la transacción
3	server	Alfanumérico	Compatibilidad atrás.	Identificador del Server que procesará la transacción. (en el caso de VTOL será 'VTOL')
4	messageType	Alfanumérico	Compatibilidad atrás.	Tipo de Mensaje: Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server. Data = Mensaje de la Aplicación cliente.
6	cardNumber	Numérico	Obligatorio si es Manual	Número de tarjeta. Sólo presente si el modo de ingreso fue Manual.
7	expiration	Numérico	Obligatorio si es Manual	Formato YYYYMM Fecha de vencimiento de la tarjeta. Sólo presente si el modo de ingreso fue Manual.
9	track2	Alfanumérico	Obligatorio si es MSR	Track2 de la tarjeta entero (se envía todo el contenido del track2 en este campo) Este campo sólo está presente si la banda magnética / chip de la tarjeta pudo ser leído.
10	posInputMode	Alfanumérico	Obligatorio	Modo de Ingreso: MSR = Ingreso por banda magnética Manual = Ingreso manual
11	trxType	Alfanumérico	Obligatorio	Tipo de Transacción: MembershipQuery = Consulta Membresía VoidMembershipQuery = Anulación Consulta Membresía
12	amount	Importe	Obligatorio	Monto de la transacción. 12 dígitos como máximo. Se envía sin coma. Los dos últimos dígitos representan los decimales. Ej: 1000 equivale a 10.00
13	currencyPosCode	Alfanumérico	Obligatorio	Tipos de Moneda: $ = Pesos
23	authorizationMode	Alfanumérico	Opcional, default = Online	Modo de Autorización: Online = La autorización fue realizada por el Centro Autorizador.
25	dateTime	Numérico	Obligatorio	Fecha de generación de la trx en el POS. Formato YYYYMMDDHHmmss
53	paymentCondition	Alfanumérico	Opcional	Condición de pago. Sólo se encuentra presente si existe una condición de pago vinculada con la transacción.
71	checkPendingString	Alfanumérico	Opcional, default = true	Indica si VTOL debe o no efectuar el chequeo de pendientes (se emplea para pagos parciales de tarjetas): True = activa chequeo de pendientes. False = desactiva chequeo de pendientes.
73	interestAmount	Alfanumérico	Opcional	Este campo es por si se necesita enviar el monto de los intereses en el mensaje a Autorizar. Normalmente el monto que llega del POS ya contiene los intereses en el caso de pagar en cuotas. Existe algún caso de alguna tarjeta especial donde el monto hay que enviarlo libre de intereses y justamente el monto de los intereses viaja en este campo.
74	requestAccountNumber	Alfanumérico	Opcional, default = 0	Indica si puede recibir el número de cuenta (Visa y Posnet). Valores posible: 1 = activado 0 = desactivado
147	providerPosCode	Alfanumérico	Opcional	Código del Provider. Se utiliza en los casos donde VTOL Server no puede obtener unívocamente el Proveedor utilizando los prefijos (debido enmascaramiento de la tarjeta). Ejemplo VI (Visa). Longitud 20.
164	posEncryptedFields	Numérico	Opcional	Indica si se utiliza encripción entre Pinpad y VTOL (modo RSA). En este caso los datos sensibles se envían encriptados. Si está activo, los campos a enviar encriptados son: 6, 9 Valores posibles: 1 = activado 0 = desactivado (valor por defecto).
201	additionalMessageData	Alfanumérico	Opcional	Este campo tiene como finalidad que el POS, o cliente VTOL, pueda enviar un dato X y que el mismo esté presente en la respuesta. Cada módulo según implementación puede decidir qué hacer con dicho dato (Ejem Persistir en BBDD).

1.4.5.2 Respuesta

#	FieldId	Tipo	Descripción
0	company	Numérico	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	Identificador del sitio originador de la transacción
2	node	Numérico	Identificación del nodo, en el sitio originador, donde se generó la transacción
22	authorizationCode	Alfanumérico	Código de autorización generado por el centro autorizador para la transacción.
23	authorizationMode	Alfanumérico	Modo de Autorización: Online = La autorización fue realizada por el Centro Autorizador. Offhost = La autorización fue realizada internamente por VTOL. Offline = La autorización fue realizada localmente por el POS.
24	lastTrxId	Numérico	Id de transacción. En caso que el Campo 26 sea TrxIsPending, contendrá el trxId de la transacción pendiente.
25	dateTime	Numérico	Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS.
26	responseCode	Alfanumérico	Puede contener uno de los siguientes valores: Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27 Error = ver sección Código de errores del CORE TrxIsPending = indica si existen transacciones pendientes de confirmar. En este caso, el ID de transacción a confirmar está en el campo 24.
27	isoCode	Numérico	Código de Respuesta ISO-8583 emitido por el centro autorizador. 2 dígitos como máximo
28	responseMessage	Alfanumérico	Mensaje de la Respuesta ISO-8583
29	serialNumber	Numérico	Número identificatorio de la terminal en la que se procesó la transacción.
30	businessNumber	Numérico	Número de comercio en el que se procesó la transacción.
31	lotNumber	Numérico	Número de lote en el que se registró la transacción
32	ticket	Numérico	Número de Ticket correspondiente a la transacción. 4 dígitos como máximo.
33	creditCardIssuerName	Alfanumérico	Nombre del Centro emisor de la tarjeta
34	hostName	Alfanumérico	Nombre del canal por el cual se autorizó la tarjeta.
35	errorDescription	Alfanumérico	Descripción de error. Sólo se encuentra presente si el valor del campo 26 es "Error".
42	lotDefinitionId	Numérico	Identificador de la definición de lote.
58	workingKey	Alfanumérico	VTOL devuelve este campo tal como lo entrega el CA. Representa la llave que el PINPAD deberá usar para generar el PINBLOCK en la próxima transacción.
68	rrn	Numérico	Reference referral number.
75	accountNumber	Alfanumérico	Número de cuenta. Este campo es devuelto si el campo 74- requestAccountNumber fue activado en el requerimiento. Longitud 28.
81	responseAuth	Alfanumérico	Mensaje de repuesta para ser mostrado en el diplay del POS donde se indican promociones.
165	publicKey	Alfanumérico	Clave Pública utilizada en la encripción punto a punto POS - VTOL. Viaja cuando la clave expiró y se generó una nueva; o bien, cuando es necesario sincronizar claves entre POS y VTOL.
201	additionalMessageData	Alfanumérico	Este campo tiene como finalidad que el POS, o cliente VTOL, pueda enviar un dato X y que el mismo esté presente en la respuesta. Cada módulo según implementación puede decidir qué hacer con dicho dato (Ejem Persistir en BBDD).

1.4.6 Consulta de Configuración

Por medio de éste mensaje, el POS puede solicitar a VTOL el envío de la configuración generada a partir de la ejecución de la interface para POS.
El POS debe enviar en el mensaje el número de versión de la configuración que posee, de esta manera VTOL puede validar si es necesario devolver la información o no.
A nivel implementación se recomienda no ejecutar éste mensaje entre cada mensaje de autorización ya que podría degradar la performance del sistema.
Es recomendable hacerlo en alguno de los siguientes casos:

Cuando un operador hace login
Cada una X cantidad de tiempo. Por ejemplo, cada 1 hora
Cuando el punto de venta inicia (dependiendo frecuencia)
Opcionalmente, proveer al sistema integrador una opción para forzar el cambio de configuración manualmente (que manualmente se dispare el proceso de actualización)
etc

Nota: si el POS no posee número de configuración debe enviar el valor por defecto 0 (cero), ya que VTOL valida que el campo versión siempre esté presente.

1.4.6.1 Requerimiento

#	FieldId	Tipo	Obligatorio	Descripción
0	compay	Numérico	SI	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	SI	Identificador del sitio originador de la transacción
2	node	Numérico	SI	Identificación del nodo, en el sitio originador, donde se generó la transacción
3	server	Alfanumérico	Compatibilidad atrás	Identificador del Server que procesará la transacción. ('VTOL')
4	messageType	Alfanumérico	Compatibilidad atrás	Tipo de Mensaje: Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server. Data = Mensaje de la Aplicación cliente.
11	trxType	Alfanumérico	Obligatorio	Tipo de Transacción: PosConfQuery = Consulta de Configuración
25	dateTime	Numérico	Obligatorio	Fecha de generación de la trx en el POS. Formato YYYYMMDDHHmmss
71	checkPendingString	Alfanumérico	Opcional, default = true	Indica si VTOL debe o no efectuar el chequeo de pendientes (se emplea para pagos parciales de tarjetas): True: activa chequeo de pendientes. False: desactiva chequeo de pendientes.
137	confVersion	numérico	Obligatorio	Número de versión de la configuración que posee el POS. En caso de que el POS no posea configuración previa, se debe enviar el campo con valor 0 y de esta manera evitar el error de validación por ausencia del campo.
201	additionalMessageData	Alfanumérico	Opcional	Este campo tiene como finalidad que el POS, o cliente VTOL, pueda enviar un dato X y que el mismo esté presente en la respuesta. Cada módulo según implementación puede decidir qué hacer con dicho dato (Ejem Persistir en BBDD).

1.4.6.2 Respuesta

#	FieldId	Tipo	Descripción
0	company	Numérico	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	Identificador del sitio originador de la transacción
2	node	Numérico	Identificación del nodo, en el sitio originador, donde se generó la transacción
24	trxId	Numérico	OPCIONAL. En caso que el Campo 26 sea TrxIsPending, contendrá el trxId de la transacción pendiente.
25	dateTime	Numérico	Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS.
26	responseCode	Alfanumérico	Puede contener uno de los siguientes valores: Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27 Error = ver sección Código de errores del CORE TrxIsPending = indica si existen transacciones pendientes de confirmar. En este caso, el ID de transacción a confirmar está en el campo 24.
27	isoCode	Numérico	Código de Respuesta ISO-8583 emitido por VTOL. 2 dígitos como máximo
28	responseMessage	Alfanumérico	Valor fijo ISO-8583.
137	confVersion	numérico	Número de versión de la configuración más actual. Si el número es distinto al enviado en el requerimiento, entonces el POS debe actualizar la configuración.
138	confData	Alfanumérico	Configuración creada en la generación de la Interface para POS, codificada en Base64. Viaja siempre y cuando el número de versión enviado por el POS no sea el vigente. Para más detalle ver sección Formato Interface POS
165	publicKey	Alfanumérico	Clave Pública vigente utilizada en la encripción punto a punto entre POS - VTOL
201	additionalMessageData	Alfanumérico	Este campo tiene como finalidad que el POS, o cliente VTOL, pueda enviar un dato X y que el mismo esté presente en la respuesta. Cada módulo según implementación puede decidir qué hacer con dicho dato (Ejem Persistir en BBDD).

1.4.7 Servicio de Información de Tarjeta

Permite consultar información adicional de una tarjeta, según sea de Crédito Debito o de Excepción.
Cuando VTOL recibe este mensaje, primero realiza una identificación del tipo de tarjeta, determinando si se trata de una Tarjeta de Crédito/Débito o de Excepción.
La información que se devuelve al POS se basa en el tipo de tarjeta:

Si es de excepción

Nombre de tarjeta de Excepción
Información adicional.
Si en el requerimiento viene encendido el campo de encriptado (campo 164 = 1), se intentará descencriptar todos los datos sensibles, devolviéndolos en texto plano.

Si es crédito/débito

Descripción tipo de Tarjeta.
Nombre de la tarjeta
Código de Tarjeta.
Medio de Pago

NOTA:

- Para las tarjetas Crédito Debito no se retorna ningún dato sensible en texto plano.

- Cuando viene encendido el campo de encriptado (campo 164=1), se deben enviar todos los datos sensibles encriptados. Si alguno de ellos viaja en texto plano se producirá un error y será notificado en la respuesta.

1.4.7.1 Requerimiento

#	FieldId	Tipo	Obligatorio	Descripción
0	company	Numérico	Obligatorio	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	Obligatorio	Identificador del sitio originador de la transacción
2	node	Numérico	Obligatorio	Identificación del nodo, en el sitio originador, donde se generó la transacción
3	server	Alfanumérico	Compatibilidad atrás.	Identificador del Server que procesará la transacción. ('VTOL')
4	messageType	Alfanumérico	Compatibilidad atrás.	Tipo de Mensaje: Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server. Data = Mensaje de la Aplicación cliente.
6	cardNumber	Numérico	Opcional	Número de tarjeta. Sólo presente si el modo de ingreso fue Manual.
7	expiration	Numérico	Opcional	Formato YYYYMM. Fecha de vencimiento de la tarjeta. Sólo presente si el modo de ingreso fue Manual.
8	cvc	Numérico	Opcional	Código de seguridad de la tarjeta. Sólo presente si el modo de ingreso fue Manual.
9	track2	Alfanumérico	Opcional	Track2 de la tarjeta entero. Este campo sólo está presente si la banda magnética / chip de la tarjeta pudo ser leído.
10	posInputMode	Alfanumérico	Obligatorio	Modo de Ingreso: MSR = Ingreso por banda magnética Manual = Ingreso manual Chip = EMV Chip
11	trxType	Alfanumérico	Obligatorio	Tipo de Transacción: CardInfoService = Servicio de información de Tarjeta.
25	dateTime	Numérico	Obligatorio	Fecha de generación de la trx en el POS. Formato YYYYMMDDHHmmss
66	track1	Alfanumérico	Opcional a su lectura	Track1 de la tarjeta entero. Este campo sólo está presente si la banda magnética / chip de la tarjeta pudo ser leído.
71	checkPendingString	Alfanumérico	Opcional, default = true	Indica si VTOL debe o no efectuar el chequeo de pendientes (se emplea para pagos parciales de tarjetas): True: activa chequeo de pendientes. False: desactiva chequeo de pendientes.
137	serviceCode	Numérico	Opcional	Código de Servicio, se envía cuando el mensaje esta encriptado y no se tiene acceso al Track2. Longitud 3.
147	providerPosCode	Alfanumérico	Opcional	Código del Provider. Se utiliza en los casos donde VTOL Server no puede obtener unívocamente el Proveedor utilizando los prefijos (debido enmascaramiento de la tarjeta). Ejemplo VI (Visa). Longitud 20.
164	posEncryptedFields	Numérico	Opcional	Indica si se utiliza encripción entre Pinpad y VTOL (modo RSA). En este caso los datos sensibles se envían encriptados. Si está activo, los campos a enviar encriptados son: 6, 8, 9, 66 Valores posibles: 1 = activado 0 = desactivado (valor por defecto).
201	additionalMessageData	Alfanumérico	Opcional	Este campo tiene como finalidad que el POS, o cliente VTOL, pueda enviar un dato X y que el mismo esté presente en la respuesta. Cada módulo según implementación puede decidir qué hacer con dicho dato (Ejem Persistir en BBDD).

1.4.7.2 Respuesta

#	FieldId	Tipo	Descripción
0	company	Numérico	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	Identificador del sitio originador de la transacción
2	node	Numérico	Identificación del nodo, en el sitio originador, donde se generó la transacción
6	cardNumber	Numérico	Número de tarjeta en texto plano. Opcional: Presente solo para Tarjeta de Excepción.
7	expiration	Numérico	Fecha de vencimiento de la tarjeta en texto plano. Opcional: Presente solo para Tarjeta de Excepción.
8	cvc	Numérico	Código de seguridad de la tarjeta. Opcional: Presente solo para Tarjeta de Excepción.
9	track2	Alfanumérico	Track2 de la tarjeta entero. Opcional: Tarjeta de Excepción.
24	trxId	Numérico	OPCIONAL. En caso que el Campo 26 sea TrxIsPending, contendrá el trxId de la transacción pendiente.
25	dateTime	Numérico	Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS.
26	responseCode	Alfanumérico	Puede contener uno de los siguientes valores: Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27 Error = ver sección Código de errores del CORE TrxIsPending = indica si existen transacciones pendientes de confirmar. En este caso, el ID de transacción a confirmar está en el campo 24.
27	isoCode	Numérico	Código de Respuesta ISO-8583 emitido por VTOL. 2 dígitos como máximo
28	responseMessage	Alfanumérico	Valor fijo ISO-8583
66	track1	Alfanumérico	Track1 de la tarjeta entero. Opcional: Presente solo para Tarjeta de Excepción.
140	cardType	Alfanumérico	Descripción de tipo de tarjeta. Opcional: Presente solo para Tarjeta de Crédito / Debito.
141	isDebit	Numérico	Indicador si la tarjeta es de Débito (0: no es débito, 1: es debito). Opcional: Presente solo para Tarjeta de Crédito / Debito.
142	providerName	Alfanumérico	Nombre de la tarjeta. Opcional: Presente solo para Tarjeta de Crédito / Debito.
143	providerPosCode	Alfanumérico	Código de tarjeta. Opcional: Presente solo para Tarjeta de Crédito / Debito.
144	providerPosTenderCode	Alfanumérico	Medio de Pago. Opcional: Presente solo para Tarjeta de Crédito / Debito.
145	exceptionBinName	Alfanumérico	Nombre de la tarjeta de Excepción. Opcional: Presente solo para Tarjeta de Excepción.
146	exceptionBinData	Alfanumérico	Información adicional de la tarjeta de excepción. Opcional: Presente solo para Tarjeta de Excepción.
165	publicKey	Alfanumérico	Clave Pública utilizada en la encripción punto a punto POS - VTOL. Viaja cuando la clave expiró y se generó una nueva; o bien, cuando es necesario sincronizar claves entre POS y VTOL.
201	additionalMessageData	Alfanumérico	Este campo tiene como finalidad que el POS, o cliente VTOL, pueda enviar un dato X y que el mismo esté presente en la respuesta. Cada módulo según implementación puede decidir qué hacer con dicho dato (Ejem Persistir en BBDD).

1.4.8 EMV Advice de Rechazo

Mensaje implementado para enviar un Advice al autorizador en caso de que el PINPAD rechace la autorización en primera decisión de la tarjeta en comando Y02, y segunda decisión en comando Y03, cuando la operación inicial fue rechaza por el autorizador.
El mensaje no está vinculado a ninguna autorización previa. Es solamente informativo hacia el centro autorizador.

1.4.8.1 Requerimiento

#	FieldId	Tipo	Obligatorio	Descripción
0	company	Numérico	SI	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	SI	Identificador del sitio originador de la transacción
2	node	Numérico	SI	Identificación del nodo, en el sitio originador, donde se generó la transacción
3	server	Alfanumérico	Compatibilidad atrás.	Identificador del Server que procesará la transacción. ('VTOL')
4	messageType	Alfanumérico	Compatibilidad atrás.	Tipo de Mensaje: Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server. Data = Mensaje de la Aplicación cliente.
8	cvc	Numérico	Obligatorio si es Manual. Además es opcional según la tarjeta.	Código de seguridad de la tarjeta. Sólo presente si el modo de ingreso fue Manual.
9	track2	Alfanumérico	Opcional, default = true	Track2 de la tarjeta entero (se envía todo el contenido del track2 en este campo) Este campo sólo está presente si la banda magnética / chip de la tarjeta pudo ser leído.
10	posInputMode	Alfanumérico	Obligatorio	Modo de Ingreso: Chip = EMV Chip
11	trxType	Alfanumérico	Obligatorio	Tipo de Transacción: RejectedEVMAdvice
12	amount	Importe	Obligatorio	Monto de la transacción. 12 dígitos como máximo. Se envía sin coma. Los dos últimos dígitos representan los decimales. Ej: 1000 equivale a 10.00
13	currencyPosCode	Alfanumérico	Obligatorio	Tipos de Moneda: $ = Pesos U$S = Dólares
14	payments	Numérico	Obligatorio	Cantidad de cuotas. 2 dígitos como máximo.
15	plan	Alfanumérico	Obligatorio	Plan. 1 caracter de longitud.
25	dateTime	Numérico	Obligatorio	Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS.
53	paymentCondition	Alfanumérico	Opcional	Condición de pago. Sólo se encuentra presente si existe una condición de pago vinculada con la transacción.
56	pinblock	Alfanumérico	Condicional a PINPAD	PIN encriptado. Se emplea para tarjetas de débito.
57	accountType	Alfanumérico	Condicional a tarjeta de débito	Campo que se emplea para identificar el tipo de cuenta (ej: cta cte en pesos) Se usa para tarjetas de débito. Los valores posibles son: •1 = Caja de ahorros en pesos •2 = Cuenta corriente en pesos •3 = Caja de ahorros en dólares •4 = Cuenta corriente en dólares
66	track1	Alfanumérico	Opcional a su lectura	Track1 de la tarjeta entero (se envía todo el contenido del track1 en este campo) Este campo sólo está presente si la banda magnética / chip de la tarjeta pudo ser leído.
71	checkPendingString	Alfanumérico	Opcional	Indica si VTOL debe o no efectuar el chequeo de pendientes (se emplea para pagos parciales de tarjetas): true: activa chequeo de pendientes. false: desactiva chequeo de pendientes.
102	chiptokens	Alfanumérico	Obligatorio	Visa: Criptograma tarjetas EMV Posnet: Lista de Tags EMV En la respuestas hacia el POS se actualiza por lo que envió el CA
103	emvEncryptedType	Alfanumérico	Opcional	Tipo de encriptación utilizada entre Pinpad y Host Autorizador. Los campos 103, 104, 108 y 137 deben ser utilizados en conjunto. Valores posibles: D = DES T = 3DES
104	emvEncryptedData	Alfanumérico	Opcional	Paquete encriptado devuelto por el pinpad y que se enviará al Host Autorizador. Los campos 103, 104, 108 y 137 deben ser utilizados en conjunto.
105	cardSecuenceNumber	Numérico	Opcional a PINPAD	Numero de secuencia del PAN
106	pinpadLogSerialNumber	Alfanumérico	Opcional	Número de serie lógico del pinpad
107	pinpadFisSerialNumber	Alfanumérico	Opcional	Número de serie Físico del pinpad
108	useEncryptedData	Alfanumérico	Opcional	Indica si se utiliza encriptación entre Pinpad y Host Autorizador (Visa, Posnet, etc). Los campos 103, 104, 108 y 137 deben ser utilizados en conjunto. Valores posibles: false = No se utiliza encriptación true = Se utiliza encriptación
109	pinpadResponseCode	Alfanumérico	Obligatorio	Código de Respuesta del Pinpad (CRE).
111	pinpadAutCode	Alfanumérico	Obligatorio	Código de Autorización (Z1 o Z3) del Pinpad (CAU).
118	terminalCapability	Numérico	Opcional	Capacidad de captura. Valores 1 = Manual / 2 = Lectura de Banda / 5 = Lectura de Chip
137	serviceCode	Numérico	Opcional	Código de Servicio, se envía cuando el mensaje esta encriptado (campo 108=true) y no se tiene acceso al Track2. Longitud 3. Los campos 103, 104, 108 y 137 deben ser utilizados en conjunto.
147	providerPosCode	Alfanumérico	Opcional	Código del Provider. Se utiliza en los casos donde VTOL Server no puede obtener unívocamente el Proveedor utilizando los prefijos (debido enmascaramiento de la tarjeta). Ejemplo VI (Visa). Longitud 20.
164	posEncryptedFields	Numérico	Opcional	Indica si se utiliza encripción entre Pinpad y VTOL (modo RSA). En este caso los datos sensibles se envían encriptados. Si está activo, los campos a enviar encriptados son: 6, 8, 9, 66 Valores posibles: 1 = activado 0 = desactivado (valor por defecto).
201	additionalMessageData	Alfanumérico	Opcional	Este campo tiene como finalidad que el POS, o cliente VTOL, pueda enviar un dato X y que el mismo esté presente en la respuesta. Cada módulo según implementación puede decidir qué hacer con dicho dato (Ejem Persistir en BBDD).

1.4.8.2 Respuesta

#	FieldId	Tipo	Descripción
0	company	Numérico	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	Identificador del sitio originador de la transacción
2	node	Numérico	Identificación del nodo, en el sitio originador, donde se generó la transacción
24	trxId	Numérico	OPCIONAL. En caso que el Campo 26 sea TrxIsPending, contendrá el trxId de la transacción pendiente.
25	dateTime	Numérico	Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS.
26	responseCode	Alfanumérico	Puede contener uno de los siguientes valores: Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27 Error = si existe alguna falla en la estructura del mensaje de requerimiento que hace que el centro autorizador no lo pueda interpretar TrxIsPending = indica si existen transacciones pendientes de confirmar. En este caso, el ID de transacción a confirmar está en el campo 24.
27	isoCode	Numérico	Código de Respuesta ISO-8583 emitido por VTOL. 2 dígitos como máximo
28	responseMessage	Alfanumérico	Mensaje de la Respuesta ISO-8583
165	publicKey	Alfanumérico	Clave Pública utilizada en la encripción punto a punto POS - VTOL. Viaja cuando la clave expiró y se generó una nueva; o bien, cuando es necesario sincronizar claves entre POS y VTOL.
201	additionalMessageData	Alfanumérico	Este campo tiene como finalidad que el POS, o cliente VTOL, pueda enviar un dato X y que el mismo esté presente en la respuesta. Cada módulo según implementación puede decidir qué hacer con dicho dato (Ejem Persistir en BBDD).

1.4.9 SynQuery

Este es un mensaje de consulta de sincronización de llaves P2PE con los autorizadores.
Se envía a VTOL Server para obtener las claves de encripción 3DES para datos y PIN para cada autorizador que lo implemente.

1.4.9.1 Requerimiento

#	FieldId	Tipo	Obligatorio	Descripción
0	company	Numérico	Obligatorio	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	Obligatorio	Identificador del sitio originador de la transacción
2	node	Numérico	Obligatorio	Identificación del nodo, en el sitio originador, donde se generó la transacción
11	trxType	Alfanumérico	Obligatorio	Tipo de Transacción: SyncQuery
25	dateTime	Numérico	Obligatorio	Fecha de generación de la trx en el POS. Formato YYYYMMDDHHmmss
201	additionalMessageData	Alfanumérico	Obligatorio	Mapa con los Ids de derivación por autorizador. Formato: [Autorizador1\|IdDerivación1,Autorizador2\|IdDerivación2,…,AutorizadorN\|IdDerivaciónN]
258	forceSync	Alfanumérico	Opcional	Indica si se debe forzar la sincronización de llaves con el autorizador. Valores: False (por defecto) True

1.4.9.2 Respuesta

#	FieldId	Tipo	Descripción
0	company	Numérico	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	Identificador de la tienda donde se originó el mensaje
2	node	Numérico	Identificación del nodo
25	dateTime	Numérico	Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS
26	responseCode	Alfanumérico	Puede contener uno de los siguientes valores: Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27 Error = ver sección Código de errores del CORE TrxIsPending: indica si existen transacciones pendientes de confirmar
27	isoCode	Numérico	Código de Respuesta ISO-8583. 2 dígitos como máximo
28	responseMessage	Alfanumérico	Mensaje de la Respuesta ISO-8583
259	workingKeys	Alfanumérico	Mapa con los datos de sincronización por canal. Formato: [Autorizador1\|DatosSincronizacion1,Autorizador2\| DatosSincronizacion2,…] La información en el campo Datos Sincronización se encuentra codificado en base64. Ver sección Formato Datos Sincronización

1.4.10 Cierre de Nodo

Por medio de éste mensaje se le puede indicar a VTOL que ejecute el cierre financiera de la terminal lógica asociada a la terminal física o nodo.
Existen dos modos, uno es indicarle a VTOL el identificar de definición de lote que se desea cerrar.
En este caso VTOL busca la terminal lógica (es una sola) asociada a:

Numero de tienda indicado en el mensaje
Numero de POS, nodo o terminal física indicado en el mensaje
Identificador de definición de lote.

Para la terminal lógica encontrada se planificará el cierre.
La segunda modalidad se activa mediante la omisión del campo 75. En este caso VTOL busca todas las terminales lógicas asociadas a

Numero de tienda indicado en el mensaje
Numero de POS, nodo o terminal física indicado en el mensaje

Sin importar la definición de lote y planifica el cierre.

NOTA: el cierre no se ejecuta inmediatamente recibido el mensaje, sino que se planifica para que cuando VTOL esté en condiciones de cerrar lo haga.

1.4.10.1 Requerimiento

#	FieldId	Tipo	Obligatorio	Descripción
0	company	Numérico	SI	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	SI	Identificador del sitio originador de la transacción
2	node	Numérico	SI	Identificación del nodo, en el sitio originador, donde se generó la transacción
3	server	Alfanumérico	Compatibilidad atrás	Identificador del Server que procesará la transacción. ('VTOL')
4	messageType	Alfanumérico	Compatibilidad atrás.	Tipo de Mensaje: Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server. Data = Mensaje de la Aplicación cliente.
11	trxType	Alfanumérico	Obligatorio	Tipo de Transacción: CloseNode = Cierre de nodo
25	dateTime	Numérico	Obligatorio	Fecha de generación de la trx en el POS. Formato YYYYMMDDHHmmss
71	checkPendingString	Alfanumérico	Opcional, default = true	Indica si VTOL debe o no efectuar el chequeo de pendientes (se emplea para pagos parciales de tarjetas): True: activa chequeo de pendientes. False: desactiva chequeo de pendientes.
75	lotDefinition	numérico	Opcional	Identificador de definición de lote. Es requerido que el POS sepa de antemano cuales son los identificadores de defunción de lote y a que definición de lote pertenecen.
201	additionalMessageData	Alfanumérico	Opcional	Este campo tiene como finalidad que el POS, o cliente VTOL, pueda enviar un dato X y que el mismo esté presente en la respuesta. Cada módulo según implementación puede decidir qué hacer con dicho dato (Ejem Persistir en BBDD).

1.4.10.2 Respuesta

#	FieldId	Tipo	Descripción
0	company	Numércio	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	Identificador del sitio originador de la transacción
2	node	Numérico	Identificación del nodo, en el sitio originador, donde se generó la transacción
24	trxId	Numérico	OPCIONAL. En caso que el Campo 26 sea TrxIsPending, contendrá el trxId de la transacción pendiente.
25	dateTime	Numérico	Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS.
26	responseCode	Alfanumérico	Puede contener uno de los siguientes valores: Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27 Error = ver sección Código de errores del CORE TrxIsPending = indica si existen transacciones pendientes de confirmar. En este caso, el ID de transacción a confirmar está en el campo 24.
27	isoCode	Numérico	Código de Respuesta ISO-8583 emitido por el centro autorizador. 2 dígitos como máximo
28	responseMessage	Alfanumérico	Mensaje de la Respuesta ISO-8583
201	additionalMessageData	Alfanumérico	Este campo tiene como finalidad que el POS, o cliente VTOL, pueda enviar un dato X y que el mismo esté presente en la respuesta. Cada módulo según implementación puede decidir qué hacer con dicho dato (Ejem Persistir en BBDD).

1.4.11 Echo

El propósito de este mensaje es conocer si VTOL se está ejecutando y se encuentra disponible.
Por lo general, se utiliza este mensaje en entornos de clúster donde existe un balanceador de carga.

1.4.11.1 Requerimiento

#

FieldId

Tipo

Obligatorio

Descripción

11

trxType

Alfanumérico

Obligatorio

Tipo de Transacción:

Echo = Eco

1.4.11.2 Respuesta

#	FieldId	Tipo	Descripción
25	dateTime	Numérico	Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS.
28	responseMessage	Alfanumérico	Mensaje de la Respuesta con valor constante: "OK".

1.4.12 Tercer Mensaje

1.4.12.1 Requerimiento

#	FieldId	Tipo	Descripción
0	company	Numérico	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	Identificador del sitio originador de la transacción
2	node	Numérico	Identificación del nodo, en el sitio originador, donde se generó la transacción
3	server	Alfanumérico	Identificador del Server que procesará la transacción. (‘VTOL’)
4	messageType	Alfanumérico	Tipo de Mensaje: Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server. Data = Mensaje de la Aplicación cliente.
11	trxType	Alfanumérico	Tipo de Transacción: UnSyncCompletion = Mensaje de completamiento de transacción (“tercer mensaje”)
19	lastTrxAction	Alfanumérico	Acción a realizar sobre la Transacción: Commit = Confirma la transacción Rollback = Reversa la transacción
24	lastTrxId	Numérico	Id de transacción a confirmar / reversar.
25	dateTime	Numérico	Fecha de generación de la trx en el POS. Formato YYYYMMDDHHmmss
200	EMV extra data	Alfanumérico	Datos extras que se deben enviar en el tercer mensaje cuanto el EMV Advice es requerido. Es necesario enviar los campos: adviceChipTokens, pinpadResponseCode y pinpadAutCode. Formato del campo: [adviceChipTokens\|valor,pinpadResponseCode\|valor, pinpadAutCode\|valor]

1.4.12.2 Respuesta

El tercer mensaje no tiene respuesta, salvo que esté prendido el flag de chequeo de transacciones pendientes.

1.4.13 Tercer Mensaje Embebido

El tercer mensaje puede enviarse embebido en otro requerimiento. Así en una misma transacción se enviará un requerimiento y la confirmación o reverso de una transacción pendiente. Para ello, deberán ser agregados los siguientes campos a la transacción en curso:

1.4.13.1 Requerimiento

#	FieldId	Tipo	Descripción
19	lastTrxAction	Alfanumérico	Acción a realizar sobre la Transacción: Commit = Confirma la transacción Rollback = Reversa la transacción
24	lastTrxId	Numérico	Id de transacción a confirmar / reversar.
200	EMV extra data	Alfanumérico	Datos extras que se deben enviar en el tercer mensaje cuanto el EMV Advice es requerido. Es necesario enviar los campos: adviceChipTokens, pinpadResponseCode y pinpadAutCode. Formato del campo: [adviceChipTokens\|valor,pinpadResponseCode\|valor, pinpadAutCode\|valor]

1.4.13.2 Respuesta

El tercer mensaje embebido, al igual que el Tercer Mensaje, no tiene respuesta. De todas formas, sí existe respuesta para la transacción que lo embebe.

1.4.14 Chequeo de Pendientes

El mensaje de chequeo de pendientes sirve para averiguar si el POS que envía la transacción tiene alguna transacción pendiente de confirmación.

1.4.14.1 Requerimiento

#	FieldId	Tipo	Descripción
0	company	Numérico	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	Identificador del sitio originador de la transacción
2	node	Numérico	Identificación del nodo, en el sitio originador, donde se generó la transacción
3	server	Alfanumérico	Identificador del Server que procesará la transacción. (en el caso de VTOL será 'VTOL')
4	messageType	Alfanumérico	Tipo de Mensaje: Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server. Data = Mensaje de la Aplicación cliente.
11	trxType	Alfanumérico	Tipo de Transacción: CheckPending = Mensaje de chequeo de pendientes.
25	dateTime	Numérico	Fecha de generación de la trx en el POS. Formato YYYYMMDDHHmmss

1.4.14.2 Respuesta

#	FieldId	Tipo	Descripción
0	company	Numérico	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	Identificador del sitio originador de la transacción
2	node	Numérico	Identificación del nodo, en el sitio originador, donde se generó la transacción. OPCIONAL: Aparece si campo 26 es TrxIsPending.
24	trxId	Numérico	OPCIONAL: En caso que el Campo 26 sea TrxIsPending, contendrá el trxId de la transacción pendiente.
25	dateTime	Numérico	Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS.
26	responseCode	Alfanumérico	Puede contener uno de los siguientes valores: Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27 Error = ver sección Código de errores del CORE TrxIsPending: indica si existen transacciones pendientes de confirmar. En este caso, el ID de transacción a confirmar está en el campo 24.
27	isoCode	Numérico	Código de Respuesta emitido por VTOL. OPCIONAL: Aparece si campo 26 no es TrxIsPending.
28	responseMessage	Alfanumérico	Mensaje de respuesta. Por ejemplo "Aprobada" OPCIONAL: Aparece si campo 26 no es TrxIsPending.
31	lotNumber	Numérico	Constante igual a 1 para mantener compatibilidad hacia atrás. OPCIONAL: Aparece si campo 26 no es TrxIsPending.
32	ticket	Numérico	Constante igual a 1 para mantener compatibilidad hacia atrás. OPCIONAL: Aparece si campo 26 no es TrxIsPending.

Nota: si la respuesta es "aprobada" significa que no hay transacciones pendientes.

1.4.15 Chequeo de Listado de Pendientes

Este mensaje permite listar todos los id de las transacciones pendientes en VTOL que una tienda en particular, física o virtual, tiene.

1.4.15.1 Requerimiento

#	FieldId	Tipo	Descripción
0	company	Numérico	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	Identificador del sitio originador de la transacción
2	node	Numérico	Identificación del nodo, en el sitio originador, donde se generó la transacción
3	server	Alfanumérico	Identificador del Server que procesará la transacción. (en el caso de VTOL será 'VTOL')
4	messageType	Alfanumérico	Tipo de Mensaje: Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server. Data = Mensaje de la Aplicación cliente.
11	trxType	Alfanumérico	Tipo de Transacción: CheckPendingList = Mensaje de chequeo de pendientes.
25	dateTime	Numérico	Fecha de generación de la trx en el POS. Formato YYYYMMDDHHmmss

1.4.15.2 Respuesta

#	FieldId	Tipo	Descripción
0	company	Numérico	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	Identificador del sitio originador de la transacción
2	node	Numérico	Identificación del nodo, en el sitio originador, donde se generó la transacción. OPCIONAL: Aparece si campo 26 es TrxIsPending.
25	dateTime	Numérico	Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS.
26	responseCode	Alfanumérico	Puede contener uno de los siguientes valores: Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27 Error = ver sección Código de errores del CORE TrxIsPending: indica si existen transacciones pendientes de confirmar. En este caso, los IDs de las transacciones a confirmar están en el campo 161.
27	isoCode	Numérico	Código de Respuesta emitido por VTOL OPCIONAL: Aparece si campo 26 no es TrxIsPending.
28	responseMessage	Alfanumérico	Mensaje de respuesta. Por ejemplo "Aprobada" OPCIONAL: Aparece si campo 26 no es TrxIsPending.
31	lotNumber	Numérico	Constante igual a 1 para mantener compatibilidad hacia atrás. OPCIONAL: Aparece si campo 26 no es TrxIsPending.
32	ticket	Numérico	Constante igual a 1 para mantener compatibilidad hacia atrás. OPCIONAL: Aparece si campo 26 no es TrxIsPending.
161	trxIdList	Numérico	OPCIONAL: En caso que el campo 26 sea TrxIsPending contendrá la lista de transacciones pendientes.

Nota: Si la respuesta es "aprobada" significa que no hay transacciones pendientes.

1.4.16 Operaciones PEI

Esta funcionalidad permite efectuar Pagos Electrónicos Inmediatos (PEI) en los puntos de venta. Estos pagos inmediatos se efectúan con tarjetas de débito con banda magnética y se transfieren y acreditan de manera instantánea con un costo inferior a una venta tradicional.

Las operaciones soportadas para PEI son:

SalePEI = Permite realizar un pago presencial PEI (transferencia bancaria).
RefundPEI = Permite realizar una devolución (parcial o total) de un pago presencial PEI realizado con anterioridad.
QueryPEI = Permite realizar una consulta de una operación de pago o de devolución que tuvo como respuesta el error "391 - Error en comunicación" para conocer si fue autorizada la operación y así obtener los datos de la misma por parte del centro autorizador. Este mensaje surge ya que hay una limitante por parte del autorizador que no existe un mecanismo de reversa de transacciones.

Nota: La operatoria PEI no posee tercer mensaje, por lo que cada operación queda automáticamente en estado "Commited" (comiteado).

1.4.16.1 Requerimiento

Referencias

X = Obligatorio

O = Opcional

- = No requerido

Número	Nombre del campo	Tipo de dato	SalePEI	RefundPEI	QueryPEI	Descripción
0	company	Numérico	X	X	X	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	X	X	X	Identificador del sitio originador de la transacción
2	node	Numérico	X	X	X	Identificación del nodo, en el sitio originador, donde se generó la transacción
3	server	Alfanumérico	X	X	X	Identificador del Server que procesará la transacción. (en el caso de VTOL será 'VTOL')
4	messageType	Alfanumérico	X	X	X	Tipo de Mensaje: Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server. Data = Mensaje de la Aplicación cliente.
8	Cvc	Numérico	X	X	-	Código de seguridad de la tarjeta
9	track2	Alfanumérico	X	X	X	Track2 de la tarjeta entero (se envía todo el contenido del track2 en este campo)
10	inputMode	Alfanumérico	X	X	X	Forma en que se ingresó/leyó la tarjeta. Valor posible: MSR – Leída por banda magnética
11	trxType	Alfanumérico	X	X	X	Tipo de Transacción: SalePEI = Compra PEI RefundPEI = Devolución PEI QueryPEI = Consulta de transacción PEI
12	amount	Importe	X	X	-	Monto de la transacción. 12 dígitos como máximo. Se envía sin coma. Los dos últimos dígitos representan los decimales. Ej: 1000 equivale a 10.00
13	currencyPosCode	Alfanumérico	X	X	-	Tipos de Moneda: $ = Pesos U$S = Dólares
25	dateTime	Numérico	X	X	X	Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. Es importante persistir este valor para consultar el resultado de una operación en caso de algún inconveniente
66	track1	Alfanumérico	X	X	X	Track1 de la tarjeta entero (se envía todo el contenido del track1 en este campo)
71	checkPendingString	Alfanumérico	O Default = true	O Default = true	O Default = true	Indica si VTOL debe o no efectuar el chequeo de pendientes (se emplea para pagos parciales de tarjetas): True: activa chequeo de pendientes. False: desactiva chequeo de pendientes.
153	idOperationPEI	Alfanumérico	-	X	-	Identificador de la operación PEI de pago que se desea devolver
155	cbu	Alfanumérico	-	O	-	CBU de la cuenta destino de la devolución asociada con la tarjeta Banelco. Si el dato se envía, el valor es validado por Link
156	cbuAlias	Alfanumérico	-	O	-	Alias del CBU de la cuenta destino de la devolución asociada con la tarjeta Banelco. Si el dato se envía, el valor es validado por Link
157	customerDoc	Alfanumérico	X	O	-	Número de documento del titular de la tarjeta
158	lastFourDigits	Numérico	X	X	-	Últimos 4 dígitos de la tarjeta. La solicitud de la validación de los últimos 4 dígitos de la tarjeta es configurable por prefijo
161	operationConcept	Numérico	O	-	-	Concepto por el cual se realiza la operación, valores posibles: 1 = COMPRA_DE_BIENES 2 = PAGO_DE_SERVICIOS 3 = EXTRACCION
164	posEncryptedFields	Numérico	X	X	X	Indica si se utiliza encripción RSA. En este caso los datos sensibles se envían encriptados. Si está activo, los campos a enviar encriptados son: 8, 9, 66 Valores posibles: 1 = activado (valor por defecto) 0 = desactivado
173	dateTimeOriginalTrx	Numérico	-	-	X	Fecha y hora de realización de la transacción de venta o devolución que se desea consultar en formato YYYYMMDDHHMMSS. Se debe enviar el valor del campo 25 de la transacción a consultar

Ejemplo

Request to VTOL (SalePEI):

Request: {158:9002;66:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX;157:34000499;13:$;12:1500;11:SalePEI;10:MSR;9:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX;8:XXX;4:DATA;3:VTOL;164:1;71:True;2:1;25:20180905111036;1:1;161:1}

Request to VTOL (RefundPEI):

Request: {25:20180905111046;71:True;164:1;66:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX;158:9002;157:34000499;156:alias;155:12345678945612345879;13:$;12:100;153:9439999999999999943;11:RefundPEI;10:MSR;9:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX;8:XXX;4:DATA;3:VTOL;2:1;1:1}

Request to VTOL (QueryPEI):

Request: {66:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX;173:20180905111046;11:QueryPEI;10:MSR;9:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX;4:DATA;3:VTOL;164:1;71:True;2:1;25:20180905111059;1:1}

1.4.16.2 Respuesta

Referencias

X = Obligatorio

O = Opcional

- = No requerido

Número	Nombre del campo	Tipo de dato	SalePEI	RefundPEI	QueryPEI	Descripción
0	company	Numérico	X	X	X	Identificador de la compañía donde se generó la transacción
1	store	Alfanumérico	X	X	X	Identificador del sitio originador de la transacción
2	node	Numérico	X	X	X	Identificación del nodo, en el sitio originador, donde se generó la transacción
25	dateTime	Numérico	X	X	X	Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. El valor en este campo debe ser el mismo que el valor de la fecha y hora del requerimiento. El POS utiliza este dato para validar que se trate de la misma transacción
26	responseCode	Alfanumérico	X	X	X	Puede contener uno de los siguientes valores: Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27 Error = ver sección Códigos de error del CORE TrxIsPending: indica si existen transacciones pendientes de confirmar. En este caso, el ID de transacción a confirmar está en el campo 24
27	isoCode	Numérico	X	X	X	Código de Respuesta ISO-8583 emitido por el centro autorizador. 2 dígitos como máximo. Ver sección Códigos de Respuesta de VTOL Server para PEI
28	responseMessage	Alfanumérico	X	X	X	Mensaje de la Respuesta ISO-8583 relacionado con el código del campo 27
35	errorDescription	Alfanumérico	X	X	X	Descripción de error. Sólo se encuentra presente si el valor del campo 26 es “Error”
153	idOperationPEI	Alfanumérico	X	X	X	Identificador de la operación PEI de pago o de devolución
154	idOperationOrigenPEI	Alfanumérico	-	X	O	Identificador de la operación PEI de origen con la cual se solicitó la devolución.
170	idCommercePEI	Alfanumérico	X	X	X	Identificador PEI de compañía
171	idBranchPEI	Alfanumérico	X	X	X	Identificador PEI de local
172	idTerminalPEI	Alfanumérico	X	X	X	Identificador PEI de terminal
174	originalTrxStatus	Numérico	-	-	O	Informa el estado de la transacción original en una operación de consulta. Si el campo en la respuesta no se recibe es porque la consulta falló. Puede contener uno de los siguientes valores: 0: Aprobada 1: Rechazada 2: En proceso
278	bankingRefNum	Alfanumérico	X	-	X	Numero de referencia de la transacción de pago. Se utiliza para conciliar con los reportes de las entidades bancarias. Número generado por LINK.

Ejemplo

Response from VTOL (SalePEI):

Response message: {25:20180905111036;2:1;1:1;171:87;170:143;153:9439999999999999943;172:SYN001;27:00;26:ISO8583;28:APROBADA}

Response from VTOL (RefundPEI):

Response message: {25:20180905111046;2:1;1:1;171:87;170:143;154:9439999999999999943;153:3879999999999999387;172:SYN001;27:00;26:ISO8583;28:APROBADA}

Response from VTOL (QueryPEI):

Response message: {25:20180905111059;2:1;1:1;171:87;170:143;154:9439999999999999943;153:3879999999999999387;172:SYN001;27:00;174:0;26:ISO8583;28:APROBADA}

1.4.17 Tokenize

Mensaje utilizado para el pago de resumen de cuenta de una tarjeta de crédito.

1.4.17.1 Requerimiento

#	FieldId	Tipo	Obligatorio	Descripción
0	company	Numérico	SI	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	SI	Identificador del sitio originador de la transacción
2	node	Numérico	SI	Identificación del nodo, en el sitio originador, donde se generó la transacción
3	server	Alfanumérico	Compatibilidad atrás.	Identificador del Server que procesará la transacción. ('VTOL')
4	messageType	Alfanumérico	Compatibilidad atrás.	Tipo de Mensaje: Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server. Data = Mensaje de la Aplicación cliente.
6	cardNumber	Numérico	Obligatorio	Número de tarjeta
7	expiration	Numérico	Obligatorio	Formato YYYYMM Fecha de vencimiento de la tarjeta
11	trxType	Alfanumérico	Obligatorio	Tipo de Transacción: Tokenize = Tokenización
157	customerDoc	Alfanumérico	Obligatorio	Número de documento del titular de la tarjeta
265	customerId	Alfanumérico	Obligatorio	Identificador del usuario o comprador
266	cardHolderName	Alfanumérico	Obligatorio	Nombre del tarjetahabiente

1.4.17.2 Respuesta

#	FieldId	Tipo	Descripción
0	company	Numérico	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	Identificador del sitio originador de la transacción
2	node	Numérico	Identificación del nodo, en el sitio originador, donde se generó la transacción
22	authorizationCode	Alfanumérico	Código de autorización generado por el centro autorizador para la transacción.
23	authorizationMode	Alfanumérico	Modo de Autorización: Online = La autorización fue realizada por el Centro Autorizador. Offhost = La autorización fue realizada internamente por VTOL. Offline = La autorización fue realizada localmente por el POS.
24	lastTrxId	Numérico	Id de transacción. En caso que el Campo 26 sea TrxIsPending, contendrá el trxId de la transacción pendiente.
25	dateTime	Numérico	Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS.
26	responseCode	Alfanumérico	Puede contener uno de los siguientes valores: Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27 Error = ver sección Código de errores del CORE TrxIsPending: indica si existen transacciones pendientes de confirmar. En este caso, el ID de transacción a confirmar está en el campo 24.
27	isoCode	Numérico	Código de Respuesta ISO-8583 emitido por el centro autorizador. 2 dígitos como máximo
28	responseMessage	Alfanumérico	Mensaje de la Respuesta ISO-8583
201	additionalMessageData	Alfanumérico	Este campo tiene como finalidad que el POS, o cliente VTOL, pueda enviar un dato X y que el mismo esté presente en la respuesta. Cada módulo según implementación puede decidir qué hacer con dicho dato (Ejem Persistir en BBDD).
263	vtolToken	Alfanumérico	Token VTOL tras tokenizar una tarjeta
267	vtolTokenExpire	Numérico	Fecha y hora de expiración del Token VTOL en formato YYYYMMDD

1.4.18 Billeteras electrónicas

VTOL se integra con las siguientes billeteras electrónicas para permitir efectuar pagos en los puntos de venta:

Mercado Pago: La plataforma de pagos online más importante de América Latina
Todo Pago: La plataforma de pagos de Prisma

Las operaciones soportadas en VTOL Server para Billeteras electrónicas son:

SaleWallet = Permite realizar una compra presencial con billetera
RefundWallet = Permite realizar una devolución (parcial o total) de una compra presencial con billetera realizada con anterioridad
QuerySaleWallet = Permite realizar una consulta de una operación de compra con billetera para conocer si la misma fue autorizada y así obtener los datos de la misma por parte del Autorizador. Y además para Todo Pago se utilizará para informar las cuotas.

Nota

Las operatorias de billeteras electrónicas poseen tercer mensaje.

Procedimiento para Mercado Pago

El proceso de pagos con billetera virtual se realizará de la siguiente manera:

Se inicia con el envío de una orden de venta (transacción SaleWallet) por parte del POS a VTOL.
Recién en ese momento el comprador podrá efectuar la lectura del código QR impreso en la caja mediante su smartphone.
Mercado Pago, con la información de la orden de venta recibida por VTOL, le comunicará a la app de la billetera virtual el importe total y el detalle de los artículos adquiridos.
El comprador visualizará en su app mobile el detalle de la compra, y efectuará el pago seleccionado el medio de pago (tarjeta, o saldo de Mercado Pago), la tarjeta enrolada (o incorporando una nueva), las cuotas y confirmando el pago.
El POS recibirá la respuesta de la transacción SaleWallet a través de VTOL, quien informará si la operación resultó autorizada por Mercado Pago.
1. Puede darse el caso que VTOL responda "Consulte el pago por tiempo expirado". Este escenario puede surgir cuando el cliente demora en confirmar el pago desde su app mobile, y expira el tiempo designado por defecto en VTOL, entonces al POS se le da una respuesta automática por timeout. Para conocer el resultado de la operación, el POS deberá realizar una consulta (transacción QuerySaleWallet). Las respuestas del QuerySaleWallet pueden ser las siguientes:
  1. VTOL responde "Aprobado". Indica que el pago fue autorizado por Mercado Pago. El paso siguiente del POS es confirmar o cancelar la transacción, con un tercer mensaje.
  2. VTOL responde "Pago Rechazado, desea seguir esperando?". Indica que el cliente intentó pagar pero Mercado Pago rechazó el pago, pero a su vez el cliente puede volver a intentar realizar el pago con otra tarjeta u otro medio de pago, por lo cual el POS puede "seguir esperando" para permitirle al cliente intentar pagar nuevamente, y luego el POS deberá enviar un nuevo QuerySaleWallet, o directamente cancelar la operación.
Por último, el POS deberá confirmar la operación, mediante el tercer mensaje (transacción UnsyncCompletion).

Para obtener de forma completa todo el detalle de la transacción, posterior venta, el POS deberá enviar de forma automática la transacción QuerySaleWallet.

La anulación, no precisa de interacción por parte del comprador en la caja. Simplemente el POS envía el identificador del número de pago del Autorizador en el mensaje RefundWallet.

Procedimiento para Todo Pago

El proceso de pagos con billetera virtual de Todo Pago difiere respecto de Mercado Pago, ya que el cliente en su app mobile simplemente selecciona la tarjeta con la cual realizará el pago, y luego el resto de la operatoria la deberá realizar el cajero, es decir, el ingreso de las cuotas, promociones, etc. El proceso se realizará de la siguiente manera:

Se inicia con el envío de una orden de venta (transacción SaleWallet) por parte del POS a VTOL.
Recién en ese momento el comprador podrá efectuar la lectura del código QR impreso en la caja mediante su smartphone. Seleccionará la tarjeta con la cual realizará el pago. Y luego aceptará la tarjeta elegida en su app mobile.
VTOL recibirá la información de la tarjeta del cliente, por medio de Todo Pago, y le responderá al POS que se deben ingresar las cuotas según los planes de pago disponibles (sólo para aquellos comercios que permitan pagos en cuotas).
El POS ingresará las cuotas, y enviará la información a VTOL por medio de la transacción QuerySaleWallet.
El POS recibirá la respuesta de la transacción a través de VTOL, quien informará si la operación resultó autorizada por Todo Pago.
1. Puede darse el caso que VTOL responda "Consulte el pago por tiempo expirado". Este escenario puede surgir por algún problema de conexión y VTOL no pudo obtener el mensaje sobre el resultado de Todo Pago. Con este mensaje se le informa al POS que para conocer el resultado de la operación, deberá realizar una nueva consulta (transacción QuerySaleWallet). Las respuestas del QuerySaleWallet pueden ser las siguientes:
  1. VTOL responde "Aprobado". Indica que el pago fue autorizado por Todo Pago. El paso siguiente del POS es confirmar o cancelar la transacción, con un tercer mensaje.
  2. VTOL responde "Pago Rechazado". Indica que el pago no fue autorizado por Todo Pago. Por lo tanto la operación no puede continuar. Si el POS deberá iniciar una nueva transacción.
Por último, el POS deberá confirmar la operación, mediante el tercer mensaje (transacción UnsyncCompletion).

1.4.18.1 Requerimiento

Referencias

X = Obligatorio
O = Opcional
- = No requerido

Número	Nombre del campo	Tipo de dato	SaleWallet	RefundWallet	QuerySaleWallet	Descripción
0	company	Numérico	X	X	X	Identificador de la compañía donde se generó la transacción.
1	store	Alfanumérico	X	X	X	Identificador del sitio originador de la transacción
2	node	Numérico	X	X	X	Identificación del nodo, en el sitio originador, donde se generó la transacción
3	server	Alfanumérico	X	X	X	Identificador del Server que procesará la transacción. (en el caso de VTOL será 'VTOL')
4	messageType	Alfanumérico	X	X	X	Tipo de Mensaje: Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server. Data = Mensaje de la Aplicación cliente.
11	trxType	Alfanumérico	X	X	X	Tipo de Transacción: SaleWallet = Compra con billetera electrónica RefundWallet = Devolución de compra realizada con billetera electrónica QuerySaleWallet = Consulta de transacción de compra realizada con billetera electrónica
12	amount	Importe	X	X	-	Monto de la transacción. 12 dígitos como máximo. Se envía sin coma. Los dos últimos dígitos representan los decimales. Ej: 1000 equivale a 10.00 Nota: El importe debe ser el número correspondiente a la moneda informada
13	currencyPosCode	Alfanumérico	X	X	-	Tipos de moneda: $ = Pesos U$S = Dólares Nota: En el punto de venta se deberá informar la moneda de la cuenta vendedor de Mercado Pago (si el retailer posee una cuenta argentina en Mercado Pago entonces tendrá que informar la moneda $ -pesos argentinos-) Nota: Para Todo Pago la moneda siempre es $ -pesos argentinos- Importante: Tener en cuenta que operando con Mercado Pago siempre debe coincidir el país de la cuenta vendedor con el país de la cuenta comprador
14	payments	Numérico	-	-	O	Cantidad de cuotas por las cuales se realizará el pago. 2 dígitos como máximo Si es sin cuotas, el valor por defecto es 1
15	plan	Alfanumérico	-	-	O	Plan. 1 caracter de longitud
16	originalDate	Numérico	-	X	X	Fecha de realización de la compra con billetera electrónica en formato YYYYMMDD
24	lastTrxId	Numérico	O	O	O	Utilizado cuando está activo el control transaccional. En este campo el POS debe enviar la última transacción procesada correctamente.
25	dateTime	Numérico	X	X	X	Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS
53	paymentCondition	Alfanumérico	-	-	O	Condición de pago. Sólo se encuentra presente si existe una condición de pago vinculada con la transacción
71	checkPendingString	Alfanumérico	O Default = true	O Default = true	O Default = true	Indica si VTOL debe o no efectuar el chequeo de pendientes (se emplea para pagos parciales de tarjetas): True: activa chequeo de pendientes. False: desactiva chequeo de pendientes.
147	providerPosCode	Alfanumérico	-	-	O	Proveedor / tarjeta seleccionada manualmente de la lista devuelta por VTOL. Por Ejemplo: Si el saleWallet retorna la lista {VI, EL}, en el querySaleWallet se debe enviar el valor seleccionado entre las dos opciones VI o EL.
268	walletPosTrxId	Alfanumérico	X	-	O	Identificador único de la transacción de billetera para la compañía. Es originado por el POS para realizar una compra con billetera Formato: codigoTienda (longitud 10) + codigoCaja (longitud 10) + Fecha (AAMMDDHHmmss) (longitud 12) Longitud total de 32 Opcional en QuerySaleWallet: Se informa este campo o el campo walletPaymentId para localizar una transacción de compra
269	walletType	Numérico	X	X	X	Tipo de billetera por la cual se cursará la transacción en el POS. Opciones: 1: Mercado Pago 2: Todo Pago
270	posTicket	Base 64	X	-	-	Información del ticket en formato xml y posteriormente transformado en Base 64. Ver sección Estructura del campo posTicket
271	walletPaymentId	Alfanumérico	-	X	O	Identificador del número de pago informado por el Autorizador en el campo 271 de la respuesta de la operación SaleWallet Opcional en QuerySaleWallet: Se informa este campo o el campo walletPosTrxId para localizar una transacción de compra

Ejemplo

Request to VTOL (SaleWallet):

Request: {270:PG1lc3NhZ2U+CiAgICAgICA8aXRlbS1hZGQgc2VxPSIxIiBjb2RlPSIwMDAxIiBkaXNjb3VudGFibGU9InRydWUiIHVuaXRwcmljZT0iMjUuMCIgcXR5PSIxLjAiIGxldmVsMT0iTUVOIiBsZXZlbDI9IkNBU1VBTCIgc3VwcGxpZXI9IiIgYnJhbmQ9IkxFVklTIiB4cHJpY2U9IjI1LjAiIG1hZ25pdHVkZT0iMS4wIiBkZXNjcmlwdGlvbj0iSmVhbiBjYXN1YWwiIGN1cnJlbmN5PSIkIiAvPgogICAgICAgPGl0ZW0tYWRkIHNlcT0iMiIgY29kZT0iMDAwMiIgZGlzY291bnRhYmxlPSJ0cnVlIiB1bml0cHJpY2U9IjI4LjAiIHF0eT0iMi4wIiBsZXZlbDE9Ik1FTiIgbGV2ZWwyPSJDQVNVQUwiIHN1cHBsaWVyPSIiIGJyYW5kPSJMRVZJUyIgeHByaWNlPSI0OC4wIiBtYWduaXR1ZGU9IjEuMCIgZGVzY3JpcHRpb249IkplYW4gY2FzdWFsIiBjdXJyZW5jeT0iJCIgLz4KPC9tZXNzYWdlPg==;269:1;268:1120181116055713;13:$;12:1200;11:SaleWallet;4:DATA;3:VTOL;2:1;25:20181116055713;71:True;1:1}

Request to VTOL (RefundWallet):

Request: {271:4379999999999999437;269:1;16:20181116;13:$;12:1200;11:RefundWallet;4:DATA;3:VTOL;2:1;25:20181116105619;71:True;1:1}

Request to VTOL (QuerySaleWallet):

Request: {271:2289999999999999228;269:1;16:20190214;268:11020190514050534;25:20190214050534;11:QuerySaleWallet}

Estructura del campo posTicket

El mensaje con la estructura del ticket estará en XML. El elemento raíz de ese mensaje XML deberá ser la etiqueta <message>, siendo la misma lo que se llamará encabezado.

La manera de ejecutar un comando es utilizando una etiqueta con la forma <elemento-comando>. El elemento "item" identifica a los artículos. De esta manera, si se desea, por ejemplo, agregar un nuevo artículo el comando a utilizar será <item-add>. En el cuerpo del mensaje podrá contener uno, ninguno o varios de estos comandos.

Cada uno de los comandos que se envían posee diversos atributos, los cuales identifican al elemento que se está enviando y definen diversas propiedades que poseen los mismos. Poseerá un número de secuencia, el cual identifica cada elemento unívocamente:

Propiedad	Tipo de dato	Descripción	Requerido
*seq*	Entero positivo	Número identificador único del elemento dentro de la transacción.	Sí

Cada comando posee una serie de atributos que definirán las distintas propiedades del elemento que se está agregando (además del número de secuencia antes mencionado).

Para el elemento ítem, los atributos serán los siguientes:

Elemento	Atributo	Tipo de dato	Descripción	Requerido	Valor ante ausencia
Ítem	*unitprice*	Numérico positivo	Precio unitario del artículo en cuestión.	Si
	*xprice*	Numérico positivo	Precio extendido del artículo en cuestión. Es igual a la cantidad por el precio unitario.	Si
	*qty*	Entero positivo	Cantidad de artículos en la línea.	Si
	*magnitude*	Numérico positivo	Si el artículo es mensurable por otro unidad que no sea la cantidad, deberá ser expresad en esta propiedad.	No	0
	*code*	Alfanumérico	Código propio del artículo.	No	"-"
	*brand*	Alfanumérico	Marca del artículo.	No	"-"
	*supplier*	Alfanumérico	Proveedor al que pertenece el artículo.	No	"-"
	*discountable*	Alfanumérico	Si el artículo es puede recibir descuentos o no.	No	"-"
	*level1*	Alfanumérico	Nivel 1 de categorización del artículo. Anteriormente este nivel se conocía con el nombre de Departamento.	No	"-"
	*level2*	Alfanumérico	Nivel 2 de categorización del artículo. Anteriormente este nivel se conocía como la Familia del artículo.	No	"-"
	*level3*	Alfanumérico	Nivel 3 de categorización del artículo. Anteriormente este nivel se conocía como la Categoría del artículo.	No	"-"
	*level4*	Alfanumérico	Nivel 4 de categorización del artículo. Anteriormente este nivel se conocía como la subcategoría del artículo.	No	"-"
	description	Alfanumérico	Descripción del ítem	Si
	currency	Alfanumérico	Moneda utilizada en el precio del ítem Nota: En el punto de venta se deberá informar la moneda de la cuenta vendedor de Mercado Pago (si el retailer posee una cuenta argentina en Mercado Pago entonces tendrá que informar la moneda $ -pesos argentinos-).	Si

Ejemplo

<message>
<item-add seq="1" code="0001" discountable="true" unitprice="25.0" qty="1.0" level1="MEN" level2="CASUAL" supplier="" brand="LEVIS" xprice="25.0" magnitude="1.0" description="Jean casual" currency="$" />
<item-add seq="2" code="0002" discountable="true" unitprice="28.0" qty="2.0" level1="MEN" level2="CASUAL" supplier="" brand="LEVIS" xprice="48.0" magnitude="1.0" description="Jean casual" currency="$" />
</message>

Importante

Esta estructura generada debe transformarse al formato Base 64 para informárselo a VTOL en el campo 270 posTicket.

1.4.18.2 Respuesta

Número	Nombre del campo	Tipo de dato	SaleWallet	RefundWallet	QuerySaleWallet	Descripción
0	company	Numérico	X	X	X	Identificador de la compañía donde se generó la transacción
1	store	Alfanumérico	X	X	X	Identificador del sitio originador de la transacción
2	node	Numérico	X	X	X	Identificación del nodo, en el sitio originador, donde se generó la transacción
6	cardNumber	Alfanumérico	O	-	O	Tarjeta enmascarada seleccionada al momento de efectuar el pago QR. El campo es opcional en caso de que se haya abonado con saldo de la cuenta de Mercado Pago
12	amount	Importe	-	-	X	Monto de la transacción
13	currencyPosCode	Alfanumérico	-	-	X	Tipos de moneda: $ = Pesos U$S = Dólares
14	payments	Numérico	-	-	O	Cantidad de cuotas seleccionadas al momento de realizar el pago QR. El campo es opcional en caso de que se haya abonado con saldo de la cuenta de Mercado Pago
22	authorizationCode	Alfanumérico	X	-	X	Código de autorización informado por el Autorizador
24	trxId	Numérico	X	X	X	Identificador de la transacción
25	dateTime	Numérico	X	X	X	Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. El valor en este campo debe ser el mismo que el valor de la fecha y hora del requerimiento. El POS utiliza este dato para validar que se trate de la misma transacción
26	responseCode	Alfanumérico	X	X	X	Puede contener uno de los siguientes valores: Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27 Error = ver sección Códigos de error del CORE TrxIsPending: indica si existen transacciones pendientes de confirmar. En este caso, el ID de transacción a confirmar está en el campo 24
27	isoCode	Numérico	X	X	X	Código de Respuesta emitido por el centro autorizador. 2 dígitos como máximo. Ver sección Códigos de Respuesta de VTOL Server para Billeteras Electrónicas
28	responseMessage	Alfanumérico	X	X	X	Mensaje de la Respuesta relacionado con el código del campo 27
140	paymentType	Numérico	-	-	X	Tipo de pago. Valores posibles: 0: Tarjeta 1: Efectivo
142	providerName	Alfanumérico	-	-	O	Proveedor de la tarjeta seleccionada al momento de efectuar el pago QR. El campo es opcional en caso de que se haya abonado con saldo de la cuenta de Mercado Pago
147	providerPosCode	Lista	O	-	-	Lista de proveedores/tarjetas que coinciden con la tarjeta ingresada en la app de la billetera electrónica. Ejemplo: {VI, EL}. Esta lista deberá ser utilizada para seleccionar la tarjeta manualmente por el POS.
157	customerDoc	Numérico	O	O	O	Numero de documento del titular de la tarjeta.
303	customerName	Alfanumérico	O	O	O	Nombre del titular de la tarjeta.
166	trxReferenceNumber	Numérico	X	X	-	Identificador único de la transacción en VTOL Server. Longitud entre 19 y 20 dígitos, debido a que utiliza el día como parte de formato
271	walletPaymentId	Alfanumérico	X	-	X	Identificador del número de pago informado por el Autorizador
272	amountRefunded	Importe	-	-	X	Monto devuelto en la transacción
273	paymentStatus	Alfanumérico	-	-	X	Estado de la transacción de pago informado por el Autorizador. Estados posibles: 0: Aprobado 1: Devuelto 2: Pendiente 3: Autorizado 4: En Progreso 5: En mediacion 6: Rechazado 7: Cancelado 8: Contracargo
274	paymentStatusDetail	Alfanumérico	-	-	X	Detalle del estado de la transacción de pago informado por el Autorizador
275	cardType	Numérico	-	-	O	Tipo de tarjeta seleccionada al momento de efectuar el pago QR. El campo es opcional en caso de que se haya abonado con saldo de la cuenta de Mercado Pago. Valores posibles: 0: Débito 1: Crédito
1010	currentSessionId	Numérico	X	X	X	Identificador de la sesión
1027	libResponseCode	Numérico	X	X	X	Código de respuesta de la librería. Indica cómo fue procesada la operación en EMVKIT: Éxito = 000 Error <> 000 Ver sección Códigos de Respuesta de Librería
1028	libResponseMessage	Alfanumérico	X	X	X	Mensaje descriptivo del código de respuesta de la librería

Ejemplo

Response from VTOL (SaleWallet):

Response message: {1:1;2:1;1027:000;1028:Ok;166:14021905052200000204;271:2289999999999999228;1010:1550131493463;22:1234567;24:121;25:20190214050518;26:ISO8583;27:00;28:APROBADA}

Response from VTOL (RefundWallet):

Response message: {1:1;2:1;1010:1550131493463;1027:000;1028:Ok;25:20190214050543;26:ISO8583;27:509;28:Estado trx original no acepta devolucion}

Response from VTOL (QuerySaleWallet):

Response message: {1:1;2:1;1027:000;1028:Ok;6:450995xxxxxx3704;140:0;12:53.0;13:$;14:1;142:visa;271:2289999999999999228;272:0.0;273:0;274:accredited;1010:1550131493463;275:1;22:1234567;24:121;25:20190214050534;26:ISO8583;27:00;28:APROBADA}

1.5 Códigos de Respuesta al POS

La respuesta que el POS recibe de VTOL se encuentra en los siguientes campos:

Campo 27: Código de Respuesta
Campo 28: Descripción de la Respuesta

A continuación se detallan las respuestas posibles con una breve descripción de cada una:

Código	Descripción
'00'	Aprobada
'01'	Pedir autorización telefónica
'02'	Pedir autorización
'03'	Comercio inválido
'04'	Capturar tarjeta
'05'	Denegada
'07'	Retenga y llame
'11'	Aprobada
'12'	Transacción inválida
'13'	Monto inválido
'14'	Tarjeta inválida
'25'	No existe original
'30'	Error en formato
'38'	Excede ingreso de PIN
'43'	Retener tarjeta
'45'	No opera en cuotas
'46'	Tarjeta no vigente
'47'	PIN requerido
'48'	Excede máximo de cuotas
'49'	Error fecha de vencimiento
'50'	Entrega supera límite
'51'	Fondos insuficientes
'53'	Cuenta inexistente
'54'	Tarjeta vencida
'55'	PIN incorrecto
'56'	Tarjeta no habilitada
'57'	Transacción no permitida
'58'	Servicio inválido
'61'	Excede límite
'65'	Excede límite de tarjeta
'76'	Llamar al emisor
'77'	Error plan/cuotas
'85'	Aprobada
'86'	No envía fecha original
'89'	Terminal inválida
'91'	Emisor fuera de línea
'94'	Número de secuencia duplicado
'95'	Re-transmitiendo
'96'	Error en sistema
'98'	No aprobada
'99'	Error no clasificado
	Modo de ingreso inválido
	Proveedor inválido
	Error CVC
	Error creando mensaje
	Tipo de mensaje inválido
	No envía código de autorización
	Error en fecha efectiva
	Error en fecha vencimiento
	Tarjeta no efectiva
	No opera off-line
	Devolución monto mayor
	Original ya anulada
	Original ya devuelta
	Original reversada
	Moneda inválida
	No envía fecha
	Campo 71 inválido
	Campo 71 nulo
	CVC inválido
	Tarjeta inválida
	Track2 inválido
	No envía moneda
	No envía CVC
	Timeout
	Fecha original inválida
	No envía ticket original
	Ticket original inválido
	No envía código de autorización de venta referida
	Reintente
	Chiptokens Invalido
	Pinpad R. Cod. Error
	Pinpad A. Cod. Error

Nota: La respuesta con código '99' representa un error en el procesamiento interno de VTOL, independientemente de la interacción con el Centro Autorizador. Dicho error no debe ser manejado por el POS.

1.5.1 Códigos de Respuesta de VTOL Server para PEI

A continuación se detallan las respuestas posibles de VTOL Server, cuando se opera con PEI, con una breve descripción de cada una:

Código	Descripción
00	APROBADA
300	Se agoto el tiempo de espera
301	La sucursal ingresada es incorrecta
302	El concepto ingresado es incorrecto
303	El concepto ingresado no esta disponible
304	El concepto ingresado no esta habilitado
305	La cuenta destino del pago es incorrecta
306	La cuenta destino no esta habilitada
307	La cuenta origen del pago es incorrecta
308	La cuenta origen no esta habilitada
309	La Red destino del pago es incorrecta
310	La cuenta del comercio es incorrecta
311	La cuenta de la sucursal es incorrecta
312	El comercio supero el importe máximo
313	La sucursal supero el importe máximo
314	La tarjeta ha superado el importe diario
315	Comercio ha superado el importe diario
316	Comercio ha superado el importe mensual
317	Comercio supero las trxs diarias
318	Comercio supero las trxs mensuales
319	La sucursal supero el importe diario
320	La sucursal supero el importe mensual
321	La sucursal supero las trxs diarias
322	La sucursal supero las trxs mensuales
323	Encriptacion incorrecta
324	El DNI no coincide con el de la tarjeta
325	Los datos de tarjeta no se condicen
326	El comercio es invalido
327	Cuenta destino del comercio es invalida
328	La tarjeta es invalida
329	La referencia de trx ya fue utilizada
330	El importe no es un numero mayor a cero
331	Ultimos 4 dig. no coinciden con la tarj.
332	Tarjeta inhabilitada para operar
333	Tarjeta vencida
334	Fondos insuficientes
335	El CBU Banelco ingresado es incorrecto
336	El ALIAS CBU Banelco es incorrecto
337	El id de pago es invalido
338	El id del canal es invalido
339	Importe excede saldo remanente del pago
340	El ID de requerimiento es invalido
341	IP de cliente invalida
342	Existe una devolucion aprobada del pago
343	El pago tiene devoluciones parciales
344	Pago no admite el tipo de devolucion
345	Pago no admite el tipo de devolucion
346	Terminal en uso
347	Terminal PEI Invalida
348	Comercio PEI Invalido
349	Sucursal PEI Invalida
350	Id operacion Requerido
351	Id operacion Rango invalido
352	Ultimos cuatro digitos invalidos
353	Numero de documento requerido
354	Trx original no se puede devolver
355	La cuenta es incorrecta
356	La cuenta no está habilitada
357	La cuenta del comercio es incorrecta
358	La cuenta de la sucursal es incorrecta
359	Comercio supero monto para concepto
360	Sucursal supero monto para concepto
361	Tarjeta supero monto tipo de operacion
362	Comercio supero monto tipo operacion
363	Comercio supero monto tipo operacion
364	Comercio supero cantidad transacciones
365	Comercio supero cantidad transacciones
366	Sucursal supero monto diario permitido
367	Sucursal supero monto mensual permitido
368	Sucursal supero cantidad trxs diarias
369	Sucursal supero cantidad trx mensuales
370	Error al desencriptar campos encriptados
371	La cuenta destino del comercio invalida
372	Ref de trx del comercio ya fue utilizada
373	Ultimos 4 digitos incorrectos
374	El ID de requerimiento enviado invalido
375	Error General
376	Concepto ingresado no habilitado
377	Concepto ingresado no habilitado
378	Cuenta es incorrecta
379	Cuenta no está habilitada
380	ALIAS CBU red Banelco es incorrecto
381	El pago tiene devoluciones parciales
382	Esta operacion no acepta devol. total
383	Esta operacion no acepta devol. parcial
384	La fecha es invalida
385	El estado del pago es invalido
386	El Concepto Operacion es invalido
387	Estado trx original no acepta devolucion
388	Importe devolucion supero monto limite
389	No se encontró la trx original
390	No es posible devolver una devolución
391	Error en comunicación
392	Campo DateTimeOriginalTrx invalido
393	Autorizacion Original en Proceso

1.5.2 Códigos de Respuesta de VTOL Server para Antifraude

A continuación se detallan las respuestas posibles de VTOL Server, cuando se opera con Antifraude, con una breve descripción de cada una:

Código	Descripción
601	Fraude – Val BlackList
602	Posible Fraude – BlackList
603	Fraude – Velocity Check
604	Posible fraude – Velocity Check
605	Error val concurrente, posible fraude
606	Error val velocitycheck, posible fraude
607	Error gral validación de Antifraude
610	Faltan campos requeridos en el req.

1.5.3 Códigos de Respuesta de VTOL Server para Tokenización

A continuación se detallan las respuestas posibles de VTOL Server, cuando se opera con Tokenización, con una breve descripción de cada una:

Código	Descripción
400	Tarjeta no soporta tokenizacion
401	Excedio tiempo de tokenizacion
402	Token error comunicacion
403	Token error persistencia
404	Token error parseo campo
405	Token error respuesta NOK
406	VTOL TOKEN Expirado
407	Error generar token
408	VTOL Token no encontrado
409	VTOL token requerido
410	Token publico no encontrado en comercio
411	Token publico expirado
412	No existe num de comercio para tokenizar

1.5.4 Códigos de Respuesta de VTOL Server para Billeteras electrónicas

A continuación se detallan las respuestas posibles de VTOL Server, cuando se opera con Billeteras Electrónicas, con una breve descripción de cada una:

Código	Descripción
00	APROBADA
500	No se encuentra la transaccion original
501	El campo WalletPosTrxId es requerido
502	El campo WalletType es requerido
503	No esta configurado una Compañia MP
504	No esta configurado una Caja MP
505	El tipo de billetera es invalido
506	El campo WalletPaymentId es requerido
507	El campo OriginalDate es requerido
508	No es posible devolver una devolucion
509	Estado trx original no acepta devolucion
510	Importe devolucion supero monto limite
511	No se pudo realizar la orden de pago
512	La transaccion no posee estado
513	El campo posTicket es requerido
514	Consulte el pago por tiempo expirado
515	Tiempo expirado confirmacion devolucion
516	No se encuentra el pago original
517	Estado trx original no acepta devolucion
518	No se encuentra la devolucion
519	Acceso a MP no esta autorizado
520	Accion a MP no esta autorizada
521	El campo WalletPosTrxId es invalido
523	Estado trx original no acepta devolucion
524	Importe invalido para devolucion
525	Estado trx original no acepta devolucion
526	Compañia MP no permite operar
527	Numero devoluciones parciales superados
528	El pago es antiguo para ser devuelto
529	No es posible devolver una devolucion
530	Compañia MP sin dinero para devolver
531	Compañia MP sin dinero disponible
532	Estado trx original no acepta devolucion
533	Devolucion parcial no soportada
534	Url de notificacion invalido
535	El monto de la transaccion es invalido
536	Error general por parte de MP
537	No se encuentra la transaccion original
538	El campo WalletPosTrxId es requerido
539	Devuelto
540	Pendiente
541	Autorizado
542	En Progreso
543	En mediacion
544	Rechazado
545	Cancelado
546	Contracargo
547	No se encontró la trx original
548	Error en comunicación
549	No existe comunicación con Mercado Pago
550	Error al consultar venta original online

1.6 Código de errores del CORE

Es posible que VTOL responda "Error" en el campo 26 del mensaje de respuesta. Éste valor indica que se ha producido un error dentro del flujo inicial y principal del core de VTOL, previo al procesamiento de las reglas de negocio asociadas al tipo de transacción.
Normalmente los casos en donde se puede dar ésta situación son los siguientes:
Por ejemplo:

Si el nodo o el store son inválidos
Si el mensaje tiene un formato erróneo
Si el campo 11 no fue enviado en el requerimiento
Si el campo 11 tiene un valor no soportado por VTOL
Si el campo 1 no fue enviado en el requerimiento
Si el campo 2 no fue enviado en el requerimiento
Si un campo enviado en el requerimiento no es soportado por VTOL
Si VTOL no tienen conexión con base de datos
Si hay otro error interno al core (la transacción no llegó al módulo)
Si la transacción se empezó a procesar en el módulo y éste nunca responde. Esto provoca que se active un flujo alternativo de Timeout del CORE que se da a los 60 segundos.
Si el CORE no puede aceptar más transacciones porque está sobrecargado

El mensaje de respuesta tiene siempre el siguiente formato:

Dónde:

Donde 32 y 31 se responden por compatibilidad hacia atrás con otras implementaciones.
El campo 28 siempre posee la descripción del error.
El campo 27 siempre es "99".
El campo 26 siempre dice "Error".
El campo 25 es la hora del requerimiento.

1.7 Formato Interface POS

A continuación se detalla la información que viaja en el campo ConfData y que se corresponde con la interface generada para el POS.
La versión de Formato de interface utilizada por Crédito Debito Argentina es la v101

Header

Pos.	Descripción	Longitud	Tipo de dato	Detalle
1	HD	2	AN	Identificador de tipo de registro
2	Local	6	AN	Código local.
3	Incremental	6	N	Nº de incremental.
4	CRC	8	N
5	Fecha / Hora	16	AN	Fecha/Hora. yyyy/mm/dd

Ejemplo:
HD:000001;000004;00003d23;2008/03/07 10:20

Tabla Provider

Pos.	Descripción	Longitud	Tipo de dato	Detalle
1	PV	2	AN	Identificador de tipo de registro
2	ID Tarjeta	2	AN	ID proveedor VTOL
3	Nombre	40	AN	Nombre proveedor
4	Medio de Pago	20	AN	Código proveedor en POS. Campo de relación entre POS y VTOL (Opcional)

Ejemplo:
PV:VI;Visa;
PV:MA;Mastercard;

Tabla Prefijos

Pos	Descripción	Longitud	Tipo de dato	Detalle
1	PF	2	AN	Identificador de tipo de registro
2	Hasta	20	AN	Rango Desde.
3	Desde	20	AN	Rango Hasta.
4	Largo prefijo	2	N	Largo del prefijo.
5	Largo tarjeta	2	N	Largo de la tarjeta.
6	ID Tarjeta	2	AN	ID proveedor VTOL
7	Condición	10	AN
8	Largo CVC	2	N	Largo código seguridad.
9	Validar digito	1	N	Valida el digito verificador.
10	Envía Track I	1	N	0/vacío deshabilitado / 1 habilitado / 2 Opcional.
11	Validar vencimiento	1	N	Valida fecha vencimiento.
12	Offline permitido	1	N	Permite operar offline.
13	Offline monto	14	N	Límite para operación Offline.
14	Habilitado	1	N	Prefijo habilitado.
15	Valida fecha efectiva	1	N	Valida fecha emisión o fecha desde.
16	Valida CVC	1	N	0/vacío deshabilitado / 1 habilitado / 2 Opcional.
17	Service code	5	AN	Se suele utilizar en VTOL para diferenciar Visa débito (2) de Visa crédito (0 ó vació)
18	Ingreso manual permitido	1	N
19	Chequea boletines	1	N	Valida contra boletines protectivos.
20	Es debito	1	N	Es prefijo de tarjeta de tipo débito. (0/vacío ó 1)
21	Requiere pin.	1	N	0 deshabilitado / 1 habilitado / 2 Opcional.
22	Valida últimos N números.	2	N	Cantidad de últimos números a validar de la tarjeta. 0 no valida nada.
23	Pide tipo de cuenta.	1	N	Requiere envío tipo de cuenta. (0 ó 1)
24	Solicita número de cuenta	1	N	Solicita al autorizador el número de cuenta. (0 ó 1)
25	Cashback	1	N	Habilita la operatoria de Cashback
26	Puntos de Lealtad	1	N	Habilita la acumulación y/o redención de puntos de lealtad.
27	Tarjeta que Encripta punto a punto POS - CA.	1	N	Indica si la tarjeta encripta. (0 ó 1)
28	Posición de la Master Key	1	N	Indica la posición de la Master Key en los registros del Firmware. Valores posibles: 0: Mastercard y Maestro 1: Visa 1 99: Indica que el Pinpad no tiene registro para la MK. Es el caso de tarjeta Amex.
29	Código de banco	10	AN	Código del banco
30	Permite Fallback	1	N	Visa 1; Mastercard y Maestro 0

Ejemplo:
PF:4;4;1;16;VI;;3;1;1;1;1;1000;1;0;1;;1;0;0;0;4;0;1;0;0;1;1;;1
PF:34;34;2;15;AM;;4;1;1;1;1;00;1;0;1;;1;0;0;0;0;0;0;0;0;0;;;
PF:69;50;2;16;MA;;0;0;1;0;0;1000;1;0;0;;0;0;1;1;0;1;0;0;0;0;0;;0

Tabla Monedas

Pos.	Descripción	Longitud	Tipo de dato	Detalle
1	MN	2	AN	Identificador de tipo de registro
2	Símbolo moneda	10	AN	$ ó U$S
3	Descripción	20	AN	Nombre de la moneda.

Ejemplo:
MN:$;PESOS
MN:U$S;DOLARES

Tabla Plan de Pagos

Pos.	Descripción	Longitud	Tipo de dato	Detalle
1	PP	2	AN	Identificador de tipo de registro
2	ID Tarjeta	2	AN	ID proveedor VTOL
3	Símbolo moneda	10	AN
4	Condición de pago	20	AN	Información adicional del plan de pago.
5	Plan	4	N
6	Cuotas	4	N
7	Numero de comercio	30	AN
8	ID Lote	6	N
9	Limite a superar.	13	N	Monto a superar para poder utilizar el plan de pagos. En formato 0000000000.00 0 indica sin límite
10	Limite intereses	13	N	Si el monto es superior a éste valor, entonces el interés es = 0 En formato 0000000000.00 0 indica sin límite
11	Interés	5	AN	Tasa de interés (%) para el plan de pago. En formato 00.00 0 indica sin interés
12	Promocional	1	N	Activa con 1 o Desactiva con 0, Si aplica o no una promoción para el plan de pago.

Ejemplo:
PP:AM;$;;0;1;98765432;101607;0000000000.00;0000000000.00;12.30;1
PP:VI;$;;0;10;98765432;101608;0000000100.00;0000000000.00;15.00;0

Tabla Definición de Lote

Pos.	Descripción	Longitud	Tipo de dato	Detalle
1	DL	2	AN	Identificador de tipo de registro
2	ID Lote	6	N	Identificador interno de Lote en VTOL
3	Caja o Nodo	10	N
4	Número de serie terminal	200	AN

Ejemplo:
DL:5;0000000001;99990080
DL:5;0000000002;99990081
DL:5;0000000003;99990082
DL:5;0000000004;99990083
DL:5;0000000005;99990084
DL:5;0000000006;99990085
DL:5;0000000007;99990086

Tabla Bines de Excepción

Pos.	Descripción	Longitud	Tipo de dato	Detalle
1	BE	2	AN	Identificador de tipo de registro
2	Desde	9	N	Rango Desde
3	Hasta	9	N	Rango Hasta
4	Nombre tarjeta	25	AN	Nombre de tarjeta de Excepción
5	Información Adicional	500	AN	Informacion adicional de la tarjeta de excepción

Ejemplo:
BE:6006;6006;17;ASOCIADO;Pepe-123
BE:601056;601056;16;GIFT CARD;Extra

1.8 Formato Datos Sincronización

El formato es el siguiente:
Status;PinWorkingKey;PinWorkingKeyCtrl;dataWorkingkey;dataWorkingkeyCtrl

Donde:

Status: código de estado de procesamiento de la consulta de sincronización de llaves para el autorizador en cuestión. Ver tabla códigos de estado.
PinWorkingKey: llave de PIN
PinWorkingKeyCtrl: información de control para llave de PIN
dataWorkingkey: llave de DATOS
dataWorkingkeyCtrl: información de control para llave de DATOS

Channel [POSNET] Decoded Sync Data [00;5b4940313332346231375b4940653030;6330;315b4940313336346235335b49403138;6236]

Channel [VISA] Decoded Sync Data [02]

1.8.1 Códigos de Estado

Código	Descripción
00	La sincronización con el autorizador se realizó con éxito y se obtuvieron llaves nuevas
01	No se realizó la sincronización con el autorizador debido a que el flag de sincronización forzada no fue enviado en TRUE y la terminal no estaba con estado de sincronización pendiente
02	La sincronización de llaves no está implementada para el autorizador
03	La respuesta a la sincronización de llaves no fue respondida en tiempo y forma por el autorizador

1.9 Manejo de PIN

1.10 Flujo de datos EMV

1.10.1 Tercer Mensaje - Flujo Normal

El Advice hacia el autorizador es generado luego de recibir el tercer mensaje Commit desde el POS.

Pasos:

En caso de que el campo requiredAdvice tenga valor true, el POS debe enviar en el tercer mensaje Commit, los campos chipTokens (criptograma del Advice) y pinpadResponseCode (código autorización del Pinpad).
Estos datos se incluyen el campo 200 –extraData-, con el siguiente formato:

adviceChipTokens

Nota: Si el campo requiredAdvice no tiene valor true, se envía el tercer mensaje sin el campo de datos extras.

2. VTOL procesa el tercer mensaje registrando el código de respuesta del Pinpad (Aprobada o Rechazada) y genera el Advice a enviar hacia el autorizador incluyendo los datos recibidos en el Commit.

1.10.2 Tercer Mensaje - Pagos Parciales

Los pagos parciales son permitidos, siempre y cuando no sean para la misma terminal lógica. En VTOL se valida que si la terminal tiene estado AdvicePending, no se podrá realizar otra autorización antes de enviar el Advice.
El POS debe acumular los mensajes de Advice aprobados y rechazados por el Pinpad.

En caso de que el POS finalice la transacción de POS:

- Hace Commit de todas las transacciones y se mandan los Advice

2. En caso de que el POS no finalice la transacción de POS, contingencia o anulación total, existen varias opciones que VTOL soportará. Será decisión del POS ver qué estrategia utilizar en base a cómo sea la certificación con VISA/POSNET:

- El POS hace Rollback de todas las autorizaciones:
  - VTOL elimina el Advice pendiente de enviar y hace un Rollback de las autorizaciones
- El POS hace Rollback de las autorizaciones aprobadas por CA y el Pinpad, y Commit de autorizaciones aprobadas por CA y no aprobadas por el Pinpad
  - VTOL elimina los Advice de las operaciones aprobadas por el CA y el Pinpad, y envía reversos; por otro lado, envía los Advice de las autorizaciones no aprobadas por el Pinpad.

1.11 Mecanismo en Tiendas Virtuales

Cuando se transacciona desde un POS no físico, como ser una tienda virtual, VTOL debe asignar automáticamente un número de nodo a la transacción.
Por lo que cuando se utiliza tiendas virtuales, en el requerimiento de los mensajes, no se deberá mencionar el nodo pero sí la tienda sobre la que se opera. VTOL al recibir una transacción asignará un nodo a dicha tienda. Este nodo deberá existir, estar libre para su uso y no tener transacciones pendientes.
VTOL tendrá definido un número de nodos por tienda y los manejará automáticamente. De cierto modo, esto limitará la cantidad máxima de transacciones en paralelo que la tienda soportará.

1.12 Antifraude

El módulo de Antifraude consiste en un conjunto de reglas especializado en analizar compras realizadas en los puntos de venta, con el objetivo de identificar operaciones fraudulentas. Se recolectan datos del comportamiento de los usuarios y se los compara con patrones sospechosos para aprobar o no la transacción.

El operador de un retail configurará las reglas en la consola web de VTOL y posteriormente VTOL Server validará dichas reglas precargadas con el requerimiento entregado por el POS, efectuando un rechazo en caso de activarse la regla en vez de enviarse la autorización al centro autorizador.

Nota: Para conocer cómo efectuar la configuración de Antifraude, dirigirse al documento "VTOL Core - Manual de Usuario" apartado "Antifraude".

La lógica de validación de transacción será on-line, al momento de realizar el pago.

Las reglas de antifraude disponibles son las siguientes:

Blacklist: Listas negras de números de tarjetas (conjunto de números de tarjetas fraudulentas, que el retailer puede cargar en el sistema VTOL para rechazarlas al momento de una operatoria)
Velocity checks: Reglas de acumulación (conjunto de reglas de acumulación que permiten realizar validaciones por determinados datos. Estos pueden ser: cantidad total de transacciones, cantidad de items adquiridos en una transacción, importe total sumarizado en una transacción. Estas validaciones se pueden configurar por un período establecido y también se puede configurar por el canal de ingreso de la operación)

Además, por compañía se podrá configurar qué regla antifraude se encontrará activa.

Con respecto a la mensajería, en el requerimiento de una compra, el POS precisará informar los siguientes datos según cada regla de antifraude:

Blacklist
- cardNumber (número de tarjeta)
Velocity checks
- posChannelOrigin (canal de origen de la transacción)
- cardNumber (número de tarjeta)
- user (nombre o id de usuario o cliente informado)
- userIp (IP de usuario)
- cardHolderName (titular de tarjeta)
- vtolToken (token VTOL)
- posTicket (ticket con los items adquiridos)

En la respuesta, VTOL informará si la transacción fue rechazada por fraude.

1.13 Tokenización

En Argentina, VISA ofrece el servicio de tokenización denominado PTSP -Prisma Token Service Provider- para sus tarjetas de crédito y de débito (marca VISA). La tokenización permitir efectuar pagos con tarjetas de débito y crédito en medios no presenciales (e-commerce) que por cuestiones de seguridad, hasta hoy, no se permitían y también para poder enrolar tarjetas y no tener la necesidad de solicitárselas nuevamente a los clientes.

Las transacciones que soporta la tokenización son:

ventas (pagos puntuales)
anulación
devolución
anulación de devolución
pagos recurrentes (pagos habituales con una periodicidad)

En VTOL existirán dos tipos de integraciones para los pagos puntuales:

Operación e-commerce sin billetera: Se resuelve como una venta normal, donde VTOL efectúa la tokenización y el pago y le retorna al POS, además de la respuesta de la autorización, un token VTOL con su fecha de expiración
Operación e-commerce con billetera: El POS tendrá que enviarle a VTOL dos mensajes:
- El enrolamiento (mensaje tokenize). Aquí VTOL efectuará la operatoria de enrolamiento y le devolverá al POS el token VTOL con su fecha de expiración para que se realice en un próximo paso la venta con ese token
- La venta con token VTOL (mensaje sale). VTOL efectúa la venta utilizando el token VTOL. Tener en cuenta que siempre, para pagos puntuales, aunque la tarjeta se encuentre enrolada y no sea preciso informar el PAN, se debe informar el CVV de la tarjeta

Nota: En caso de querer efectuar tokenización desde un e-commerce, será preciso integrar al e-commerce el componente VTOL Payment Bridge.

Además de poder efectuarse pagos puntuales tokenizados, se podrán efectuar pagos recurrentes (estos son pagos que se realizan con una periodicidad). Para ello, se precisa que la tarjeta ya se encuentre enrolada y tokenizada y además se debió haber realizado un pago puntual previamente con dicha tarjeta para constatar el ingreso de CVV por parte del usuario.

En VTOL, la forma de efectuar un pago recurrente será con un mensaje de venta directo hacia VTOL Server originado por un sistema de pagos recurrentes, donde se informará, además de los datos de la operación (como el importe y moneda), los siguientes valores:

el token VTOL, informado en la respuesta de VTOL. Es importante que VTOL Payment Bridge entregue al e-commerce el Token VTOL
la condición de pago de pago recurrentes, ya cargada previamente en la consola de VTOL (campo Condición de Pago, dentro de los puntos de menú Opciones de Pago y Números de comercio y definición de lote)
y el campo posChannelOrigin en 2 (Pago recurrente)

Árvore de páginas

VTOL CD AR - Manual de mensajería POS - VTOL AR

1. Campos de los mensajes

1.1 Conexión con VTOL Server

1.1.1 Ejemplo Comunicación Cliente SSL en JAVA

1.2 Protocolo de comunicación POS – VTOL Server

1.2.1 Header

1.2.1.1 Creación del Header

1.2.1.2 Lectura del Header

1.2.2 Mensaje

1.2.3 Escape de caracteres

1.3 Mecanismo de "Tercer Mensaje"

1.3.1 Descripción

1.3.2 Control de operaciones pendientes (mensaje "CheckPending")

1.3.3 Tercer Mensaje con múltiples operaciones

1.4 Transacciones permitidas

1.4.1 Venta / Pre-autorización / Anulación / Anulación Pre-autorización / Cash Back / Anulación Cash Back

1.4.1.1 Requerimiento

1.4.1.2 Respuesta

1.4.1.3 Pre-autorización

1.4.1.4 Anulación de Pre-autorización

1.4.1.5 Cash Back / Anulación Cash Back

1.4.1.6 Anulación

1.4.2 Devolución

1.4.2.1 Requerimiento

1.4.2.2 Respuesta

1.4.3 ServicePayment

1.4.3.1 Requerimiento

1.4.3.2 Respuesta

1.4.4 VoidServicePayment

1.4.4.1 Requerimiento

1.4.4.2 Respuesta

1.4.5 Consulta Membresía/Anulación Consulta Membresía

1.4.5.1 Requerimiento

1.4.5.2 Respuesta

1.4.6 Consulta de Configuración

1.4.6.1 Requerimiento

1.4.6.2 Respuesta

1.4.7 Servicio de Información de Tarjeta

1.4.7.1 Requerimiento

1.4.7.2 Respuesta

1.4.8 EMV Advice de Rechazo

1.4.8.1 Requerimiento

1.4.8.2 Respuesta

1.4.9 SynQuery

1.4.9.1 Requerimiento

1.4.9.2 Respuesta

1.4.10 Cierre de Nodo

1.4.10.1 Requerimiento

1.4.10.2 Respuesta

1.4.11 Echo

1.4.11.1 Requerimiento

1.4.11.2 Respuesta

1.4.12 Tercer Mensaje

1.4.12.1 Requerimiento

1.4.12.2 Respuesta

1.4.13 Tercer Mensaje Embebido

1.4.13.1 Requerimiento

1.4.13.2 Respuesta

1.4.14 Chequeo de Pendientes

1.4.14.1 Requerimiento

1.4.14.2 Respuesta

1.4.15 Chequeo de Listado de Pendientes

1.4.15.1 Requerimiento

1.4.15.2 Respuesta

1.4.16 Operaciones PEI

1.4.16.1 Requerimiento

1.4.16.2 Respuesta

1.4.17 Tokenize

1.4.17.1 Requerimiento

1.4.17.2 Respuesta

1.4.18 Billeteras electrónicas

1.4.18.1 Requerimiento

1.4.18.2 Respuesta

1.5 Códigos de Respuesta al POS

1.5.1 Códigos de Respuesta de VTOL Server para PEI

1.5.2 Códigos de Respuesta de VTOL Server para Antifraude

1.5.3 Códigos de Respuesta de VTOL Server para Tokenización

1.5.4 Códigos de Respuesta de VTOL Server para Billeteras electrónicas

1.6 Código de errores del CORE