Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.


Image RemovedImage Added




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



VTOL CRÉDITO DÉBITO ARGENTINA

Mensajería POS - VTOL

...




Painel
borderColor#E4E3E3
bgColor#ffffff
titleColor#ffffff
borderWidth1px
titleBGColor#704581
titleREVISIONES


Expandir
titleExpandir revisiones



Fecha

Revisión

Cambios

1

02/11/2009

1.0

Generación del documento

2

04/11/2009

1.1

Indicación de campos obligatorios

3

26/04/2010

1.2

Actualización de gráfico manejo de PINPAD

4

22/03/2011

1.3

Incorporación mensajes MembershipQuery y VoidMembershipQuery para consulta membresía Club Personal y Club La Nación

5

03/06/2011

1.4

Agregado de definición de mensaje de cierre de lote

6

30/05/2012

1.5

Agrego Tabla de Respuestas al POS y mejoro explicación de Tercer Mensaje y Chequeo de Pendientes.

7

08/03/2013

1.6

Agrego nuevos campos relacionados con operador y vendedor en operaciones de pre-autorización, venta, devolución y anulación.
Nuevo mensaje para consulta de configuración 'PosConfQuery'.

8

21/08/2013

1.7

Agregado de apartado de error del core.

9

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.

10

15/11/2013

1.9

Agregado de 'Formato Interface POS'

11

23/12/2013

2.0

Agregado de detalle de los mensajes ServicePayment y VoidServicePayment

12

13/02/2014

2.1

Agregado del campo bandera '164 – posEncryptedFields', que indica cuando los datos sensibles viajan encriptados.

13

29/05/2014

2.2

Aclaración sobre el uso de pre-autorizaciones.

14

22/08/2014

2.3

Agregado de campo pinpadAutoCode en Tercer Mensaje y RejectedEMVAdvice.

15

29/08/2014

2.4

Actualización del Formato Interface POS, agregando el campo 'Tarjeta que Encripta' a los prefijos.

16

11/09/2014

2.5

Incorporación de Bines de Excepción y nuevo mensaje CardInfoService.

17

09/12/2014

2.6

Agregado de mensaje de Anulación de Pre Autorización.

18

26/02/2015

2.7

Agregado de nuevos campos ServiceCode y ProviderPosCode.

19

27/02/2015

2.8

Agregado de nuevos mensajes propios a la funcionalidad Cash Back.

20

07/08/2015

2.9

Agregado de aclaraciones en el uso de la mensajería

21

09/09/2015

3.0

Incorporación de campo PinpadApplicationVersion en los mensajes Sale, VoidSale, Refund y VoidRefund

22

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.

23

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)

24

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

25

19/04/2017

3.4

Actualización de la tabla Prefijo en el apartado Formato Interface POS

26

03/05/2017

3.5

Incorporación del apartado 1.3.10 Echo

27

05/05/2017

3.6

Incorporación del apartado 1.3.9 SynQuery y de la sección 1.7 Formato Datos Sincronización

28

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

29

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

3004/09/20183.9Incorporación de la funcionalidad PEI en la mensajería
31

14/12/2018 

4.0Incorporación del apartado Antifraude e incorporación de la funcionalidad Antifraude en la mensajería
3208/02/20194.1Incorporación del apartado Tokenización e incorporación de la funcionalidad Tokenización en la mensajería
3303/04/20194.2Agregado del campo 0 (Compañía) en la mensajería de todos los tipos de transacciones.
3428/08/20194.3Incorporación de la funcionalidad Billeteras electrónicas en la mensajería.
3501/04/20204.4Incorporación de mensajería para operaciones eCommerce.
3622/06/20204.5Incorporación de mensajería para operaciones de Cuenta DNI.
3730/07/20204.6Incorporación de funcionalidad de Billeteras Mercado Pago con retiro de efectivo.
3828/08/20204.7Incorporación de consideraciones en el Formato de Interface POS en la tabla Plan de Pagos, para tiendas presenciales.
3922/09/20204.8Se actualiza el campo 54 (additionalAmount) como tipo de dato Importe, en la mensajería de Billeteras electrónicas.
4021/10/20204.9Incorporación de funcionalidad PEI No Presencial
4126/11/20204.10Agregado del campo Descripción en Formato de Interface POS para indicar la descripción sobre un plan de pago.
4211/12/20204.11Incorporación de funcionalidad de QR Adquiriente.
4316/12/20204.12Incorporación del campo afApplicationCondition para validar la aplicación de reglas antifraudes por el módulo AF de VTOL.
4405/03/20214.13Se actualiza el nombre y la descripción del campo 406 en la respuesta de la mensajería de QR Adquiriente.
4505/05/20214.14Incorporación de mensajería para Consultar tarjetas de Fidelidad
4611/05/20214.15Se quitan las referencias de la billetera Todo Pago, ya que dicha Billetera está incluida dentro de QR Adquiriente Prisma.
4719/05/20214.16Incorporación de mensajería para Billetera Yacaré. Se incluye dentro del apartado "1.4.18 Billeteras electrónicas"
4823/09/20214.17En QR Adquiriente, las billeteras Bimo, Modo y Todo Pago, se diferencian por id en el campo WalletType. Incorporación disponible a partir de la versión 3.8.0.12b de VTOL Server.
4901/10/20214.18Incorporación de mensajería para Billetera Plus Pagos. Se incluye dentro del apartado "1.4.18 Billeteras electrónicas"
5010/11/20214.19Incorporación de mensajería para Billetera Rappi Payless. Se incluye dentro del apartado "1.4.18 Billeteras electrónicas".

Índice

Índice

...

5103/03/20224.20Incorporación de mensajería para funcionalidad QR Adquiriente Fiserv. Se incluye dentro del apartado "1.4.26 QR Adquiriente Fiserv".
5204/03/20224.21

Incorporación de mensajería para funcionalidad PayStore. Se incluye dentro del apartado "1.4.27 Operaciones PayStore".

5316/03/20224.22Agregado del campo Marca de tarjeta en el "Formato Interface POS", dentro de la tabla "Provider".
5412/04/20244.23Incorporación de mensajería para funcionalidad GoCuotas API QR. Se incluye dentro del apartado "1.4.28 Operaciones GoCuotas API QR".
5515/04/20244.24Incorporación de mensajería para funcionalidad GoCuotas API Full. Se incluye dentro del apartado "1.4.29 Operaciones GoCuotas API Full".
5608/05/20254.25Agrego campo 421:tipAmount para manejo de ventas con propina para transacciones de venta





Painel
borderColor#E4E3E3
titleColor#ffffff
borderWidth1
titleBGColor#704581
titleCONTENIDO


Expandir
titleExpandir contenido

Índice


Âncora
_Toc485222713
_Toc485222713
1. Campos de los mensajes

Âncora
_Toc201665538
_Toc201665538
Âncora
_Toc485222714
_Toc485222714
Âncora
_Toc145327442
_Toc145327442
1.1 Conexión con VTOL Server

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


Parámetro

Descripción

IP de VTOL Server

IP donde se encuentra VTOL Server.

Puerto SSL de VTOL Server

Es el puerto SSL sonde escucha VTOL Server. Valor por defecto: 3003

Almacén de certificados del servidor

Ruta donde se encuentra el almacén de certificados con los certificados del servidor.

Contraseña para acceder al almacén de certificados

Contraseña para acceder al almacén de certificados.

Algoritmo del almacén de certificados

Algoritmo del manejador del almacén de certificados. Valor por defecto: SunX509

Tipo de almacén de certificados

Indica el tipo de almacén de certificados. Valor por defecto: JKS

...


Âncora
_Toc485222716
_Toc485222716
1.2 Protocolo de comunicación POS – VTOL Server

Synthesis Napse 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}

...

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:

...

Requerimiento

#

FieldId

Tipo

Obligatorio

Descripción

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

1

store

Alfanumérico

SI

Identificador del sitio originador de la transacción

2

node

Numérico

SI

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

3

server

Alfanumérico

Compatibilidad atrás.

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

4

messageType

Alfanumérico

Compatibilidad atrás.

Tipo de Mensaje:

  • Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server.
  • Data = Mensaje de la Aplicación cliente.

6

cardNumber

Numérico

Obligatorio si es Manual

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

7

expiration

Numérico

Obligatorio si es Manual

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

8

Cvc

Numérico

Obligatorio si es Manual. Además es opcional según la tarjeta.

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

9

track2

Alfanumérico

Obligatorio si es MSR

Track2 de la tarjeta entero (se envía todo el contenido del track2 en este campo) Este campo sólo está presente si la banda magnética / chip de la tarjeta pudo ser leído.

10

posInputMode

Alfanumérico

Obligatorio

Modo de Ingreso:

  • MSR = Ingreso por banda magnética
  • Manual = Ingreso manual
  • Chip = EMV Chip
  • MSR Chip = Fallback
  • E-Commerce = Comercio electrónico

11

trxType

Alfanumérico

Obligatorio

Tipo de Transacción:

  • Sale = Compra. Opcionalmente puede acompañarse con una extracción de efectivo (CashBack) cuando se envía el campo monto adicional.
  • PreAuthorization = Pre-autorización
  • VoidSale= Anulación de venta. Opcionalmente puede acompañarse con una Anulación de extracción de efectivo, enviando el monto en el campo monto adicional.
  • VoidPreAuthorization = Anulación de Pre-autorización.
  • VoidRefund = Anulación de devolución
  • CashBack = Extracción de efectivo solamente. NO incluye una Compra.
  • VoidCashBack = Anulación de extracción de efectivo (No incluye una Compra).

12

amount

Importe

Obligatorio

14

payments

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

13

currencyPosCode

Alfanumérico

Obligatorio

Tipos de Moneda:

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

Nota: Para ventas con propina, en este campo se envía el importe total de la compra (consumo + propina) sin especificar el valor de la propina, y la propina se envía en el campo 421 "tipAmount".

13

currencyPosCode

Alfanumérico

Obligatorio

Tipos de Moneda:

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

14

payments

Numérico

Obligatorio

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

15

plan

Alfanumérico

Obligatorio

Plan. 1 caracter de longitud.

17

originalTrxTicketNr

Numérico

Opcional

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

18

referedSale

Numérico

Condicional a tarjeta AMEX

Se usa para indicar si una venta se hizo de forma referida. SOLO para AMEX. Se debe encender este campo con el valor 1.

22

authorizationCode

Alfanumérico

Condicional si fue realizada la autorización telefónica o la pre-autorización.

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

23

authorizationMode

Alfanumérico

Opcional, default = Online

Modo de Autorización:

  • Online = La autorización fue realizada por el Centro Autorizador.
  • Offhost = La autorización fue realizada internamente por VTOL.
  • Offline = La autorización fue realizada localmente por el POS. Y para Capturar la pre-autorización o Anular la pre-autorización

25

dateTime

Numérico

Obligatorio

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

53

paymentCondition

Alfanumérico

Opcional

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

54

additionalAmount

Alfanumérico

Opcional CASH BACK

Contiene el Importe del "Cash Back". Se usa en transacciones del tipo CashBack o Sale + CashBack. Debe contener 12 dígitos como máximo

56

pinblock

Alfanumérico

Condicional a PINPAD

PIN encriptado. Se emplea para tarjetas que tienen PIN. Ejemplo pinblock: D76484D688FE1826

57

accountType

Alfanumérico

Condicional a tarjeta de débito

Campo que se emplea para identificar el tipo de cuenta (ej: cta cte en pesos) Se usa para tarjetas de débito. Los valores posibles son:

  • 1 = Caja de ahorros en pesos
  • 2 = Cuenta corriente en pesos
  • 3 = Caja de ahorros en dólares
  • 4 = Cuenta corriente en dolares

66

track1

Alfanumérico

Opcional a su lectura

Track1 de la tarjeta entero (se envía todo el contenido del track1 en este campo) Este campo sólo está presente si la banda magnética / chip de la tarjeta pudo ser leído.

70

effectiveDate

Alfanumérico

Opcional AMEX

Fecha efectiva. Se usa para AMEX con formato yyMM

71

checkPendingString

Alfanumérico

Opcional, default = true

Indica si VTOL debe o no efectuar el chequeo de pendientes (se emplea para pagos parciales de tarjetas):

  • true = activa chequeo de pendientes.
  • false = desactiva chequeo de pendientes.

72

creditCardCondition

Alfanumérico

Opcional

Es una cadena de 3 de largo donde se indica una condición de la tarjeta. Se usa para las tarjetas regionales o propias donde los prefijos se superponen. Este valor es identificable en el TrackI de la tarjeta y si es manual se le pregunta al cajero.

73

interestAmount

Alfanumérico

Opcional

Este campo es por si se necesita enviar el monto de los intereses en el mensaje a Autorizar. Normalmente el monto que llega del POS ya contiene los intereses en el caso de pagar en cuotas. Existe algún caso de alguna tarjeta especial donde el monto hay que enviarlo libre de intereses y justamente el monto de los intereses viaja en este campo.

74

requestAccountNumber

Alfanumérico

Opcional, default = 0

Indica si puede recibir el número de cuenta (Visa y Posnet). Valores posible:

  • 1 = activado
  • 0 = desactivado

101

differDate

Alfanumérico

Opcional

Fecha diferida. Solo utilizada para AMEX.

102

chipTokens

Alfanumérico

Obligatorio para modo de ingreso Chip

Visa: Criptograma tarjetas EMV
Posnet: Lista de Tags EMV

103

emvEncryptedType

Alfanumérico

Opcional

Tipo de encriptación utilizada entre Pinpad y Host Autorizador.
Los campos 103, 104, 108 y 137 deben ser utilizados en conjunto.
Valores posibles:

  • D = DES
  • T = 3DES

104

emvEncryptedData

Alfanumérico

Opcional

Paquete encriptado devuelto por el pinpad y que se enviará al Host Autorizador.
Los campos 103, 104, 108 y 137 deben ser utilizados en conjunto.

105

cardSequenceNumber

Numérico

Opcional

Numero de secuencia del PAN

106

pinpadLogSerialNumber

Alfanumérico

Opcional

Número de serie lógico del pinpad

107

pinpadFisSerialNumber

Alfanumérico

Opcional

Número de serie Físico del pinpad

108

useEncryptedData

Alfanumérico

Opcional

Indica si se utiliza encriptación entre Pinpad y Host Autorizador (Visa, Posnet, etc).
Los campos 103, 104, 108 y 137 deben ser utilizados en conjunto.
Valores posibles:

  • false = No se utiliza encriptación
  • true = Se utiliza encriptación

118

terminalCapability

Alfanumérico

Opcional

Capacidad de captura. Valores 1 = Manual / 2 = Lectura de Banda / 5 = Lectura de Chip

130

posPeriod

Numérico

