Você está vendo a versão antiga da página. Ver a versão atual.

Comparar com o atual Ver Histórico da Página

« Anterior Versão 15 Próxima »



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/20183.9Incorporación de la funcionalidad PEI en la mensajería

14/12/2018 

4.0Incorporación del apartado Antifraude e incorporación de la funcionalidad Antifraude en la mensajería
08/02/20194.1Incorporación del apartado Tokenización e incorporación de la funcionalidad Tokenización en la mensajería
03/04/20194.2Agregado del campo 0 (Compañía) en la mensajería de todos los tipos de transacciones.
28/08/20194.3Incorporación de la funcionalidad Billeteras electrónicas en la mensajería.
01/04/20204.4Incorporación de mensajería para operaciones eCommerce.
22/06/20204.5Incorporación de mensajería para operaciones de Cuenta DNI.
30/07/20204.6Incorporación de funcionalidad de Billeteras Mercado Pago con retiro de efectivo.
28/08/20204.7Incorporación de consideraciones en el Formato de Interface POS en la tabla Plan de Pagos, para tiendas presenciales.
22/09/20204.8Se actualiza el campo 54 (additionalAmount) como tipo de dato Importe, en la mensajería de Billeteras electrónicas.
21/10/20204.9Incorporación de funcionalidad PEI No Presencial
26/11/20204.10Agregado del campo Descripción en Formato de Interface POS para indicar la descripción sobre un plan de pago.
11/12/20204.11Incorporación de funcionalidad de QR Adquiriente.
16/12/20204.12Incorporación del campo afApplicationCondition para validar la aplicación de reglas antifraudes por el módulo AF de VTOL.
05/03/20214.13Se actualiza el nombre y la descripción del campo 406 en la respuesta de la mensajería de QR Adquiriente.
05/05/20214.14Incorporación de mensajería para Consultar tarjetas de Fidelidad
11/05/20214.15Se quitan las referencias de la billetera Todo Pago, ya que dicha Billetera está incluida dentro de QR Adquiriente Prisma.


Í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      =   212 + 24 + 23 + 21 = 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:

  1. El POS envía un requerimiento de autorización a VTOL.
  2. VTOL responde al POS que el requerimiento fue autorizado y envía el ID de la transacción.
  3. 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:

  1. 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


Requerimiento

#

FieldId

Tipo

Obligatorio

Descripción

0companyNuméricoSIIdentificador 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
  • E-Commerce = Comercio electrónico

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 = Pre-autorizació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 Pre-autorizació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 si fue realizada la autorización telefónica o la pre-autorización.

Código de autorización telefónica o retornado en la Pre-autorización. 6 dígitos como máximo. Este campo se encuentra presente si la transacción se autorizó off-line por teléfono o en una Pre-autorización.

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. Y para Capturar la pre-autorización o Anular la pre-autorización

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)

261cipherSuiteNuméricoOpcional

Indica el largo de la llave RSA para encriptar y desencriptar datos sensibles. En VTOL Admin debe estar habilitada la propiedad de datos sensibles.
Valores posibles:

  • 1: utiliza largo de 1024
  • 2. utiliza largo de 2048
263vtolTokenAlfanuméricoOpcional

Cuando se efectúa una transacción Sale, VoidSale, Refund o VoidRefund tokenizada, se puede enviar el Token VTOL

264posChannelOriginNuméricoOpcional

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

Si no se envía este campo, se toma por defecto el valor 0.

265customerIdAlfanuméricoOpcionalNombre o id de usuario que realizó la transacción
266cardHolderNameAlfanuméricoOpcionalNombre del tarjetahabiente
270posTicketAlfanuméricoOpcionalInformación del ticket en formato xml y posteriormente transformado en Base 64. Ver sección Estructura del campo posTicket
403afApplicationConditionAlfanuméricoOpcional

Condición de aplicación antifraude. Este dato será utilizado por el módulo antifraude de VTOL para ejecutar o ignorar validaciones de fraude.

Longitud máxima: 50 caracteres.

Se puede enviar en transacciones de:

  • Sale
  • PreAuthorization
  • Sale Offline

Si el POS envía una Condición en este campo, se validará si la compañía está suscripta a alguna regla con dicha Condición. Si está suscripta, se ejecutará la regla AF, pero si no está suscripta, no se ejecutará.

Si el POS envía este campo vacío, o no lo envía, se validará si la compañía está suscripta a alguna regla "Sin condición". Si está suscripta, se ejecutará la regla que no tiene condición, y si no está suscripta, no se ejecutará.

Si el POS envía una Condición, pero no está creada en antifraude de VTOL, no se ejecutará ninguna regla AF.


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

"-"

descriptionAlfanuméricoDescripción del ítemSi
currencyAlfanumé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.


Importante: La especificación XML define cinco "entidades predefinidas" que representan caracteres especiales y requiere que todos los procesadores XML los respeten.

Ellos son: " & ' < >

En caso de utilizarse deberán ser escapados.

1.4.1.2 Respuesta


Respuesta

#

FieldId

Tipo

Descripción

0companyNuméricoIdentificador 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).

263vtolTokenAlfanuméricoCuando se efectúa una transacción Sale, VoidSale, Refund o VoidRefund tokenizada, se puede recibir el Token VTOL
267vtolTokenExpireNumé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, operaciones eCommerce.
El flujo normal de ésta operatoria es el siguiente:

  1. Se realiza una pre-autorización por un monto X.
    1. Se debe almacenar el código de autorización recibido en la respuesta.
  2. Se lleva a cabo la venta de los productos.
  3. Finalizada la venta se procede a realizar la captura (Sale offline) por el momento exacto e incorporando el código de autorización recibido en el paso 1. El sistema aprobará automáticamente esta 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:

  1. Se realiza una pre-autorización por un monto X.
  2. Por algún motivo, como el expuesto más 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)

  1. 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).

  1. 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).

263vtolTokenAlfanumérico

Cuando se efectúa una transacción Sale, VoidSale, Refund o VoidRefund tokenizada, se puede enviar el Token VTOL

264posChannelOriginNumé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

Si no se envía este campo, se toma por defecto el valor 0.


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

0companyNuméricoSIIdentificador 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

0companyNuméricoIdentificador 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

0companyNuméricoSIIdentificador 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

0companyNuméricoIdentificador 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

0compayNuméricoSIIdentificador 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

0companyNuméricoIdentificador 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

0companyNuméricoObligatorioIdentificador 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

0companyNuméricoIdentificador 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

0companyNuméricoSIIdentificador 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

0companyNuméricoIdentificador 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

0companyNuméricoObligatorioIdentificador 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

0companyNuméricoIdentificador 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

0companyNuméricoSIIdentificador 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

0companyNumércioIdentificador 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

Mensajería para confirmar o anular la transacción en VTOL Server.


1.4.12.1 Requerimiento


#

FieldId

Tipo

Descripción

0companyNuméricoIdentificador 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

0companyNuméricoIdentificador 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

0companyNuméricoIdentificador 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

0companyNuméricoIdentificador 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

0companyNuméricoIdentificador 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

RefundPEIQueryPEI

Descripción

0companyNuméricoXXXIdentificador de la compañía donde se generó la transacción.
1storeAlfanuméricoXXXIdentificador del sitio originador de la transacción
2nodeNuméricoXXXIdentificación del nodo, en el sitio originador, donde se generó la transacción
3serverAlfanuméricoXXXIdentificador del Server que procesará la transacción. (en el caso de VTOL será 'VTOL')
4messageTypeAlfanuméricoXXX

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

XX

Track2 de la tarjeta entero (se envía todo el contenido del track2 en este campo)

10

inputMode

Alfanumérico

X

XX

Forma en que se ingresó/leyó la tarjeta. Valor posible:

  • MSR – Leída por banda magnética

11

trxType

Alfanumérico

X

XX

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

XX

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

66track1AlfanuméricoXXXTrack1 de la tarjeta entero (se envía todo el contenido del track1 en este campo)
71checkPendingStringAlfanumé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.
153idOperationPEIAlfanumérico-X-Identificador de la operación PEI de pago que se desea devolver
155cbuAlfanumé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
156cbuAliasAlfanumé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
157customerDocAlfanumé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

161operationConceptNuméricoO--

Concepto por el cual se realiza la operación, valores posibles:

  • 1 = COMPRA_DE_BIENES
  • 2 = PAGO_DE_SERVICIOS
  • 3 = EXTRACCION
164posEncryptedFieldsNuméricoXXX

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
173dateTimeOriginalTrxNumérico--XFecha 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
403afApplicationConditionAlfanuméricoO--

Condición de aplicación antifraude. Este dato será utilizado por el módulo antifraude de VTOL para ejecutar o ignorar validaciones de fraude.

Longitud máxima: 50 caracteres.

Si el POS envía una Condición en este campo, se validará si la compañía está suscripta a alguna regla con dicha Condición. Si está suscripta, se ejecutará la regla AF, pero si no está suscripta, no se ejecutará.

Si el POS envía este campo vacío, o no lo envía, se validará si la compañía está suscripta a alguna regla "Sin condición". Si está suscripta, se ejecutará la regla que no tiene condición, y si no está suscripta, no se ejecutará.

Si el POS envía una Condición, pero no está creada en antifraude de VTOL, no se ejecutará ninguna regla AF.


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

SalePEIRefundPEIQueryPEI

Descripción

0companyNuméricoXXXIdentificador de la compañía donde se generó la transacción
1storeAlfanuméricoXXXIdentificador del sitio originador de la transacción
2nodeNuméricoXXXIdentificación del nodo, en el sitio originador, donde se generó la transacción

25

dateTime

Numérico

XXX

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

XXX

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

XXX

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

XXX

Mensaje de la Respuesta ISO-8583 relacionado con el código del campo 27

35

errorDescription

Alfanumérico

XXX

