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. |
21/08/2013 | 1.7 | Agregado de apartado de error del core. |
09/09/2013 | 1.8 | Agrego campos EMV en operaciones de Venta, Devolución y anulación. Incorporo mensaje RejectedEMVAdvice y flujo de datos EMV. |
15/11/2013 | 1.9 | Agregado de 'Formato Interface POS' |
23/12/2013 | 2.0 | Agregado de detalle de los mensajes ServicePayment y VoidServicePayment |
13/02/2014 | 2.1 | Agregado del campo bandera '164 – posEncryptedFields', que indica cuando los datos sensibles viajan encriptados. |
29/05/2014 | 2.2 | Aclaración sobre el uso de pre-autorizaciones. |
22/08/2014 | 2.3 | Agregado de campo pinpadAutoCode en Tercer Mensaje y RejectedEMVAdvice. |
29/08/2014 | 2.4 | Actualización del Formato Interface POS, agregando el campo 'Tarjeta que Encripta' a los prefijos. |
11/09/2014 | 2.5 | Incorporación de Bines de Excepción y nuevo mensaje CardInfoService. |
09/12/2014 | 2.6 | Agregado de mensaje de Anulación de Pre Autorización. |
26/02/2015 | 2.7 | Agregado de nuevos campos ServiceCode y ProviderPosCode. |
27/02/2015 | 2.8 | Agregado de nuevos mensajes propios a la funcionalidad Cash Back. |
07/08/2015 | 2.9 | Agregado de aclaraciones en el uso de la mensajería |
09/09/2015 | 3.0 | Incorporación de campo PinpadApplicationVersion en los mensajes Sale, VoidSale, Refund y VoidRefund |
30/10/2015 | 3.1 | El campo ProviderPosCode para a ser el número 147. Incorporación de campo trxReferenceNumber en las respuestas de VTOL. Corrección de formato esperado en campo 7 - Expiration. El formato correcto es: YYMM. |
11/02/2016 | 3.2 | Incorporación del campo 201 additionalMessageData en el requerimiento y respuesta y la posibilidad de incluir el número de Ticket original en una anulación (Campo 17 originalTrxTicketNr) |
29/07/2016 | 3.3 | Incorporación del apartado 1.9. Mecanismo en Tiendas Virtuales y del 1.3.13. Chequeo de Listado de Pendientes |
19/04/2017 | 3.4 | Actualización de la tabla Prefijo en el apartado Formato Interface POS |
03/05/2017 | 3.5 | Incorporación del apartado 1.3.10 Echo |
05/05/2017 | 3.6 | Incorporación del apartado 1.3.9 SynQuery y de la sección 1.7 Formato Datos Sincronización |
06/06/2017 | 3.7 | Actualización de la tabla Prefijo en el apartado Formato Interface POS. Mayor detalle del campo MasterKey Position, incluyendo el valor 99 |
07/07/2017 | 3.8 | Agregado del campo promocional en Formato Interface POS para indicar que se aplica una promoción sobre un plan de pago |
| 04/09/2018 | 3.9 | Incorporación de la funcionalidad PEI en la mensajería |
14/12/2018 | 4.0 | Incorporación del apartado Antifraude e incorporación de la funcionalidad Antifraude en la mensajería |
| 08/02/2019 | 4.1 | Incorporación del apartado Tokenización e incorporación de la funcionalidad Tokenización en la mensajería |
| 03/04/2019 | 4.2 | Agregado del campo 0 (Compañía) en la mensajería de todos los tipos de transacciones. |
| 28/08/2019 | 4.3 | Incorporación de la funcionalidad Billeteras electrónicas en la mensajería. |
| 01/04/2020 | 4.4 | Incorporación de mensajería para operaciones eCommerce. |
| 22/06/2020 | 4.5 | Incorporación de mensajería para operaciones de Cuenta DNI. |
| 30/07/2020 | 4.6 | Incorporación de funcionalidad de Billeteras Mercado Pago con retiro de efectivo. |
| 28/08/2020 | 4.7 | Incorporación de consideraciones en el Formato de Interface POS en la tabla Plan de Pagos, para tiendas presenciales. |
| 22/09/2020 | 4.8 | Se actualiza el campo 54 (additionalAmount) como tipo de dato Importe, en la mensajería de Billeteras electrónicas. |
| 21/10/2020 | 4.9 | Incorporación de funcionalidad PEI No Presencial |
| 26/11/2020 | 4.10 | Agregado del campo Descripción en Formato de Interface POS para indicar la descripción sobre un plan de pago. |
| 11/12/2020 | 4.11 | Incorporación de funcionalidad de QR Adquiriente. |
| 16/12/2020 | 4.12 | Incorporación del campo afApplicationCondition para validar la aplicación de reglas antifraudes por el módulo AF de VTOL. |
| 05/03/2021 | 4.13 | Se actualiza el nombre y la descripción del campo 406 en la respuesta de la mensajería de QR Adquiriente. |
| 05/05/2021 | 4.14 | Incorporación de mensajería para Consultar tarjetas de Fidelidad |
| 11/05/2021 | 4.15 | Se quitan las referencias de la billetera Todo Pago, ya que dicha Billetera está incluida dentro de QR Adquiriente Prisma. |
Índice
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 |
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.
/** 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()); } } |
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.
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.
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 |}...............|
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
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.
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}
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:
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.
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:
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.
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. |
En esta sección se detallarán las transacciones soportadas por VTOL así como los campos requeridos u opcionales de cada transacción.
| Requerimiento | ||||
|---|---|---|---|---|
# | FieldId | Tipo | Obligatorio | Descripción |
| 0 | company | Numérico | SI | Identificador de la compañía donde se generó la transacción |
1 | store | Alfanumérico | SI | Identificador del sitio originador de la transacción |
2 | node | Numérico | SI | Identificación del nodo, en el sitio originador, donde se generó la transacción. |
3 | server | Alfanumérico | Compatibilidad atrás. | Identificador del Server que procesará la transacción. ('VTOL') |
4 | messageType | Alfanumérico | Compatibilidad atrás. | Tipo de Mensaje:
|
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:
|
11 | trxType | Alfanumérico | Obligatorio | Tipo de Transacción:
|
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:
|
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:
|
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:
|
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):
|
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:
|
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 |
103 | emvEncryptedType | Alfanumérico | Opcional | Tipo de encriptación utilizada entre Pinpad y Host Autorizador.
|
104 | emvEncryptedData | Alfanumérico | Opcional | Paquete encriptado devuelto por el pinpad y que se enviará al Host Autorizador. |
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).
|
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. |
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
|
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) |
| 261 | cipherSuite | Numérico | Opcional | Indica el largo de la llave RSA para encriptar y desencriptar datos sensibles. En VTOL Admin debe estar habilitada la propiedad de datos sensibles.
|
| 263 | vtolToken | Alfanumérico | Opcional | Cuando se efectúa una transacción Sale, VoidSale, Refund o VoidRefund tokenizada, se puede enviar el Token VTOL |
| 264 | posChannelOrigin | Numérico | Opcional | Indica el canal de origen de la transacción. Es un código con los siguientes valores posibles:
Si no se envía este campo, se toma por defecto el valor 0. |
| 265 | customerId | Alfanumérico | Opcional | Nombre o id de usuario que realizó la transacción |
| 266 | cardHolderName | Alfanumérico | Opcional | Nombre del tarjetahabiente |
| 270 | posTicket | Alfanumérico | Opcional | Información del ticket en formato xml y posteriormente transformado en Base 64. Ver sección Estructura del campo posTicket |
| 403 | afApplicationCondition | Alfanumérico | Opcional | 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:
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 | "-" | |
| description | Alfanumérico | Descripción del ítem | Si | ||
| currency | Alfanumérico | Moneda utilizada en el precio del ítem Nota: En el punto de venta se deberá informar la moneda de la cuenta vendedor de Mercado Pago (si el retailer posee una cuenta argentina en Mercado Pago entonces tendrá que informar la moneda $ -pesos argentinos-). | Si |
Ejemplo
<message> |
| 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. |
| Respuesta | |||
|---|---|---|---|
# | FieldId | Tipo | Descripción |
| 0 | company | Numérico | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | Identificador del sitio originador de la transacción |
2 | node | Numérico | Identificación del nodo, en el sitio originador, donde se generó la transacción |
22 | authorizationCode | Alfanumérico | Código de autorización generado por el centro autorizador para la transacción. |
23 | authorizationMode | Alfanumérico | Modo de Autorización:
|
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:
|
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. |
82 | softwareVersion | Alfanumérico | Versión de la aplicación. |
102 | chipTokens | Alfanumérico | En las respuestas hacia el POS se actualiza con el valor que envió el CA. |
110 | requeredAdvice | Alfanumérico | Con valor true si se requiere que se envíe el advice para la autorización. En este caso la terminal lógica queda en estado AdvicePending. |
130 | posPeriod | Numérico | Periodo enviado por el POS. Longitud 5 |
131 | turn | Numérico | Turno. Longitud 2 |
132 | operatorCode | Alfanumérico | Código de operador. Longitud 20 |
133 | operatorName | Alfanumérico | Nombre de operador. Longitud 50 |
134 | sellerCode | Alfanumérico | Código del vendedor. Longitud 20 |
135 | sellerName | Alfanumérico | Nombre del vendedor. Longitud 50 |
136 | attentionMode | Alfanumérico | Modalidad de atención (AU ó AS). Longitud 2 |
165 | publicKey | Alfanumérico | Clave Pública utilizada en la encripción punto a punto POS - VTOL. Viaja cuando la clave expiró y se generó una nueva; o bien, cuando es necesario sincronizar claves entre POS y VTOL. |
166 | trxReferenceNumber | Numérico | Identificador único de la transacción en VTOL Server. Longitud entre 19 y 20 dígitos, debido a que utiliza el día como parte de formato. |
201 | additionalMessageData | Alfanumérico | Este campo tiene como finalidad que el POS, o cliente VTOL, pueda enviar un dato X y que el mismo esté presente en la respuesta. Cada módulo según implementación puede decidir qué hacer con dicho dato (Ejem Persistir en BBDD). |
| 263 | vtolToken | Alfanumérico | Cuando se efectúa una transacción Sale, VoidSale, Refund o VoidRefund tokenizada, se puede recibir el Token VTOL |
| 267 | vtolTokenExpire | Numérico | Fecha y hora de expiración del Token VTOL en formato YYYYMMDD |
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:
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:
La Anulación de una pre-autorización no se incluirá en los archivos de cierre o TEF.
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)
Tipo de mensaje Cash Back (trxType = CashBack).
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.
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.
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.
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:
|
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 |
13 | currencyPosCode | Alfanumérico | Tipos de Moneda:
|
14 | payments | Numérico | Cantidad de cuotas. 2 dígitos como máximo. |
15 | plan | Alfanumérico | Código de plan. Largo 1. |
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. |
201 | additionalMessageData | Alfanumérico | Este campo tiene como finalidad que el POS, o cliente VTOL, pueda enviar un dato X y que el mismo esté presente en la respuesta. Cada módulo según implementación puede decidir qué hacer con dicho dato (Ejem Persistir en BBDD). |
| 263 | vtolToken | Alfanumérico | Cuando se efectúa una transacción Sale, VoidSale, Refund o VoidRefund tokenizada, se puede enviar el Token VTOL |
| 264 | posChannelOrigin | Numérico | Indica el canal de origen de la transacción. Es un código con los siguientes valores posibles:
Si no se envía este campo, se toma por defecto el valor 0. |
Nota: Tomar como referencia la respuesta del tipo de mensaje Sale
Mensaje utilizado para el pago de resumen de cuenta de una tarjeta de crédito.
# | FieldId | Tipo | Obligatorio | Descripción |
| 0 | company | Numérico | SI | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | SI | Identificador del sitio originador de la transacción |
2 | node | Numérico | SI | Identificación del nodo, en el sitio originador, donde se generó la transacción |
3 | server | Alfanumérico | Compatibilidad atrás. | Identificador del Server que procesará la transacción. ('VTOL') |
4 | messageType | Alfanumérico | Compatibilidad atrás. | Tipo de Mensaje:
|
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:
|
11 | trxType | Alfanumérico | Obligatorio | Tipo de Transacción:
|
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:
|
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:
|
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:
|
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):
|
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:
|
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
|
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). |
# | FieldId | Tipo | Descripción |
| 0 | company | Numérico | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | Identificador del sitio originador de la transacción |
2 | node | Numérico | Identificación del nodo, en el sitio originador, donde se generó la transacción |
22 | authorizationCode | Alfanumérico | Código de autorización generado por el centro autorizador para la transacción. |
23 | authorizationMode | Alfanumérico | Modo de Autorización:
|
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:
|
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). |
Anulación de pago de resumen de tarjeta de crédito.
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:
|
Nota: Tomar como referencia la respuesta del tipo de mensaje ServicePayment
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:
# | FieldId | Tipo | Obligatorio | Descripción |
| 0 | company | Numérico | SI | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | SI | Identificador del sitio originador de la transacción |
2 | node | Numérico | SI | Identificación del nodo, en el sitio originador, donde se generó la transacción |
3 | server | Alfanumérico | Compatibilidad atrás. | Identificador del Server que procesará la transacción. (en el caso de VTOL será 'VTOL') |
4 | messageType | Alfanumérico | Compatibilidad atrás. | Tipo de Mensaje:
|
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:
|
11 | trxType | Alfanumérico | Obligatorio | Tipo de Transacción:
|
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:
|
23 | authorizationMode | Alfanumérico | Opcional, default = Online | Modo de 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. |
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):
|
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:
|
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
|
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). |
# | FieldId | Tipo | Descripción |
| 0 | company | Numérico | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | Identificador del sitio originador de la transacción |
2 | node | Numérico | Identificación del nodo, en el sitio originador, donde se generó la transacción |
22 | authorizationCode | Alfanumérico | Código de autorización generado por el centro autorizador para la transacción. |
23 | authorizationMode | Alfanumérico | Modo de Autorización:
|
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:
|
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). |
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:
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.
# | FieldId | Tipo | Obligatorio | Descripción |
| 0 | compay | Numérico | SI | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | SI | Identificador del sitio originador de la transacción |
2 | node | Numérico | SI | Identificación del nodo, en el sitio originador, donde se generó la transacción |
3 | server | Alfanumérico | Compatibilidad atrás | Identificador del Server que procesará la transacción. ('VTOL') |
4 | messageType | Alfanumérico | Compatibilidad atrás | Tipo de Mensaje:
|
11 | trxType | Alfanumérico | Obligatorio | Tipo de Transacció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):
|
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). |
# | FieldId | Tipo | Descripción |
| 0 | company | Numérico | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | Identificador del sitio originador de la transacción |
2 | node | Numérico | Identificación del nodo, en el sitio originador, donde se generó la transacción |
24 | trxId | Numérico | OPCIONAL. En caso que el Campo 26 sea TrxIsPending, contendrá el trxId de la transacción pendiente. |
25 | dateTime | Numérico | Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. |
26 | responseCode | Alfanumérico | Puede contener uno de los siguientes valores:
|
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. |
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). |
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
Si es crédito/débito
NOTA:
# | FieldId | Tipo | Obligatorio | Descripción |
| 0 | company | Numérico | Obligatorio | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | Obligatorio | Identificador del sitio originador de la transacción |
2 | node | Numérico | Obligatorio | Identificación del nodo, en el sitio originador, donde se generó la transacción |
3 | server | Alfanumérico | Compatibilidad atrás. | Identificador del Server que procesará la transacción. ('VTOL') |
4 | messageType | Alfanumérico | Compatibilidad atrás. | Tipo de Mensaje:
|
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:
|
11 | trxType | Alfanumérico | Obligatorio | Tipo de Transacción:
|
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):
|
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
|
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). |
# | FieldId | Tipo | Descripción |
| 0 | company | Numérico | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | Identificador del sitio originador de la transacción |
2 | node | Numérico | Identificación del nodo, en el sitio originador, donde se generó la transacción |
6 | cardNumber | Numérico | Número de tarjeta en texto plano. Opcional: Presente solo para Tarjeta de Excepción. |
7 | expiration | Numérico | Fecha de vencimiento de la tarjeta en texto plano. Opcional: Presente solo para Tarjeta de Excepción. |
8 | cvc | Numérico | Código de seguridad de la tarjeta. Opcional: Presente solo para Tarjeta de Excepción. |
9 | track2 | Alfanumérico | Track2 de la tarjeta entero. Opcional: Tarjeta de Excepción. |
24 | trxId | Numérico | OPCIONAL. En caso que el Campo 26 sea TrxIsPending, contendrá el trxId de la transacción pendiente. |
25 | dateTime | Numérico | Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. |
26 | responseCode | Alfanumérico | Puede contener uno de los siguientes valores:
|
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). |
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.
# | FieldId | Tipo | Obligatorio | Descripción |
| 0 | company | Numérico | SI | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | SI | Identificador del sitio originador de la transacción |
2 | node | Numérico | SI | Identificación del nodo, en el sitio originador, donde se generó la transacción |
3 | server | Alfanumérico | Compatibilidad atrás. | Identificador del Server que procesará la transacción. ('VTOL') |
4 | messageType | Alfanumérico | Compatibilidad atrás. | Tipo de Mensaje:
|
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:
|
11 | trxType | Alfanumérico | Obligatorio | Tipo de Transacción:
|
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:
|
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: |
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):
|
102 | chiptokens | Alfanumérico | Obligatorio | Visa: Criptograma tarjetas EMV |
103 | emvEncryptedType | Alfanumérico | Opcional | Tipo de encriptación utilizada entre Pinpad y Host Autorizador.
|
104 | emvEncryptedData | Alfanumérico | Opcional | Paquete encriptado devuelto por el pinpad y que se enviará al Host Autorizador. |
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).
|
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. |
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
|
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). |
# | FieldId | Tipo | Descripción |
| 0 | company | Numérico | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | Identificador del sitio originador de la transacción |
2 | node | Numérico | Identificación del nodo, en el sitio originador, donde se generó la transacción |
24 | trxId | Numérico | OPCIONAL. En caso que el Campo 26 sea TrxIsPending, contendrá el trxId de la transacción pendiente. |
25 | dateTime | Numérico | Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. |
26 | responseCode | Alfanumérico | Puede contener uno de los siguientes valores:
|
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). |
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.
# | FieldId | Tipo | Obligatorio | Descripción |
|---|---|---|---|---|
| 0 | company | Numérico | Obligatorio | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | Obligatorio | Identificador del sitio originador de la transacción |
2 | node | Numérico | Obligatorio | Identificación del nodo, en el sitio originador, donde se generó la transacción |
11 | trxType | Alfanumérico | Obligatorio | Tipo de Transacción:
|
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:
|
# | FieldId | Tipo | Descripción |
|---|---|---|---|
| 0 | company | Numérico | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | Identificador de la tienda donde se originó el mensaje |
2 | node | Numérico | Identificación del nodo |
25 | dateTime | Numérico | Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS |
26 | responseCode | Alfanumérico | Puede contener uno de los siguientes valores:
|
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 |
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:
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
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.
# | FieldId | Tipo | Obligatorio | Descripción |
| 0 | company | Numérico | SI | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | SI | Identificador del sitio originador de la transacción |
2 | node | Numérico | SI | Identificación del nodo, en el sitio originador, donde se generó la transacción |
3 | server | Alfanumérico | Compatibilidad atrás | Identificador del Server que procesará la transacción. ('VTOL') |
4 | messageType | Alfanumérico | Compatibilidad atrás. | Tipo de Mensaje:
|
11 | trxType | Alfanumérico | Obligatorio | Tipo de Transacció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):
|
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). |
# | FieldId | Tipo | Descripción |
| 0 | company | Numércio | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | Identificador del sitio originador de la transacción |
2 | node | Numérico | Identificación del nodo, en el sitio originador, donde se generó la transacción |
24 | trxId | Numérico | OPCIONAL. En caso que el Campo 26 sea TrxIsPending, contendrá el trxId de la transacción pendiente. |
25 | dateTime | Numérico | Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. |
26 | responseCode | Alfanumérico | Puede contener uno de los siguientes valores:
|
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). |
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.
# | FieldId | Tipo | Obligatorio | Descripción |
11 | trxType | Alfanumérico | Obligatorio | Tipo de Transacción:
|
# | 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". |
Mensajería para confirmar o anular la transacción en VTOL Server.
# | FieldId | Tipo | Descripción |
| 0 | company | Numérico | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | Identificador del sitio originador de la transacción |
2 | node | Numérico | Identificación del nodo, en el sitio originador, donde se generó la transacción |
3 | server | Alfanumérico | Identificador del Server que procesará la transacción. (‘VTOL’) |
4 | messageType | Alfanumérico | Tipo de Mensaje:
|
11 | trxType | Alfanumérico | Tipo de Transacción:
|
19 | lastTrxAction | Alfanumérico | Acción a realizar sobre 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] |
El tercer mensaje no tiene respuesta, salvo que esté prendido el flag de chequeo de transacciones pendientes.
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:
# | FieldId | Tipo | Descripción |
19 | lastTrxAction | Alfanumérico | Acción a realizar sobre 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] |
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.
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.
# | FieldId | Tipo | Descripción |
| 0 | company | Numérico | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | Identificador del sitio originador de la transacción |
2 | node | Numérico | Identificación del nodo, en el sitio originador, donde se generó la transacción |
3 | server | Alfanumérico | Identificador del Server que procesará la transacción. (en el caso de VTOL será 'VTOL') |
4 | messageType | Alfanumérico | Tipo de Mensaje:
|
11 | trxType | Alfanumérico | Tipo de Transacción:
|
25 | dateTime | Numérico | Fecha de generación de la trx en el POS. Formato YYYYMMDDHHmmss |
# | FieldId | Tipo | Descripción |
| 0 | company | Numérico | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | Identificador del sitio originador de la transacción |
2 | node | Numérico | Identificación del nodo, en el sitio originador, donde se generó la transacción. |
24 | trxId | Numérico | OPCIONAL: En caso que el Campo 26 sea TrxIsPending, contendrá el trxId de la transacción pendiente. |
25 | dateTime | Numérico | Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. |
26 | responseCode | Alfanumérico | Puede contener uno de los siguientes valores:
|
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" |
31 | lotNumber | Numérico | Constante igual a 1 para mantener compatibilidad hacia atrás. |
32 | ticket | Numérico | Constante igual a 1 para mantener compatibilidad hacia atrás. |
Nota: si la respuesta es "aprobada" significa que no hay transacciones pendientes.
Este mensaje permite listar todos los id de las transacciones pendientes en VTOL que una tienda en particular, física o virtual, tiene.
# | FieldId | Tipo | Descripción |
| 0 | company | Numérico | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | Identificador del sitio originador de la transacción |
2 | node | Numérico | Identificación del nodo, en el sitio originador, donde se generó la transacción |
3 | server | Alfanumérico | Identificador del Server que procesará la transacción. (en el caso de VTOL será 'VTOL') |
4 | messageType | Alfanumérico | Tipo de Mensaje:
|
11 | trxType | Alfanumérico | Tipo de Transacción:
|
25 | dateTime | Numérico | Fecha de generación de la trx en el POS. Formato YYYYMMDDHHmmss |
# | FieldId | Tipo | Descripción |
| 0 | company | Numérico | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | Identificador del sitio originador de la transacción |
2 | node | Numérico | Identificación del nodo, en el sitio originador, donde se generó la transacción. |
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:
|
27 | isoCode | Numérico | Código de Respuesta emitido por VTOL |
28 | responseMessage | Alfanumérico | Mensaje de respuesta. Por ejemplo "Aprobada" |
31 | lotNumber | Numérico | Constante igual a 1 para mantener compatibilidad hacia atrás. |
32 | ticket | Numérico | Constante igual a 1 para mantener compatibilidad hacia atrás. |
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.
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:
| Nota: La operatoria PEI no posee tercer mensaje, por lo que cada operación queda automáticamente en estado "Commited" (comiteado). |
Referencias X = Obligatorio |
Número | Nombre del campo | Tipo de dato | SalePEI | RefundPEI | QueryPEI | Descripción |
|---|---|---|---|---|---|---|
| 0 | company | Numérico | X | X | X | Identificador de la compañía donde se generó la transacción. |
| 1 | store | Alfanumérico | X | X | X | Identificador del sitio originador de la transacción |
| 2 | node | Numérico | X | X | X | Identificación del nodo, en el sitio originador, donde se generó la transacción |
| 3 | server | Alfanumérico | X | X | X | Identificador del Server que procesará la transacción. (en el caso de VTOL será 'VTOL') |
| 4 | messageType | Alfanumérico | X | X | X | Tipo de Mensaje:
|
8 | Cvc | Numérico | X | X | - | Código de seguridad de la tarjeta |
9 | track2 | Alfanumérico | X | X | X | Track2 de la tarjeta entero (se envía todo el contenido del track2 en este campo) |
10 | inputMode | Alfanumérico | X | X | X | Forma en que se ingresó/leyó la tarjeta. Valor posible:
|
11 | trxType | Alfanumérico | X | X | X | Tipo de Transacción:
|
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:
|
25 | dateTime | Numérico | X | X | X | Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. Es importante persistir este valor para consultar el resultado de una operación en caso de algún inconveniente |
| 66 | track1 | Alfanumérico | X | X | X | Track1 de la tarjeta entero (se envía todo el contenido del track1 en este campo) |
| 71 | checkPendingString | Alfanumérico | O Default = true | O Default = true | O Default = true | Indica si VTOL debe o no efectuar el chequeo de pendientes (se emplea para pagos parciales de tarjetas):
|
| 153 | idOperationPEI | Alfanumérico | - | X | - | Identificador de la operación PEI de pago que se desea devolver |
| 155 | cbu | Alfanumérico | - | O | - | CBU de la cuenta destino de la devolución asociada con la tarjeta Banelco. Si el dato se envía, el valor es validado por Link |
| 156 | cbuAlias | Alfanumérico | - | O | - | Alias del CBU de la cuenta destino de la devolución asociada con la tarjeta Banelco. Si el dato se envía, el valor es validado por Link |
| 157 | customerDoc | Alfanumérico | X | O | - | Número de documento del titular de la tarjeta |
158 | lastFourDigits | Numérico | X | X | - | Últimos 4 dígitos de la tarjeta. La solicitud de la validación de los últimos 4 dígitos de la tarjeta es configurable por prefijo |
| 161 | operationConcept | Numérico | O | - | - | Concepto por el cual se realiza la operación, valores posibles:
|
| 164 | posEncryptedFields | Numérico | X | X | X | Indica si se utiliza encripción RSA. En este caso los datos sensibles se envían encriptados. Si está activo, los campos a enviar encriptados son: 8, 9, 66
|
| 173 | dateTimeOriginalTrx | Numérico | - | - | X | Fecha y hora de realización de la transacción de venta o devolución que se desea consultar en formato YYYYMMDDHHMMSS. Se debe enviar el valor del campo 25 de la transacción a consultar |
| 403 | afApplicationCondition | Alfanumérico | O | - | - | 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} |
Referencias X = Obligatorio |
Número | Nombre del campo | Tipo de dato | SalePEI | RefundPEI | QueryPEI | Descripción |
|---|---|---|---|---|---|---|
| 0 | company | Numérico | X | X | X | Identificador de la compañía donde se generó la transacción |
| 1 | store | Alfanumérico | X | X | X | Identificador del sitio originador de la transacción |
| 2 | node | Numérico | X | X | X | Identificación del nodo, en el sitio originador, donde se generó la transacción |
25 | dateTime | Numérico | X | X | X | Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. El valor en este campo debe ser el mismo que el valor de la fecha y hora del requerimiento. El POS utiliza este dato para validar que se trate de la misma transacción |
26 | responseCode | Alfanumérico | X | X | X | Puede contener uno de los siguientes valores:
|
27 | isoCode | Numérico | X | X | X | Código de Respuesta ISO-8583 emitido por el centro autorizador. 2 dígitos como máximo. Ver sección Códigos de Respuesta de VTOL Server para PEI |
28 | responseMessage | Alfanumérico | X | X | X | Mensaje de la Respuesta ISO-8583 relacionado con el código del campo 27 |
35 | errorDescription | Alfanumérico | X | X | X | Descripción de error. Sólo se encuentra presente si el valor del campo 26 es “Error” |
153 | idOperationPEI | Alfanumérico | X | X | X | Identificador de la operación PEI de pago o de devolución |
| 154 | idOperationOrigenPEI | Alfanumérico | - | X | O | Identificador de la operación PEI de origen con la cual se solicitó la devolución. |
| 170 | idCommercePEI | Alfanumérico | X | X | X | Identificador PEI de compañía |
| 171 | idBranchPEI | Alfanumérico | X | X | X | Identificador PEI de local |
| 172 | idTerminalPEI | Alfanumérico | X | X | X | Identificador PEI de terminal |
| 174 | originalTrxStatus | Numérico | - | - | O | Informa el estado de la transacción original en una operación de consulta. Si el campo en la respuesta no se recibe es porque la consulta falló. Puede contener uno de los siguientes valores:
|
| 278 | bankingRefNum | Alfanumérico | X | - | X | Numero de referencia de la transacción de pago. Se utiliza para conciliar con los reportes de las entidades bancarias. Número generado por LINK. |
Ejemplo
Response from VTOL (SalePEI): Response message: {25:20180905111036;2:1;1:1;171:87;170:143;153:9439999999999999943;172:SYN001;27:00;26:ISO8583;28:APROBADA} Response from VTOL (RefundPEI): Response message: {25:20180905111046;2:1;1:1;171:87;170:143;154:9439999999999999943;153:3879999999999999387;172:SYN001;27:00;26:ISO8583;28:APROBADA} Response from VTOL (QueryPEI): Response message: {25:20180905111059;2:1;1:1;171:87;170:143;154:9439999999999999943;153:3879999999999999387;172:SYN001;27:00;174:0;26:ISO8583;28:APROBADA} |
Mensaje utilizado para el pago de resumen de cuenta de una tarjeta de crédito.
# | FieldId | Tipo | Obligatorio | Descripción |
|---|---|---|---|---|
| 0 | company | Numérico | SI | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | SI | Identificador del sitio originador de la transacción |
2 | node | Numérico | SI | Identificación del nodo, en el sitio originador, donde se generó la transacción |
3 | server | Alfanumérico | Compatibilidad atrás. | Identificador del Server que procesará la transacción. ('VTOL') |
4 | messageType | Alfanumérico | Compatibilidad atrás. | Tipo de Mensaje:
|
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:
|
| 157 | customerDoc | Alfanumérico | Obligatorio | Número de documento del titular de la tarjeta |
| 265 | customerId | Alfanumérico | Obligatorio | Identificador del usuario o comprador |
| 266 | cardHolderName | Alfanumérico | Obligatorio | Nombre del tarjetahabiente |
# | FieldId | Tipo | Descripción |
|---|---|---|---|
| 0 | company | Numérico | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | Identificador del sitio originador de la transacción |
2 | node | Numérico | Identificación del nodo, en el sitio originador, donde se generó la transacción |
22 | authorizationCode | Alfanumérico | Código de autorización generado por el centro autorizador para la transacción. |
23 | authorizationMode | Alfanumérico | Modo de Autorización:
|
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:
|
27 | isoCode | Numérico | Código de Respuesta ISO-8583 emitido por el centro autorizador. 2 dígitos como máximo |
28 | responseMessage | Alfanumérico | Mensaje de la Respuesta ISO-8583 |
201 | additionalMessageData | Alfanumérico | Este campo tiene como finalidad que el POS, o cliente VTOL, pueda enviar un dato X y que el mismo esté presente en la respuesta. Cada módulo según implementación puede decidir qué hacer con dicho dato (Ejem Persistir en BBDD). |
| 263 | vtolToken | Alfanumérico | Token VTOL tras tokenizar una tarjeta |
| 267 | vtolTokenExpire | Numérico | Fecha y hora de expiración del Token VTOL en formato YYYYMMDD |
VTOL se integra con las siguientes billeteras electrónicas para permitir efectuar pagos en los puntos de venta:
Las operaciones soportadas en VTOL Server para Billeteras electrónicas son:
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:
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
Devoluciones
Anulaciones
X = Obligatorio |
Número | Nombre del campo | Tipo de dato | SaleWallet | RefundWallet | QuerySaleWallet | Descripción |
|---|---|---|---|---|---|---|
| 0 | company | Numérico | X | X | X | Identificador de la compañía donde se generó la transacción. |
| 1 | store | Alfanumérico | X | X | X | Identificador del sitio originador de la transacción |
| 2 | node | Numérico | X | X | X | Identificación del nodo, en el sitio originador, donde se generó la transacción |
| 3 | server | Alfanumérico | X | X | X | Identificador del Server que procesará la transacción. (en el caso de VTOL será 'VTOL') |
| 4 | messageType | Alfanumérico | X | X | X | Tipo de Mensaje:
|
11 | trxType | Alfanumérico | X | X | X | Tipo de Transacción:
|
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:
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 |
| 14 | payments | Numérico | - | - | O | Cantidad de cuotas por las cuales se realizará el pago. 2 dígitos como máximo Si es sin cuotas, el valor por defecto es 1 |
| 15 | plan | Alfanumérico | - | - | O | Plan. 1 caracter de longitud |
| 16 | originalDate | Numérico | - | X | X | Fecha de realización de la compra con billetera electrónica en formato YYYYMMDD |
| 24 | lastTrxId | Numérico | O | O | O | Utilizado cuando está activo el control transaccional. En este campo el POS debe enviar la última transacción procesada correctamente. |
25 | dateTime | Numérico | X | X | X | Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS |
| 53 | paymentCondition | Alfanumérico | - | - | O | Condición de pago. Sólo se encuentra presente si existe una condición de pago vinculada con la transacción |
| 54 | additionalAmount | Importe | O | O | - | 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. |
| 71 | checkPendingString | Alfanumérico | O Default = true | O Default = true | O Default = true | Indica si VTOL debe o no efectuar el chequeo de pendientes (se emplea para pagos parciales de tarjetas):
|
| 268 | walletPosTrxId | Alfanumérico | X | - | O | Identificador único de la transacción de billetera para la compañía. Es originado por el POS para realizar una compra con billetera Formato: Opcional en QuerySaleWallet: Se informa este campo o el campo walletPaymentId para localizar una transacción de compra |
| 269 | walletType | Numérico | X | X | X | Tipo de billetera por la cual se cursará la transacción en el POS. Opciones: 1: Mercado Pago |
| 270 | posTicket | Base 64 | X | - | - | Información del ticket en formato xml y posteriormente transformado en Base 64. Ver sección Estructura del campo posTicket |
| 271 | walletPaymentId | Alfanumérico | - | X | O | Identificador del número de pago informado por el Autorizador en el campo 271 de la respuesta de la operación SaleWallet Opcional en QuerySaleWallet: Se informa este campo o el campo walletPosTrxId para localizar una transacción de compra |
| 311 | purchaseTitle | Alfanumérico | O | - | - | 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". |
| 312 | purchaseDesc | Alfanumérico | O | - | - | 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 | "-" | |
| description | Alfanumérico | Descripción del ítem | Si | ||
| currency | Alfanumérico | Moneda utilizada en el precio del ítem Nota: En el punto de venta se deberá informar la moneda de la cuenta vendedor de Mercado Pago (si el retailer posee una cuenta argentina en Mercado Pago entonces tendrá que informar la moneda $ -pesos argentinos-). | Si | ||
| measure | Alfanumérico | Unidad de medida del ítem. Valores posibles: unit - pack | No | "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> |
Esta estructura generada debe transformarse al formato Base 64 para informárselo a VTOL en el campo 270 posTicket. |
Número | Nombre del campo | Tipo de dato | SaleWallet | RefundWallet | QuerySaleWallet | Descripción |
|---|---|---|---|---|---|---|
| 0 | company | Numérico | X | X | X | Identificador de la compañía donde se generó la transacción |
| 1 | store | Alfanumérico | X | X | X | Identificador del sitio originador de la transacción |
| 2 | node | Numérico | X | X | X | Identificación del nodo, en el sitio originador, donde se generó la transacción |
| 6 | cardNumber | Alfanumérico | O | - | O | Tarjeta enmascarada seleccionada al momento de efectuar el pago QR. El campo es opcional en caso de que se haya abonado con saldo de la cuenta de Mercado Pago |
| 12 | amount | Importe | X | - | X | Monto de la transacción. Valor entero. Los últimos 2 dígitos corresponden a los decimales. |
| 13 | currencyPosCode | Alfanumérico | - | - | X | Tipos de moneda:
|
| 14 | payments | Numérico | - | - | O | Cantidad de cuotas seleccionadas al momento de realizar el pago QR. El campo es opcional en caso de que se haya abonado con saldo de la cuenta de Mercado Pago |
| 22 | authorizationCode | Alfanumérico | X | - | X | Código de autorización informado por el Autorizador |
| 24 | trxId | Numérico | X | X | X | Identificador de la transacción |
| 25 | dateTime | Numérico | X | X | X | Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. El valor en este campo debe ser el mismo que el valor de la fecha y hora del requerimiento. El POS utiliza este dato para validar que se trate de la misma transacción |
| 26 | responseCode | Alfanumérico | X | X | X | Puede contener uno de los siguientes valores:
|
| 27 | isoCode | Numérico | X | X | X | 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 |
| 28 | responseMessage | Alfanumérico | X | X | X | Mensaje de la Respuesta relacionado con el código del campo 27 |
| 54 | additionalAmount | Importe | O | O | O | 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. |
| 140 | paymentType | Numérico | - | - | X | Tipo de pago. Valores posibles: 0: Tarjeta |
| 142 | providerName | Alfanumérico | - | - | O | Proveedor de la tarjeta seleccionada al momento de efectuar el pago QR. El campo es opcional en caso de que se haya abonado con saldo de la cuenta de Mercado Pago |
| 147 | providerPosCode | Lista | O | - | - | Lista de proveedores/tarjetas que coinciden con la tarjeta ingresada en la app de la billetera electrónica. Ejemplo: {VI, EL}. Esta lista deberá ser utilizada para seleccionar la tarjeta manualmente por el POS. |
| 157 | customerDoc | Numérico | O | O | O | Numero de documento del titular de la tarjeta. |
| 303 | customerName | Alfanumérico | O | O | O | Nombre del titular de la tarjeta. |
| 166 | trxReferenceNumber | Numérico | X | X | - | Identificador único de la transacción en VTOL Server. Longitud entre 19 y 20 dígitos, debido a que utiliza el día como parte de formato |
| 271 | walletPaymentId | Alfanumérico | X | - | X | Identificador del número de pago informado por el Autorizador |
| 272 | amountRefunded | Importe | - | - | X | Monto devuelto en la transacción |
| 273 | paymentStatus | Alfanumérico | - | - | X | Estado de la transacción de pago informado por el Autorizador. Estados posibles: 0: Aprobado |
| 274 | paymentStatusDetail | Alfanumérico | - | - | X | Detalle del estado de la transacción de pago informado por el Autorizador |
| 275 | cardType | Numérico | - | - | O | Tipo de tarjeta seleccionada al momento de efectuar el pago QR. El campo es opcional en caso de que se haya abonado con saldo de la cuenta de Mercado Pago. Valores posibles: 0: Débito |
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} |
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:
Nro | Campo | Tipo | Sale | Capture | PreAuth | VoidPreAuth | Descripción |
|---|---|---|---|---|---|---|---|
| 0 | company | Numérico | X | X | X | X | Identificador de la compañía donde se generó la transacción |
1 | store | Alfanumérico | X | X | X | X | Identificador del sitio originador de la transacción |
3 | server | Alfanumérico | X | X | X | X | Identificador del Server que procesará la transacción. ('VTOL') |
4 | messageType | Alfanumérico | X | X | X | X | Tipo de Mensaje:
|
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 | X | X | X | X | Modo de Ingreso de la tarjeta: 3 - E-Commerce |
11 | trxType | Alfanumérico | X | X | X | X | Tipo de Transacción:
|
12 | amount | Importe | X | X | 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 | X | X | Tipos de Moneda:
|
14 | payments | Numérico | X | X | X | X | Cantidad de cuotas. 2 dígitos como máximo. |
15 | plan | Alfanumérico | X | X | X | X | 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 | X | X | X | X | Modo de Autorización:
|
25 | dateTime | Numérico | X | X | X | X | 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. |
| 118 | terminalCapability | Alfanumérico | X | X | X | X | Capacidad de captura. Valor a enviar:
|
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. |
| 167 | originalTrxReferenceNumber | Alfanumérico | O | X | O | 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 Sale o una PreAuthorization. Obligatorio para los trxType: Anulación de autorización (VoidPreAuthorization) y Captura (Sale offline). |
| 201 | additionalMessageData | Alfanumérico | O | O | O | O | 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. |
| 264 | posChannelOrigin | Numérico | O | O | O | O | Indica el canal de origen de la transacción. Es un código con los siguientes valores posibles:
|
| 266 | cardHolderName | Alfanumérico | X | O | X | O | Nombre del tarjetahabiente |
| 270 | posTicket | Alfanumérico | O | O | O | O | Información del ticket en formato xml y posteriormente transformado en Base 64. Ver sección Estructura del campo posTicket |
| 265 | customerId | Alfanumérico | O | O | O | O | Nombre de usuario que realizó la transacción. Este campo se utiliza para validar posibles fraudes, por parte del módulo Antifraude de VTOL. |
| 290 | customerIp | Alfanumérico | O | O | O | O | IP 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. |
| 291 | customerDocType | Alfanumérico | O | O | O | O | Tipo 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. |
| 157 | customerDoc | Alfanumérico | O | O | O | O | Nú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. |
| 292 | customerFirstName | Alfanumérico | O | O | O | O | Nombre 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. |
| 293 | customerLastName | Alfanumérico | O | O | O | O | Apellido 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. |
| 294 | cardHolderBirthday | Alfanumérico | X | X | X | X | Fecha de nacimiento del titular de la tarjeta. Formato YYYYMMDD. Este dato se envía a Prisma para validar posibles fraudes por parte del emisor. |
| 295 | cardHolderDocType | Alfanumérico | X | X | X | X | Tipo de documento del titular de la tarjeta. Este dato se envía a Prisma para validar posibles fraudes por parte del emisor. |
| 296 | cardHolderDocNumber | Alfanumérico | X | X | X | X | Número de documento del titular de la tarjeta. Este dato se envía a Prisma para validar posibles fraudes por parte del emisor. |
| 297 | cardHolderAddressStreet | Alfanumérico | O | O | O | O | Calle de entrega del resumen del titular de la tarjeta. Este dato se envía a Prisma para validar posibles fraudes por parte del emisor. |
| 298 | cardHolderAddressNumber | Alfanumérico | X | X | X | O | Nú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. |
| 299 | cardHolderZipCode | Alfanumérico | O | O | O | O | Có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. |
| 305 | cardHolderAddressComplement | Alfanumérico | O | O | O | O | Complemento 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. |
| 306 | cardIssuingBank | Alfanumérico | O | O | O | O | Banco 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. |
| 307 | cardBrand | Alfanumérico | O | O | O | O | Marca 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. |
| 403 | afApplicationCondition | Alfanumérico | O | O | O | - | 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. |
Nro | Campo | Tipo | Descripción |
|---|---|---|---|
| 0 | company | Numérico | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | Identificador del sitio originador de la transacción |
2 | node | Numérico | Identificación del nodo, en el sitio originador, donde se generó la transacción |
22 | authorizationCode | Alfanumérico | Código de autorización generado por el centro autorizador para la transacción. |
23 | authorizationMode | Alfanumérico | Modo de Autorización:
|
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:
|
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. |
| 308 | vteValidation | Alfanumé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.
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: Ejemplo: Código informado = 0112
|
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.
Nro | Campo | Tipo | Descripción |
|---|---|---|---|
| 0 | company | Numérico | Identificador de la compañía donde se generó la transacción. |
| 1 | store | Alfanumérico | Identificador del sitio originador de la transacción |
| 10 | inputMode | Alfanumérico | Modo de Ingreso de la tarjeta:
|
11 | trxType | Alfanumérico | Tipo de Transacció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 |
13 | currencyPosCode | Alfanumérico | Tipos de Moneda:
|
14 | payments | Numérico | Cantidad de cuotas. 2 dígitos como máximo. |
15 | plan | Alfanumérico | Código de plan. Largo 1. |
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. |
| 167 | originalTrxReferenceNumber | Numérico | Identificador de la transacción original generado VTOL Server. |
| 25 | dateTime | Numérico | Fecha 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. |
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. |
| 264 | posChannelOrigin | Numérico | Indica el canal de origen de la transacción.
|
Nota: Tomar como referencia la respuesta del tipo de mensaje Sale.
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:
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
La operatoria PEI no posee tercer mensaje, por lo que cada operación queda automáticamente en estado "Commited" (comiteado). |
X = Obligatorio |
| Nro | Nombre del campo | Tipo de dato | SalePEI | RefundPEI | QueryPEI | Descripción |
|---|---|---|---|---|---|---|
| 0 | company | Numérico | X | X | X | Identificador de la compañía donde se generó la transacción. |
| 1 | store | Alfanumérico | X | X | X | Identificador del sitio originador de la transacción |
| 2 | node | Numérico | X | X | X | Identificación del nodo, en el sitio originador, donde se generó la transacción |
| 3 | server | Alfanumérico | X | X | X | Identificador del Server que procesará la transacción. (en el caso de VTOL será 'VTOL') |
| 4 | messageType | Alfanumérico | X | X | X | Tipo de Mensaje:
|
10 | inputMode | Alfanumérico | X | X | X | Forma de ingreso:
|
11 | trxType | Alfanumérico | X | X | X | Tipo de Transacción:
|
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:
|
13 | currencyPosCode | Alfanumérico | X | X | - | Tipos de Moneda:
|
25 | dateTime | Numérico | X | X | X | Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. Es importante persistir este valor para consultar el resultado de una operación en caso de algún inconveniente |
| 153 | idOperationPEI | Alfanumérico | - | X | O | Identificador de operación Cuenta DNI PEI de pago que se desea devolver o consultar. |
| 157 | customerDoc | Alfanumérico | O | - | - | Número de documento del titular de la cuenta. Obligatorio junto con softToken, únicamente si el modo de ingreso es softToken. |
| 173 | dateTimeOriginalTrx | Numérico | - | - | X | Fecha y hora de realización de la transacción de venta o devolución que se desea consultar en formato YYYYMMDDHHMMSS. Se debe enviar el valor del campo 25 de la transacción a consultar. |
| 279 | softToken | Alfanumérico | O | - | - | 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érico | O | - | - | 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. |
| Nro | Campo | Tipo de dato | SalePEI | RefundPEI | QueryPEI | Descripción |
|---|---|---|---|---|---|---|
| 0 | company | Numérico | X | X | X | Identificador de la compañía donde se generó la transacción. |
| 1 | store | Alfanumérico | X | X | X | Identificador del sitio originador de la transacción |
| 2 | node | Numérico | X | X | X | Identificación del nodo, en el sitio originador, donde se generó la transacción |
| 25 | dateTime | Numérico | X | X | X | Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. El valor en este campo debe ser el mismo que el valor de la fecha y hora del requerimiento. El POS utiliza este dato para validar que se trate de la misma transacción. |
26 | responseCode | Alfanumérico | X | X | X | Puede contener uno de los siguientes valores:
|
27 | isoCode | Numérico | X | X | X | Código de Respuesta ISO-8583 emitido por el centro autorizador. 2 dígitos como máximo. Ver sección Códigos de Respuesta de VTOL Server para PEI |
28 | responseMessage | Alfanumérico | X | X | X | Mensaje de la Respuesta ISO-8583 relacionado con el código del campo 27 |
35 | errorDescription | Alfanumérico | X | X | X | Descripción de error. Sólo se encuentra presente si el valor del campo 26 es “Error” |
153 | idOperationPEI | Alfanumérico | X | X | X | Identificador de la operación PEI de pago o de devolución |
| 154 | idOperationOrigenPEI | Alfanumérico | - | X | O | Identificador de la operación original de pago. |
| 170 | idCommercePEI | Alfanumérico | X | X | X | Identificador PEI de compañía |
| 171 | idBranchPEI | Alfanumérico | X | X | X | Identificador PEI de local |
| 172 | idTerminalPEI | Alfanumérico | X | X | X | Identificador PEI de terminal |
| 174 | originalTrxStatus | Numérico | - | - | O | Informa el estado de la transacción original en una operación de consulta. Si el campo en la respuesta no se recibe es porque la consulta falló. Puede contener uno de los siguientes valores:
|
| 278 | bankingRefNum | Alfanumérico | X | X | X | Número de referencia de la transacción de pago. |
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:
Sólo será requerido informar Promociones PEI en caso que se realice una venta PEI con productos que tengan promociones. |
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.
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.
X = Obligatorio |
| Nro | Campo | Tipo de dato | PromoPei | Descripción |
|---|---|---|---|---|
| 0 | company | Numérico | X | Identificador de la compañía donde se generó la transacción. |
| 1 | store | Alfanumérico | X | Identificador del sitio originador de la transacción |
| 2 | node | Numérico | X | Identificación del nodo, en el sitio originador, donde se generó la transacción |
| 3 | server | Alfanumérico | X | Identificador del Server que procesará la transacción. (en el caso de VTOL será 'VTOL') |
| 4 | messageType | Alfanumérico | X | Tipo de Mensaje:
|
11 | trxType | Alfanumérico | X | Tipo de Transacción:
|
| 301 | originalTrxType | Alfanumérico | X | Identificador 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. |
| 13 | currencyPosCode | Alfanumérico | X | Tipos de Moneda:
|
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 |
| 153 | idOperationPEI | Alfanumérico | X | Identificador de operación PEI de pago que devuelve Link en la respuesta del pago. |
| 278 | bankingRefNum | Alfanumérico | X | Número de referencia bancaria de la operación de pago. Es devuelta por Link en la operación de pago. |
| Nro | Campo | Tipo de dato | PromoPei | Descripción |
|---|---|---|---|---|
| 0 | company | Numérico | X | Identificador de la compañía donde se generó la transacción. |
| 1 | store | Alfanumérico | X | Identificador del sitio originador de la transacción |
| 2 | node | Numérico | X | Identificació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:
|
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” |
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:
Nota: La operatoria PEI no posee tercer mensaje, por lo que cada operación queda automáticamente en estado "Commited" (comiteado). |
X = Obligatorio |
| Nro | Campo | Tipo | SalePEI | RefundPEI | QueryPEI | |
|---|---|---|---|---|---|---|
| 0 | company | Numérico | X | X | X | Identificador de la compañía donde se generó la transacción |
1 | store | Alfanumérico | X | X | X | Identificador del sitio originador de la transacción |
3 | server | Alfanumérico | X | X | X | Identificador del Server que procesará la transacción. Enviar: VTOL |
4 | messageType | Alfanumérico | X | X | X | Tipo de Mensaje:
|
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 | X | X | X | Modo de Ingreso de la tarjeta:
|
11 | trxType | Alfanumérico | X | X | X | Tipo de Transacción:
|
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:
|
14 | payments | Numérico | X | X | - | Cantidad de cuotas. Enviar siempre: 1 |
15 | plan | Alfanumérico | X | - | - | Plan. Enviar siempre: 0 |
| 16 | originalDate | Fecha | - | X | - | Fecha de la transacción original en el formato YYYYMMDD. |
25 | dateTime | Numérico | X | X | X | Fecha de generación de la trx en el POS. Formato YYYYMMDDHHmmss |
| 118 | terminalCapability | Alfanumérico | X | X | X | Capacidad de captura. Valor a enviar:
|
147 | providerPosCode | Alfanumérico | O | - | - | Código del Provider. Ejemplo: VI (Visa). Longitud 20. |
| 153 | idOperationPEI | Alfanumérico | - | X | - | Identificador de la operación PEI de pago original que se desea devolver. |
| 167 | originalTrxReferenceNumber | Alfanumé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. |
| 201 | additionalMessageData | Alfanumérico | O | O | - | 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. |
| 264 | posChannelOrigin | Numérico | X | X | X | Indica el canal de origen de la transacción. Es un código con los siguientes valores posibles:
|
| 266 | cardHolderName | Alfanumérico | X | X | - | Nombre del tarjetahabiente |
| 270 | posTicket | Alfanumérico | O | O | - | Información del ticket en formato xml y posteriormente transformado en Base 64. Ver sección Estructura del campo posTicket |
| 139 | customerRef | Alfanumé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. |
| 265 | customerId | Alfanumérico | O | O | - | Nombre de usuario que realizó la transacción |
| 157 | customerDoc | Alfanumérico | O | O | - | Número de documento del cliente que realizó la transacción. |
| 161 | operationConcept | Alfanumérico | X | - | - | Concepto por el cual se realiza la operación, valores posibles:
|
| 173 | dateTimeOriginalTrx | Numérico | - | - | X | Fecha y hora de realización de la transacción de venta o devolución que se desea consultar en formato YYYYMMDDHHMMSS. Se debe enviar el valor del campo 25 de la transacción a consultar. |
| 290 | customerIp | Alfanumérico | O | O | - | IP de origen de donde se efectuó la transacción |
| 291 | customerDocType | Alfanumérico | O | O | - | Tipo de documento del cliente que realizó la transacción. |
| 292 | customerFirstName | Alfanumérico | O | O | - | Nombre del cliente registrado en el e-commerce que realizó la transacción. |
| 293 | customerLastName | Alfanumérico | O | O | - | Apellido del cliente registrado en el e-commmerce que realizó la transacción. |
| 295 | cardHolderDocType | Alfanumérico | X | - | - | Tipo de documento del titular de la tarjeta. |
| 296 | cardHolderDocNumber | Alfanumérico | X | - | - | Número de documento del titular de la tarjeta. |
| 306 | cardIssuingBank | Alfanumérico | O | O | - | Banco emisor de la tarjeta. Longitud máxima 20. |
| 307 | cardBrand | Alfanumérico | O | O | - | Marca de la tarjeta. Longitud máxima 20. |
| 403 | afApplicationCondition | Alfanumérico | O | - | - | 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. |
| Nro | Campo | Tipo | SalePEI | RefundPEI | QueryPEI | Descripción |
|---|---|---|---|---|---|---|
| 0 | company | Numérico | X | X | X | Identificador de la compañía donde se generó la transacción. |
1 | store | Alfanumérico | X | X | X | Identificador del sitio originador de la transacción |
2 | node | Numérico | X | X | X | Identificación del nodo, en el sitio originador, donde se generó la transacción |
| 6 | cardNumber | Alfanumérico | X | X | O | Número de tarjeta enmascarado con la cual se realizó el pago. Ejemplo: 450799xxxxxx0010 |
25 | dateTime | Numérico | X | X | X | Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. |
26 | responseCode | Alfanumérico | X | X | X | Puede contener uno de los siguientes valores:
|
27 | isoCode | Numérico | X | X | X | Código de Respuesta ISO-8583 emitido por el centro autorizador. 2 dígitos como máximo |
28 | responseMessage | Alfanumérico | X | X | X | Mensaje de la Respuesta ISO-8583 |
33 | creditCardIssuerName | Alfanumérico | X | X | X | Nombre del emisor de la tarjeta |
35 | errorDescription | Alfanumérico | X | X | X | Descripción de error. Sólo se encuentra presente si el valor del campo 26 es "Error". |
166 | trxReferenceNumber | Numérico | X | X | X | Identificador único de la transacción en VTOL Server. Longitud entre 19 y 20 dígitos, debido a que utiliza el día como parte de formato. |
| 153 | idOperationPEI | Alfanumérico | X | X | X | Identificador de la operación PEI de pago o de devolución |
| 154 | idOperationOrigenPEI | Alfanumérico | - | X | O | Identificador de la operación PEI de origen con la cual se solicitó la devolución. |
| 170 | idCommercePEI | Alfanumérico | X | X | X | Identificador PEI de compañía |
| 171 | idBranchPEI | Alfanumérico | X | X | X | Identificador PEI de local |
| 174 | originalTrxStatus | Alfanumé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:
|
| 278 | bankingRefNum | Alfanumérico | X | - | X | Numero de referencia de la transacción de pago. Se utiliza para conciliar con los reportes de las entidades bancarias. Número generado por LINK. |
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:
Procedimiento para QR Adquiriente
El proceso de pagos para QR Adquiriente con billetera virtual se realizará de la siguiente manera:
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.
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:
|
X = Obligatorio |
Número | Nombre del campo | Tipo de dato | SaleWallet | RefundWallet | QueryWallet | Descripción |
|---|---|---|---|---|---|---|
| 0 | company | Numérico | X | X | X | Identificador de la compañía donde se generó la transacción. |
| 1 | store | Alfanumérico | X | X | X | Identificador del local donde se generó la transacción. |
| 2 | node | Numérico | X | X | X | Identificador de la caja donde se generó la transacción. |
| 3 | server | Alfanumérico | X | X | X | Identificador del Server que procesará la transacción. (en el caso de VTOL será 'VTOL') |
| 4 | messageType | Alfanumérico | X | X | X | Tipo de Mensaje:
|
| 11 | trxType | Alfanumérico | X | X | X | Tipo de Transacción:
|
| 12 | amount | Numérico | X | X | - | 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. |
| 13 | currencyPosCode | Alfanumérico | X | X | - | Tipos de moneda:
|
| 16 | originalDate | Numérico | - | X | X | Fecha de realización de la compra con billetera electrónica en formato YYYYMMDD |
| 24 | lastTrxId | Numérico | O | O | O | Utilizado cuando está activo el control transaccional. En este campo el POS debe enviar la última transacción procesada correctamente. |
| 25 | dateTime | Numérico | X | X | X | Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS |
| 268 | walletPosTrxId | Alfanumérico | X | X | O | Identificador único de la transacción de billetera para la compañía. Es originado por el POS para realizar una compra con billetera. Formato: Opcional en QueryWallet: Se informa este campo o el campo walletPaymentId para localizar una transacción de compra. |
| 269 | walletType | Numérico | X | X | X | Tipo de billetera por la cual se cursará la transacción en el POS. Opciones: 2: QR Adquiriente |
| 270 | posTicket | Alfanumérico | X | - | - | Información del ticket en formato xml y posteriormente transformado en Base 64. Ver sección Estructura del campo posTicket |
| 271 | walletPaymentId | Alfanumérico | - | X | O | Identificador del número de pago informado por el Autorizador en el campo 271 de la respuesta de la operación SaleWallet. Opcional en QueryWallet: Se informa este campo o el campo walletPosTrxId para localizar una transacción de compra. |
| 401 | paymentMethodsData | Json | X | - | - | Información de los planes de pago, en formato json |
| 402 | walletBenefits | Json | X | - | - | 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 | "-" | |
| description | Alfanumérico | Descripción del ítem | Si | ||
| currency | Alfanumérico | Moneda utilizada en el precio del ítem Nota: En el punto de venta se deberá informar la moneda de la cuenta vendedor de Mercado Pago (si el retailer posee una cuenta argentina en Mercado Pago entonces tendrá que informar la moneda $ -pesos argentinos-). | Si | ||
| measure | Alfanumérico | Unidad de medida del ítem. Valores posibles: unit - pack | No | "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> |
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ámetro | Tipo de dato | Requerido | Descripción | |
|---|---|---|---|---|
| providerPosCode | Alfanumérico | Si | 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. | |
| bankCode | Numérico | No | Identificador del banco asociado a la tarjeta. Debe corresponder al ID de banco dispuesto por el BCRA. Ver códigos de bancos. | |
| installments | Array | Si | Información de las cuotas. | |
| paymentOptionId | Alfanumérico | Si | 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. | |
| quantity | Numérico | Si | Cantidad de cuotas. Número entero. Máximo 2 dígitos | |
| paymentCondition | Alfanumérico | No | 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. | |
| amountPerInstallment | Importe | Si | Monto por cuotas. Valor entero. Los 2 últimos dígitos corresponden a los decimales. | |
| totalAmount | Importe | Si | Monto total. Incluye los recargos. Valor entero. Los 2 últimos dígitos corresponden a los decimales. | |
| surcharge | Numérico | Si | C.F.T. (Costo Financiero Total). Porcentaje de recargo sobre las cuotas. Valor entero. Los 2 últimos dígitos corresponden a los decimales. | |
| nominalAnnualRate | Numérico | Si | T.N.A. (Tasa Nominal Anual). Valor entero. Los 2 últimos dígitos corresponden a los decimales. | |
Ejemplo del campo paymentMethodsData (401)
[
{
"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ámetro | Tipo de dato | Requerido | Descripción | |
|---|---|---|---|---|
| benefitCardId | Alfanumérico | Si | 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. | |
| providerPosCode | Alfanumérico | Si | Código de la tarjeta de beneficio configurada en VTOL. Por ejemplo para Clarin 365 el código es "CC". | |
discountPercentage | Numérico | Si | Porcentaje de descuento a aplicar sobre la compra. Valor entero. Los 2 últimos dígitos corresponden a los decimales. | |
maximumDiscountAmount | Numérico | Si | Importe 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)
[
{
"benefitCardId":"1",
"providerPosCode":"CC",
"discountPercentage":2000,
"maximumDiscountAmount":25000
},
{
"benefitCardId":"2",
"providerPosCode":"CP",
"discountPercentage":3000,
"maximumDiscountAmount":50000
}
] |
X = Obligatorio |
Número | Nombre del campo | Tipo de dato | SaleWallet | RefundWallet | QueryWallet | Descripción |
|---|---|---|---|---|---|---|
| 0 | company | Numérico | X | X | X | Identificador de la compañía donde se generó la transacción |
| 1 | store | Alfanumérico | X | X | X | Identificador del sitio originador de la transacción |
| 2 | node | Numérico | X | X | X | Identificación del nodo, en el sitio originador, donde se generó la transacción. |
| 6 | cardNumber | Alfanumérico | X | - | O | Tarjeta enmascarada seleccionada por el cliente al momento de efectuar el pago QR. |
| 12 | amount | Importe | X | - | 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. |
| 13 | currencyPosCode | Alfanumérico | X | - | X | Tipos de moneda:
|
| 14 | payments | Numérico | X | - | O | Cantidad de cuotas seleccionadas al momento de realizar el pago QR. |
| 22 | authorizationCode | Alfanumérico | X | - | X | Código de autorización informado por el Autorizador |
| 24 | trxId | Numérico | X | X | X | Identificador de la transacción. |
| 25 | dateTime | Numérico | X | X | X | Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. El valor en este campo debe ser el mismo que el valor de la fecha y hora del requerimiento. El POS utiliza este dato para validar que se trate de la misma transacción |
| 26 | responseCode | Alfanumérico | X | X | X | Puede contener uno de los siguientes valores:
|
| 27 | isoCode | Numérico | X | X | X | Código de Respuesta emitido por el centro autorizador. 2 dígitos como máximo. Ver sección Códigos de Respuesta de VTOL Server para Billeteras Electrónicas |
| 28 | responseMessage | Alfanumérico | X | X | X | Mensaje de la Respuesta relacionado con el código del campo 27 |
29 | serialNumber | Numérico | O | O | O | Número identificatorio de la terminal en la que se procesó la transacción. Retorna en operaciones aprobadas. |
30 | businessNumber | Numérico | O | O | O | Número de comercio en el que se procesó la transacción. Retorna en operaciones aprobadas. |
| 81 | responseAuth | Alfanumérico | O | O | O | Mensaje de repuesta para imprimir en el ticket del POS. Retorna en operaciones aprobadas. Contiene información generada por el Autorizador. |
| 140 | paymentType | Numérico | - | - | X | Tipo de pago. Valores posibles: 0: Tarjeta |
| 142 | providerName | Alfanumérico | - | - | O | Proveedor de la tarjeta seleccionada al momento de efectuar el pago QR. |
| 147 | providerPosCode | Alfanumérico | O | - | O | Código del Provider. Retornará cuando la transacción fue aprobada por el Autorizador. |
| 166 | trxReferenceNumber | Numérico | X | X | - | Identificador único de la transacción en VTOL Server. Longitud entre 19 y 20 dígitos, debido a que utiliza el día como parte de formato |
| 271 | walletPaymentId | Alfanumérico | X | - | X | Identificador del número de pago informado por el Autorizador |
| 272 | amountRefunded | Importe | - | - | X | Monto devuelto en la transacción |
| 273 | paymentStatus | Alfanumérico | - | - | X | Estado de la transacción de pago informado por el Autorizador. Estados posibles: 0: Aprobado |
| 306 | cardIssuingBank | Alfanumérico | O | - | O | Banco emisor de la tarjeta. Retornará cuando la transacción fue aprobada por el Autorizador. |
| 404 | paymentOptionId | Alfanumérico | X | - | 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. |
| 405 | benefitCardId | Alfanumérico | X | - | O | Identificador de la tarjeta de beneficio aplicada en el pago por estar vinculada en la billetera virtual del cliente. |
| 406 | originalAmount | Importe | X | - | O | Monto original de la transacción: de venta o de devolución. |
| 407 | amountDiscounted | Importe | X | - | 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. |
Operatoria para realizar desde el Punto de Venta consultas de las tarjetas de fidelidad.
X = Obligatorio |
Número | Nombre del campo | Tipo de dato | CardQuery | Descripción |
|---|---|---|---|---|
| 0 | company | Numérico | X | Identificador de la compañía donde se generó la transacción. |
| 1 | store | Alfanumérico | X | Identificador del sitio originador de la transacción |
| 2 | node | Numérico | X | Identificación del nodo, en el sitio originador, donde se generó la transacción |
| 3 | server | Alfanumérico | X | Identificador del Server que procesará la transacción. (en el caso de VTOL será 'VTOL') |
| 4 | messageType | Alfanumérico | X | Tipo de Mensaje:
|
11 | trxType | Alfanumérico | X | Tipo de Transacción:
|
25 | dateTime | Numérico | X | Fecha y hora de realización de la transacción en formato: YYYYMMDDHHMMSS |
| 269 | walletType | Numérico | X | Tipo de billetera por la cual se realizará la consulta. Opciones: 2: Adquiriente Prisma |
| 408 | loyaltyCard | Numérico | X | Tipo de tarjeta de fidelidad que se quiere consultar. Opciones: 1: Clarín 365 |
| 157 | customerDoc | Numérico | X | 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} |
X = Obligatorio |
Número | Nombre del campo | Tipo de dato | CardQuery | Descripción |
|---|---|---|---|---|
| 0 | company | Numérico | X | Identificador de la compañía donde se generó la transacción |
| 1 | store | Alfanumérico | X | Identificador del sitio originador de la transacción |
| 2 | node | Numérico | X | Identificación del nodo, en el sitio originador, donde se generó la transacción. |
| 6 | cardNumber | Alfanumérico | X | Número de Tarjeta del cliente. Si es una tarjeta de fidelidad, retornará en plano. |
| 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:
|
| 27 | isoCode | Numérico | X | 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 Consulta de Fidelidad |
| 28 | responseMessage | Alfanumérico | X | Mensaje de la Respuesta relacionado con el código del campo 27 |
| 292 | customerFirstName | Alfanumérico | X | Nombre del tarjetahabiente. |
| 293 | customerLastName | Alfanumérico | X | Apellido del tarjetahabiente. |
| 409 | loyaltyCardCategory | Alfanumérico | X | Categoría de la tarjeta de fidelidad. Puede retornar los siguientes valores:
|
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} |
La respuesta que el POS recibe de VTOL se encuentra en los siguientes campos:
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.
A continuación se detallan las respuestas posibles de VTOL Server, cuando se opera con PEI, con una breve descripción de cada una:
Código | Descripción |
|---|---|
| 00 | APROBADA |
| 300 | Se agoto el tiempo de espera |
| 301 | La sucursal ingresada es incorrecta |
| 302 | El concepto ingresado es incorrecto |
| 303 | El concepto ingresado no esta disponible |
| 304 | El concepto ingresado no esta habilitado |
| 305 | La cuenta destino del pago es incorrecta |
| 306 | La cuenta destino no esta habilitada |
| 307 | La cuenta origen del pago es incorrecta |
| 308 | La cuenta origen no esta habilitada |
| 309 | La Red destino del pago es incorrecta |
| 310 | La cuenta del comercio es incorrecta |
| 311 | La cuenta de la sucursal es incorrecta |
| 312 | El comercio supero el importe máximo |
| 313 | La sucursal supero el importe máximo |
| 314 | La tarjeta ha superado el importe diario |
| 315 | Comercio ha superado el importe diario |
| 316 | Comercio ha superado el importe mensual |
| 317 | Comercio supero las trxs diarias |
| 318 | Comercio supero las trxs mensuales |
| 319 | La sucursal supero el importe diario |
| 320 | La sucursal supero el importe mensual |
| 321 | La sucursal supero las trxs diarias |
| 322 | La sucursal supero las trxs mensuales |
| 323 | Encriptacion incorrecta |
| 324 | El DNI no coincide con el de la tarjeta |
| 325 | Los datos de tarjeta no se condicen |
| 326 | El comercio es invalido |
| 327 | Cuenta destino del comercio es invalida |
| 328 | La tarjeta es invalida |
| 329 | La referencia de trx ya fue utilizada |
| 330 | El importe no es un numero mayor a cero |
| 331 | Ultimos 4 dig. no coinciden con la tarj. |
| 332 | Tarjeta inhabilitada para operar |
| 333 | Tarjeta vencida |
| 334 | Fondos insuficientes |
| 335 | El CBU Banelco ingresado es incorrecto |
| 336 | El ALIAS CBU Banelco es incorrecto |
| 337 | El id de pago es invalido |
| 338 | El id del canal es invalido |
| 339 | Importe excede saldo remanente del pago |
| 340 | El ID de requerimiento es invalido |
| 341 | IP de cliente invalida |
| 342 | Existe una devolucion aprobada del pago |
| 343 | El pago tiene devoluciones parciales |
| 344 | Pago no admite el tipo de devolucion |
| 345 | Pago no admite el tipo de devolucion |
| 346 | Terminal en uso |
| 347 | Terminal PEI Invalida |
| 348 | Comercio PEI Invalido |
| 349 | Sucursal PEI Invalida |
| 350 | Id operacion Requerido |
| 351 | Id operacion Rango invalido |
| 352 | Ultimos cuatro digitos invalidos |
| 353 | Numero de documento requerido |
| 354 | Trx original no se puede devolver |
| 355 | La cuenta es incorrecta |
| 356 | La cuenta no está habilitada |
| 357 | La cuenta del comercio es incorrecta |
| 358 | La cuenta de la sucursal es incorrecta |
| 359 | Comercio supero monto para concepto |
| 360 | Sucursal supero monto para concepto |
| 361 | Tarjeta supero monto tipo de operacion |
| 362 | Comercio supero monto tipo operacion |
| 363 | Comercio supero monto tipo operacion |
| 364 | Comercio supero cantidad transacciones |
| 365 | Comercio supero cantidad transacciones |
| 366 | Sucursal supero monto diario permitido |
| 367 | Sucursal supero monto mensual permitido |
| 368 | Sucursal supero cantidad trxs diarias |
| 369 | Sucursal supero cantidad trx mensuales |
| 370 | Error al desencriptar campos encriptados |
| 371 | La cuenta destino del comercio invalida |
| 372 | Ref de trx del comercio ya fue utilizada |
| 373 | Ultimos 4 digitos incorrectos |
| 374 | El ID de requerimiento enviado invalido |
| 375 | Error General |
| 376 | Concepto ingresado no habilitado |
| 377 | Concepto ingresado no habilitado |
| 378 | Cuenta es incorrecta |
| 379 | Cuenta no está habilitada |
| 380 | ALIAS CBU red Banelco es incorrecto |
| 381 | El pago tiene devoluciones parciales |
| 382 | Esta operacion no acepta devol. total |
| 383 | Esta operacion no acepta devol. parcial |
| 384 | La fecha es invalida |
| 385 | El estado del pago es invalido |
| 386 | El Concepto Operacion es invalido |
| 387 | Estado trx original no acepta devolucion |
| 388 | Importe devolucion supero monto limite |
| 389 | No se encontró la trx original |
| 390 | No es posible devolver una devolución |
| 391 | Error en comunicación |
| 392 | Campo DateTimeOriginalTrx invalido |
| 393 | Autorizacion Original en Proceso |
| 394 | No permite operar tarjeta de credito |
| 600 | El codigo de barras es requerido |
| 601 | El softToken es requerido |
| 602 | El importe de promoción es invalido |
| 603 | Original transaction type es requerido |
| 604 | El numero de referencia bancaria es requerido |
| 605 | El importe original informado es invalido |
| 606 | La venta original no tiene promoción aplicada |
| 607 | El numero de referencia bancaria es incorrecto |
| 608 | La venta original no permite promoción |
| 609 | Clave DNI inválido |
| 610 | Se agoto el tiempo de espera |
| 611 | Código de barras invalido |
| 612 | La referencia ingresada es inválida |
| 613 | El timestamp ingresado no respeta el formato |
| 614 | La cuenta origen no tiene tarjeta asociada |
| 615 | La cuenta origen de los fondos es inexistente |
| 616 | Cuenta origen sin fondos suficientes |
| 617 | La terminal ingresada es incorrecta |
| 618 | <Código para posibles nuevos errores de PEI - Link no manejados por VTOL> |
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 |
|---|---|---|
| 801 | Tarjeta no autorizada | Fraude por validación de BlackList |
| 802 | Tarjeta no autorizada | Posible Fraude por BlackList |
| 803 | Operación no autorizada | Fraude por Velocity Check |
| 804 | Operación no autorizada | Posible fraude por Velocity Check |
| 805 | Operación no autorizada | Error en validación concurrente, posible fraude por Velocity Check |
| 806 | Operación no autorizada | Error en validación Velocity Check |
| 807 | Operación no autorizada | Error general en validación de Antifraude |
| 810 | Operación no autorizada | Faltan campos requeridos en el requerimiento |
A continuación se detallan las respuestas posibles de VTOL Server, cuando se opera con Tokenización, con una breve descripción de cada una:
Código | Descripción |
|---|---|
| 400 | Tarjeta no soporta tokenizacion |
| 401 | Excedio tiempo de tokenizacion |
| 402 | Token error comunicacion |
| 403 | Token error persistencia |
| 404 | Token error parseo campo |
| 405 | Token error respuesta NOK |
| 406 | VTOL TOKEN Expirado |
| 407 | Error generar token |
| 408 | VTOL Token no encontrado |
| 409 | VTOL token requerido |
| 410 | Token publico no encontrado en comercio |
| 411 | Token publico expirado |
| 412 | No existe num de comercio para tokenizar |
A continuación se detallan las respuestas posibles de VTOL Server, cuando se opera con Billeteras Electrónicas, con una breve descripción de cada una:
| Código | Descripción |
|---|---|
| 00 | APROBADA |
| 500 | No se encuentra la transaccion original |
| 501 | El campo WalletPosTrxId es requerido |
| 502 | El campo WalletType es requerido |
| 503 | No esta configurado una Compañia MP |
| 504 | No esta configurado una Caja MP |
| 505 | El tipo de billetera es invalido |
| 506 | El campo WalletPaymentId es requerido |
| 507 | El campo OriginalDate es requerido |
| 508 | No es posible devolver una devolucion |
| 509 | Estado trx original no acepta devolucion |
| 510 | Importe devolucion supero monto limite |
| 511 | No se pudo realizar la orden de pago |
| 512 | La transaccion no posee estado |
| 513 | El campo posTicket es requerido |
| 514 | Tiempo expirado. Elija Consultar o Cancelar pago |
| 515 | Tiempo expirado confirmacion devolucion |
| 516 | Pago aun no realizado, desea seguir esperando? |
| 517 | Estado trx original no acepta devolucion |
| 518 | No se encuentra la devolucion |
| 519 | Acceso a MP no esta autorizado |
| 520 | Accion a MP no esta autorizada |
| 521 | El campo WalletPosTrxId es invalido |
| 523 | Estado trx original no acepta devolucion |
| 524 | Importe invalido para devolucion |
| 525 | Estado trx original no acepta devolucion |
| 526 | Compañia MP no permite operar |
| 527 | Numero devoluciones parciales superados |
| 528 | El pago es antiguo para ser devuelto |
| 529 | No es posible devolver una devolucion |
| 530 | Compañia MP sin dinero para devolver |
| 531 | Compañia MP sin dinero disponible |
| 532 | Estado trx original no acepta devolucion |
| 533 | Devolucion parcial no soportada |
| 534 | Url de notificacion invalido |
| 535 | El monto de la transaccion es invalido |
| 536 | Error general por parte de MP |
| 537 | No se encuentra la transaccion original |
| 538 | El campo WalletPosTrxId es requerido |
| 539 | Devuelto |
| 540 | Pendiente |
| 541 | Autorizado |
| 542 | En Progreso |
| 543 | En mediacion |
| 544 | Rechazado |
| 545 | Cancelado |
| 546 | Contracargo |
| 547 | No se encontró la trx original |
| 548 | Error en comunicación |
| 549 | No existe comunicación con Mercado Pago |
| 550 | Error al consultar venta original online |
| 552 | Orden no generada por Prisma |
| 553 | Pago Rechazado por parte de Prisma |
| 554 | Esta operación requiere autorización |
| 555 | Esta operación requiere autorización |
| 556 | Pago rechazado, reintente con otro medio de pago |
| 557 | Pago rechazado, reintente con otro medio de pago |
| 558 | Pago rechazado, reintente con otro medio de pago |
| 559 | Pago rechazado, reintente con otro medio de pago |
| 560 | Pago rechazado, reintente con otro medio de pago |
| 561 | No fue posible procesar su pago, intente más tarde |
| 562 | No fue posible procesar su pago, intente más tarde |
| 563 | No fue posible procesar su pago, intente más tarde |
| 564 | No fue posible procesar su pago, intente más tarde |
| 565 | No fue posible procesar su pago, intente más tarde |
| 566 | La cantidad de cuotas seleccionada es inválida |
| 567 | La cantidad de cuotas seleccionada es inválida |
| 568 | Tarjeta de crédito vencida |
| 569 | Tarjeta de crédito no habilitada |
| 570 | Fondos insuficientes, reintente otro medio de pago |
| 571 | Fondos insuficientes, reintente otro medio de pago |
| 572 | Datos incorrectos, revíselos y reintente |
| 573 | Datos incorrectos, revíselos y reintente |
| 574 | No fue posible procesar su pago, intente más tarde |
| 575 | No fue posible procesar su pago, intente más tarde |
| 576 | Tarjeta no vigente, reintente otro medio de pago |
| 577 | Esta operación requiere autorización |
| 578 | No fue posible procesar su pago, intente más tarde |
| 579 | No fue posible procesar su pago, intente más tarde |
| 580 | La cantidad de cuotas seleccionada es inválida |
| 581 | Datos incorrectos, revíselos y reintente |
| 582 | Datos incorrectos, revíselos y reintente |
| 583 | Las cuotas informadas son incorrectas |
| 584 | No existe la compra que se desea anular |
| 585 | El originante no es válido |
| 586 | El comercio informado es inválido |
| 587 | El establecimiento informado es inválido |
| 588 | El establecimiento no pertenece al comercio |
| 589 | El punto de venta informado es inválido |
| 590 | El punto de venta no pertenece al establecimiento |
| 591 | El tipo de documento es inválido |
| 592 | Se debe informar el ID de la operación |
| 593 | Se debe informar un timeStamp |
| 594 | Se debe informar el traceNumber |
| 595 | Intención de pago vencida |
| 598 | Las cuotas del pago ya fueron informadas |
| 650 | Importe de devolución de cashout invalido |
| 651 | Importe de cashout invalido |
| 652 | Medio 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 |
A continuación se detallan las respuestas posibles de VTOL Server, cuando se realizan operaciones no presenciales:
Código | Descripción | Observaciones |
|---|---|---|
| 760 | Datos del tarjetahabiente inválidos. | VTOL valida los datos requeridos del tarjetahabiente. Si VPB no los manda, retorna este mensaje. |
| 99 | Datos 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 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. |
| 762 | Error 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. |
| 763 | La preautorización expiró | VTOL valida que la pre-autorización no se encuentre vencida. Si la pre-autorización está vencida, retorna este mensaje. |
| 764 | Monto 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. |
A continuación se detallan las respuestas posibles de VTOL Server, cuando se realizan consultas de tarjetas de fidelidad:
Código | Descripción | Observaciones |
|---|---|---|
| 770 | Cliente no encontrado en servicio de fidelidad | El servicio de fidelidad respondió que el cliente no fue encontrado en su base de datos. |
| 771 | El cliente no está activo en servicio de fidelidad | El servicio de fidelidad respondió que el cliente no tiene ninguna tarjeta activa. |
| 772 | Error en el servicio de fidelidad | Cuando el servicio de fidelidad no está disponible o se vence el timeout. |
| 773 | Error 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. |
| 774 | Es requerido el documento del cliente | El POS no envió el número de DNI del cliente. |
| 775 | Es requerido el tipo de tarjeta de fidelidad | El POS no envió el tipo de tarjeta de fidelidad del cliente. |
| 776 | El documento no es valido | El número de DNI enviado no tiene el formato correcto. |
| 777 | Tipo de tarjeta de fidelidad no válido. | El tipo de tarjeta de fidelidad enviado no está soportado. |
| 778 | Consulta no disponible para esta billetera | El tipo de consulta no es soportado por el tipo de billetera enviado por el POS en el campo WalletType. |
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:
El mensaje de respuesta tiene siempre el siguiente formato:
Dónde:
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 |
| 6 | Descripción del banco | 40 | AN | Descripció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. |
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. |
24 | Solicita número de cuenta | 1 | N | Solicita al autorizador el número de cuenta. |
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. |
28 | Posición de la Master Key | 1 | N | Indica la posición de la Master Key en los registros del Firmware. Valores posibles: |
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. |
10 | Limite intereses | 13 | N | Si el monto es superior a éste valor, entonces el interés es = 0 |
11 | Interés | 5 | AN | Tasa de interés (%) para el plan de pago. En formato 00.00 |
12 | Promocional | 1 | N | Activa con 1 o Desactiva con 0, Si aplica o no una promoción para el plan de pago. |
| 13 | Descripción | 20 | AN | Descripción del Plan de pago. |
| 14 | Tipo de operación | 1 | N | Indica cuál es el tipo de operación asociado al plan de pagos. Opciones posibles:
|
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
El formato es el siguiente:
Status;PinWorkingKey;PinWorkingKeyCtrl;dataWorkingkey;dataWorkingkeyCtrl
Donde:
Channel [POSNET] Decoded Sync Data [00;5b4940313332346231375b4940653030;6330;315b4940313336346235335b49403138;6236]
Channel [VISA] Decoded Sync Data [02]
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 |
El Advice hacia el autorizador es generado luego de recibir el tercer mensaje Commit desde el POS.
Pasos:
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.
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.
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:
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á.
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:
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:
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.
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:
En VTOL existirán dos tipos de integraciones para los pagos puntuales:
| 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:
A continuación se detallan los ID de los bancos dispuestos por el BCRA.
ID de Banco | Descripción |
|---|---|
| 7 | BANCO DE GALICIA Y BUENOS AIRES S.A.U. |
| 11 | BANCO DE LA NACION ARGENTINA |
| 14 | BANCO DE LA PROVINCIA DE BUENOS AIRES |
| 15 | INDUSTRIAL AND COMMERCIAL BANK OF CHINA |
| 16 | CITIBANK N.A. |
| 17 | BANCO BBVA ARGENTINA S.A. |
| 20 | BANCO DE LA PROVINCIA DE CORDOBA S.A. |
| 27 | BANCO SUPERVIELLE S.A. |
| 29 | BANCO DE LA CIUDAD DE BUENOS AIRES |
| 34 | BANCO PATAGONIA S.A. |
| 44 | BANCO HIPOTECARIO S.A. |
| 45 | BANCO DE SAN JUAN S.A. |
| 65 | BANCO MUNICIPAL DE ROSARIO |
| 72 | BANCO SANTANDER RIO S.A. |
| 83 | BANCO DEL CHUBUT S.A. |
| 86 | BANCO DE SANTA CRUZ S.A. |
| 93 | BANCO DE LA PAMPA SOCIEDAD DE ECONOMÍA M |
| 94 | BANCO DE CORRIENTES S.A. |
| 97 | BANCO PROVINCIA DEL NEUQUÉN SOCIEDAD ANÓ |
| 143 | BRUBANK S.A.U. |
| 147 | BANCO INTERFINANZAS S.A. |
| 150 | HSBC BANK ARGENTINA S.A. |
| 165 | JPMORGAN CHASE BANK, NATIONAL ASSOCIATIO |
| 191 | BANCO CREDICOOP COOPERATIVO LIMITADO |
| 198 | BANCO DE VALORES S.A. |
| 247 | BANCO ROELA S.A. |
| 254 | BANCO MARIVA S.A. |
| 259 | BANCO ITAU ARGENTINA S.A. |
| 262 | BANK OF AMERICA, NATIONAL ASSOCIATION |
| 266 | BNP PARIBAS |
| 268 | BANCO PROVINCIA DE TIERRA DEL FUEGO |
| 269 | BANCO DE LA REPUBLICA ORIENTAL DEL URUGU |
| 277 | BANCO SAENZ S.A. |
| 281 | BANCO MERIDIAN S.A. |
| 285 | BANCO MACRO S.A. |
| 299 | BANCO COMAFI SOCIEDAD ANONIMA |
| 300 | BANCO DE INVERSION Y COMERCIO EXTERIOR S |
| 301 | BANCO PIANO S.A. |
| 305 | BANCO JULIO SOCIEDAD ANONIMA |
| 309 | BANCO RIOJA SOCIEDAD ANONIMA UNIPERSONAL |
| 310 | BANCO DEL SOL S.A. |
| 311 | NUEVO BANCO DEL CHACO S. A. |
| 312 | BANCO VOII S.A. |
| 315 | BANCO DE FORMOSA S.A. |
| 319 | BANCO CMF S.A. |
| 321 | BANCO DE SANTIAGO DEL ESTERO S.A. |
| 322 | BANCO INDUSTRIAL S.A. |
| 330 | NUEVO BANCO DE SANTA FE SOCIEDAD ANONIMA |
| 331 | BANCO CETELEM ARGENTINA S.A. |
| 332 | BANCO DE SERVICIOS FINANCIEROS S.A. |
| 336 | BANCO BRADESCO ARGENTINA S.A.U. |
| 338 | BANCO DE SERVICIOS Y TRANSACCIONES S.A. |
| 339 | RCI BANQUE S.A. |
| 340 | BACS BANCO DE CREDITO Y SECURITIZACION S |
| 341 | BANCO MASVENTAS S.A. |
| 384 | WILOBANK S.A. |
| 386 | NUEVO BANCO DE ENTRE RÍOS S.A. |
| 389 | BANCO COLUMBIA S.A. |
| 426 | BANCO BICA S.A. |
| 431 | BANCO COINAG S.A. |
| 432 | BANCO DE COMERCIO S.A. |
| 435 | BANCO SUCREDITO REGIONAL S.A.U. |