Opcional

Periodo enviado por el POS. Longitud 5

131

turn

Numérico

Opcional

Turno. Longitud 2

132

operatorCode

Alfanumérico

Opcional

Código de operador. Longitud 20

133

operatorName

Alfanumérico

Opcional

Nombre de operador. Longitud 50

134

sellerCode

Alfanumérico

Opcional

Código del vendedor. Longitud 20

135

sellerName

Alfanumérico

Opcional

Nombre del vendedor. Longitud 50

136

attentionMode

Alfanumérico

Opcional

Modalidad de atención (AU ó AS). Longitud 2

137

serviceCode

Numérico

Opcional

Código de Servicio, se envía cuando el mensaje esta encriptado (campo 108=true) y no se tiene acceso al Track2. Longitud 3.
Los campos 103, 104, 108 y 137 deben ser utilizados en conjunto.

147

providerPosCode

Alfanumérico

Opcional

Código del Provider. Se utiliza en los casos donde VTOL Server no puede obtener unívocamente el Proveedor utilizando los prefijos (debido enmascaramiento de la tarjeta). Ejemplo VI (Visa). Longitud 20.

164

posEncryptedFields

Numérico

Opcional

Indica si se utiliza encripción entre Pinpad y VTOL (modo RSA). En este caso los datos sensibles se envían encriptados. Si está activo, los campos a enviar encriptados son: 6, 8, 9, 66
Valores posibles:

  • 1 = activado
  • 0 = desactivado (valor por defecto).

168

pinpadApplicationVersion

Alfanumérico

Opcional

Versión de la aplicación del software del PinPad

201

additionalMessageData

Alfanumérico

Opcional

Este campo tiene como finalidad que el POS, o cliente VTOL, pueda enviar un dato X y que el mismo esté presente en la respuesta. Cada módulo según implementación puede decidir qué hacer con dicho dato (Ejem Persistir en BBDD)

261cipherSuiteNuméricoOpcional

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

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

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

264posChannelOriginNuméricoOpcional

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

  • 0: Presencial
  • 1: E-Commerce
  • 2: Reservado para uso futuro
  • 3: IVR

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

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

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

Longitud máxima: 50 caracteres.

Se puede enviar en transacciones de:

  • Sale
  • PreAuthorization
  • Sale Offline

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

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

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

421tipAmountImporteOpcional

Monto de propina.  Se envía sin coma. Los dos últimos dígitos representan los decimales. Ej: 1000 equivale a 10.00


Âncora
posticket
posticket
1.4.1.1.1 Estructura del campo posTicket

...

#

FieldId

Tipo

Descripción

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

1

store

Alfanumérico

Identificador del sitio originador de la transacción

2

node

Numérico

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

3

server

Alfanumérico

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

4

messageType

Alfanumérico

Tipo de Mensaje:

  • Control  = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server.
  • Data      =  Mensaje de la Aplicación cliente.

11

trxType

Alfanumérico

Tipo de Transacción:

  • UnSyncCompletion = Mensaje de completamiento de transacción (“tercer mensaje”)

19

lastTrxAction

Alfanumérico

Acción a realizar sobre la Transacción:

  • Commit  = Confirma la transacción
  • Rollback = Reversa la transacción

24

lastTrxId

Numérico

Id de transacción a confirmar / reversar.

25

dateTime

Numérico

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

200

EMV extra data

Alfanumérico

Datos extras que se deben enviar en el tercer mensaje cuanto cuando el EMV Advice es requerido. 

Es necesario enviar los campos: adviceChipTokens, pinpadResponseCode y pinpadAutCode.

Formato del campo:

[adviceChipTokens|valor,pinpadResponseCode|valor, pinpadAutCode|valor]

Ver detalle en: EMV Extra Data


1.4.12.2 Respuesta


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

...

Procedimiento para Pago Offline con Rappi Payless:

1. El POS envía un SaleWallet a VTOL con la billetera Rappi (walletType: 8).
2. VTOL envía la autorización a Rappi, pero no hay conexión.
3. VTOL responde al POS código 620, “Reintente pago por modo offline con código PIN”. Y la operación queda rechazada en VTOL.
4. El POS calcula el código PIN utilizando un barcode vigente. Y se lo informa al rappi tendero para que lo ingrese en su app y así se autoriza el pago.
5. El POS envía una nueva SaleWallet a VTOL, informando el campo 22 (authorizationCode) con el valor del PIN. Esto es para dejar asentada en VTOL que la transacción se realizó en modo offline.
6. VTOL responde “Aprobado” al POS. La autorización se realiza de forma offline, es decir no se envía ningún mensaje a Rappi.
7. El POS envía tercer mensaje a VTOL, "commit" para confirmar la transacción.
8. El POS imprime el ticket y entrega los productos al rappi tendero.

...

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.

Dentro del encabezado, se podrá enviar el valor de los descuentos totales y de los impuestos totales que aplicarán a la compra. Son campos opcionales.

Los campos dentro del encabezado son: totDiscount y totTaxes

Detalle de los campos:

Elemento

Tipo de dato

Descripción

Requerido

Valor ante ausencia

totDiscountNuméricoImporte total de descuento que calcula el POS. Será la sumatoria de descuentos que se apliquen a los artículos.No0
totTaxesNuméricoImporte total de impuesto que calcula el POS. Será la sumatoria de impuestos que se apliquen sobre la compra.No0


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. 

...

Elemento

Atributo

Tipo de dato

Descripción

Requerido

Valor ante ausencia

Ítem













unitprice

Numérico positivo

Precio unitario del artículo en cuestión.

Si

 


xprice

Numérico positivo

Precio extendido del artículo en cuestión. Es igual a la cantidad por el precio unitario.

Si 


qty

Entero positivo

Cantidad de artículos en la línea.

Si 


magnitude

Numérico positivo

Si el artículo es mensurable por otro unidad que no sea la cantidad, deberá ser expresad en esta propiedad.

No

0

code

Alfanumérico

Código propio del artículo.

No

"-"

brand

Alfanumérico

Marca del artículo.

No

"-"

supplier

Alfanumérico

Proveedor al que pertenece el artículo.

No

"-"

discountable

Alfanumérico

Si el artículo es puede recibir descuentos o no.

No

"-"

level1

Alfanumérico

Nivel 1 de categorización del artículo. Anteriormente este nivel se conocía con el nombre de Departamento.

No

"-"

level2

Alfanumérico

Nivel 2 de categorización del artículo. Anteriormente este nivel se conocía como la Familia del artículo.

No

"-"

level3

Alfanumérico

Nivel 3 de categorización del artículo. Anteriormente este nivel se conocía como la Categoría del artículo.

No

"-"

level4

Alfanumérico

Nivel 4 de categorización del artículo. Anteriormente este nivel se conocía como la subcategoría del artículo.

No

"-"

descriptionAlfanuméricoDescripción del ítemSi
currencyAlfanumérico

Moneda utilizada en el precio del ítem

Nota: En el punto de venta se deberá informar la moneda de la cuenta vendedor de Mercado Pago (si el retailer posee una cuenta argentina en Mercado Pago entonces tendrá que informar la moneda $ -pesos argentinos-).

Si
measureAlfanuméricoUnidad de medida del ítem. Valores posibles: unit - packNo"unit"

...

Bloco de código
languagexml
themeEclipse
<message>
<item-add seq<message totDiscount="1" 100.00" totTaxes="50.00">
<item-add seq="1" code="0001" discountable="true" unitprice="25100.0" qty="1"3.0" xprice="300.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="2848.0" qty="1.0" xprice="248.0" level1="MEN" level2="CASUAL" supplier="" brand="LEVIS" xprice="48.0" magnitude="1" description="Jean casual" currency="$" />
</message>

...

Número

Nombre del campo

Tipo de dato

SaleWalletRefundWalletQueryWallet

Descripción

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

Para Rappi este campo no retorna.

12amountImporteX-XMonto de la transacción. Valor entero. Los últimos 2 dígitos corresponden a los decimales.
13currencyPosCodeAlfanuméricoO-X

Tipos de moneda:

  • $ = Pesos
  • U$S = Dólares
14paymentsNumérico--OCantidad de cuotas seleccionadas al momento de realizar el pago QR. El campo es opcional en caso de que se haya abonado con saldo de la cuenta de Mercado Pago
22authorizationCodeAlfanuméricoO-O

Código de autorización informado por el Autorizador.

Para Mercado Pago sólo retorna cuando el cliente paga con tarjeta de crédito o débito.

Para Yacaré este campo no retorna.

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

Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. El valor en este campo debe ser el mismo que el valor de la fecha y hora del requerimiento. El POS utiliza este dato para validar que se trate de la misma transacción

26responseCodeAlfanuméricoXXX

Puede contener uno de los siguientes valores:

  • Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27
  • Error = ver sección Códigos de error del CORE
  • TrxIsPending: indica si existen transacciones pendientes de confirmar. En este caso, el ID de transacción a confirmar está en el campo 24
27isoCodeNuméricoXXX

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

28responseMessageAlfanuméricoXXX

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

54additionalAmountImporteOOO

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

Sólo disponible para billetera Mercado Pago.

140paymentTypeNumérico--X

Tipo de pago. Valores posibles:

0: Tarjeta
1: Efectivo
2: Transferencia

142providerNameAlfanumérico--OProveedor de la tarjeta seleccionada al momento de efectuar el pago QR. El campo es opcional en caso de que se haya abonado con saldo de la cuenta de Mercado Pago
147providerPosCodeListaO--Lista de proveedores/tarjetas que coinciden con la tarjeta ingresada en la app de la billetera electrónica. Ejemplo: {VI, EL}. Esta lista deberá ser utilizada para seleccionar la tarjeta manualmente por el POS.
157customerDocNuméricoOOONumero de documento del titular de la tarjeta.
303customerNameAlfanuméricoOOONombre del titular de la tarjeta.
166trxReferenceNumberNuméricoXXXIdentificador único de la transacción en VTOL Server. Longitud entre 19 y 20 dígitos, debido a que utiliza el día como parte de formato
271walletPaymentIdAlfanuméricoX-X

Identificador del número de pago informado por el Autorizador.

Para Rappi, en este campo retorna el barcode utilizado para el pago.

272amountRefundedImporte--XMonto devuelto en la transacción
273paymentStatusAlfanuméricoO-O

Estado de la transacción de pago informado por el Autorizador. Estados posibles:

0: Aprobado
1: Devuelto
2: Pendiente
3: Autorizado
4: En Progreso
5: En mediacion
6: Rechazado
7: Cancelado
8: Contracargo
9: Reversado

274paymentStatusDetailAlfanuméricoO-ODetalle del estado de la transacción de pago informado por el Autorizador.
275cardTypeNumérico--O

Tipo de tarjeta seleccionada al momento de efectuar el pago QR. Es opcional en caso de que se haya abonado con saldo de la cuenta de Mercado Pago.

Para Yacaré este campo no retorna.

Para Rappi este campo no retorna.

Valores posibles:
0: Débito
1: Crédito

415walletPayoutIdAlfanuméricoO-O

Identificador del ID de cashback informado por el Autorizador.

Sólo retorna en caso de haber realizado Retiro de efectivo con la app de Mercado Pago.


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 (QueryWallet):

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}

...

OOOO

Nro

Campo

Tipo

Sale

Capture

PreAuth

VoidPreAuth

Descripción

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

1

store

Alfanumérico

XXXX

Identificador del sitio originador de la transacción

3

server

Alfanumérico

XXXX

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

4

messageType

Alfanumérico

XXXX

Tipo de Mensaje:

  • Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server.
  • Data = Mensaje de la Aplicación cliente.

6

cardNumber

Numérico

X-X-

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

7

expirationDate

Numérico

X-X-

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

8

cvc

Numérico

X-X-

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

10

inputMode

Alfanumérico

XXXX

Modo de Ingreso de la tarjeta:

3 - E-Commerce

11

trxType

Alfanumérico

XXXX

Tipo de Transacción:

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

12

amount

Importe

XXXX

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

13

currencyPosCode

Alfanumérico

XXXX

Tipos de Moneda:

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

14

payments

Numérico

XXXX

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

15

plan

Alfanumérico

XXXX

Plan. 1 caracter de longitud.

17

originalTrxTicketNr

Numérico

---X

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

Obligatorio para devoluciones.

22

authorizationCode

Alfanumérico

-X--

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

Obligatorio para Captura.

23

authorizationMode

Alfanumérico

XXXX

Modo de Autorización:

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

25

dateTime

Numérico

XXXX

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

53

paymentCondition

Alfanumérico

O-O-

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

73

interestAmount

Alfanumérico

O-O-

Este campo es por si se necesita enviar el monto de los intereses en el mensaje a Autorizar. Normalmente el monto que llega del POS ya contiene los intereses en el caso de pagar en cuotas. Existe algún caso de alguna tarjeta especial donde el monto hay que enviarlo libre de intereses y justamente el monto de los intereses viaja en este campo.

118terminalCapabilityAlfanuméricoXXXX

Capacidad de captura. Valor a enviar:

  • 1 = Manual

147

providerPosCode

Alfanumérico

O-O-

Código del Provider. Se utiliza en los casos donde VTOL Server no puede obtener unívocamente el Proveedor utilizando los prefijos (debido enmascaramiento de la tarjeta). Ejemplo VI (Visa). Longitud 20.

167originalTrxReferenceNumberAlfanuméricoOXOX

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

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

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

201additionalMessageDataAlfanuméricoOOOOEste campo tiene como finalidad que el cliente VTOL, pueda enviar un dato X y que el mismo esté presente en la respuesta. Cada módulo según implementación puede decidir qué hacer con dicho dato.
264posChannelOriginNuméricoXXXX

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

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

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

Longitud máxima: 50 caracteres.

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

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

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

...

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


1.4.20.1 Requerimiento

Nro

Campo

Tipo

Descripción

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

Modo de Ingreso de la tarjeta:

  • E-Commerce

11

trxType

Alfanumérico

Tipo de Transacción:

  • Refund = devolución

12

amount

Importe

Monto de la transacción. 12 dígitos como máximo. Se envía sin coma. Los dos últimos dígitos representan los decimales. Ej: 1000 equivale a 10.00
Nota: valor de la venta original

13

currencyPosCode

Alfanumérico

Tipos de Moneda:

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

14

payments

Numérico

Cantidad de cuotas. 2 dígitos como máximo.
Nota: valor de la venta original

15

plan

Alfanumérico

Código de plan. Largo 1.
Nota: valor de la venta original

16

originalDate

Fecha

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

17

originalTrxTicketNr

Numérico

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

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

53

paymentCondition

Alfanumérico

Condición de pago. Sólo se encuentra presente si existe una condición de pago vinculada con la transacción.
Nota: valor de la venta original