Descripción de error. Sólo se encuentra presente si el valor del campo 26 es “Error”

153

idOperationPEI

Alfanumérico

XXX

Identificador de la operación PEI de pago o de devolución

154idOperationOrigenPEIAlfanumérico-XOIdentificador de la operación PEI de origen con la cual se solicitó la devolución.
170idCommercePEIAlfanuméricoXXXIdentificador PEI de compañía
171idBranchPEIAlfanuméricoXXXIdentificador PEI de local
172idTerminalPEIAlfanuméricoXXXIdentificador PEI de terminal
174originalTrxStatusNumé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
278bankingRefNumAlfanuméricoX-XNumero 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

0companyNuméricoSIIdentificador 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
157customerDocAlfanuméricoObligatorioNúmero de documento del titular de la tarjeta
265customerIdAlfanuméricoObligatorioIdentificador del usuario o comprador
266cardHolderNameAlfanuméricoObligatorioNombre del tarjetahabiente


1.4.17.2 Respuesta


#

FieldId

Tipo

Descripción

0companyNuméricoIdentificador 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).

263vtolTokenAlfanuméricoToken VTOL tras tokenizar una tarjeta
267vtolTokenExpireNumé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

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

  • SaleWallet = Permite realizar una compra presencial con billetera
  • SaleWallet con cashback = Permite realizar una compra presencial y realizar retiro de efectivo. Sólo para billetera Mercado Pago.
  • 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. 


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:

  1. Se inicia con el envío de una orden de venta (transacción SaleWallet) por parte del POS a VTOL.
  2. Recién en ese momento el comprador podrá efectuar la lectura del código QR impreso en la caja mediante su smartphone. 
  3. 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.
  4. 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.
  5. 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.
  6. 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 operar cashout con Mercado Pago

Se podrán realizar las siguientes operaciones:

Ventas

  • Ventas de productos y retiro de efectivo
    • En estos casos, se aprueban ambas cosas. No es posible obtener aprobaciones parciales.

Devoluciones

  • Se pueden realizar devoluciones de los productos y del cashout.
    • Operación de venta con productos y cashout. Permite devolver en una misma transacción, lo siguiente:
      • Devolución total de los productos y del cashout
      • Devolución parcial de los productos, y devolución total del cashout
      • Devolución total o parcial solo de los productos
      • Devolución total solo del cashout
      • Varias devoluciones parciales de los productos
    • Operación de venta sólo con productos. Permite devolver en una misma transacción, lo siguiente:
      • Devolución total o parcial de los productos
      • Varias devoluciones parciales de los productos
  • En la operación de devolución parcial de productos, se permiten efectuar varias devoluciones parciales de un pago. Se pueden realizar hasta 20 devoluciones parciales a un mismo pago.  VTOL valida que no se supere el monto de la venta.
  • La devolución de cashout siempre debe ser por el monto total.

Anulaciones

  • Una vez recibida la respuesta de operación Aprobada por parte de Mercado Pago, se puede realizar lo siguiente:
    • Para una venta con productos y cashout. Permite anular:
      • Los productos y el cashout, todo junto. Esto se logra enviando un UnSyncCompletion=rollback
    • Para una venta sólo con productos. Permita anular:
      • Todos los productos. Esto se logra enviando un UnSyncCompletion=rollback.
  • No es posible realizar anulaciones intermedias. 



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

0companyNuméricoXXXIdentificador de la compañía donde se generó la transacción.
1storeAlfanuméricoXXXIdentificador del sitio originador de la transacción
2nodeNuméricoXXXIdentificación del nodo, en el sitio originador, donde se generó la transacción
3serverAlfanuméricoXXXIdentificador del Server que procesará la transacción. (en el caso de VTOL será 'VTOL')
4messageTypeAlfanuméricoXXX

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

XX

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-)

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

14paymentsNumérico--OCantidad 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
15planAlfanumérico--OPlan. 1 caracter de longitud
16originalDateNumérico-XX

Fecha de realización de la compra con billetera electrónica en formato YYYYMMDD

24lastTrxIdNuméricoOOOUtilizado cuando está activo el control transaccional. En este campo el POS debe enviar la última transacción procesada correctamente.

25

dateTime

Numérico

X

XX

Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS

53paymentConditionAlfanumérico--OCondición de pago. Sólo se encuentra presente si existe una condición de pago vinculada con la transacción
54additionalAmountImporteOO-

Contiene el Importe del "Cashout". 12 dígitos como máximo. Valor entero. Los últimos 2 dígitos corresponden a los decimales.

Para devoluciones, se debe enviar el monto total del cashout.

Para devolver sólo el cashout, se debe enviar el campo 12 (amount) con valor 0.

Sólo disponible para billetera de Mercado Pago.

71checkPendingStringAlfanumé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.
268walletPosTrxIdAlfanuméricoX-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

269walletTypeNuméricoXXX

Tipo de billetera por la cual se cursará la transacción en el POS. Opciones:

1: Mercado Pago

270posTicketBase 64X--

Información del ticket en formato xml y posteriormente transformado en Base 64. Ver sección Estructura del campo posTicket

271walletPaymentIdAlfanumérico

-

XO

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

311purchaseTitleAlfanuméricoO--

Título de la venta. Longitud máxima 100.

Si el POS no lo envía, VTOL tomará un valor por defecto. El siguiente label: "Pago con Mercado Pago en" + "CompanyName".

312purchaseDescAlfanuméricoO--

Descripción de la venta. Longitud máxima 100.

Si el POS no lo envía, VTOL tomará un valor por defecto. El siguiente label: "Pago realizado con QR. Por un monto de $amount. Y retiro de efectivo de $additionalAmount.".


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;54:50000}

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

"-"

descriptionAlfanuméricoDescripción del ítemSi
currencyAlfanumé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
measureAlfanuméricoUnidad de medida del ítem. Valores posibles: unit - packNo"unit"


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" 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" 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

SaleWalletRefundWalletQuerySaleWallet

Descripción

0companyNuméricoXXXIdentificador de la compañía donde se generó la transacción
1storeAlfanuméricoXXXIdentificador del sitio originador de la transacción
2nodeNuméricoXXXIdentificación del nodo, en el sitio originador, donde se generó la transacción
6cardNumberAlfanuméricoO-OTarjeta 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
12amountImporteX-XMonto de la transacción. Valor entero. Los últimos 2 dígitos corresponden a los decimales.
13currencyPosCodeAlfanumérico--X

Tipos de moneda:

  • $ = Pesos
  • U$S = Dólares
14paymentsNumérico--OCantidad 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
22authorizationCodeAlfanuméricoX-X

Código de autorización informado por el Autorizador

24trxIdNuméricoXXXIdentificador de la transacción
25dateTimeNuméricoXXX

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

26responseCodeAlfanuméricoXXX

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
27isoCodeNuméricoXXX

Código de Respuesta emitido por el centro autorizador. 3 dígitos como máximo. Ver sección Códigos de Respuesta de VTOL Server para Billeteras Electrónicas

28responseMessageAlfanuméricoXXX

Mensaje de la Respuesta relacionado con el código del campo 27

54additionalAmountImporteOOO

Contiene el Importe del "Cashout". Para aquellas operaciones realizadas con retiro de efectivo. Valor entero. Los últimos 2 dígitos corresponden a los decimales.

Sólo disponible para billetera de Mercado Pago.

140paymentTypeNumérico--X

Tipo de pago. Valores posibles:

0: Tarjeta
1: Efectivo

142providerNameAlfanumérico--OProveedor 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
147providerPosCodeListaO--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.
157customerDocNuméricoOOONumero de documento del titular de la tarjeta.
303customerNameAlfanuméricoOOONombre del titular de la tarjeta.
166trxReferenceNumberNuméricoXX-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
271walletPaymentIdAlfanuméricoX-XIdentificador del número de pago informado por el Autorizador
272amountRefundedImporte--XMonto devuelto en la transacción
273paymentStatusAlfanumé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

274paymentStatusDetailAlfanumérico--XDetalle del estado de la transacción de pago informado por el Autorizador
275cardTypeNumé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


Ejemplo

Response from VTOL (SaleWallet):

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

Response from VTOL (RefundWallet):

Response message: {1:1;2:1;25:20190214050543;26:ISO8583;27:509;28:Estado trx original no acepta devolucion}

Response from VTOL (QuerySaleWallet):

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



1.4.19 Operaciones eCommerce

Este mensajería explica la integración directa entre una tienda online con VTOL Server. Para implementar esta mensajería, el comercio debe estar certificado bajo las normas PCI DSS. El eCommerce debe poseer su propio formulario de captura de datos de tarjeta, para luego enviar dichos datos directamente a VTOL Server.


Las operaciones soportadas en VTOL Server para eCommerce son:

  • Operación en una fase: VTOL ofrece la posibilidad de realizar una transacción en una sola fase, llamada Venta (cargo). Directamente se realiza la transacción financiera y se aplica el cobro en la tarjeta del cliente. 
    • Sale = Permite realizar una compra online. En esta modalidad VTOL autoriza, verifica y captura el importe de la venta todo de una vez.

  • Operaciones en dos fases: VTOL ofrece la posibilidad de realizar transacciones en dos pasos, primero se realiza una pre-autorización, y luego se genera la captura.
    • PreAuthorization = La pre-autorización es una reserva de fondos en la tarjeta del comprador. Esto significa que al realizar la misma, todavía no se generó un cobro al cliente en su tarjeta. Nunca aparece en el resumen de cuenta del tarjeta habiente. Solo cuando se realice una captura el cliente verá el pago. Cuando se recibe la respuesta de la pre-autorización, se debe almacenar el código de autorización recibido.
    • Sale (Capture) = Esta operatoria se utiliza exclusivamente luego de haber realizado un Pedido de Autorización en 2 pasos. La misma es una operación offline. Para poder confirmar definitivamente el pago al cliente, es necesario capturar los fondos que se reservaron, enviando el código de autorización recibido en la pre-autorización. La captura se realiza por el monto exacto de la venta, por lo cual es posible realizar la captura por el monto total o de forma parcial.
    • VoidPreAuthorization = Permite anular completamente una pre-autorización que había sido aprobada previamente. Si el cliente se arrepiente de realizar la compra, 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. Para anularla, la misma puede estar en un lote abierto o cerrado.