201

additionalMessageData

Alfanumérico

Este campo tiene como finalidad que el cliente VTOL, pueda enviar un dato X y que el mismo esté presente en la respuesta. Cada módulo según implementación puede decidir qué hacer con dicho dato.

264posChannelOriginNumérico

Indica el canal de origen de la transacción.

  • E-Commerce


1.4.20.2 Respuesta

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

...

Informações
titleReferencias

X = Obligatorio
O = Opcional
- = No requerido


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

Tipo de Mensaje:

  • Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server.
  • Data = Mensaje de la Aplicación cliente.

10

inputMode

Alfanumérico

X

XX

Forma de ingreso:

  • BarCode
  • SoftToken

11

trxType

Alfanumérico

X

XX

Tipo de Transacción:

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

12

amount

Importe

X

X-

Monto de la transacción de Venta o de Devolución. 12 dígitos como máximo. Se envía sin coma. Los dos últimos dígitos representan los decimales. Ej: 1000 equivale a 10.00

Se validará el importe enviado por el POS:

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

13

currencyPosCode

Alfanumérico

X

X-

Tipos de Moneda:

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

25

dateTime

Numérico

X

XX

Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. Es importante persistir este valor para consultar el resultado de una operación en caso de algún inconveniente

153idOperationPEIAlfanumérico-XO

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

157customerDocAlfanumérico

O

--

Número de documento del titular de la cuenta.

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

173dateTimeOriginalTrxNumérico--XFecha y hora de realización de la transacción de venta o devolución que se desea consultar en formato YYYYMMDDHHMMSS. Se debe enviar el valor del campo 25 de la transacción a consultar.
279softTokenAlfanuméricoO--

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

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

300
barCode
AlfanuméricoO--

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

Obligatorio únicamente si el modo de ingreso es barCode.


1.4.21.2 Respuesta

NroCampoTipo de datoSalePEIRefundPEIQueryPEIDescripción
0companyNuméricoXXXIdentificador de la compañía donde se generó la transacción.
1storeAlfanuméricoXXXIdentificador del sitio originador de la transacción
2nodeNuméricoXXXIdentificación del nodo, en el sitio originador, donde se generó la transacción
25dateTimeNuméricoXXXFecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. El valor en este campo debe ser el mismo que el valor de la fecha y hora del requerimiento. El POS utiliza este dato para validar que se trate de la misma transacción.

26

responseCode

Alfanumérico

XXX

Puede contener uno de los siguientes valores:

  • Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27
  • Error = ver sección Códigos_de_Errores_del_CORE_de_VTOLServer
  • TrxIsPending: indica si existen transacciones pendientes de confirmar. En este caso, el ID de transacción a confirmar está en el campo 24

27

isoCode

Numérico

XXX

Código de Respuesta ISO-8583 emitido por el centro autorizador. 2 dígitos como máximo. Ver sección Códigos de Respuesta de VTOL Server para PEI

28

responseMessage

Alfanumérico

XXX

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

35

errorDescription

Alfanumérico

XXX

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

153

idOperationPEI

Alfanumérico

XXX

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

154idOperationOrigenPEIAlfanumérico-XOIdentificador de la operación original de pago.
170idCommercePEIAlfanuméricoXXXIdentificador PEI de compañía
171idBranchPEIAlfanuméricoXXXIdentificador PEI de local
172idTerminalPEIAlfanuméricoXXXIdentificador PEI de terminal
174originalTrxStatusNumérico--O

Informa el estado de la transacción original en una operación de consulta. Si el campo en la respuesta no se recibe es porque la consulta falló.

Puede contener uno de los siguientes valores:

    • 0: Aprobada
    • 1: Rechazada
    • 2: En proceso
278bankingRefNumAlfanuméricoXXXNúmero de referencia de la transacción de pago.


Âncora
promopei
promopei
1.4.22 Promociones PEI para Cuenta DNI

...

Informações
titleReferencias

X = Obligatorio
O = Opcional
- = No requerido


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

Tipo de Mensaje:

  • Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server.
  • Data = Mensaje de la Aplicación cliente.

11

trxType

Alfanumérico

X

Tipo de Transacción:

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

12

amount

Importe

X

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

13currencyPosCodeAlfanuméricoX

Tipos de Moneda:

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

302

promoAmount

Importe

X

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

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

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

25

dateTime

Numérico

X

Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. Es importante persistir este valor para consultar el resultado de una operación en caso de algún inconveniente

153idOperationPEIAlfanuméricoX

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

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


1.4.22.2 Respuesta

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

25

dateTime

Numérico

X

Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. El valor en este campo debe ser el mismo que el valor de la fecha y hora del requerimiento. El POS utiliza este dato para validar que se trate de la misma transacción

26

responseCode

Alfanumérico

X

Puede contener uno de los siguientes valores:

  • Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27
  • Error = ver sección Códigos de error del CORE
  • TrxIsPending: indica si existen transacciones pendientes de confirmar. En este caso, el ID de transacción a confirmar está en el campo 24

27

isoCode

Numérico

X

Código de Respuesta ISO-8583 emitido por el centro autorizador. 2 dígitos como máximo. Ver sección Códigos de Respuesta de VTOL Server para PEI

28

responseMessage

Alfanumérico

X

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

35

errorDescription

Alfanumérico

X

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


1.4.23 Operaciones PEI No Presencial

...

Informações
titleReferencias

X = Obligatorio
O = Opcional
- = No requerido


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

1

store

Alfanumérico

XXX

Identificador del sitio originador de la transacción

3

server

Alfanumérico

XXX

Identificador del Server que procesará la transacción.

Enviar: VTOL

4

messageType

Alfanumérico

XXX

Tipo de Mensaje:

  • Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server.
  • Data = Mensaje de la Aplicación cliente.

6

cardNumber

Numérico

X--

Número de tarjeta.

7

expirationDate

Numérico

X--

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

8

cvc

Numérico

X--

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

10

inputMode

Alfanumérico

XXX

Modo de Ingreso de la tarjeta:

  • Manual

11

trxType

Alfanumérico

XXX

Tipo de Transacción:

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

12

amount

Importe

XX-

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

13

currencyPosCode

Alfanumérico

XX-

Tipos de Moneda:

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

14

payments

Numérico

XX-

Cantidad de cuotas.

Enviar siempre: 1

15

plan

Alfanumérico

X--

Plan.

Enviar siempre: 0

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

25

dateTime

Numérico

XXX

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

118terminalCapabilityAlfanuméricoXXX

Capacidad de captura. Valor a enviar:

  • 1 = Manual

147

providerPosCode

Alfanumérico

O--

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

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

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

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

201additionalMessageDataAlfanuméricoOO-

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

En VPB es el campo ecommerceCustomField.

264posChannelOriginNuméricoXXX

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

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

O

O

O

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

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

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

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

  • 1 = COMPRA_DE_BIENES
173dateTimeOriginalTrxNumérico--XFecha y hora de realización de la transacción de venta o devolución que se desea consultar en formato YYYYMMDDHHMMSS. Se debe enviar el valor del campo 25 de la transacción a consultar.
290customerIpAlfanuméricoOO-IP de origen de donde se efectuó la transacción
291customerDocTypeAlfanuméricoOO-Tipo de documento del cliente que realizó la transacción.
292customerFirstNameAlfanuméricoOO-Nombre del cliente registrado en el e-commerce que realizó la transacción.
293customerLastNameAlfanuméricoOO-Apellido del cliente registrado en el e-commmerce que realizó la transacción.
295cardHolderDocTypeAlfanuméricoX--Tipo de documento del titular de la tarjeta.
296cardHolderDocNumberAlfanuméricoX--Número de documento del titular de la tarjeta.
306cardIssuingBankAlfanuméricoOO-Banco emisor de la tarjeta. Longitud máxima 20.
307cardBrandAlfanuméricoOO-Marca de la tarjeta. Longitud máxima 20.
403afApplicationConditionAlfanuméricoO--

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

Longitud máxima: 50 caracteres.

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

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

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


1.4.23.2 Respuesta

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

1

store

Alfanumérico

XXX

Identificador del sitio originador de la transacción

2

node

Numérico

XXX

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

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

25

dateTime

Numérico

XXX

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

26

responseCode

Alfanumérico

XXX

Puede contener uno de los siguientes valores:

  • Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27
  • Error = ver sección Código de errores del CORE
  • TrxIsPending: indica si existen transacciones pendientes de confirmar. En este caso, el ID de transacción a confirmar está en el campo 24.

27

isoCode

Numérico

XXX

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

28

responseMessage

Alfanumérico

XXX

Mensaje de la Respuesta ISO-8583

33

creditCardIssuerName

Alfanumérico

XXX

Nombre del emisor de la tarjeta

35

errorDescription

Alfanumérico

XXX

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

166

trxReferenceNumber

Numérico

XXX

Identificador único de la transacción en VTOL Server. Longitud entre 19 y 20 dígitos, debido a que utiliza el día como parte de formato.

153idOperationPEIAlfanuméricoXXXIdentificador de la operación PEI de pago o de devolución
154idOperationOrigenPEIAlfanumérico-XOIdentificador de la operación PEI de origen con la cual se solicitó la devolución.
170idCommercePEIAlfanuméricoXXXIdentificador PEI de compañía
171idBranchPEIAlfanuméricoXXXIdentificador PEI de local
174originalTrxStatusAlfanumérico--O

Informa el estado de la transacción original en una operación de consulta. Si el campo en la respuesta no se recibe es porque la consulta falló.

Puede contener uno de los siguientes valores:

    • 0: Aprobada
    • 1: Rechazada
    • 2: En proceso
278bankingRefNumAlfanuméricoX-XNumero de referencia de la transacción de pago. Se utiliza para conciliar con los reportes de las entidades bancarias. Número generado por LINK.



1.4.24 Operaciones QR Adquiriente Prisma

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

...

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

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.

...

Informações
titleReferencias

X = Obligatorio
O = Opcional
- = No requerido


Número

Nombre del campo

Tipo de dato

SaleWallet

RefundWallet

QueryWallet

Descripción

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

Tipo de Mensaje:

  • Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server.
  • Data = Mensaje de la Aplicación cliente.
11trxTypeAlfanuméricoXXX

Tipo de Transacción:

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

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

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

13currencyPosCodeAlfanuméricoXX-

Tipos de moneda:

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

lastTrxId

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

Identificador único de la transacción de billetera para la compañía. Es originado por el POS para realizar una compra con billetera.

Formato:
codigoTienda (longitud 10) + codigoCaja (longitud 10) + Fecha (AAMMDDHHmmss) (longitud 12)
Longitud total de 32.

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

269walletTypeNuméricoXXX

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

2: Billetera Bimo
3: Billetera Modo
4: Billetera Todo Pago

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

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

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

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

walletBenefits

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



Âncora
posTicket
posTicket
Estructura del campo posTicket (270)

...

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.


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

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


Elemento

Atributo

Tipo de dato

Descripción

Requerido

Valor ante ausencia

Ítem

 

 

 

 

 

 

 

 

 

 

 





















unitprice

Numérico positivo

Precio unitario del artículo en cuestión.

Si

 


xprice

Numérico positivo

Precio extendido del artículo en cuestión. Es igual a la cantidad por el precio unitario.

Si

 


qty

Entero positivo

Cantidad de artículos en la línea.

Si

 


magnitude

Numérico positivo

Si el artículo es mensurable por otro unidad que no sea la cantidad, deberá ser expresad en esta propiedad.

No

0

code

Alfanumérico

Código propio del artículo.

No

"-"

brand

Alfanumérico

Marca del artículo.

No

"-"

supplier

Alfanumérico

Proveedor al que pertenece el artículo.

No

"-"

discountable

Alfanumérico

Si el artículo es puede recibir descuentos o no.

No

"-"

level1

Alfanumérico

Nivel 1 de categorización del artículo. Anteriormente este nivel se conocía con el nombre de Departamento.

No

"-"

level2

Alfanumérico

Nivel 2 de categorización del artículo. Anteriormente este nivel se conocía como la Familia del artículo.

No

"-"

level3

Alfanumérico

Nivel 3 de categorización del artículo. Anteriormente este nivel se conocía como la Categoría del artículo.

No

"-"

level4

Alfanumérico

Nivel 4 de categorización del artículo. Anteriormente este nivel se conocía como la subcategoría del artículo.

No

"-"

descriptionAlfanuméricoDescripción del ítemSi
currencyAlfanumérico

Moneda utilizada en el precio del ítem

Nota: En el punto de venta se deberá informar la moneda de la cuenta vendedor de Mercado Pago (si el retailer posee una cuenta argentina en Mercado Pago entonces tendrá que informar la moneda $ -pesos argentinos-).

Si
measureAlfanuméricoUnidad de medida del ítem. Valores posibles: unit - packNo"unit"


Ejemplo

Bloco de código
languagexml
<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>

...

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

ParámetroTipo de datoRequeridoDescripción
providerPosCodeAlfanuméricoSi

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

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

bankCodeNuméricoNo

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

Ver códigos de bancos.

installmentsArraySiInformación de las cuotas.

paymentOptionIdAlfanuméricoSi

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

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

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


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

paymentConditionAlfanuméricoNo

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

Máximo 20 caracteres.


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

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

surchargeNuméricoSi

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


nominalAnnualRateNuméricoSi

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


Ejemplo del campo paymentMethodsData (401)

...

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

ParámetroTipo de datoRequeridoDescripción
benefitCardIdAlfanuméricoSi

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

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

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

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

discountPercentage

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

maximumDiscountAmount

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


Ejemplo del campo walletBenefits (402)

...

Informações
titleReferencias

X = Obligatorio
O = Opcional
- = No requerido


Número

Nombre del campo

Tipo de dato

SaleWallet

RefundWallet

QueryWallet

Descripción

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

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

13currencyPosCodeAlfanuméricoX-X

Tipos de moneda:

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

Código de autorización informado por el Autorizador

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

Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. El valor en este campo debe ser el mismo que el valor de la fecha y hora del requerimiento. El POS utiliza este dato para validar que se trate de la misma transacción

26responseCodeAlfanuméricoXXX

Puede contener uno de los siguientes valores:

  • Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27
  • Error = ver sección Códigos de error del CORE
  • TrxIsPending: indica si existen transacciones pendientes de confirmar. En este caso, el ID de transacción a confirmar está en el campo 24
27isoCodeNuméricoXXX

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

28responseMessageAlfanuméricoXXX

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

29

serialNumber

Numérico

OOO

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

Retorna en operaciones aprobadas.

30

businessNumber

Numérico

OOO

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

Retorna en operaciones aprobadas.

31lotNumberNuméricoOOONúmero de lote en el que se registró la transacción
32ticketNuméricoOOONúmero de Ticket correspondiente a la transacción. 4 dígitos como máximo.
81responseAuthAlfanuméricoOOOMensaje de repuesta para imprimir en el ticket del POS. Retorna en operaciones aprobadas. Contiene información generada por el Autorizador.
140paymentTypeNumérico--X

Tipo de pago. Valores posibles:

0: Tarjeta
1: Efectivo

142providerNameAlfanumérico--OProveedor de la tarjeta seleccionada al momento de efectuar el pago QR.
147providerPosCodeAlfanuméricoO-OCódigo del Provider. Retornará cuando la transacción fue aprobada por el Autorizador.
166trxReferenceNumberNuméricoXX-Identificador único de la transacción en VTOL Server. Longitud entre 19 y 20 dígitos, debido a que utiliza el día como parte de formato
271walletPaymentIdAlfanuméricoX-XIdentificador del número de pago informado por el Autorizador
272amountRefundedImporte--XMonto devuelto en la transacción
273paymentStatusAlfanumérico--O

Estado de la transacción de pago informado por el Autorizador. Estados posibles:

0: Aprobado
1: Devuelto
2: Pendiente
3: Autorizado
4: En Progreso
6: Rechazado
7: Cancelado
8: Contracargo

275cardTypeNumérico--O

Tipo de tarjeta seleccionada al momento de efectuar el pago QR por parte del cliente.

Valores posibles:
0: Débito
1: Crédito

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

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

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

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

407amountDiscountedImporteX-O

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

Sólo retorna cuando se aplicó un descuento.


1.4.25 Consultar tarjetas de Fidelidad

...

Informações
titleReferencias

X = Obligatorio
O = Opcional
- = No requerido


Número

Nombre del campo

Tipo de dato

CardQuery

Descripción

0companyNuméricoX

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

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

Tipo de Mensaje:

  • Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server.
  • Data = Mensaje de la Aplicación cliente.

11

trxType

Alfanumérico

X

Tipo de Transacción:

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

25

dateTime

Numérico

X

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

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

2: Adquiriente Prisma

408loyaltyCardNuméricoX

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

1: Clarín 365

157customerDocNuméricoX

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


Ejemplo

Request to VTOL:

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


1.4.25.2 Respuesta

Informações
titleReferencias

X = Obligatorio
O = Opcional
- = No requerido


Número

Nombre del campo

Tipo de dato

CardQuery

Descripción

0companyNuméricoXIdentificador de la compañía donde se generó la transacción
1storeAlfanuméricoXIdentificador del sitio originador de la transacción
2nodeNuméricoXIdentificación del nodo, en el sitio originador, donde se generó la transacción.
6cardNumberAlfanuméricoXNúmero de Tarjeta del cliente. Si es una tarjeta de fidelidad, retornará en plano.
25dateTimeNuméricoXFecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. El valor en este campo debe ser el mismo que el valor de la fecha y hora del requerimiento. El POS utiliza este dato para validar que se trate de la misma transacción
26responseCodeAlfanuméricoX

Puede contener uno de los siguientes valores:

  • Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27
  • Error = ver sección Códigos de error del CORE
27isoCodeNuméricoXCódigo de Respuesta emitido por el centro autorizador. 3 dígitos como máximo. Ver sección: Códigos de Respuesta de VTOL Server para Consulta de Fidelidad
28responseMessageAlfanuméricoXMensaje de la Respuesta relacionado con el código del campo 27
292customerFirstNameAlfanuméricoXNombre del tarjetahabiente.
293customerLastNameAlfanuméricoXApellido del tarjetahabiente.
409loyaltyCardCategoryAlfanuméricoX

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

  • Classic
  • Plus


Ejemplo de Respuesta

Response from VTOL:

Response: {25:20210503193023;2:1;1:1;0:1;6:44123456789010;292:Juan;293:Perez;409:CLASSIC;26:ISO8583;27:00;28:APROBADA}

...

...



...

1.4.26 Operaciones QR Adquiriente Fiserv

VTOL se integra con QR Adquiriente de Fiserv para permitir efectuar pagos en los puntos de venta con billeteras electrónicas. En el pinpad se imprime el código QR en pantalla, el cual siempre es dinámico, es decir que se genera uno nuevo por cada transacción.

Las operaciones soportadas son:

  • SaleWallet = Permite realizar una compra presencial con billetera electrónica.
  • RefundWallet = NO se permite realizar una devolución con Adquiriente Fiserv. No está contemplado en Fiserv.
  • QueryWallet = Permite realizar una consulta de una operación de compra con billetera para conocer si la misma fue autorizada y así obtener los datos por parte del Autorizador.


Nota
titleNota

Las operatorias de billeteras electrónicas poseen tercer mensaje; por lo que en el cierre de sesión se efectuará el envío del requerimiento del tercer mensaje.


Procedimiento para QR Adquiriente Fiserv

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

  1. Se inicia con el envío de una orden de venta (transacción SaleWallet) por parte del POS a VTOL Server. En el requerimiento, el POS podrá incluir las opciones de pago mediante las cuales se realizará la operación.
  2. VTOL recibe la orden de venta del POS, y envía la información a Fiserv con todos los datos de la venta.
  3. Fiserv responde a VTOL que la orden de venta fue creada, y envía el QR para imprimir en el Punto de Venta.
  4. VTOL envía hacia el POS el QR enviado por Fiserv. El POS muestra el QR. 
  5. VTOL responde al POS: "QR generado. Consulte operación"
  6. En ese momento el comprador podrá realizar con su billetera virtual la lectura del código QR. Luego de escanear el QR, el comprador visualizará el detalle de la compra, seleccionando tarjeta, cuotas y confirmando el pago.
  7. Fiserv envía a VTOL el Bin de la tarjeta (prefijo y últimos 4 dígitos) del cliente para que VTOL obtenga el Proveedor de la tarejta. Además envía la opción de pago seleccionada por el cliente, informando cuotas y monto final de la operación.
  8. VTOL valida que la opción de pago esté configurada en su sistema. Si las cuotas y el monto final de la operación son correctos, se envían los datos a Fiserv para ser autorizados.
  9. Fiserv cursa el pago con el Autorizador.
  10. El POS deberá consultar el estado del pago, enviando un mensaje de QueryWallet.
    1. Las respuestas del QueryWallet pueden ser las siguientes:
      1. VTOL responde "Aprobado". Indica que el pago fue autorizado por Fiserv. El paso siguiente del POS es confirmar o cancelar la transacción.
      2. VTOL responde "Rechazado". Indica que el cliente intentó pagar pero Fiserv rechazó el pago.
  11. Por último, el POS debe confirmar la operación, mediante un Tercer Mensaje (Commit o Rollback).


Aviso
titleManejo de cuotas

En caso de ser un pago con Tarjeta de Débito, el POS deberá enviar en el mensaje SaleWallet el campo payments (14) con valor = 1.

En caso de ser un pago con Tarjeta de Crédito, el POS deberá enviar en el mensaje SaleWallet el campo payments (14) con valor mayor a 0.

En caso de ser un pago con Dinero en cuenta, el POS deberá enviar en el mensaje SaleWallet el campo payments (14) con valor = 0, o directamente no enviar el campo 14.

Operatoria de pago con Tarjetas:

El Punto de Venta informará en el mensaje de SaleWallet el Monto y las Cuotas de la operación. VTOL responderá al POS el dato de la tarjeta seleccionada por el cliente en su Billetera Virtual, y el POS con esa información podrá modificar o no el monto original y las cuotas originales. Esto es para que el POS pueda aplicar algún beneficio, por ejemplo 12 cuotas sin interés, o para aplicar intereses, por ejemplo 12 con interés, con el cual el monto puede afectarse. Por lo tanto, el POS enviará en el mensaje de QueryWallet el monto y las cuotas, pudiendo modificar ambos datos.

El flujo es el siguiente:

  1. El POS envía un SaleWallet con el monto y las cuotas de la operación.
  2. Se despliega en el pinpad el QR dinámico para ser escaneado por la billetera virtual del cliente.
  3. El cliente escanea el QR y selecciona la Tarjeta para confirmar el pago.
  4. VTOL responde al POS el código 514 (Tiempo expirado. Elija Consultar o Cancelar pago)
  5. El POS envía un QueryWallet para obtener los datos del pago.
  6. VTOL responde cuál fue la Tarjeta elegida por el cliente, con el código 654 (Valide monto y cuotas según tarjeta elegida) y hace un eco del monto y las cuotas originales enviadas por el POS.
  7. El POS envía un nuevo QueryWallet, enviando los campos de monto y cuotas, pudiendo modificar ambos datos.
    1. Si el POS no envía los campos de monto y cuotas, VTOL responderá nuevamente el código 654 (Valide monto y cuotas según tarjeta elegida)
  8. VTOL responde los datos del pago autorizado.
  9. El POS confirma la operación enviando un Cierre de sesión en estado CLOSE.
  10. VTOL responde OK.
  11. Finaliza el flujo.


1.4.26.1 Requerimiento

Informações
titleReferencias

X = Obligatorio
O = Opcional
- = No requerido


Número

Nombre del campo

Tipo de dato

SaleWallet

QueryWallet

Descripción

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

X

Tipo de Mensaje:

  • Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server.
  • Data = Mensaje de la Aplicación cliente.
11trxTypeAlfanuméricoXX

Tipo de Transacción:

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

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

13currencyPosCodeAlfanuméricoX-

Tipos de moneda:

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

lastTrxId

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

Identificador único de la transacción de billetera para la compañía. Es originado por el POS para realizar una compra con billetera.

Formato:
codigoTienda (longitud 10) + codigoCaja (longitud 10) + Fecha (AAMMDDHHmmss) (longitud 12)
Longitud total de 32.

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

269walletTypeNuméricoXX

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

7: QR Adquiriente Fiserv

270posTicketAlfanuméricoX-Información del ticket en formato xml y posteriormente transformado en Base 64. Ver sección Estructura del campo posTicket
271walletPaymentIdAlfanumérico-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.

410QRCodeAlfanuméricoO-

El POS enviará si desea recibir el código QR para imprimirlo en la caja. Valores posibles:

True: indica que se recibirá el código QR y se inyectará en el pinpad.

False: indica que se recibirá el código QR pero no se inyectará en el pinpad.

No se envía el campo: indica que no se recibirá el código QR


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.

Dentro del encabezado, se podrá enviar el valor de los descuentos totales y de los impuestos totales que aplicarán a la compra.

Los campos dentro del encabezado serán: totDiscount y totTaxes

Detalle de los campos:

Elemento

Tipo de dato

Descripción

Requerido

Valor ante ausencia

totDiscountNuméricoImporte total de descuento que calcula el POS. Será la sumatoria de descuentos que se apliquen a los artículos.No0
totTaxesNuméricoImporte total de impuesto que calcula el POS. Será la sumatoria de impuestos que se apliquen sobre la compra.No0


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.


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

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


Elemento

Atributo

Tipo de dato

Descripción

Requerido

Valor ante ausencia

Ítem





















unitprice

Numérico positivo

Precio unitario del artículo en cuestión.

Si


xprice

Numérico positivo

Precio extendido del artículo en cuestión. Es igual a la cantidad por el precio unitario.

Si


qty

Entero positivo

Cantidad de artículos en la línea.

Si


magnitude

Numérico positivo

Si el artículo es mensurable por otro unidad que no sea la cantidad, deberá ser expresad en esta propiedad.

No

0

code

Alfanumérico

Código propio del artículo.

No

"-"

brand

Alfanumérico

Marca del artículo.

No

"-"

supplier

Alfanumérico

Proveedor al que pertenece el artículo.

No

"-"

discountable

Alfanumérico

Si el artículo es puede recibir descuentos o no.

No

"-"

level1

Alfanumérico

Nivel 1 de categorización del artículo. Anteriormente este nivel se conocía con el nombre de Departamento.

No

"-"

level2

Alfanumérico

Nivel 2 de categorización del artículo. Anteriormente este nivel se conocía como la Familia del artículo.

No

"-"

level3

Alfanumérico

Nivel 3 de categorización del artículo. Anteriormente este nivel se conocía como la Categoría del artículo.

No

"-"

level4

Alfanumérico

Nivel 4 de categorización del artículo. Anteriormente este nivel se conocía como la subcategoría del artículo.

No

"-"

descriptionAlfanuméricoDescripción del ítemSi
currencyAlfanumérico

Moneda utilizada en el precio del ítem

Nota: En el punto de venta se deberá informar la moneda de la cuenta vendedor de Mercado Pago (si el retailer posee una cuenta argentina en Mercado Pago entonces tendrá que informar la moneda $ -pesos argentinos-).

Si
measureAlfanuméricoUnidad de medida del ítem. Valores posibles: unit - packNo"unit"


Ejemplo

Bloco de código
languagexml
<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>


Aviso
titleImportante

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



1.4.26.2 Respuesta

Informações
titleReferencias

X = Obligatorio
O = Opcional
- = No requerido


Número

Nombre del campo

Tipo de dato

SaleWallet

QueryWallet

Descripción

0companyNuméricoXXIdentificador de la compañía donde se generó la transacción
1storeAlfanuméricoXXIdentificador del sitio originador de la transacción
2nodeNuméricoXXIdentificación del nodo, en el sitio originador, donde se generó la transacción.
12amountImporteXX

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

13currencyPosCodeAlfanuméricoXX

Tipos de moneda:

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

Código de autorización informado por el Autorizador

24trxIdNuméricoXXIdentificador de la transacción.

25

dateTime

Numérico

XX

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

XX

Puede contener uno de los siguientes valores:

  • Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27
  • Error = ver sección Códigos de error del CORE
  • TrxIsPending: indica si existen transacciones pendientes de confirmar. En este caso, el ID de transacción a confirmar está en el campo 24

27

isoCode

Numérico

XX

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

XX

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

140paymentTypeNumérico-X

Tipo de pago. Valores posibles:

0: Tarjeta
1: Efectivo
2: Transferencia

166trxReferenceNumberNuméricoX-Identificador único de la transacción en VTOL Server. Longitud entre 19 y 20 dígitos, debido a que utiliza el día como parte de formato
271walletPaymentIdAlfanumérico-XIdentificador del número de pago informado por el Autorizador
273paymentStatusAlfanumérico-X

Estado de la transacción de pago informado por el Autorizador. Estados posibles:

0: Aprobado
2: Pendiente
6: Rechazado
7: Cancelado
9: Reversado

275cardTypeNumérico-O

Tipo de tarjeta seleccionada al momento de efectuar el pago QR. Valores posibles:

0: Débito
1: Crédito

410QRCodeAlfanuméricoOOSe envía la cadena de texto (string del QR dinámico) que retorna desde Fiserv. Este string se utiliza para imprimir el QR en el POS.
1010currentSessionIdNuméricoXXIdentificador de la sesión
1027libResponseCodeNuméricoXX