1.4.19.1 Requerimiento

Nro

Campo

Tipo

Sale

Capture

PreAuth

VoidPreAuth

Descripción

0companyNuméricoXXXXIdentificador de la compañía donde se generó la transacción

1

store

Alfanumérico

XXXX

Identificador del sitio originador de la transacción

3

server

Alfanumérico

XXXX

Identificador del Server que procesará la transacción. ('VTOL')

4

messageType

Alfanumérico

XXXX

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

X-X-

Número de tarjeta. Sólo presente si el modo de ingreso fue Manual.

7

expirationDate

Numérico

X-X-

Formato YYMM Fecha de vencimiento de la tarjeta. Sólo presente si el modo de ingreso fue Manual.

8

cvc

Numérico

X-X-

Código de seguridad de la tarjeta. Sólo presente si el modo de ingreso fue Manual.

10

inputMode

Alfanumérico

XXXX

Modo de Ingreso de la tarjeta:

3 - E-Commerce

11

trxType

Alfanumérico

XXXX

Tipo de Transacción:

  • Sale = Compra online en 1 fase.
  • Sale = Captura offline en 2 fases.
  • PreAuthorization = Pre autorización online en 2 fases.
  • VoidPreAuthorization = Anulación de Pre autorización. Offline.

12

amount

Importe

XXXX

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

XXXX

Tipos de Moneda:

  • $ = Pesos
  • U$S = Dólares

14

payments

Numérico

XXXX

Cantidad de cuotas. 2 dígitos como máximo.

15

plan

Alfanumérico

XXXX

Plan. 1 caracter de longitud.

17

originalTrxTicketNr

Numérico

---X

Campo Opcional. Si viaja se debe precisar el número de ticket de la venta original para poder distinguir la transacción a anular. 4 dígitos como máximo.

Obligatorio para devoluciones.

22

authorizationCode

Alfanumérico

-X--

Código de autorización retornado en la pre autorización. 6 dígitos como máximo.

Obligatorio para Captura.

23

authorizationMode

Alfanumérico

XXXX

Modo de Autorización:

  • Online = Para Pre-autorización y Sale (de 1 fase).
  • Offline = Para Captura (de 2 fases) y Anulación de Pre-autorización.

25

dateTime

Numérico

XXXX

Fecha de generación de la trx en el POS. Formato YYYYMMDDHHmmss

53

paymentCondition

Alfanumérico

O-O-

Condición de pago. Sólo se encuentra presente si existe una condición de pago vinculada con la transacción.

73

interestAmount

Alfanumérico

O-O-

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.

118terminalCapabilityAlfanuméricoXXXX

Capacidad de captura. Valor a enviar:

  • 1 = Manual

147

providerPosCode

Alfanumérico

O-O-

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.

167originalTrxReferenceNumberAlfanuméricoOXOX

Identificador único de la transacción en VTOL Server. Longitud entre 19 y 20 dígitos.

Dato enviado por VTOL Server en el campo 166, en la respuesta de un Sale o una PreAuthorization.

Obligatorio para los trxType: Anulación de autorización (VoidPreAuthorization) y Captura (Sale offline).

201additionalMessageDataAlfanuméricoOOOOEste campo tiene como finalidad que el 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.
264posChannelOriginNuméricoOOOO

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
266cardHolderNameAlfanuméricoXOXONombre del tarjetahabiente
270posTicketAlfanuméricoOOOOInformación del ticket en formato xml y posteriormente transformado en Base 64. Ver sección Estructura del campo posTicket
265customerIdAlfanuméricoOOOONombre de usuario que realizó la transacción. Este campo se utiliza para validar posibles fraudes, por parte del módulo Antifraude de VTOL.
290customerIpAlfanuméricoOOOOIP de origen de donde se efectuó la transacción. Este campo se utiliza para validar posibles fraudes, por parte del módulo Antifraude de VTOL.
291customerDocTypeAlfanuméricoOOOOTipo de documento del cliente que realizó la transacción. Este campo se utiliza para validar posibles fraudes, por parte del módulo Antifraude de VTOL.
157customerDocAlfanuméricoOOOONúmero de documento del cliente que realizó la transacción. Este campo se utiliza para validar posibles fraudes, por parte del módulo Antifraude de VTOL.
292customerFirstNameAlfanuméricoOOOONombre del cliente registrado en el e-commerce que realizó la transacción. Este campo se utiliza para validar posibles fraudes, por parte del módulo Antifraude de VTOL.
293customerLastNameAlfanuméricoOOOOApellido del cliente registrado en el e-commmerce que realizó la transacción. Este campo se utiliza para validar posibles fraudes, por parte del módulo Antifraude de VTOL.
294cardHolderBirthdayAlfanuméricoXXXXFecha de nacimiento del titular de la tarjeta. Formato YYYYMMDD. Este dato se envía a Prisma para validar posibles fraudes por parte del emisor.
295cardHolderDocTypeAlfanuméricoXXXXTipo de documento del titular de la tarjeta. Este dato se envía a Prisma para validar posibles fraudes por parte del emisor.
296cardHolderDocNumberAlfanuméricoXXXXNúmero de documento del titular de la tarjeta. Este dato se envía a Prisma para validar posibles fraudes por parte del emisor.
297cardHolderAddressStreetAlfanuméricoOOOOCalle de entrega del resumen del titular de la tarjeta. Este dato se envía a Prisma para validar posibles fraudes por parte del emisor.
298cardHolderAddressNumberAlfanuméricoXXXONúmero de Puerta de entrega del resumen del titular de la tarjeta. Este dato se envía a Prisma para validar posibles fraudes por parte del emisor.
299cardHolderZipCodeAlfanuméricoOOOOCódigo postal de entrega del resumen del titular de la tarjeta. Este dato se envía a Prisma para validar posibles fraudes por parte del emisor.
305cardHolderAddressComplementAlfanuméricoOOOOComplemento de la dirección. Piso / departamento de entrega de resumen del titular de la tarjeta. Este dato se envía a Prisma para validar posibles fraudes por parte del emisor.
306cardIssuingBankAlfanuméricoOOOOBanco emisor de la tarjeta. Longitud máxima 20. Si se envía este campo, VTOL validará que el número de tarjeta enviado esté asociado a un prefijo con el banco de la tarjeta.
307cardBrandAlfanuméricoOOOOMarca de la tarjeta. Longitud máxima 20. Si se envía este campo, VTOL validará que el número de tarjeta enviado esté asociado a un prefijo con la marca de la tarjeta.
403afApplicationConditionAlfanuméricoOOO-

Condición de aplicación antifraude. Este dato será utilizado por el módulo antifraude de VTOL para ejecutar o ignorar validaciones de fraude.

Longitud máxima: 50 caracteres.

Si el POS envía una Condición en este campo, se validará si la compañía está suscripta a alguna regla con dicha Condición. Si está suscripta, se ejecutará la regla AF, pero si no está suscripta, no se ejecutará.

Si el POS envía este campo vacío, o no lo envía, se validará si la compañía está suscripta a alguna regla "Sin condición". Si está suscripta, se ejecutará la regla que no tiene condición, y si no está suscripta, no se ejecutará.

Si el POS envía una Condición, pero no está creada en antifraude de VTOL, no se ejecutará ninguna regla AF.


1.4.19.2 Respuesta

Nro

Campo

Tipo

Descripción

0companyNuméricoIdentificador 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. Ver sección Códigos de Respuesta de VTOL Server para Operaciones no presenciales

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.

75

accountNumber

Alfanumérico

Número de cuenta. Este campo es devuelto si el campo 74- requestAccountNumber fue activado en el requerimiento. Longitud 28.

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 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.

308vteValidationAlfanumérico

Longitud 4 dígitos. Retorna en operaciones no presenciales, de Sale y Pre-autorización.

El autorizador Prisma realiza validación de los siguientes datos del tarjeta habiente.

  • cardHolderDocType
  • cardHolderDocNumber
  • cardHolderAddressNumber
  • cardHolderBirthday

El resultado se informa con un código de 4 dígitos. Cada dígito es el resultado de la validación de los campos enviado en el requerimiento, en el orden indicado arriba. Los valores posibles son:
0 = Dato Correcto. 1 = Dato No Coincide. 2 = Dato No Validado

Ejemplo: Código informado = 0112
Este código informa que:

  • Tipo de Documento = Correcto
  • Nro. de Documento = No Coincide
  • Número de Puerta de Domicilio de Entrega = No Coincide
  • Fecha de Nacimiento = No Validado


1.4.20 Devoluciones eCommerce

La estructura del mensaje de devolución es similar al mensaje de venta, con la diferencia que se agregan campos que identifican a la transacción original sobre la que se hace la devolución: (16) originalDate, (17) originalTrxTicketNr y (167) originalTrxReferenceNumber.


1.4.20.1 Requerimiento

Nro

Campo

Tipo

Descripción

0companyNuméricoIdentificador de la compañía donde se generó la transacción.
1storeAlfanuméricoIdentificador del sitio originador de la transacción
10inputModeAlfanumérico

Modo de Ingreso de la tarjeta:

  • E-Commerce

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

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

Fecha de la transacción original en el formato YYYYMMDD.

17

originalTrxTicketNr

Numérico

Número de ticket de la transacción original. 4 dígitos como máximo.