Código de respuesta de la librería.
Indica cómo fue procesada la operación en EMVKIT:
Éxito = 000
Error <> 000
Ver sección Códigos de Respuesta de Librería

1028libResponseMessageAlfanuméricoXXMensaje descriptivo del código de respuesta de la librería



1.4.27 Operaciones PayStore

VTOL se integra con PayStore de Prisma para permitir efectuar pagos en los puntos de venta, utilizando tarjetas presentes de crédito o débito, y billeteras electrónicas.

Las operaciones soportadas son:

  • SaleWallet = Permite realizar una compra presencial a través de PayStore.
  • SaleWallet con cashback = Permite realizar una compra presencial y realizar retiro de efectivo.
  • RefundWallet = Permite realizar una devolución (total) de una compra presencial a través de PayStore. No se permiten devoluciones parciales.
  • QueryWallet = Permite realizar una consulta de una operación de compra con PayStore para conocer si la misma fue autorizada y así obtener los datos por parte del Autorizador.


Procedimiento para PayStore

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

  1. Se inicia con el envío de una orden de venta (transacción SaleWallet) por parte del POS a VTOL. En el requerimiento, el POS puede incluir o no la cantidad de cuotas del pago.
  2. VTOL recibe la orden de venta del POS, y envía la información a PayStore con todos los datos de la venta.
  3. En ese momento el cajero podrá capturar los datos del pago en la terminal pinpad, el cual puede ser con tarjeta física de crédito y débito, o bien con billetera virtual, realizando la lectura del código QR que se muestra en el pinpad.
  4. El POS recibirá la respuesta de la transacción SaleWallet con el mensaje: "Consulte el pago". 
  5. Para conocer el resultado de la operación, el POS deberá realizar una consulta (transacción QueryWallet). Las respuestas del QueryWallet pueden ser las siguientes:
      1. VTOL responde "Aprobado". Indica que el pago fue autorizado por PayStore. El paso siguiente del POS es confirmar o cancelar la transacción. Se imprime el comprobante en la terminal pinpad.
      2. VTOL responde "Rechazado". Indica que el cliente intentó pagar pero PayStore rechazó el pago.
  6. Por último, el POS deberá confirmar la operación, mediante el Tercer Mensaje, enviando Commit.

La anulación o devolución, sí precisa de interacción por parte del comprador en la caja, en la terminal pinpad se debe capturar los mismos datos de la tarjeta o billetera virtual que se utilizó para el pago. El POS envía el identificador del número de pago del Autorizador en el mensaje RefundWallet.


Aviso
titleImportante

Si una Venta está Aprobada en el pinpad, no es posible reversarla. Cuando la caja intente reversar, se crea entrada en Resolución Administrativa para que sea tratada de forma manual.


Procedimiento para Cashout con PayStore

Se podrán realizar las siguientes operaciones:

Ventas

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

Devoluciones

  • Realizar devoluciones de los productos y del cashout.
    • Operación de venta con productos y cashout. Permite devolver:
      • Devolución total de los productos y del cashout.
    • Operación de venta sólo con productos. Permite devolver:
      • Devolución total de los productos
  • La devolución de cashout siempre debe ser por el monto total.


1.4.27.1 Requerimiento

Informações
titleReferencias

X = Obligatorio
O = Opcional
- = No requerido
C = Condicional


Número

Nombre del campo

Tipo de dato

SaleWallet

RefundWallet

QueryWallet

Descripción

0companyNuméricoX

X

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

Tipo de Mensaje:

  • Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server.
  • Data = Mensaje de la Aplicación cliente.

11

trxType

Alfanumérico

X

XX

Tipo de Transacción:

  • SaleWallet = Compra con billetera electrónica

12

amount

Importe

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, el importe debe ser siempre por el total de la venta y en la misma moneda informada.

13

currencyPosCode

Alfanumérico

X

X-

Tipos de moneda:

  • $ = Pesos
14paymentsNuméricoO--

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

Si no se informa este campo, se toma por defecto el valor 1.

16originalDateNumérico-XXFecha de realización de la compra con billetera electrónica en formato YYYYMMDD
24lastTrxIdNuméricoOOOUtilizado cuando está activo el control transaccional. En este campo el POS debe enviar la última transacción procesada correctamente.

25

dateTime

Numérico

X

XXFecha y hora de realización de la transacción en formato: YYYYMMDDHHMMSS
54additionalamountImporteOO-

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

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

268walletPosTrxIdAlfanuméricoXXO

Identificador único de la transacción de billetera para la compañía. Es originado por el POS para realizar una compra o una devolución.

Formato:
codigoTienda (longitud 10) + codigoCaja (longitud 10) + Fecha (AAMMDDHHmmss) (longitud 12)

Longitud total de 32

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

269walletTypeNuméricoXXX

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

9: PayStore

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

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

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

311purchaseTitleAlfanuméricoO--

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

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

312purchaseDescAlfanuméricoO--

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

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

413printCopiesVoucherNuméricoOO-

Indica las copias del comprobante de pago debe imprimir el terminal. Valores posibles:

1. Solo copia comercio
2. Solo copia cliente
3. Ambas copias

Si no se envía este campo, no se imprime ninguna copia

414paymentOperationMethodNuméricoO--

Indica el medio de pago que se podrá utilizar para la operación. Valores posibles:

1. Tarjeta (pago con tarjeta física débito o crédito)
2. Código QR (pago con billeteras virtuales)

Si no se envía este campo, se toma por defecto el valor 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.

Dentro del encabezado, se podrá enviar el valor de los descuentos totales y de los impuestos totales que aplicarán a la compra.

Los campos dentro del encabezado serán: totDiscount y totTaxes

Detalle de los campos:

Elemento

Tipo de dato

Descripción

Requerido

Valor ante ausencia

totDiscountNuméricoImporte total de descuento que calcula el POS. Será la sumatoria de descuentos que se apliquen a los artículos.No0
totTaxesNuméricoImporte total de impuesto que calcula el POS. Será la sumatoria de impuestos que se apliquen sobre la compra.No0


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.


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. Puede ser el sku o ean.

No

"-"

brand

Alfanumérico

Marca del artículo.

No

"-"

supplier

Alfanumérico

Proveedor al que pertenece el artículo.

No

"-"

discountable

Alfanumérico

Si el artículo es puede recibir descuentos o no.

No

"-"

level1

Alfanumérico

Nivel 1 de categorización del artículo. Anteriormente este nivel se conocía con el nombre de Departamento.

No

"-"

level2

Alfanumérico

Nivel 2 de categorización del artículo. Anteriormente este nivel se conocía como la Familia del artículo.

No

"-"

level3

Alfanumérico

Nivel 3 de categorización del artículo. Anteriormente este nivel se conocía como la Categoría del artículo.

No

"-"

level4

Alfanumérico

Nivel 4 de categorización del artículo. Anteriormente este nivel se conocía como la subcategoría del artículo.

No

"-"

descriptionAlfanuméricoDescripción del ítemSi
currencyAlfanumérico

Moneda utilizada en el precio del ítem.

Si
measureAlfanuméricoUnidad de medida del ítem. Valores posibles: unit - packNo"unit"


Ejemplo

Bloco de código
languagexml
<message totDiscount="100.00" totTaxes="50.00">
<item-add seq="1" code="0001" discountable="true" unitprice="100.0" qty="3.0" xprice="300.0" level1="MEN" level2="CASUAL" supplier="" brand="LEVIS"  magnitude="1" description="Jean casual" currency="$" />
<item-add seq="2" code="0002" discountable="true" unitprice="28.0" qty="1.0" xprice="48.0" level1="MEN" level2="CASUAL" supplier="" brand="LEVIS" magnitude="1" description="Jean casual" currency="$" />
</message>


Ejemplo de requerimiento:

SaleWallet:
{269:9;268:0000000001000000000120223603013649;25:20220303133649;71:True;14:1;13:$;12:8100;11:SaleWallet;4:DATA;270:PG1lc3NhZ2UgjYXN1YWwiIGN1cnJlbmN5PSIkIiAvPgo8L21lc3NhZ2U+Cg}

RefundWallet:
{271:03013659-d8ec-4e06-974c-e967f83e782e;16:20220303;269:9;268:0000000001000000000120223803013836;13:$;12:8100;11:RefundWallet;4:DATA;3:VTOL;2:1;25:20220303133836;71:True;1:1;0:1}

QueryWallet:
{0:1;1:1;2:1;3:VTOL;4:DATA;11:QueryWallet;16:20220303;25:20220303133921;71:False;268:0000000001000000000120223803013836;269:9}



1.4.27.2 Respuesta

Informações
titleReferencias

X = Obligatorio
O = Opcional
- = No requerido
C = Condicional


Número

Nombre del campo

Tipo de dato

SaleWallet

RefundWallet

QueryWallet

Descripción

0companyNuméricoXXX

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

1storeAlfanuméricoXXXIdentificador del sitio originador de la transacción.
2nodeNuméricoXXXIdentificación del nodo, en el sitio originador, donde se generó la transacción.
12amountImporteX-XMonto de la transacción. Valor entero. Los últimos 2 dígitos corresponden a los decimales.
13currencyPosCodeAlfanuméricoX-X

Tipos de moneda:

  • $ = Pesos
 14paymentsNuméricoO--

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

Si no se informa este campo, se toma por defecto el valor 1.

24trxIdNuméricoXXXIdentificador de la transacción
25dateTimeNuméricoXXXFecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. El valor en este campo debe ser el mismo que el valor de la fecha y hora del requerimiento. El POS utiliza este dato para validar que se trate de la misma transacción
26responseCodeAlfanuméricoXXX

Puede contener uno de los siguientes valores:

  • Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27
  • Error = ver sección Códigos de error del CORE
  • TrxIsPending: indica si existen transacciones pendientes de confirmar. En este caso, el ID de transacción a confirmar está en el campo 24
27isoCodeNuméricoXXXCódigo de Respuesta emitido por el centro autorizador. 3 dígitos como máximo. Ver sección Códigos de Respuesta de VTOL Server para Billeteras Electrónicas
28responseMessageAlfanuméricoXXXMensaje de la Respuesta relacionado con el código del campo 27
29serialNumberNuméricoOXXNúmero que identifica la terminal lógica en la que se procesó la transacción.
30businessNumberNuméricoOXXNúmero de comercio en el que se procesó la transacción.
31lotNumberNuméricoOXXNúmero de lote en el que se registró la transacción.
32ticketNuméricoOXXNúmero de Ticket correspondiente a la transacción.
54additionalamountImporteOOO

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.

142providerNameAlfanumérico--O

Proveedor de la tarjeta seleccionada al momento de efectuar el pago.

166trxReferenceNumberNuméricoXXXIdentificador único de la transacción en VTOL Server. Longitud entre 19 y 20 dígitos, debido a que utiliza el día como parte de formato
271walletPaymentIdAlfanuméricoX-XIdentificador del número de pago informado por el Autorizador
273paymentStatusAlfanuméricoX-X

Estado de la transacción de pago informado por el Autorizador. Estados posibles:

0: Aprobado
1: Devuelto
2: Pendiente
3: Autorizado
4: En Progreso
6: Rechazado
7: Cancelado
8: Contracargo

274paymentStatusDetailAlfanuméricoX-XDetalle del estado de la transacción de pago informado por el Autorizador
275cardTypeNuméricoO-O

Tipo de tarjeta seleccionada al momento de efectuar el pago.

Valores posibles:

0: Débito
1: Crédito


Ejemplo de respuesta:

SaleWallet:
{25:20220303133649;2:1;1:1;0:1;12:8100;275:0;13:$;27:514;273:0;140:0;14:0;26:ISO8583;28:Tiempo expirado. Elija Consultar o Cancelar;24:13;166:3032213365800000020;271:03013659-d8ec-4e06-974c-e967f83e782e}

RefundWallet:
{2:1;1:1;0:1;24:14;25:20220303133836;26:ISO8583;27:514;28:Tiempo expirado. Elija Consultar o Cancelar;166:3032213385800000021}

QueryWallet:
{0:1;1:1;2:1;12:8100;13:$;24:14;25:20220303133921;26:ISO8583;27:00;28:APROBADA;166:3032213385800000021;271:03013858-d8ec-4e06-974c-e967f83e782e;273:0;274:CONFIRMED}


1.4.28 Operaciones GoCuotas API QR

VTOL se integra con GoCuotas API QR para permitir efectuar pagos mediante un código QR estático por cada caja, en modalidad presencial, desde un punto de venta (POS). Al enviar la intención de compra desde VTOL a GoCuotas, se habilitará un QR que el usuario comprador deberá escanear desde la cámara de su celular y se le redireccionará a la web de GoCuotas, en donde deberá tener una cuenta registrada con una tarjeta de débito para realizar el pago. El encargado de aprobar los pagos es GOCUOTAS, quien es el encargado también de la gestión e impresión de los códigos QR. Luego VTOL deberá recibir mediante una notificación la respuesta con el estado de la orden, ya sea Confirmado o Cancelado.

Las transacciones soportadas son:

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

Definición del flujo de la operación SaleWallet:

  1. El POS envía la transacción de venta (SaleWallet) a VTOL.
  2. VTOL le envía a GoCuotas el requerimiento de Authenticacion al endpoint /api/qr/v1/authentication. Nota: el request message solo se envía si no existe un authToken vigente, la vigencia de cada authToken es de 24 hs
  3. GoCuotas responde a VTOL con el message HTTP 200 en donde le envía el Token de autenticación aprobado.
  4. VTOL se comunica con GoCuotas para enviar la intención de pago mediante un POST al endpoint /api/qr/v1/checkouts. 
  5. GoCuotas responde con el mensaje HTTP 201 "Orden creada" y algunos campos en el messagge response como el sale_token, status, amount_in_cents, entre otros. El campo sale_token será el token que representará la nueva venta y que se deberá enviar en algunos requests.
  6. VTOL recibe el mensaje de que la orden fue creada. Importante: luego de la creación de la orden de pago, se tienen 15 min para realizar la confirmación del pago, si se excede el tiempo establecido, la compra será cancelada automáticamente.
  7. Se pueden presentar los siguientes escenarios:
    1. Si el usuario escanea el QR y selecciona la tarjeta de débito/ cuotas para realizar el pago dentro del tiempo establecido (15 min), entonces, VTOL recibe la notificación de la compra con el estado de la orden confirmada (status: approved), ya que el usuario realizó el pago de forma exitosa. Luego VTOL le responde al POS con el estado de la transacción aprobada (isoCode "00" y responseMessage "Aprobada"). 
    2.  Si expiró el tiempo establecido de los 15 min para realizar el pago, entonces, VTOL recibe la notificación de la compra con el estado cancelada (status: denied). En este caso, la orden se cancela de forma automáticamente. Luego VTOL le responde al POS con la información de la orden cancelada.

Nota: la información de la confirmación o cancelación del pago será enviando al webhook_url que se completó al momento de crear la venta con QR. El mismo será un POST con formato JSON. En el caso de confirmación de pago por parte del cliente, el webhook será enviado en el momento. Por otro lado, si el cliente no realiza el pago, el webhook de cancelación de venta será enviado a los 15 minutos.

      8. Se continua con el flujo 7.a. El POS envía el tercer mensaje de “Commit”.

      9. Finaliza el flujo de la operación.

Definición del flujo de la operación RefundWallet:

  1. El POS le envía a VTOL la operación “RefundWallet” con los campos 271 walletPaymentId, 24 trxId (opcional) y el 12 Ammount. Nota: si la devolución es por el monto total de la compra, se deberá enviar en el campo 12 el importe total o si el importe que se desea devolver es menor al total de la compra, se deberá enviar el importe en dicho campo, y se refiere a una compra parcial.
  2. VTOL se comunica con GoCuotas mediante al endpoint /api/qr/v1/orders para consultar el estado de la orden, en donde se envía el saleToken que identifica la transacción original que se desea devolver.
  3. GoCuotas responde el código HTTP 200 con el estado de la transacción de compra y los datos de la operación. Importante: la orden debe estar confirmada (status: approved) para poder solicitar la devolución parcial o total. Una orden se marca como confirmada luego de que el usuario realiza el pago de forma exitosa.
  4. VTOL le responde al POS con el estado de la orden confirmada, con el campo 27 isoCode = 00 y el campo 28 responseMessage = Aprobada.
  5. El POS le envía a VTOL el tercer mensaje "Commit".
  6. VTOL se comunica con GoCuotas mediante el endpoint api/qr/v1/refund para solicitar la devolución total o parcial de una venta. Se envían los parámetros sale_token y amount_in_cents.
  7. GoCuotas le responde a VTOL con datos de la transacción como el status, order_reference_id, amount_in_cents, entre otros.
  8. Finaliza el flujo de la operación. 


Dica
titleImportante:

Se pueden realizar devoluciones por el monto total de la transacción y también por un monto parcial.

Definición del flujo de la operación QueryWallet:

  1. El POS le envía a VTOL la operación “QueryWallet” con el campo 268: WalletPosTrxId.
  2. VTOL se comunica con GoCuotas mediante el endpoint /checkouts/{api_qr_sale_token}, en donde se deberá enviar un sale_token válido. Nota: VTOL solo se comunica con GoCuotas si el pago no está aprobado. Si el pago se encuentra aprobado, entonces VTOL le responde automáticamente al POS con la información de la orden aprobada, sin realizar la consulta a GoCuotas.
  3. GoCuotas le responde a VTOL el código HTTP 200 con el status de la operación y los otros campos definidos por GoCuotas.
  4. VTOL le responde al POS el estado Aprobado de la operación solicitada (saleWallet o refundWallet).

1.4.28.1 Requerimiento POS - VTOL

Informações
titleReferencia de campos:

X = Obligatorio
O = Opcional
- = No requerido
C = Condicional


Número

Nombre del campo

Tipo de dato

SaleWallet

RefundWallet

QueryWallet

Descripción

0

company

Alfanumérico

X

X

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

1

store

Numérico

X

X

X

Identificador del sitio originador de la transacción

2

node

Alfanumérico

X

X

X

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

3

server

Alfanumérico

X

X

X

Identificador del Server que procesará la transacción. (en el caso de VTOL será 'VTOL')

4

messageType

Alfanumérico

X

X

X

Tipo de Mensaje:

  • Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server.
  • Data = Mensaje de la Aplicación cliente.

11

trxType

Alfanumérico

X

X

X

Tipo de Transacción:

  • SaleWallet= Permite realizar una compra presencial con billetera.
  • RefundWallet = Permite realizar una devolución (parcial o total) de una compra presencial con billetera realizada con anterioridad.
  • QueryWallet = Consulta de transacción de compra realizada con billetera electrónica

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

X

-

Tipos de moneda:

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

25

dateTimeNuméricoXXXFecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS

71

checkPendingStringAlfanuméricoOXX

Indica si VTOL debe o no efectuar el chequeo de pendientes:

  • true = activa chequeo de pendientes.
  • false = desactiva chequeo de pendientes.

Default = true.

157

customerDocNuméricoXO-

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

Valida la cantidad de dígitos ingresados, máximo 8 dígitos.

268walletPosTrxIdAlfanuméricoXXX

Identificador único de la transacción de billetera para la compañía. Debe ser único por tipo de transacción. Es originado por el POS para realizar una compra o devolución con billetera.

Formato:
codigoTienda (longitud 10) + codigoCaja (longitud 10) + Fecha (AAMMDDHHmmss) (longitud 12)
Longitud total de 32

269walletTypeNuméricoXXX

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

1: Mercado Pago

5: Yacaré

6: Plus Pagos

8: Rappi Payless

10: GoCuotas

270walletPosTicketAlfanuméricoX--Información del ticket en formato xml y posteriormente transformado en Base 64.  Ver sección Estructura del campo posTicket

271

walletPaymentIdAlfanumérico-XOIdentificador del número de pago informado por el Autorizador.
416customerPhoneAreaCodeNuméricoO--

Código de área de teléfono celular del cliente. 

Valida la cantidad de dígitos, máximo 5 dígitos. No se envía el 0 en el código de área. 

417customerPhoneNuméricoO--

Teléfono celular del cliente. 

Valida la cantidad de dígitos ingresados, máximo 9 dígitos.

418customerEmail AlfanuméricoO--

Mail del cliente. 

Valida el formato del mail: [email protected]

1.4.28.2 Respuesta VTOL - POS

Informações
titleReferencia de campos:

X = Obligatorio
O = Opcional
- = No requerido
C = Condicional


Número

Nombre del campo

Tipo de dato

SaleWallet

RefundWallet

QueryWallet

Descripción

0

company

Alfanumérico

X

X

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

1

store

Numérico

X

X

X

Identificador del sitio originador de la transacción

2

node

Alfanumérico

X

X

X

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

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

-

X

Tipos de moneda:

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

24

trxId

Numérico

X

X

X

Identificador de la transacción

25

clientDateNuméricoXXXFecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS

26

responseCodeAlfanuméricoXXX

Puede contener uno de los siguientes valores:

  • Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27
  • Error = ver sección Códigos de error del CORE
  • TrxIsPending: indica si existen transacciones pendientes de confirmar. En este caso, el ID de transacción a confirmar está en el campo 24

27

isoCodeNuméricoXXX

Código de Respuesta emitido por el centro autorizador. 3 dígitos como máximo.

Ver sección Códigos de respuesta VTOL Server para GoCuotas

28

responseMessageAlfanuméricoXXXMensaje de la Respuesta relacionado con el código del campo 27

140

paymentTypeNuméricoX-X

Tipo de pago. Valore posible 0: Tarjeta

166

trxReferenceNumberNuméricoXX-Identificador único de la transacción en VTOL Server. Longitud entre 19 y 20 dígitos, debido a que utiliza el día como parte de formato

271

walletPaymentIdAlfanuméricoX-XIdentificador del número de pago informado por el Autorizador.

273

paymentStatusAlfanuméricoX-X

Estado de la transacción de pago informado por el Autorizador.

Estados posibles:

0: Aprobado
1: Devuelto
2: Pendiente
3: Autorizado
4: En Progreso
5: En mediacion
6: Rechazado
7: Cancelado
8: Contracargo
9: Reversado

274paymentStatusDetailAlfanumérico--XDetalle del estado de la transacción de pago informado por el Autorizador

275

cardTypeNuméricoX-X

Tipo de tarjeta seleccionada al momento de efectuar el pago.

Valor posible:
0: Débito

1.4.29 Operaciones GoCuotas API Full

VTOL se integra con la API Full de GOCUOTAS para permitir a los comercios aceptar esta billetera como un método de pago adicional. GoCuotas, es una billetera que permite realizar el pago con tarjeta de DEBITO de una compra hasta en 4 cuotas sin interés. Se realizarán pagos con la Billetera GOCUOTAS, en modalidad presencial, desde un punto de venta (POS). El encargado de aprobar los pagos será GOCUOTAS. VTOL enviará una intención de pago, y esperará recibir la respuesta del mismo, ya sea Aprobado o Rechazado.

En la versión API Full de GoCuotas al ingresar todos los datos para generar una venta, se le enviará un código de verificación al celular del cliente que se le deberá solicitar luego para realizar la validación de identidad y poder completar la venta. Se puede agregar una nueva tarjeta que se utilizará para completar la venta (solo es necesario para clientes nuevos o clientes que necesiten utilizar otra tarjeta). También se pueden realizar reembolsos por el monto total o parcial de la venta y consultar ordenes generadas. Las operaciones soportadas son las siguientes: 

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


Definición del flujo de la operación SaleWallet:

  1. Se inicia con el envío de una orden de venta (transacción SaleWallet) por parte del POS a VTOL.
  2. VTOL le envía a GoCuotas el requerimiento de Authentication mediante el endpoint /authentication. Nota: el request message solo se envía si no existe un authToken vigente, la vigencia de cada authToken es de 24 hs.
  3. GoCuotas responde a VTOL con el message HTTP 200 en donde se envía el Token de autenticación aprobado.
  4. Luego VTOL se comunica con GoCuotas mediante endpoint / send_code, en donde se envían todos los datos necesarios para generar la venta: email, dni, area_code (sin "0"), telephone_number (sin "15"), amount_in_cents, number_of_installments, order_reference_id y Authorization: Bearer.
  5. GoCuotas responde a VTOL con el Message HTTP 201 y el dato "sale_token" que será el token que representará la nueva venta.
  6. VTOL le responde al POS el isocode 714 y el responseMessage “Orden creada, ingrese el código de verificación”
  7. El POS le envía a VTOL el primer QueryWallet con el campo 279: softToken.
  8. VTOL se comunica con GoCuotas mediante el endpoint /code_verification, en donde envía los campos sale_token, code y Authorization: Bearer. En este endpoint se envía el código de seguridad “code” que recibió el cliente en su celular para validar su identidad.
  9. GoCuotas le responde a VTOL con el dato de la tarjeta (card) que contiene los últimos 4 dígitos y el status de la compra. GoCuotas responde con toda la información de la venta generada y con los datos del cliente.
  10. VTOL le responde al POS con el isocode 718 y el responseMessage “Confirma la tarjeta recibida”.
  11. El POS le envía a VTOL la segunda QueryWallet (se envía el campo 6: cardNumber con los últimos cuatro dígitos de la tarjeta como eco del campo 6 de la respuesta de VTOL al POS del paso anterior). 
  12. VTOL se comunica con Gocuotas mediante al endpoint / payments (este endpoint se utiliza para realizar el pago y completar la venta).
  13. GoCuotas responde a VTOL con el status aprobado de la transacción y otros datos.
  14. VTOL le responde al POS con el estado de la transacción aprobada (isoCode "00" y responseMessage "Aprobada")
  15. Por último, el POS envía el tercer mensaje de “Commit”.


Definición del flujo de la operación SaleWallet con cambio de tarjeta:

A continuación, se define el flujo para procesar un pago con cambio de tarjeta de débito "Aprobado":

  1. Se inicia con el envío de una orden de venta (transacción SaleWallet) por parte del POS a VTOL.
  2. VTOL le envía a GoCuotas el requerimiento de Authentication mediante el endpoint /authentication. Nota: el request message solo se envía si no existe un authToken vigente, la vigencia de cada authToken es de 24 hs.
  3. GoCuotas responde a VTOL con el Message HTTP 200 en donde se envía el Token con la respuesta Aprobado.
  4. Luego VTOL se comunica con GoCuotas mediante endpoint / send_code, en donde se envían todos los datos necesarios para generar la venta: el email, dni, area_code (sin "0"), telephone_number (sin "15"), amount_in_cents, number_of_installments, order_reference_id y Authorization: Bearer.
  5. GoCuotas responde a VTOL con el Message HTTP 201 y el dato"sale_token" que será el token que representará la nueva venta.
  6. VTOL le responde al POS el isocode 714 y el responseMessage “Orden creada, ingrese el código de verificación”
  7. El POS le envía a VTOL el primer QueryWallet con el campo 279: softToken.
  8. VTOL se comunica con GoCuotas mediante el endpoint / code_verification, en donde le envía los campos sale_token, code y Authorization: Bearer. En este endpoint se envía el código de seguridad “code” que recibió el cliente en su celular para validar su identidad.
  9. GoCuotas le responde a VTOL con el dato de la tarjeta (card) que contiene los últimos 4 dígitos y el status de la compra. GoCuotas responde con toda la información de la venta generada y con los datos del cliente.
  10. VTOL le responde al POS con el isocode 718 y el responseMessage “Confirma la tarjeta recibida”.
  11. El POS le envía a VTOL la segunda QueryWallet con los campos, "6: cardNumber" (dieciséis dígitos de la tarjeta), "8: cvc" (tres dígitos), expirationDate (cuatro dígitos en formato AAMM).
  12. VTOL le envía a GoCuotas el requerimiento del cambio de tarjeta mediante el endpoint / cards (este endpoint se utiliza en el caso de que el cliente no tenga ninguna tarjeta cargada en el sistema de GoCuotas o si es necesario cambiar de tarjeta para realizar el pago).
  13. GoCuotas le responde a VTOL con los siguientes datos: sale_token, status, last_four_digits, entre otros.
  14. VTOL le responde al POS con el isocode 718 y el responseMessage “Confirma la tarjeta recibida”.
  15. El POS le envía a VTOL la tercera QueryWallet con el "campo 6: cardNumber".
  16. VTOL se comunica con Gocuotas mediante al endpoint / payments  (este endpoint se utiliza para realizar el pago y completar la venta).
  17. GoCuotas responde a VTOL con los campos payment_successfully_confirmed: true, "status": "approved", card, entre otros.
  18. VTOL le envía al POS el response message "Aprobada".