167originalTrxReferenceNumberNuméricoIdentificador de la transacción original generado VTOL Server.
25dateTimeNuméricoFecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS.

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 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.

264posChannelOriginNumérico

Indica el canal de origen de la transacción.

  • E-Commerce


1.4.20.2 Respuesta

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


1.4.21 Operaciones Cuenta DNI

Operatoria para realizar pagos en los Puntos de Venta utilizando como medio de pago un código de barras o token generado por una aplicación mobile  del Banco Provincia. Una operación con CuentaDNI es una operación PEI, salvo que el modo de ingreso será diferente, ya que no se utilizará ningún tipo de tarjeta. El cliente deberá informar al cajero del POS el código generado por la aplicación mobile. Las operaciones serán presenciales.

Las operaciones PEI (Pago Electrónico Inmediato) se transfieren desde la cuenta del cliente a la cuenta del retailer y se acreditan de manera instantánea.

En esta operación, no se realiza una interacción con el pinpad y el mensaje recibido por el POS es enviado directamente a VTOL Server para su posterior autorización con Red Link.

Las operaciones soportadas para Cuenta DNI son:

  • SalePEI = Permite realizar un pago presencial con Cuenta DNI, utilizando código de barras o softToken
  • RefundPEI = Permite realizar una devolución (parcial o total) de un pago presencial con Cuenta DNI realizado con anterioridad.
  • QueryPEI = Permite realizar una consulta de una operación de pago o de devolución que obtuvo como respuesta el error "391 - Error en comunicación" o una respuesta de timeout. Este mensaje surge ya que hay una limitante por parte del autorizador que no existe un mecanismo de reversa de transacciones.

Estados de operaciones:

Cuando las transacciones de Cuenta DNI sean aprobadas por el autorizador LINK, el estado de las operaciones quedarán en estado "Commit".

Reintentos

VTOL no efectuará ni manejará reintentos de solicitudes. En caso de que la autorización por parte de LINK no se haya realizado, VTOL no reintentará enviar el request de pago/devolución, sino que le informará al POS la situación de error, denegación o falla. El POS será el responsable de efectuar el reintento.

Reversos

La operación de reversa automática en Link no existe. 

Promociones

Para Cuenta DNI existe una mensajería para informar las promociones de aquellos productos que tengan una promoción vinculada a las operaciones de pago PEI. Las promociones con Cuenta DNI se detallan en el punto 1.4.22 Promociones PEI para Cuenta DNI

Importante

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


1.4.21.1 Requerimiento

Referencias

X = Obligatorio
O = Opcional
- = No requerido


NroNombre del campoTipo de datoSalePEIRefundPEIQueryPEIDescripción
0companyNuméricoXXXIdentificador de la compañía donde se generó la transacción.
1storeAlfanuméricoXXXIdentificador del sitio originador de la transacción
2nodeNuméricoXXXIdentificación del nodo, en el sitio originador, donde se generó la transacción
3serverAlfanuméricoXXXIdentificador del Server que procesará la transacción. (en el caso de VTOL será 'VTOL')
4messageTypeAlfanuméricoXXX

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.

10

inputMode

Alfanumérico

X

XX

Forma de ingreso:

  • BarCode
  • SoftToken

11

trxType

Alfanumérico

X

XX

Tipo de Transacción:

  • SalePEI = Compra Cuenta DNI PEI
  • RefundPEI = Devolución Cuenta DNI PEI
  • QueryPEI = Consulta de transacción Cuenta DNI PEI

12

amount

Importe

X

X-

Monto de la transacción de Venta o de Devolució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

Se validará el importe enviado por el POS:

  • En la venta: que el importe sea mayor a 0.
  • En la devolución: que el importe sea mayor a 0 y menor al importe original de venta. Si el POS informa un importe igual que el original de venta, o no lo informa, corresponde a una devolución Total. Si el POS informa un importe menor que el original de venta, corresponde a una devolución Parcial.

13

currencyPosCode

Alfanumérico

X

X-

Tipos de Moneda:

  • $ = Pesos
  • U$S = Dólares

25

dateTime

Numérico

X

XX

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

153idOperationPEIAlfanumérico-XO

Identificador de operación Cuenta DNI PEI de pago que se desea devolver o consultar.

157customerDocAlfanumérico

O

--

Número de documento del titular de la cuenta.

Obligatorio junto con softToken, únicamente si el modo de ingreso es softToken.

173dateTimeOriginalTrxNumérico--XFecha 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.
279softTokenAlfanuméricoO--

Token generado por la app mobile. Este token se lo informa el cliente al cajero, para que sea ingresado en el POS.

Obligatorio junto con customerDoc, únicamente si el modo de ingreso es softToken.

300
barCode
AlfanuméricoO--

Código generado por la app mobile. Este código se lo informa el cliente al cajero, para que sea ingresado en el POS.

Obligatorio únicamente si el modo de ingreso es barCode.


1.4.21.2 Respuesta

NroCampoTipo de datoSalePEIRefundPEIQueryPEIDescripción
0companyNuméricoXXXIdentificador de la compañía donde se generó la transacción.
1storeAlfanuméricoXXXIdentificador del sitio originador de la transacción
2nodeNuméricoXXXIdentificación del nodo, en el sitio originador, donde se generó la transacción
25dateTimeNuméricoXXXFecha 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

XXX

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_Errores_del_CORE_de_VTOLServer
  • 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

XXX

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

XXX

Mensaje de la Respuesta ISO-8583 relacionado con el código del campo 27

35

errorDescription

Alfanumérico

XXX

Descripción de error. Sólo se encuentra presente si el valor del campo 26 es “Error”

153

idOperationPEI

Alfanumérico

XXX

Identificador de la operación PEI de pago o de devolución

154idOperationOrigenPEIAlfanumérico-XOIdentificador de la operación original de pago.
170idCommercePEIAlfanuméricoXXXIdentificador PEI de compañía
171idBranchPEIAlfanuméricoXXXIdentificador PEI de local
172idTerminalPEIAlfanuméricoXXXIdentificador PEI de terminal
174originalTrxStatusNumé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
278bankingRefNumAlfanuméricoXXXNúmero de referencia de la transacción de pago.


1.4.22 Promociones PEI para Cuenta DNI

Operatoria que permite al Punto de Venta (POS) informar promociones sobre una operación de pago PEI, e informar la devolución de un pago PEI sujeto a promoción.

Actualmente la funcionalidad de Promociones PEI estará vinculada únicamente con transacciones realizadas por CuentaDNI.

Para realizar un mensaje de Promociones PEI, se debe haber realizado previamente un pago y contar con los datos de idOperacion y nroReferenciaBancaria que son devueltos por Link cuando una operación de pago resulta Aprobada.

Las operaciones soportadas para Promociones PEI son:

  • PromoPEI = Permite informar una promoción sobre una operación de pago PEI, y permite informar una devolución de un pago PEI que fue sujeto a promoción.


Sólo será requerido informar Promociones PEI en caso que se realice una venta PEI con productos que tengan promociones.


Cómo informa el POS una Promoción

Luego de realizar una operación de Pago PEI, el POS deberá informar (en caso que aplique) la promoción sobre ese pago. Informará en el campo amount el monto original de la venta y en el campo promoAmount la sumatoria del importe de los productos sujetos a promoción. Si el pago completo está sujeto a promoción, el promoAmount será igual al amount. Si sólo una porción del pago está sujeta a promoción, entonces promoAmount será solamente el importe de aquellos producto sujetos a promoción. El cálculo de la promoción contra el cliente lo realizará LINK.

Este mecanismo se ideó para el caso que los comercios tengan solo algunos productos sujetos a promoción, entonces se informará a LINK la porción del pago al cual aplicar promoción.

Cómo informa el POS una Devolución de un pago sujeto a Promoción

Luego de realizar una devolución de un pago PEI, el POS deberá informar (en caso que aplique) la promoción que se aplicó a los productos de esa devolución. Informará en el campo amount la sumatoria del importe de los productos a devolver y en el campo promoAmount la sumatoria del importe de los productos a devolver que fueron informados como promoción en el pago.


1.4.22.1 Requerimiento

Referencias

X = Obligatorio
O = Opcional
- = No requerido


NroCampoTipo de datoPromoPeiDescripción
0companyNuméricoXIdentificador de la compañía donde se generó la transacción.
1storeAlfanuméricoXIdentificador del sitio originador de la transacción
2nodeNuméricoXIdentificación del nodo, en el sitio originador, donde se generó la transacción
3serverAlfanuméricoXIdentificador del Server que procesará la transacción. (en el caso de VTOL será 'VTOL')
4messageTypeAlfanuméricoX

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

Tipo de Transacción:

  • PromoPEI
301originalTrxTypeAlfanuméricoXIdentificador del Tipo de Promoción que se está informando. Valores posibles: "1" para Pagos con promociones y "2" para Devoluciones de pagos con promoción.

12

amount

Importe

X

Monto total de la transacción original de venta, debe ser el mismo valor. 12 dígitos como máximo. Se envía sin coma. Los dos últimos dígitos representan los decimales.

13currencyPosCodeAlfanuméricoX

Tipos de Moneda:

  • $ = Pesos
  • U$S = Dólares

302

promoAmount

Importe

X

Importe para informar una promoción o para informar la devolución de un pago con promoción. En donde los últimos 2 dígitos serán los decimales. Puede ser igual al importeOperacion (amount), en el caso en que todo el importe del pago esté sujeto a promoción. Pero no puede superar el importeOperacion.

Para informar una Promoción en una Venta, se informará la sumatoria del importe de los productos sujetos a promoción. Si el pago completo está sujeto a promoción, el PromoAmount será igual a amount.

El mismo comportamiento se aplicará para informar la Devolución de un pago sujeto a promoción. Se informará la suma del importe de los productos que fueron sujetos a promoción en la venta.

25

dateTime

Numérico

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

153idOperationPEIAlfanuméricoX

Identificador de operación PEI de pago que devuelve Link en la respuesta del pago.

278bankingRefNumAlfanuméricoXNúmero de referencia bancaria de la operación de pago. Es devuelta por Link en la operación de pago.


1.4.22.2 Respuesta

NroCampoTipo de datoPromoPeiDescripción
0companyNuméricoXIdentificador de la compañía donde se generó la transacción.
1storeAlfanuméricoXIdentificador del sitio originador de la transacción
2nodeNuméricoXIdentificación del nodo, en el sitio originador, donde se generó la transacción

25

dateTime

Numérico

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

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

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

Mensaje de la Respuesta ISO-8583 relacionado con el código del campo 27

35

errorDescription

Alfanumérico

X

Descripción de error. Sólo se encuentra presente si el valor del campo 26 es “Error”


1.4.23 Operaciones PEI No Presencial

Esta funcionalidad permite efectuar Pagos Electrónicos Inmediatos (PEI) No Presenciales desde canales de call center utilizando tarjetas de débito, la transferencia y acreditación será de manera instantánea con un costo inferior a una venta tradicional.

Las operaciones soportadas para PEI No Presencial son:

  • SalePEI = Permite realizar un pago no presencial PEI (transferencia bancaria).
  • RefundPEI = Permite realizar una devolución (parcial o total) de un pago 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.23.1 Requerimiento

Referencias

X = Obligatorio
O = Opcional
- = No requerido


NroCampoTipoSalePEIRefundPEIQueryPEI
0companyNuméricoXXXIdentificador de la compañía donde se generó la transacción

1

store

Alfanumérico

XXX

Identificador del sitio originador de la transacción

3

server

Alfanumérico

XXX

Identificador del Server que procesará la transacción.

Enviar: VTOL

4

messageType

Alfanumérico

XXX

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

X--

Número de tarjeta.

7

expirationDate

Numérico

X--

Formato YYMM Fecha de vencimiento de la tarjeta. Sólo presente si el modo de ingreso fue Manual.

8

cvc

Numérico

X--

Código de seguridad de la tarjeta. Sólo presente si el modo de ingreso fue Manual.

10

inputMode

Alfanumérico

XXX

Modo de Ingreso de la tarjeta:

  • Manual

11

trxType

Alfanumérico

XXX

Tipo de Transacción:

  • SalePEI = Compra con débito PEI.
  • RefundPEI = Devolución de una compra con PEI.
  • QueryPEI = Consulta de transacción PEI.

12

amount

Importe

XX-

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

XX-

Tipos de Moneda:

  • $ = Pesos
  • U$S = Dólares

14

payments

Numérico

XX-

Cantidad de cuotas.

Enviar siempre: 1

15

plan

Alfanumérico

X--

Plan.

Enviar siempre: 0

16originalDateFecha-X-Fecha de la transacción original en el formato YYYYMMDD.

25

dateTime

Numérico

XXX

Fecha de generación de la trx en el POS. Formato YYYYMMDDHHmmss

118terminalCapabilityAlfanuméricoXXX

Capacidad de captura. Valor a enviar:

  • 1 = Manual

147

providerPosCode

Alfanumérico

O--

Código del Provider. Ejemplo: VI (Visa). Longitud 20.

153idOperationPEIAlfanumérico-X-Identificador de la operación PEI de pago original que se desea devolver.
167originalTrxReferenceNumberAlfanumérico-X-

Identificador único de la transacción en VTOL Server. Longitud entre 19 y 20 dígitos.

Dato enviado por VTOL Server en el campo 166, en la respuesta de un SalePEI.

201additionalMessageDataAlfanuméricoOO-

Este es un campo que VPB obtiene del eCommerce y que el mismo esté presente en la respuesta para trazabilidad.

En VPB es el campo ecommerceCustomField.

264posChannelOriginNuméricoXXX

Indica el canal de origen de la transacción. Es un código con los siguientes valores posibles:

  • 3 = IVR
266cardHolderNameAlfanuméricoXX-Nombre del tarjetahabiente
270posTicketAlfanuméricoOO-Información del ticket en formato xml y posteriormente transformado en Base 64. Ver sección Estructura del campo posTicket
139customerRefAlfanumérico

O

O

O

Número de referencia de comercio para trazabilidad de transacción. 20 caracteres como máximo.

Se recomienda su utilización en Ventas y Devoluciones para poder consultar en caso de error de conexión con VTOL.

265customerIdAlfanuméricoOO-Nombre de usuario que realizó la transacción
157customerDocAlfanuméricoOO-Número de documento del cliente que realizó la transacción.
161operationConceptAlfanuméricoX--

Concepto por el cual se realiza la operación, valores posibles:

  • 1 = COMPRA_DE_BIENES
173dateTimeOriginalTrxNumérico--XFecha 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.
290customerIpAlfanuméricoOO-IP de origen de donde se efectuó la transacción
291customerDocTypeAlfanuméricoOO-Tipo de documento del cliente que realizó la transacción.
292customerFirstNameAlfanuméricoOO-Nombre del cliente registrado en el e-commerce que realizó la transacción.
293customerLastNameAlfanuméricoOO-Apellido del cliente registrado en el e-commmerce que realizó la transacción.
295cardHolderDocTypeAlfanuméricoX--Tipo de documento del titular de la tarjeta.
296cardHolderDocNumberAlfanuméricoX--Número de documento del titular de la tarjeta.
306cardIssuingBankAlfanuméricoOO-Banco emisor de la tarjeta. Longitud máxima 20.
307cardBrandAlfanuméricoOO-Marca de la tarjeta. Longitud máxima 20.
403afApplicationConditionAlfanuméricoO--

Condición de aplicación antifraude. Este dato será utilizado por el módulo antifraude de VTOL para ejecutar o ignorar validaciones de fraude.

Longitud máxima: 50 caracteres.

Si el POS envía una Condición en este campo, se validará si la compañía está suscripta a alguna regla con dicha Condición. Si está suscripta, se ejecutará la regla AF, pero si no está suscripta, no se ejecutará.

Si el POS envía este campo vacío, o no lo envía, se validará si la compañía está suscripta a alguna regla "Sin condición". Si está suscripta, se ejecutará la regla que no tiene condición, y si no está suscripta, no se ejecutará.

Si el POS envía una Condición, pero no está creada en antifraude de VTOL, no se ejecutará ninguna regla AF.


1.4.23.2 Respuesta

NroCampoTipoSalePEIRefundPEIQueryPEIDescripción
0companyNuméricoXXXIdentificador de la compañía donde se generó la transacción.

1

store

Alfanumérico

XXX

Identificador del sitio originador de la transacción

2

node

Numérico

XXX

Identificación del nodo, en el sitio originador, donde se generó la transacción

6cardNumberAlfanuméricoXXONúmero de tarjeta enmascarado con la cual se realizó el pago. Ejemplo: 450799xxxxxx0010

25

dateTime

Numérico

XXX

Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS.

26

responseCode

Alfanumérico

XXX

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

XXX

Código de Respuesta ISO-8583 emitido por el centro autorizador. 2 dígitos como máximo

28

responseMessage

Alfanumérico

XXX

Mensaje de la Respuesta ISO-8583

33

creditCardIssuerName

Alfanumérico

XXX

Nombre del emisor de la tarjeta

35

errorDescription

Alfanumérico

XXX

Descripción de error. Sólo se encuentra presente si el valor del campo 26 es "Error".

166

trxReferenceNumber

Numérico

XXX

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.

153idOperationPEIAlfanuméricoXXXIdentificador de la operación PEI de pago o de devolución
154idOperationOrigenPEIAlfanumérico-XOIdentificador de la operación PEI de origen con la cual se solicitó la devolución.
170idCommercePEIAlfanuméricoXXXIdentificador PEI de compañía
171idBranchPEIAlfanuméricoXXXIdentificador PEI de local
174originalTrxStatusAlfanumé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
278bankingRefNumAlfanuméricoX-XNumero de referencia de la transacción de pago. Se utiliza para conciliar con los reportes de las entidades bancarias. Número generado por LINK.


1.4.24 Operaciones QR Adquiriente

VTOL se integra con QR Adquiriente de Prisma para permitir efectuar pagos en los puntos de venta con billeteras electrónicas.

Las operaciones soportadas son:

  • SaleWallet = Permite realizar una compra presencial con billetera electrónica.
  • RefundWallet = Permite realizar una devolución (total) de una compra presencial con billetera realizada con anterioridad. No se permiten devoluciones parciales.
  • QueryWallet = Permite realizar una consulta de una operación de compra con billetera para conocer si la misma fue autorizada y así obtener los datos por parte del Autorizador.


Procedimiento para QR Adquiriente

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

  1. Se inicia con el envío de una orden de venta (transacción SaleWallet) por parte del POS a VTOL. En el requerimiento, el POS incluirá las opciones de pago que tiene disponibles la caja, para que luego el cliente seleccione la opción de pago más conveniente en su billetera.
  2. VTOL recibe la orden de venta del POS, y envía la información a Prisma con todos los datos de la venta.
  3. En ese momento el comprador podrá realizar, con su billetera virtual, la lectura del código QR disponible en la caja.
  4. Prisma, con la información recibida por VTOL, le comunicará a la billetera virtual el Importe, y las opciones de pago (tarjetas, cuotas, intereses).
  5. El comprador visualizará el detalle de la compra, con las opciones de pago enviadas por la caja, y efectuará el pago seleccionando la tarjeta enrolada, las cuotas y confirmando el pago.
  6. El POS recibirá la respuesta de la transacción SaleWallet a través de VTOL, quien informará si la operación resultó autorizada por Prisma.
    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 envía una respuesta automática por timeout. Para conocer el resultado de la operación, el POS deberá realizar una consulta (transacción QueryWallet). Las respuestas del QueryWallet pueden ser las siguientes:
      1. VTOL responde "Aprobado". Indica que el pago fue autorizado por Prisma. El paso siguiente del POS es confirmar o cancelar la transacción, con un tercer mensaje.
      2. VTOL responde "Rechazado". Indica que el cliente intentó pagar pero Prisma rechazó el pago.
  7. Por último, el POS deberá confirmar la operación, mediante el cierre de sesión (en estado Close).