Definición del flujo de la operación SaleWallet con cambio de tarjeta que excede el tiempo máximo (2min) para realizar el pago:

 A continuación, se define el flujo para procesar un pago con cambio de tarjeta superando el tiempo máximo (2min) para realizar el pago:

  1. Se inicia con el envío de una orden de venta (transacción SaleWallet) por parte del POS a VTOL.
  2. VTOL le envía a GoCuotas el requerimiento de Authentication mediante el endpoint /authentication. Nota: el request message solo se envía si no existe un authToken vigente, la vigencia de cada authToken es de 24 hs.
  3. GoCuotas responde a VTOL con el Message HTTP 200 en donde se envía el Token con la respuesta Aprobado.
  4. Luego VTOL se comunica con GoCuotas mediante endpoint / send_code, en donde se envían todos los datos necesarios para generar la venta: el email, dni, area_code (sin "0"), telephone_number (sin "15"), amount_in_cents, number_of_installments, order_reference_id y Authorization: Bearer.
  5. GoCuotas responde a VTOL con el Message HTTP 201 y el dato del "sale_token" que será el token que representará la nueva venta.
  6. VTOL le responde al POS el isocode 714 y el responseMessage “Orden creada, ingrese el código de verificación”
  7. El POS le envía a VTOL el primer QueryWallet con el campo 279: softToken.
  8. VTOL se comunica con GoCuotas mediante el endpoint / code_verification, en donde le envía los campos sale_token, code y Authorization: Bearer. En este endpoint se envía el código de seguridad “code” que recibió el cliente en su celular para validar su identidad.
  9. GoCuotas le responde a VTOL con el dato de la tarjeta (card) que contiene los últimos 4 dígitos y el status de la compra. GoCuotas responde con toda la información de la venta generada y con los datos del cliente.
  10. VTOL le responde al POS con el isocode 718 y el responseMessage “Confirma la tarjeta recibida”.
  11. El POS le envía a VTOL la segunda QueryWallet con los campos, "6 cardNumber" (dieciséis dígitos de la tarjeta), "8 cvc" (tres dígitos), expirationDate (cuatro dígitos en formato AAMM). También se debe informar el campo "269 WalletType" con GoCuotas.
  12. VTOL le envía a GoCuotas el requerimiento del cambio de tarjeta mediante el endpoint /cards (este endpoint se utiliza en el caso de que el cliente no tenga ninguna tarjeta cargada en en el sistema de GoCuotas o si es necesario cambiar de tarjeta para realizar el pago).
  13. GoCuotas le responde a VTOL con los siguientes datos: sale_token, status, last_four_digits, entre otros
  14. VTOL le responde al POS con el isocode 718 y el responseMessage “Confirma la tarjeta recibida”.
  15. El POS le envía a VTOL la tercera QueryWallet con el "campo 6: cardNumber" en donde se deben ingresar los cuatro últimos dígitos de la tarjeta para confirma el pago.
  16. VTOL se comunica con Gocuotas mediante el endpoint / payments. Se valida que se excede el tiempo determinado de 2 minutos para realizar el pago.
  17. GoCuotas responde "Response message: (confirmed: false....)"
  18. VTOL responde al POS "Response message: Error 604, No se puede realizar el pago, reinicie la operación"
  19. Se reitera nuevamente el envío de una orden de venta (transacción SaleWallet) por parte del POS a VTOL.
  20. VTOL se comunica con GoCuotas mediante el endpoint / send_code, en donde se envían los datos del email, dni, area_code (sin "0"), telephone_number (sin "15"), amount_in_cents, number_of_installments, order_reference_id y Authorization: Bearer.
  21. GoCuotas responde a VTOL con el Message HTTP 200 (verificar cód de respuesta) y el dato del "sale_token".
  22. VTOL le responde al POS el isocode 714 y el responseMessage “Orden creada, ingrese el código de verificación”
  23. El POS le envía a VTOL la cuarta QueryWallet con el campo 279: softToken.
  24. VTOL se comunica con GoCuotas mediante el enpoint “code_verification”, en donde le envía los campos sale_token, code y Authorization: Bearer.
  25. El POS le envía a VTOL la quinta QueryWallet enviando el campo 6: cardNumber con los últimos cuatro dígitos de la tarjeta para confirmar el pago.
  26. VTOL se comunica con Gocuotas mediante al endpoint / payments.
  27. GoCuotas responde a VTOL con el status aprobado de la transacción y otros datos.
  28. VTOL le responde a POS con el estado de la transacción aprobada (isoCode "00" y responseMessage "Aprobada")
  29. Por último, el POS envía el tercer mensaje de “Commit”.


Definición del flujo de la operación RefundWallet:

  1. El POS le envía a VTOL la operación “RefundWallet” con los campos 271 walletPaymentId, 24 trxId (opcional) y el 12 Ammount. Nota: si la devolución es por el monto total de la compra, se deberá enviar en el campo 12 el importe total. Si el importe que se desea devolver es menor al total de la compra, se deberá enviar el importe en dicho campo, y se refiere a una compra parcial.
  2. VTOL se comunica con GoCuotas mediante el endpoint / orders para consultar la orden, en donde se envía el saleToken y el Authorization: Bearer.
  3. GoCuotas responde el código HTTP 200 con el status de la transacción de compra y los datos de la operación.
  4. VTOL le responde al POS.
  5. VTOL se comunica con GoCuotas mediante el endpoint / refund para solicitar la devolución total o parcial de una venta. Se envían los parámetros sale_token y el amount_in_cents.
  6. GoCuotas le responde a VTOL con datos de la transacción del refundWallet. Si la devolución se realiza por el monto total de la compra, entonces en el campo status aparece “denied”. Si el monto es menor que el importe total de la compra entonces aparece “Approved”.


Informações
titleIMPORTANTE:

Las devoluciones se deben realizar desde la misma caja donde se realizó la venta original


Informações
titleIMPORTANTE
  • Si el monto en centavos de la devolución es igual o mayor al monto en centavos de la venta, automáticamente el sistema realiza una devolución total y anula la operación, quedando en estado "DENIED"

  • Si el monto en centavos de la devolución es menor al monto en centavos de la venta, automáticamente el sistema realiza una devolución parcial, quedando en estado "APPROVED"


Definición del flujo de la operación QueryWallet:

  1. El POS le envía a VTOL la operación “QueryWallet” con el campo 268: WalletPosTrxId.
  2. VTOL se comunica con GoCuotas mediante el endpoint / orders, en donde se envía el saleToken y el Authorization: Bearer. Nota: VTOL solo se comunica con GoCuotas si el pago no está aprobado. Si el pago se encuentra aprobado, entonces VTOL le responde automáticamente al POS con la información de la orden aprobada, sin realizar la consulta a GoCuotas.
  3. GoCuotas responde con el código HTTP 200 y con el status de la solicitud del QueryWallet de la transacción de compra.
  4. VTOL le responde al POS el estado Aprobada de la operación solicitada (saleWallet o refundWallet).


1.4.29.1 Requerimiento POS - VTOL

Informações
titleReferencia de campos:

X = Obligatorio
O = Opcional
- = No requerido
C = Condicional


Número

Nombre del campo

Tipo de dato

SaleWallet

RefundWallet

QueryWallet

Descripción

0

company

Alfanumérico

X

X

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

1

store

Numérico

X

X

X

Identificador del sitio originador de la transacción

2

node

Alfanumérico

X

X

X

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

3

server

Alfanumérico

X

X

X

Identificador del Server que procesará la transacción. (en el caso de VTOL será 'VTOL')

4

messageType

Alfanumérico

X

X

X

Tipo de Mensaje:

  • Control = Mensaje de Control, para uso interno por parte de un módulo en su comunicación con el server.
  • Data = Mensaje de la Aplicación cliente.

11

trxType

Alfanumérico

X

X

X

Tipo de Transacción:

  • SaleWallet= Permite realizar una compra presencial con billetera
  • RefundWallet = Permite realizar una devolución (parcial o total) de una compra presencial con billetera realizada con anterioridad.
  • QueryWallet = Permite realizar una consulta de una operación de venta o devolución con billetera, para conocer si la misma fue autorizada y así obtener los datos de la misma por parte del Autorizador.

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

X

-

Tipos de moneda:

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

14

payments

Numérico

X

X

-

Cantidad de cuotas seleccionadas al momento de realizar el pago.

Valida la cantidad de cuotas ingresadas, solo se admiten los valores 2, 3 y 4.

16originalDateNumérico-XXFecha de realización de la compra con billetera electrónica en formato YYYYMMDD

25

dateTimeNuméricoXXXFecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS

71

checkPendingStringAlfanuméricoXXX

Indica si VTOL debe o no efectuar el chequeo de pendientes:

  • true = activa chequeo de pendientes.
  • false = desactiva chequeo de pendientes.

157

customerDocNuméricoX--

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

Valida la cantidad de dígitos ingresados, máximo 8 dígitos.

268walletPosTrxIdAlfanuméricoXXX

Identificador único de la transacción de billetera para la compañía. Debe ser único por tipo de transacción. Es originado por el POS para realizar una compra o devolución con billetera.

Formato:
codigoTienda (longitud 10) + codigoCaja (longitud 10) + Fecha (AAMMDDHHmmss) (longitud 12)
Longitud total de 32

269walletTypeNuméricoXXX

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

1: Mercado Pago

5: Yacaré

6: Plus Pagos

8: Rappi Payless

10: GoCuotas

270walletPosTicketAlfanuméricoXO-Información del ticket en formato xml y posteriormente transformado en Base 64. Ver sección Estructura del campo posTicket

271

walletPaymentIdAlfanumérico-XOIdentificador del número de pago informado por el Autorizador.
416customerPhoneAreaCodeNuméricoX--

Código de área de teléfono celular del cliente. 

Valida la cantidad de dígitos, máximo 5 dígitos. No se envía el 0 en el código de área

417customerPhoneNuméricoX--

Teléfono celular del cliente. 

Valida la cantidad de dígitos ingresados, máximodígitos.

418customerEmail AlfanuméricoX--

Mail del cliente. 

Valida el formato del mail: [email protected]


Informações
titleImportante:

Si se realiza un cambio de tarjeta se debe enviar en la segunda QueryWallet de POS a VTOL los campos especificados para la operación SaleWallet y lo siguiente: 

  • campo 6 cardNumber (dieciséis dígitos de la tarjeta).
  • campo 7 expiration (cuatro dígitos en formato AAMM).
  • campo 8 cvc (tres dígitos).

1.4.29.2 Respuesta VTOL - POS

Informações
titleReferencia de campos:

X = Obligatorio
O = Opcional
- = No requerido
C = Condicional


Número

Nombre del campo

Tipo de dato

SaleWallet

RefundWallet

QueryWallet

Descripción

1

store

Numérico

X

X

X

Identificador del sitio originador de la transacción

2

node

Alfanumérico

X

X

X

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

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

-

X

Tipos de moneda:

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

14

payments

Numérico

X

-

X

Cantidad de cuotas seleccionadas al momento de realizar el pago. Solo se admiten los valores 2, 3 y 4.

24

trxId

Numérico

X

X

X

Identificador de la transacción

25

clientDateNuméricoXXXFecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS

26

responseCodeAlfanuméricoXXX

Puede contener uno de los siguientes valores:

  • Iso8583 = la autorización fue procesada. Para evaluar si fue aprobada chequear el campo 27
  • Error = ver sección Códigos de error del CORE
  • TrxIsPending: indica si existen transacciones pendientes de confirmar. En este caso, el ID de transacción a confirmar está en el campo 24

27

isoCodeNuméricoXXX

Código de Respuesta emitido por el centro autorizador. 3 dígitos como máximo.

Ver sección Códigos de respuesta VTOL Server para GoCuotas

28

responseMessageAlfanuméricoXXXMensaje de la Respuesta relacionado con el código del campo 27

140

paymentTypeNuméricoX-X

Tipo de pago. Valore posible 0: Tarjeta

166

trxReferenceNumberNuméricoXX-Identificador único de la transacción en VTOL Server. Longitud entre 19 y 20 dígitos, debido a que utiliza el día como parte de formato

271

walletPaymentIdAlfanuméricoX-XIdentificador del número de pago informado por el Autorizador.

273

paymentStatusAlfanuméricoX-X

Estado de la transacción de pago informado por el Autorizador.

Estados posibles:

0: Aprobado
1: Devuelto
2: Pendiente
3: Autorizado
4: En Progreso
5: En mediacion
6: Rechazado
7: Cancelado
8: Contracargo
9: Reversado

274paymentStatusDetailAlfanumérico--XDetalle del estado de la transacción de pago informado por el Autorizador

275

cardTypeNuméricoX-X

Tipo de tarjeta seleccionada al momento de efectuar el pago.

Valor posible:
0: Débito

Âncora
_Toc485222740
_Toc485222740
1.5 Códigos de Respuesta al POS


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

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

...

Código

Descripción

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

Clave DNI inválido

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

...

354Trx original no se puede devolver
355La cuenta es incorrecta
356La cuenta no está habilitada
357La cuenta del comercio es incorrecta
358La cuenta de la sucursal es incorrecta
359Comercio supero monto para concepto
360Sucursal supero monto para concepto
361Tarjeta supero monto tipo de operacion
362Comercio supero monto tipo operacion
363Comercio supero monto tipo operacion
364Comercio supero cantidad transacciones
365Comercio supero cantidad transacciones
366Sucursal supero monto diario permitido
367Sucursal supero monto mensual permitido
368Sucursal supero cantidad trxs diarias
369Sucursal supero cantidad trx mensuales
370Error al desencriptar campos encriptados
371La cuenta destino del comercio invalida
372Ref de trx del comercio ya fue utilizada
373Ultimos 4 digitos incorrectos
374El ID de requerimiento enviado invalido
375Error General
376Concepto ingresado no habilitado
377Concepto ingresado no habilitado
378Cuenta es incorrecta
379Cuenta no está habilitada
380ALIAS CBU red Banelco es incorrecto
381El pago tiene devoluciones parciales
382Esta operacion no acepta devol. total
383Esta operacion no acepta devol. parcial
384La fecha es invalida
385El estado del pago es invalido
386El Concepto Operacion es invalido
387Estado trx original no acepta devolucion
388Importe devolucion supero monto limite
389No se encontró la trx original
390No es posible devolver una devolución
391Error en comunicación
392Campo DateTimeOriginalTrx invalido
393Autorizacion Original en Proceso
394No permite operar tarjeta de credito
600El codigo de barras es requerido
601El softToken es requerido
602El importe de promoción es invalido
603Original transaction type es requerido
604El numero de referencia bancaria es requerido
605El importe original informado es invalido
606La venta original no tiene promoción aplicada
607El numero de referencia bancaria es incorrecto
608La venta original no permite promoción
609

Clave DNI inválido

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



Âncora
antifraude
antifraude
1.5.2 Códigos de Respuesta de VTOL Server para Antifraude

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

Código

Descripción de respuesta al POS

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


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

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


Código

Descripción

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


Âncora
154_codRespuestaBilleteras
154_codRespuestaBilleteras
1.5.4 Códigos de Respuesta de VTOL Server para Billeteras electrónicas

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

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

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

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

...

Código

...

Descripción

...

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:

500
CódigoDescripción
00APROBADA
00APROBADA
500No se encuentra la transaccion original
501El campo WalletPosTrxId es requerido
502El campo WalletType es requerido
503No esta configurado una Compañia MP
504No esta configurado una Caja MP
505El tipo de billetera es invalido
506El campo WalletPaymentId es requerido
507El campo OriginalDate es requerido
508No es posible devolver una devolucion
509Estado trx original no acepta devolucion
510Importe devolucion supero monto limite
511No se pudo realizar la orden de pago
512La transaccion no posee estado
513El campo posTicket es requerido
514Tiempo expirado. Elija Consultar o Cancelar pago
515Tiempo expirado confirmacion devolucion
516Pago aun no realizado, desea seguir esperando?
517Estado trx original no acepta devolucion
518No se encuentra la devolucion
519Acceso a MP no esta autorizado
520Accion a MP no esta autorizada
521El campo WalletPosTrxId es invalido
522Cancelado
523Estado trx original no acepta devolucion
524Importe invalido para devolucion
525Estado trx original no acepta devolucion
526Compañia MP no permite operar
527Numero devoluciones parciales superados
528El pago es antiguo para ser devuelto
529No es posible devolver una devolucion
530Compañia MP sin dinero para devolver
531Compañia MP sin dinero disponible
532Estado trx original no acepta devolucion
533Devolucion parcial no soportada
534Url de notificacion invalido
535El monto de la transaccion es invalido
536Error general por parte de MP
537No se encuentra la transaccion original
501538El campo WalletPosTrxId es requerido
502El campo WalletType es requerido
503No esta configurado una Compañia MP
504No esta configurado una Caja MP
505El tipo de billetera es invalido
506El campo WalletPaymentId es requerido
507El campo OriginalDate es requerido
508No es posible devolver una devolucion
509Estado trx original no acepta devolucion
510Importe devolucion supero monto limite
511No se pudo realizar la orden de pago
512La transaccion no posee estado
513El campo posTicket es requerido
514Tiempo expirado. Elija Consultar o Cancelar pago
515Tiempo expirado confirmacion devolucion
516Pago aun no realizado, desea seguir esperando?
517Estado trx original no acepta devolucion
518No se encuentra la devolucion
519Acceso a MP no esta autorizado
520Accion a MP no esta autorizada
521El campo WalletPosTrxId es invalido
523Estado trx original no acepta devolucion
524Importe invalido para devolucion
525Estado trx original no acepta devolucion
526Compañia MP no permite operar
527Numero devoluciones parciales superados
528El pago es antiguo para ser devuelto
529No es posible devolver una devolucion
530Compañia MP sin dinero para devolver
531Compañia MP sin dinero disponible
532Estado trx original no acepta devolucion
533Devolucion parcial no soportada
534Url de notificacion invalido
535El monto de la transaccion es invalido
536Error general por parte de MP
537No se encuentra la transaccion original
538El campo WalletPosTrxId es requerido
539Transaccion devuelta
540Pendiente
541Autorizado
542En Progreso
543En mediacion
544Transaccion ya devuelta
545Cancelado
546Contracargo
547No se encontró la trx original
548Error en comunicación
549No existe comunicación con Mercado Pago
550Error al consultar venta original online
552Orden no generada por Prisma
553Pago Rechazado
554Esta operación requiere autorización
555Esta operación requiere autorización
556Pago rechazado, reintente con otro medio de pago
557Pago rechazado, reintente con otro medio de pago
558Pago rechazado, reintente con otro medio de pago
559Pago rechazado, reintente con otro medio de pago
560Pago rechazado, reintente con otro medio de pago
561No fue posible procesar su pago, intente más tarde
562No fue posible procesar su pago, intente más tarde
563No fue posible procesar su pago, intente más tarde
564No fue posible procesar su pago, intente más tarde
565No fue posible procesar su pago, intente más tarde
566La cantidad de cuotas seleccionada es inválida
567La cantidad de cuotas seleccionada es inválida
568Tarjeta de crédito vencida
569Tarjeta de crédito no habilitada
570Fondos insuficientes, reintente otro medio de pago
571Fondos insuficientes, reintente otro medio de pago
572Datos incorrectos, revíselos y reintente
573Datos incorrectos, revíselos y reintente
574No fue posible procesar su pago, intente más tarde
575No fue posible procesar su pago, intente más tarde
576Tarjeta no vigente, reintente otro medio de pago
577Esta operación requiere autorización
578No fue posible procesar su pago, intente más tarde
579No fue posible procesar su pago, intente más tarde
580La cantidad de cuotas seleccionada es inválida
581Datos incorrectos, revíselos y reintente
582Datos incorrectos, revíselos y reintente
583Las cuotas informadas son incorrectas
584Devolucion parcial no soportada539Transaccion devuelta
540Pendiente
541Autorizado
542En Progreso
543En mediacion
544Transaccion ya devuelta
545Cancelado
546Contracargo
547No se encontró la trx original
548Error en comunicación
549No existe comunicación con Mercado Pago
550Error al consultar venta original online
552Orden no generada por Prisma
553Pago Rechazado
554Esta operación requiere autorización
555Esta operación requiere autorización
556Pago rechazado, reintente con otro medio de pago
557Pago rechazado, reintente con otro medio de pago
558Pago rechazado, reintente con otro medio de pago
559Pago rechazado, reintente con otro medio de pago
560Pago rechazado, reintente con otro medio de pago
561No fue posible procesar su pago, intente más tarde
562No fue posible procesar su pago, intente más tarde
563No fue posible procesar su pago, intente más tarde
564No fue posible procesar su pago, intente más tarde
565No fue posible procesar su pago, intente más tarde
566La cantidad de cuotas seleccionada es inválida
567La cantidad de cuotas seleccionada es inválida
568Tarjeta de crédito vencida
569Tarjeta de crédito no habilitada
570Fondos insuficientes, reintente otro medio de pago
571Fondos insuficientes, reintente otro medio de pago
572Datos incorrectos, revíselos y reintente
573Datos incorrectos, revíselos y reintente
574No fue posible procesar su pago, intente más tarde
575No fue posible procesar su pago, intente más tarde
576Tarjeta no vigente, reintente otro medio de pago
577Esta operación requiere autorización
578No fue posible procesar su pago, intente más tarde
579No fue posible procesar su pago, intente más tarde
580La cantidad de cuotas seleccionada es inválida
581Datos incorrectos, revíselos y reintente
582Datos incorrectos, revíselos y reintente
583Las cuotas informadas son incorrectas
584Devolucion parcial no soportada
585

Transacción con CashBack no permitido

586El comercio informado es inválido
587El establecimiento informado es inválido
588El establecimiento no pertenece al comercio
589El punto de venta informado es inválido
590El punto de venta no pertenece al establecimiento
591El tipo de documento es inválido
592Se debe informar el ID de la operación
593Se debe informar un timeStamp
594Se debe informar el traceNumber
595Intención de pago vencida
596Entrega Excede Supera Limite
598Las cuotas del pago ya fueron informadas
602Devolución rechazada
603Devolución no aprobada
604Devolución pendiente de aprobación
650Importe de devolución de cashout invalido
651Importe de cashout invalido
652Medio de pago inválido
654Devolución registrada confirme administrativamente
733

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

734

No es posible cancelar la transacción informada


1.5.4.1 Códigos de respuesta de VTOL Server para Billetera Rappi Payless

CódigoDescripción00APROBADA57TRANSACCION NO PERMITIDA
CódigoDescripción
00APROBADA
57TRANSACCION NO PERMITIDA
500Sucursal no configurada Billetera RappiPayless
503Compañia no configurada Billetera RappiPayless
509Estado trx original no acepta devolucion
510Importe devolucion supero monto limite
533Devolucion parcial no soportada
537Se excedio el tiempo limite para devolver
539Devuelto
544Transaccion ya devuelta
545Cancelado
549No existe comunicación con RappiPayless
553Pago rechazado por diferencias en la orden
585Transacción con CashBack no permitido
586El comercio informado es inválido
587El establecimiento informado es inválido
588El establecimiento no pertenece al comercio
589El punto de venta informado es inválido
590El punto de venta no pertenece al establecimiento
591El tipo de documento es inválido
592Se debe informar el ID de la operación
593Se debe informar un timeStamp
594Se debe informar el traceNumber
595Intención de pago vencida
596Entrega Excede Supera Limite
598Las cuotas del pago ya fueron informadas
602Devolución rechazada
603Devolución no aprobada
604Devolución pendiente de aprobación
650Importe de devolución de cashout invalido
651Importe de cashout invalido
652Medio de pago inválido
654Devolución registrada confirme administrativamente
733

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

734

No es posible cancelar la transacción informada

1.5.4.1 Códigos de respuesta de VTOL Server para Billetera Rappi Payless

Imposible identificar el comercio. Verifique datos
595Intención de pago vencida en Billetera
599Error de validacion
601No se pudo realizar la operación, reintente
602Devolucion rechazada
605La transaccion no se puede anular
606Identificador de transaccion incorrecto
607No se pudo realizar la devolucion
611Código de barras invalido
619No se pudo realizar la cancelación
620Reintente pago por modo offline con código PIN

Âncora
Códigos de respuesta VTOL Server para GoCuotas
Códigos de respuesta VTOL Server para GoCuotas
1.5.4.2 Códigos de respuesta de VTOL Server para Billetera GoCuotas

A continuación, se detallan las respuestas posibles de VTOL Server, cuando se opera con GoCuotas:

Código

Descripción

503Compañia GoCuotas no configurada
601No se pudo crear la orden, reintente operación
623Respuesta GoCuotas inválida, reintente operación
714Orden creada, ingrese el código de verificación
599Error de validación
540Pendiente de pago
553Rechazado
539Devuelto
717Ingrese tarjeta de débito
718Confirma la tarjeta recibida
77ERROR [plan]/CUOTAS
601No se pudo confirmar el código, reintente.
622No se pudo agregar/cambiar la tarjeta, reintente.
603No se pudo realizar el pago, reintente.
549No existe comunicación con GoCuotas
602Devolución rechazada
604No se pudo realizar el pago, reinicie la operación

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

...

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

Código

Descripción

Observaciones

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

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

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

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



Âncora
_Código_de_errores
_Código_de_errores
Âncora
_Toc485222741
_Toc485222741
1.6 Código de errores del CORE

...


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 v110


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

...

Pos.

Descripción

Longitud

Tipo de dato

Detalle

1

PV

2

AN

Identificador de tipo de registro

2

ID Tarjeta

2

AN

ID proveedor VTOL

3

Nombre

40

AN

Nombre proveedor

4

Medio de Pago

20

AN

Código proveedor en POS.

Campo de relación entre POS y VTOL (Opcional)

5

Código de banco

10

AN

Código del banco (Opcional

6Descripción del banco40ANDescripción del banco (Opcional)
7Marca de Tarjeta10AN

Código de la Marca de la tarjeta (Opcional).

Si la tarjeta no tiene marca, no se informa el campo.


Ejemplo

PV:VI;Visa;;
PV:MA;Mastercard;00;DEFAULT;VI
PV:AMVIG;AmexVisa;;7;BANCO DE GALICIA Y BUENOS AIRES S.A.U.;VI
PV:MA;Maestro;;00;DEFAULT;MC
PV:MC;Master Card;;00;DEFAULT;MC
PV:AM;Amex;;00;DEFAULT;AM
PV:DI;Diners;;00;DEFAULT



Tabla Prefijos

Pos

Descripción

Longitud

Tipo de dato

Detalle

1

PF

2

AN

Identificador de tipo de registro

2

Hasta

20

AN

Rango DesdeHasta.

3

Desde

20

AN

Rango HastaDesde.

4

Largo prefijo

2

N

Largo del prefijo.

5

Largo tarjeta

2

N

Largo de la tarjeta.

6

ID Tarjeta

2

AN

ID proveedor VTOL

7

Condición

10

AN

 

8

Largo CVC

2

N

Largo código seguridad.

9

Validar digito

1

N

Valida el digito verificador.

10

Envía Track I

1

N

0/vacío deshabilitado / 1 habilitado / 2 Opcional.

11

Validar vencimiento

1

N

Valida fecha vencimiento.

12

Offline permitido

1

N

Permite operar offline.

13

Offline monto

14

N

Límite para operación Offline.

14

Habilitado

1

N

Prefijo habilitado.

15

Valida fecha efectiva

1

N

Valida fecha emisión o fecha desde.

16

Valida CVC

1

N

0/vacío deshabilitado / 1 habilitado / 2 Opcional.

17

Service code

5

AN

Se suele utilizar en VTOL para diferenciar Visa débito (2) de Visa crédito (0 ó vació)

18

Ingreso manual permitido

1

N

 

19

Chequea boletines

1

N

Valida contra boletines protectivos.

20

Es debito

1

N

Es prefijo de tarjeta de tipo débito.
(0/vacío ó 1)

21

Requiere pin.

1

N

0 deshabilitado / 1 habilitado / 2 Opcional.

22

Valida últimos N números.

2

N

Cantidad de últimos números a validar de la tarjeta. 0 no valida nada.

23

Pide tipo de cuenta.

1

N

Requiere envío tipo de cuenta.
(0 ó 1)

24

Solicita número de cuenta

1

N

Solicita al autorizador el número de cuenta.
(0 ó 1)

25

Cashback

1

N

Habilita la operatoria de Cashback

26

Puntos de Lealtad

1

N

Habilita la acumulación y/o redención de puntos de lealtad.

27

Tarjeta que Encripta punto a punto POS - CA.

1

N

Indica si la tarjeta encripta.
(0 ó 1)

28

Posición de la Master Key

1

N

Indica la posición de la Master Key en los registros del Firmware. Valores posibles:
0: Mastercard y Maestro
1: Visa 1
99: Indica que el Pinpad no tiene registro para la MK. Es el caso de tarjeta Amex.

29

Código de banco

10

AN

Código del banco

30

Permite Fallback

1

N

Visa 1; Mastercard y Maestro 0

...

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

[adviceChipTokens|valor,pinpadResponseCode|valor]


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


Importante: Para operaciones por CHIP siempre se debe enviar el campo 200 (extraData) en el Tercer Mensaje de COMMIT, informando los valores: adviceChipTokens, pinpadResponseCode y pinpadAutCode.

Ejemplo:

Bloco de código
themeRDark
[adviceChipTokens|9F1E08313534393734353682021C009F26086CA64413F38FF76F9F2701809F360200799F100706010A03A08800950580C00080009F3303E0F8C89F34031E03009F3704FE4084CE5F25031801019A032505279F02060000001050009C01008407A00000000310109F0306000000000000,pinpadResponseCode|00,pinpadAutCode|123456]


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.

...

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

ID de Banco

Descripción

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