La anulación o devolución, sí precisa de interacción por parte del comprador en la caja, en su billetera digital debe confirmar la operación. El POS envía el identificador del número de pago del Autorizador en el mensaje RefundWallet.


Importante

En la creación de un pago, el POS informará a VTOL los medios de pago que maneja la caja. Estos datos se informan en el campo 401 (paymentMethodsData).

El POS tiene dos formas de infomar los medios de pago a VTOL:

  1. Puede enviar TODOS los medios configurados en su sistema, y luego Prisma realizará un matching en la billetera virtual del cliente, en la cual sólo se mostrarán los medios de pago que tenga asociado en su billetera. Ejemplo: el POS crea un pago con los medios de pago Visa en 1 y 6 cuotas, y Mastercard en 1 y 6 cuotas. Si el cliente sólo tiene asociado en su billetera la tarjeta "Visa", entonces sólo podrá elegir Visa en 1 o 6 cuotas.
  2. Puede enviar un solo medio de pago, y el cliente podrá pagar únicamente con dicho medio. Para esto, el cajero previamente deberá preguntarle al cliente qué tarjeta tiene vinculada en su billetera virtual y en cuántas cuotas quiere pagar.



1.4.24.1 Requerimiento

Referencias

X = Obligatorio
O = Opcional
- = No requerido


Número

Nombre del campo

Tipo de dato

SaleWallet

RefundWallet

QueryWallet

Descripción

0companyNuméricoXXXIdentificador de la compañía donde se generó la transacción.
1storeAlfanuméricoXXXIdentificador del local donde se generó la transacción.
2nodeNuméricoXXXIdentificador de la caja donde se generó la transacción.
3serverAlfanuméricoXXXIdentificador del Server que procesará la transacción. (en el caso de VTOL será 'VTOL')
4messageTypeAlfanuméricoXXX

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.
11trxTypeAlfanuméricoXXX

Tipo de Transacción:

  • SaleWallet = Compra con billetera electrónica
  • RefundWallet = Devolución de compra realizada con billetera electrónica
  • QueryWallet = Consulta de transacción de compra realizada con billetera electrónica
12amountNuméricoXX-

Monto de la transacción. 12 dígitos como máximo. Valor entero. Los dos últimos dígitos representan los decimales. Ej: "1000" equivale a "10.00".

Para devoluciones, se debe enviar el monto total de la venta original, ya que no están permitidas las devoluciones totales.

13currencyPosCodeAlfanuméricoXX-

Tipos de moneda:

  • $ = Pesos
16originalDateNumérico-XXFecha de realización de la compra con billetera electrónica en formato YYYYMMDD
24

lastTrxId

NuméricoOOOUtilizado cuando está activo el control transaccional. En este campo el POS debe enviar la última transacción procesada correctamente.
25dateTimeNuméricoXXXFecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS
268walletPosTrxIdAlfanuméricoXXO

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 QueryWallet: Se informa este campo o el campo walletPaymentId para localizar una transacción de compra.

269walletTypeNuméricoXXX

Tipo de billetera por la cual se cursará la transacción en el POS. Opciones:

2: QR Adquiriente

270posTicketAlfanuméricoX--Información del ticket en formato xml y posteriormente transformado en Base 64. Ver sección Estructura del campo posTicket
271walletPaymentIdAlfanumérico-XO

Identificador del número de pago informado por el Autorizador en el campo 271 de la respuesta de la operación SaleWallet.

Opcional en QueryWallet: Se informa este campo o el campo walletPosTrxId para localizar una transacción de compra.

401paymentMethodsDataJsonX--Información de los planes de pago, en formato json
402

walletBenefits

JsonX--Información de las tarjetas de beneficio, en formato json



Estructura del campo posTicket (270)

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

"-"

descriptionAlfanuméricoDescripción del ítemSi
currencyAlfanumé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
measureAlfanuméricoUnidad de medida del ítem. Valores posibles: unit - packNo"unit"


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" 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" 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.


Estructura del campo paymentMethodsData (401)

El mensaje con la estructura de los medios de pago será en JSON. Estará conformado por los siguientes campos:

ParámetroTipo de datoRequeridoDescripción
providerPosCodeAlfanuméricoSi

Código del Proveedor de la tarjeta configurado en VTOL. Por ejemplo para Visa el código es "VI".

El código se obtiene de la Configuración de POS.

bankCodeNuméricoNo

Identificador del banco asociado a la tarjeta. Debe corresponder al ID de banco dispuesto por el BCRA.

Ver códigos de bancos.

installmentsArraySiInformación de las cuotas.

paymentOptionIdAlfanuméricoSi

Identificador de la opción de pago. Máximo 10 caracteres. Debe ser único dentro del campo "paymentMethodsData".

Permite trazabilidad con la opción que elija el cliente en el momento de pagar.

La opción de pago seleccionada por el cliente en su billetera virtual es retornada por VTOL en el mensaje de respuesta de la venta, en el campo 404.


quantityNuméricoSiCantidad de cuotas. Número entero. Máximo 2 dígitos

paymentConditionAlfanuméricoNo

Condición de la opción de pago. Sólo se informará si existe en VTOL una opción de pago con una condición.

Máximo 20 caracteres.


amountPerInstallmentImporteSiMonto por cuotas. Valor entero. Los 2 últimos dígitos corresponden a los decimales.

totalAmountImporteSiMonto total. Incluye los recargos. Valor entero. Los 2 últimos dígitos corresponden a los decimales.

surchargeNuméricoSi

C.F.T. (Costo Financiero Total). Porcentaje de recargo sobre las cuotas. Valor entero. Los 2 últimos dígitos corresponden a los decimales.


nominalAnnualRateNuméricoSi

T.N.A. (Tasa Nominal Anual). Valor entero. Los 2 últimos dígitos corresponden a los decimales.


Ejemplo del campo paymentMethodsData (401)

json
[
   {
      "providerPosCode":"VIG",
      "bankCode":"7",
      "installments":[
         {
            "paymentOptionId":"1",
            "quantity":"1",
            "amountPerInstallment":150000,
            "totalAmount":150000,
            "surcharge":0,
            "nominalAnnualRate":0
         },
         {
            "paymentOptionId":"2",
            "quantity":"6",
            "amountPerInstallment":25000,
            "totalAmount":150000,
            "surcharge":1100,
            "nominalAnnualRate":1500
         }
      ]
   },
   {
      "providerPosCode":"VI",
      "installments":[
         {
            "paymentOptionId":"3",
            "quantity":"12",
            "amountPerInstallment":15000,
            "totalAmount":180000,
            "surcharge":1256,
            "nominalAnnualRate":1487
         }
      ]
   },
   {
      "providerPosCode":"MC",
      "installments":[
         {
            "paymentOptionId":"4",
            "quantity":"1",
            "amountPerInstallment":150000,
            "totalAmount":150000,
            "surcharge":0,
            "nominalAnnualRate":0
         },
         {
            "paymentOptionId":"5",
            "quantity":"12",
            "amountPerInstallment":15000,
            "totalAmount":180000,
            "surcharge":1256,
            "nominalAnnualRate":1487
         }
      ]
   },
   {
      "providerPosCode":"MCP",
      "bankCode":"34",
      "installments":[
         {
            "paymentOptionId":"6",
            "quantity":"12",
            "amountPerInstallment":12500,
            "totalAmount":150000,
            "surcharge":130,
            "nominalAnnualRate":120
         }
      ]
   }
]


Estructura del campo walletBenefits (402)

El mensaje con la estructura de los beneficios estará en JSON. Estará conformado por los siguientes campos:

ParámetroTipo de datoRequeridoDescripción
benefitCardIdAlfanuméricoSi

Identificador de la opción de pago creada por el POS. Máximo 10 caracteres. Debe ser único dentro del campo "walletBenefits".

Permite trazabilidad con la tarjeta de beneficio aplicada en el pago por estar vinculada en la billetera virtual del cliente.

El ID del beneficio aplicado es retornado por VTOL en el mensaje de respuesta de la venta en el campo 405.

providerPosCodeAlfanuméricoSiCódigo de la tarjeta de beneficio configurada en VTOL. Por ejemplo para Clarin 365 el código es "CC".

discountPercentage

NuméricoSiPorcentaje de descuento a aplicar sobre la compra. Valor entero. Los 2 últimos dígitos corresponden a los decimales.

maximumDiscountAmount

NuméricoSiImporte máximo de descuento a aplicar sobre la compra. Valor entero. Los 2 últimos dígitos corresponden a los decimales.


Ejemplo del campo walletBenefits (402)

json
[
   {
      "benefitCardId":"1",
      "providerPosCode":"CC",
      "discountPercentage":2000,
      "maximumDiscountAmount":25000
   },
   {
      "benefitCardId":"2",
      "providerPosCode":"CP",
      "discountPercentage":3000,
      "maximumDiscountAmount":50000
   }
]


1.4.24.2 Respuesta

Referencias

X = Obligatorio
O = Opcional
- = No requerido


Número

Nombre del campo

Tipo de dato

SaleWallet

RefundWallet

QueryWallet

Descripción

0companyNuméricoXXXIdentificador de la compañía donde se generó la transacción
1storeAlfanuméricoXXXIdentificador del sitio originador de la transacción
2nodeNuméricoXXXIdentificación del nodo, en el sitio originador, donde se generó la transacción.
6cardNumberAlfanuméricoX-OTarjeta enmascarada seleccionada por el cliente al momento de efectuar el pago QR.
12amountImporteX-X

Contiene el importe que pagó el cliente, el cual puede variar si pagó con intereses o se aplicó algún descuento. Valor entero. Los últimos 2 dígitos corresponden a los decimales.

13currencyPosCodeAlfanuméricoX-X

Tipos de moneda:

  • $ = Pesos
14paymentsNuméricoX-OCantidad de cuotas seleccionadas al momento de realizar el pago QR.
22authorizationCodeAlfanuméricoX-X

Código de autorización informado por el Autorizador

24trxIdNuméricoXXXIdentificador de la transacción.
25dateTimeNuméricoXXX

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

26responseCodeAlfanuméricoXXX

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
27isoCodeNuméricoXXX

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

28responseMessageAlfanuméricoXXX

Mensaje de la Respuesta relacionado con el código del campo 27

29

serialNumber

Numérico

OOO

Número identificatorio de la terminal en la que se procesó la transacción.

Retorna en operaciones aprobadas.

30

businessNumber

Numérico

OOO

Número de comercio en el que se procesó la transacción.

Retorna en operaciones aprobadas.

81responseAuthAlfanuméricoOOOMensaje de repuesta para imprimir en el ticket del POS. Retorna en operaciones aprobadas. Contiene información generada por el Autorizador.
140paymentTypeNumérico--X

Tipo de pago. Valores posibles:

0: Tarjeta
1: Efectivo

142providerNameAlfanumérico--OProveedor de la tarjeta seleccionada al momento de efectuar el pago QR.
147providerPosCodeAlfanuméricoO-OCódigo del Provider. Retornará cuando la transacción fue aprobada por el Autorizador.
166trxReferenceNumberNuméricoXX-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
271walletPaymentIdAlfanuméricoX-XIdentificador del número de pago informado por el Autorizador
272amountRefundedImporte--XMonto devuelto en la transacción
273paymentStatusAlfanumé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
6: Rechazado
7: Cancelado
8: Contracargo

306cardIssuingBankAlfanuméricoO-OBanco emisor de la tarjeta. Retornará cuando la transacción fue aprobada por el Autorizador.
404paymentOptionIdAlfanuméricoX-O

Identificador de la opción de pago seleccionada por el cliente en su billetera virtual. Según la tarjeta, el banco, y las cuotas elegidas por el cliente, se vinculará con el paymentOptionId enviado por la caja en el requerimiento.

405benefitCardIdAlfanuméricoX-OIdentificador de la tarjeta de beneficio aplicada en el pago por estar vinculada en la billetera virtual del cliente.
406originalAmountImporteX-O

Monto original de la transacción: de venta o de devolución.

407amountDiscountedImporteX-O

Contiene el importe que se descontó sobre el importe original. Debido a la aplicación de una tarjeta de beneficio vinculada en la billetera virtual del cliente.

Sólo retorna cuando se aplicó un descuento.


1.4.25 Consultar tarjetas de Fidelidad

Operatoria para realizar desde el Punto de Venta consultas de las tarjetas de fidelidad.


1.4.25.1 Requerimiento

Referencias

X = Obligatorio
O = Opcional
- = No requerido


Número

Nombre del campo

Tipo de dato

CardQuery

Descripción

0companyNuméricoX

Identificador de la compañía donde se generó la transacción.

1storeAlfanuméricoXIdentificador del sitio originador de la transacción
2nodeNuméricoXIdentificación del nodo, en el sitio originador, donde se generó la transacción
3serverAlfanuméricoXIdentificador del Server que procesará la transacción. (en el caso de VTOL será 'VTOL')
4messageTypeAlfanuméricoX

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

Tipo de Transacción:

  • CardQuery = Consulta de transacción de compra realizada con billetera electrónica

25

dateTime

Numérico

X

Fecha y hora de realización de la transacción en formato: YYYYMMDDHHMMSS
269walletTypeNuméricoX

Tipo de billetera por la cual se realizará la consulta. Opciones:

2: Adquiriente Prisma

408loyaltyCardNuméricoX

Tipo de tarjeta de fidelidad que se quiere consultar. Opciones:

1: Clarín 365

157customerDocNuméricoX

Número de documento del cliente que realiza la consulta.


Ejemplo

Request to VTOL:

Request: {157:11111111;408:1;269:2;11:CardQuery;4:DATA;3:VTOL;2:1;25:20210503192959;71:True;1:1;0:1}


1.4.25.2 Respuesta

Referencias

X = Obligatorio
O = Opcional
- = No requerido


Número

Nombre del campo

Tipo de dato

CardQuery

Descripción

0companyNuméricoXIdentificador de la compañía donde se generó la transacción
1storeAlfanuméricoXIdentificador del sitio originador de la transacción
2nodeNuméricoXIdentificación del nodo, en el sitio originador, donde se generó la transacción.
6cardNumberAlfanuméricoXNúmero de Tarjeta del cliente. Si es una tarjeta de fidelidad, retornará en plano.
25dateTimeNuméricoXFecha 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
26responseCodeAlfanuméricoX

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
27isoCodeNuméricoXCódigo de Respuesta emitido por el centro autorizador. 3 dígitos como máximo. Ver sección: Códigos de Respuesta de VTOL Server para Consulta de Fidelidad
28responseMessageAlfanuméricoXMensaje de la Respuesta relacionado con el código del campo 27
292customerFirstNameAlfanuméricoXNombre del tarjetahabiente.
293customerLastNameAlfanuméricoXApellido del tarjetahabiente.
409loyaltyCardCategoryAlfanuméricoX

Categoría de la tarjeta de fidelidad. Puede retornar los siguientes valores:

  • Classic
  • Plus


Ejemplo

Response from VTOL:

Response: {25:20210503193023;2:1;1:1;0:1;6:44123456789010;292:Juan;293:Perez;409:CLASSIC;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:

  1. Campo 27: Código de Respuesta
  2. 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

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

Clave DNI inválido

610Se agoto el tiempo de espera
611Código de barras invalido
612La referencia ingresada es inválida
613El timestamp ingresado no respeta el formato
614La cuenta origen no tiene tarjeta asociada
615La cuenta origen de los fondos es inexistente
616Cuenta origen sin fondos suficientes
617La terminal ingresada es incorrecta
618<Código para posibles nuevos errores de PEI - Link no manejados por VTOL>


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:

Código

Descripción de respuesta al POS

Descripción del módulo antifraude
801Tarjeta no autorizadaFraude por validación de BlackList
802Tarjeta no autorizadaPosible Fraude por BlackList
803Operación no autorizadaFraude por Velocity Check
804Operación no autorizadaPosible fraude por Velocity Check
805Operación no autorizadaError en validación concurrente, posible fraude por Velocity Check
806Operación no autorizadaError en validación Velocity Check
807Operación no autorizadaError general en validación de Antifraude
810Operación no autorizadaFaltan campos requeridos en el requerimiento


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

400Tarjeta no soporta tokenizacion
401Excedio tiempo de tokenizacion
402Token error comunicacion
403Token error persistencia
404Token error parseo campo
405Token error respuesta NOK
406VTOL TOKEN Expirado
407Error generar token
408VTOL Token no encontrado
409VTOL token requerido
410Token publico no encontrado en comercio
411Token publico expirado
412No 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ódigoDescripción
00APROBADA
500No se encuentra la transaccion original
501El campo WalletPosTrxId es requerido
502El campo WalletType es requerido
503No esta configurado una Compañia MP
504No esta configurado una Caja MP
505El tipo de billetera es invalido
506El campo WalletPaymentId es requerido
507El campo OriginalDate es requerido
508No es posible devolver una devolucion
509Estado trx original no acepta devolucion
510Importe devolucion supero monto limite
511No se pudo realizar la orden de pago
512La transaccion no posee estado
513El campo posTicket es requerido
514Tiempo expirado. Elija Consultar o Cancelar pago
515Tiempo expirado confirmacion devolucion
516Pago aun no realizado, desea seguir esperando?
517Estado trx original no acepta devolucion
518No se encuentra la devolucion
519Acceso a MP no esta autorizado
520Accion a MP no esta autorizada
521El campo WalletPosTrxId es invalido
523Estado trx original no acepta devolucion
524Importe invalido para devolucion
525Estado trx original no acepta devolucion
526Compañia MP no permite operar
527Numero devoluciones parciales superados
528El pago es antiguo para ser devuelto
529No es posible devolver una devolucion
530Compañia MP sin dinero para devolver
531Compañia MP sin dinero disponible
532Estado trx original no acepta devolucion
533Devolucion parcial no soportada
534Url de notificacion invalido
535El monto de la transaccion es invalido
536Error general por parte de MP
537No se encuentra la transaccion original
538El campo WalletPosTrxId es requerido
539Devuelto
540Pendiente
541Autorizado
542En Progreso
543En mediacion
544Rechazado
545Cancelado
546Contracargo
547No se encontró la trx original
548Error en comunicación
549No existe comunicación con Mercado Pago
550Error al consultar venta original online
552Orden no generada por Prisma
553Pago Rechazado por parte de Prisma
554Esta operación requiere autorización
555Esta operación requiere autorización
556Pago rechazado, reintente con otro medio de pago
557Pago rechazado, reintente con otro medio de pago
558Pago rechazado, reintente con otro medio de pago
559Pago rechazado, reintente con otro medio de pago
560Pago rechazado, reintente con otro medio de pago
561No fue posible procesar su pago, intente más tarde
562No fue posible procesar su pago, intente más tarde
563No fue posible procesar su pago, intente más tarde
564No fue posible procesar su pago, intente más tarde
565No fue posible procesar su pago, intente más tarde
566La cantidad de cuotas seleccionada es inválida
567La cantidad de cuotas seleccionada es inválida
568Tarjeta de crédito vencida
569Tarjeta de crédito no habilitada
570Fondos insuficientes, reintente otro medio de pago
571Fondos insuficientes, reintente otro medio de pago
572Datos incorrectos, revíselos y reintente
573Datos incorrectos, revíselos y reintente
574No fue posible procesar su pago, intente más tarde
575No fue posible procesar su pago, intente más tarde
576Tarjeta no vigente, reintente otro medio de pago
577Esta operación requiere autorización
578No fue posible procesar su pago, intente más tarde
579No fue posible procesar su pago, intente más tarde
580La cantidad de cuotas seleccionada es inválida
581Datos incorrectos, revíselos y reintente
582Datos incorrectos, revíselos y reintente
583Las cuotas informadas son incorrectas
584No existe la compra que se desea anular
585El originante no es válido
586El comercio informado es inválido
587El establecimiento informado es inválido
588El establecimiento no pertenece al comercio
589El punto de venta informado es inválido
590El punto de venta no pertenece al establecimiento
591El tipo de documento es inválido
592Se debe informar el ID de la operación
593Se debe informar un timeStamp
594Se debe informar el traceNumber
595Intención de pago vencida
598Las cuotas del pago ya fueron informadas
650Importe de devolución de cashout invalido
651Importe de cashout invalido
652Medio de pago inválido
733

La transacción no corresponde a una operación de Billeteras Electrónicas

734

No es posible cancelar la transacción informada


1.5.5 Códigos de Respuesta de VTOL Server para operaciones no presenciales

A continuación se detallan las respuestas posibles de VTOL Server, cuando se realizan operaciones no presenciales:

Código

Descripción

Observaciones

760Datos del tarjetahabiente inválidos.VTOL valida los datos requeridos del tarjetahabiente. Si VPB no los manda, retorna este mensaje.
99Datos de provider inválidos.

VTOL valida los datos de Provider, Bank y Brand, a partir del prefijo configurado en VTOL. Esos datos se contrastan con los datos de la tarjeta enviados por el POS:
Si el POS no los envía, no se validan en VTOL Server.
Si en el prefijo el valor de Banco es DEFAULT en VTOL, en caso de que el POS mande el Bank, VTOL no realiza ninguna validación.
Si en el Provider el valor de Marca es DEFAULT en Vtol, en caso de que el POS mande el Brand, VTOL no realiza ninguna validación.

Si el POS manda los datos de Provider, Bank o Brand, y si VTOL valida que son incorrectos según los datos cargados en Vtol, entonces retorna este mensaje.

762Error de configuración de comercio en VTOL.VTOL valida que se encuentren configurados los datos del Comercio: Datos tributarios y Datos por canal. Si no están configurados en VTOL Server, retorna este mensaje.
763La preautorización expiró

VTOL valida que la pre-autorización no se encuentre vencida.
Primero se busca el valor de vencimiento configurado en VTOL Server y si no lo tiene configurado, toma el valor por defecto de rs_system_property.

Si la pre-autorización está vencida, retorna este mensaje.

764Monto inválido

En la Captura, cuando el POS manda un monto que se encuentra fuera de los porcentajes de variación, VTOL Server retorna este mensaje.
Primero se busca el valor de variación de montos configurado en VTOL y si no tiene configurado, toma el valor por defecto de rs_system_property.


1.5.6 Códigos de Respuesta de VTOL Server para Consulta de Fidelidad

A continuación se detallan las respuestas posibles de VTOL Server, cuando se realizan consultas de tarjetas de fidelidad:

Código

Descripción

Observaciones

770Cliente no encontrado en servicio de fidelidadEl servicio de fidelidad respondió que el cliente no fue encontrado en su base de datos.
771El cliente no está activo en servicio de fidelidadEl servicio de fidelidad respondió que el cliente no tiene ninguna tarjeta activa.
772Error en el servicio de fidelidadCuando el servicio de fidelidad no está disponible o se vence el timeout.
773Error de configuración en VTOL.

VTOL valida que se encuentre configurada la API Key del Comercio para consultar con Bimo, en las propiedades de configuración.

Si no están configurados en VTOL Server, o si Bimo responde un error 400, VTOL retorna este mensaje al POS.

774Es requerido el documento del clienteEl POS no envió el número de DNI del cliente.
775Es requerido el tipo de tarjeta de fidelidadEl POS no envió el tipo de tarjeta de fidelidad del cliente.
776El documento no es validoEl número de DNI enviado no tiene el formato correcto.
777Tipo de tarjeta de fidelidad no válido.El tipo de tarjeta de fidelidad enviado no está soportado.
778Consulta no disponible para esta billeteraEl tipo de consulta no es soportado por el tipo de billetera enviado por el POS en el campo WalletType.



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 v109


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)

5

Código de banco

10

AN

Código del banco (Opcional

6Descripción del banco40ANDescripción del banco (Opcional)


Ejemplo
PV:VI;Visa;
PV:MA;Mastercard;
PV:AM;Amex;;7;BANCO DE GALICIA Y BUENOS AIRES S.A.U.



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

Al POS exclusivamente se le enviarán las opciones de pago con Canal de Origen Presencial o las informadas en la propiedad de configuración "Canal de origen a mostrar en Nro de comercio y Def. de lote, para locales físicos". Esta configuración se encuentra disponible en VTOL Server a partir de la versión 3.8.0.8a

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.

13Descripción20ANDescripción del Plan de pago.
14Tipo de operación1N

Indica cuál es el tipo de operación asociado al plan de pagos. Opciones posibles:

  • 0 = Crédito-Débito
  • 1 = Wallet


Ejemplo:

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


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:

  1. 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.

  1. 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 forma presencial y no presencial, 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 rechazar la transacción.

El usuario operador 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 Antifraude - Manual de usuario".

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 la regla de antifraude que se encontrará activa.

Con respecto a la mensajería, en el requerimiento de una compra, el POS o eCommerce precisará informar los siguientes datos para validar 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)
    • customerId (nombre o id de usuario que efectuó la transacción)
    • customerIp (IP de origen de donde se efectuó la transacción)
    • cardHolderName (titular de tarjeta)
    • vtolToken (token VTOL)
    • posTicket (ticket con los items adquiridos)

En la respuesta al POS o eCommerce, VTOL informará si la transacción fue rechazada por alguna regla de fraude. Ver códigos de respuesta por reglas antifraude.


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)


2. Anexos

2.1 Códigos de Bancos

A continuación se detallan los ID de los bancos dispuestos por el BCRA.

ID de Banco

Descripción

7BANCO DE GALICIA Y BUENOS AIRES S.A.U.
11BANCO DE LA NACION ARGENTINA
14BANCO DE LA PROVINCIA DE BUENOS AIRES
15INDUSTRIAL AND COMMERCIAL BANK OF CHINA
16CITIBANK N.A.
17BANCO BBVA ARGENTINA S.A.
20BANCO DE LA PROVINCIA DE CORDOBA S.A.
27BANCO SUPERVIELLE S.A.
29BANCO DE LA CIUDAD DE BUENOS AIRES
34BANCO PATAGONIA S.A.
44BANCO HIPOTECARIO S.A.
45BANCO DE SAN JUAN S.A.
65BANCO MUNICIPAL DE ROSARIO
72BANCO SANTANDER RIO S.A.
83BANCO DEL CHUBUT S.A.
86BANCO DE SANTA CRUZ S.A.
93BANCO DE LA PAMPA SOCIEDAD DE ECONOMÍA M
94BANCO DE CORRIENTES S.A.
97BANCO PROVINCIA DEL NEUQUÉN SOCIEDAD ANÓ
143BRUBANK S.A.U.
147BANCO INTERFINANZAS S.A.
150HSBC BANK ARGENTINA S.A.
165JPMORGAN CHASE BANK, NATIONAL ASSOCIATIO
191BANCO CREDICOOP COOPERATIVO LIMITADO
198BANCO DE VALORES S.A.
247BANCO ROELA S.A.
254BANCO MARIVA S.A.
259BANCO ITAU ARGENTINA S.A.
262BANK OF AMERICA, NATIONAL ASSOCIATION
266BNP PARIBAS
268BANCO PROVINCIA DE TIERRA DEL FUEGO
269BANCO DE LA REPUBLICA ORIENTAL DEL URUGU
277BANCO SAENZ S.A.
281BANCO MERIDIAN S.A.
285BANCO MACRO S.A.
299BANCO COMAFI SOCIEDAD ANONIMA
300BANCO DE INVERSION Y COMERCIO EXTERIOR S
301BANCO PIANO S.A.
305BANCO JULIO SOCIEDAD ANONIMA
309BANCO RIOJA SOCIEDAD ANONIMA UNIPERSONAL
310BANCO DEL SOL S.A.
311NUEVO BANCO DEL CHACO S. A.
312BANCO VOII S.A.
315BANCO DE FORMOSA S.A.
319BANCO CMF S.A.
321BANCO DE SANTIAGO DEL ESTERO S.A.
322BANCO INDUSTRIAL S.A.
330NUEVO BANCO DE SANTA FE SOCIEDAD ANONIMA
331BANCO CETELEM ARGENTINA S.A.
332BANCO DE SERVICIOS FINANCIEROS S.A.
336BANCO BRADESCO ARGENTINA S.A.U.
338BANCO DE SERVICIOS Y TRANSACCIONES S.A.
339RCI BANQUE S.A.
340BACS BANCO DE CREDITO Y SECURITIZACION S
341BANCO MASVENTAS S.A.
384WILOBANK S.A.
386NUEVO BANCO DE ENTRE RÍOS S.A.
389BANCO COLUMBIA S.A.
426BANCO BICA S.A.
431BANCO COINAG S.A.
432BANCO DE COMERCIO S.A.
435BANCO SUCREDITO REGIONAL S.A.U.



  • Sem rótulos