Versões comparadas

Chave

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

...

Mensajería POS - VTOL





Cambios por revisiones


Fecha

Revisión

Cambios

02/11/2009

1.0

Generación del documento

04/11/2009

1.1

Indicación de campos obligatorios

26/04/2010

1.2

Actualización de gráfico manejo de PINPAD

22/03/2011

1.3

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

03/06/2011

1.4

Agregado de definición de mensaje de cierre de lote

30/05/2012

1.5

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

08/03/2013

1.6

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

21/08/2013

1.7

Agregado de apartado de error del core.

09/09/2013

1.8

Agrego campos EMV en operaciones de Venta, Devolución y anulación. Incorporo mensaje RejectedEMVAdvice y flujo de datos EMV.

15/11/2013

1.9

Agregado de 'Formato Interface POS'

23/12/2013

2.0

Agregado de detalle de los mensajes ServicePayment y VoidServicePayment

13/02/2014

2.1

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

29/05/2014

2.2

Aclaración sobre el uso de pre-autorizaciones.

22/08/2014

2.3

Agregado de campo pinpadAutoCode en Tercer Mensaje y RejectedEMVAdvice.

29/08/2014

2.4

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

11/09/2014

2.5

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

09/12/2014

2.6

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

26/02/2015

2.7

Agregado de nuevos campos ServiceCode y ProviderPosCode.

27/02/2015

2.8

Agregado de nuevos mensajes propios a la funcionalidad Cash Back.

07/08/2015

2.9

Agregado de aclaraciones en el uso de la mensajería

09/09/2015

3.0

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

30/10/2015

3.1

El campo ProviderPosCode para a ser el número 147. Incorporación de campo trxReferenceNumber en las respuestas de VTOL. Corrección de formato esperado en campo 7 - Expiration. El formato correcto es: YYMM.

11/02/2016

3.2

Incorporación del campo 201 additionalMessageData en el requerimiento y respuesta y la posibilidad de incluir el número de Ticket original en una anulación (Campo 17 originalTrxTicketNr)

29/07/2016

3.3

Incorporación del apartado 1.9. Mecanismo en Tiendas Virtuales y del 1.3.13. Chequeo de Listado de Pendientes

19/04/2017

3.4

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

03/05/2017

3.5

Incorporación del apartado 1.3.10 Echo

05/05/2017

3.6

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

06/06/2017

3.7

Actualización de la tabla Prefijo en el apartado Formato Interface POS. Mayor detalle del campo MasterKey Position, incluyendo el valor 99

07/07/2017

3.8

Agregado del campo promocional en Formato Interface POS para indicar que se aplica una promoción sobre un plan de pago

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

14/12/2018 

4.0Incorporación del apartado Antifraude e incorporación de la funcionalidad Antifraude en la mensajería
08/02/20194.1Incorporación del apartado Tokenización e incorporación de la funcionalidad Tokenización en la mensajería
03/04/20194.2Agregado del campo 0 (Compañía) en la mensajería de todos los tipos de transacciones.
28/08201908/20194.3Incorporación de la funcionalidad Billeteras electrónicas en la mensajería.
01/04/20204.4Incorporación de la mensajería para operaciones eCommerce.


Índice


Índice



Âncora
_Toc485222713
_Toc485222713
1. Campos de los mensajes

...

Âncora
_Toc485222725
_Toc485222725
1.4.1 Venta / Pre-autorización / Anulación / Anulación Pre-autorización / Cash Back / Anulación Cash Back


1.4.1.1 Requerimiento


Requerimiento

#

FieldId

Tipo

Obligatorio

Descripción

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

1

store

Alfanumérico

SI

Identificador del sitio originador de la transacción

2

node

Numérico

SI

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

3

server

Alfanumérico

Compatibilidad atrás.

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

4

messageType

Alfanumérico

Compatibilidad atrás.

Tipo de Mensaje:

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

6

cardNumber

Numérico

Obligatorio si es Manual

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

7

expiration

Numérico

Obligatorio si es Manual

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

8

Cvc

Numérico

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

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

9

track2

Alfanumérico

Obligatorio si es MSR

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

10

posInputMode

Alfanumérico

Obligatorio

Modo de Ingreso:

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

11

trxType

Alfanumérico

Obligatorio

Tipo de Transacción:

  • Sale = Compra. Opcionalmente puede acompañarse con una extracción de efectivo (CashBack) cuando se envía el campo monto adicional.
  • PreAuthorization = PreautorizaciónPre-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 PreautorizaciónPre-autorización.
  • VoidRefund = Anulación de devolución
  • CashBack = Extracción de efectivo solamente. NO incluye una Compra.
  • VoidCashBack = Anulación de extracción de efectivo (No incluye una Compra).

12

amount

Importe

Obligatorio

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

13

currencyPosCode

Alfanumérico

Obligatorio

Tipos de Moneda:

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

14

payments

Numérico

Obligatorio

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

15

plan

Alfanumérico

Obligatorio

Plan. 1 caracter de longitud.

17

originalTrxTicketNr

Numérico

Opcional

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

18

referedSale

Numérico

Condicional a tarjeta AMEX

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

22

authorizationCode

Alfanumérico

Condicional a 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 sólo si la transacción se autorizó off-line por teléfono o en una Pre-autorización.

23

authorizationMode

Alfanumérico

Opcional, default = Online

Modo de Autorización:

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

25

dateTime

Numérico

Obligatorio

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

53

paymentCondition

Alfanumérico

Opcional

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

54

additionalAmount

Alfanumérico

Opcional
CASH BACK

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

56

pinblock

Alfanumérico

Condicional a PINPAD

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

57

accountType

Alfanumérico

Condicional a tarjeta de débito

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

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

66

track1

Alfanumérico

Opcional a su lectura

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

70

effectiveDate

Alfanumérico

Opcional AMEX

Fecha efectiva. Se usa para AMEX con formato yyMM

71

checkPendingString

Alfanumérico

Opcional, default = true

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

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

72

creditCardCondition

Alfanumérico

Opcional

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

73

interestAmount

Alfanumérico

Opcional

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

74

requestAccountNumber

Alfanumérico

Opcional, default = 0

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

  • 1 = activado
  • 0 = desactivado

101

differDate

Alfanumérico

Opcional

Fecha diferida. Solo utilizada para AMEX.

102

chipTokens

Alfanumérico

Obligatorio para modo de ingreso Chip

Visa: Criptograma tarjetas EMV
Posnet: Lista de Tags EMV

103

emvEncryptedType

Alfanumérico

Opcional

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

  • D = DES
  • T = 3DES

104

emvEncryptedData

Alfanumérico

Opcional

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

105

cardSequenceNumber

Numérico

Opcional

Numero de secuencia del PAN

106

pinpadLogSerialNumber

Alfanumérico

Opcional

Número de serie lógico del pinpad

107

pinpadFisSerialNumber

Alfanumérico

Opcional

Número de serie Físico del pinpad

108

useEncryptedData

Alfanumérico

Opcional

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

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

118

terminalCapability

Alfanumérico

Opcional

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

130

posPeriod

Numérico

Opcional

Periodo enviado por el POS. Longitud 5

131

turn

Numérico

Opcional

Turno. Longitud 2

132

operatorCode

Alfanumérico

Opcional

Código de operador. Longitud 20

133

operatorName

Alfanumérico

Opcional

Nombre de operador. Longitud 50

134

sellerCode

Alfanumérico

Opcional

Código del vendedor. Longitud 20

135

sellerName

Alfanumérico

Opcional

Nombre del vendedor. Longitud 50

136

attentionMode

Alfanumérico

Opcional

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

137

serviceCode

Numérico

Opcional

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

147

providerPosCode

Alfanumérico

Opcional

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

164

posEncryptedFields

Numérico

Opcional

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

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

168

pinpadApplicationVersion

Alfanumérico

Opcional

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

201

additionalMessageData

Alfanumérico

Opcional

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

261cipherSuiteNuméricoOpcional

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

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

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

264posChannelOriginNuméricoOpcional

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

  • 0: Presencial
  • 1: E-Commerce
  • 2: Pago recurrente
  • 3: IVR
265customerIdAlfanuméricoOpcionalNombre o id de usuario que realizó la transacción
266cardHolderNameAlfanuméricoOpcional
Nombre del tarjetahabiente
270posTicketAlfanuméricoOpcionalInformación del ticket en formato xml y posteriormente transformado en Base 64. Ver sección Estructura del campo posTicket
280290usercustomerIpAlfanuméricoOpcionalNombre de usuario que realizó IP de origen de donde se efectuó la transacción
281291userIpcustomerDocTypeAlfanuméricoOpcionalIP de origen de donde se efectuó Tipo de documento del cliente que realizó la transacción.

...

157

...

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
customerDoc

...

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

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

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

...

Propiedad

...

Tipo de dato

...

Descripción

...

Requerido

...

seq

...

Entero positivo

...

Número identificador único del elemento dentro de la transacción.

...

AlfanuméricoOpcionalNúmero de documento del cliente que realizó la transacción.
292customerFirstNameAlfanuméricoOpcionalNombre del cliente registrado en el e-commerce que realizó la transacción.
293customerLastNameAlfanuméricoOpcionalApellido del cliente registrado en el e-commmerce que realizó la transacción.
294cardHolderBirthdayAlfanuméricoOpcional
Fecha de nacimiento del titular de la tarjeta. Formato YYYYMMDD.
295cardHolderDocTypeAlfanuméricoOpcional
Tipo de documento del titular de la tarjeta.
296cardHolderDocNumberAlfanuméricoOpcional
Número de documento del titular de la tarjeta.
297cardHolderAddressStreetAlfanuméricoOpcionalCalle de entrega del resumen del titular de la tarjeta.
298cardHolderAddressNumberAlfanuméricoOpcional
Número de Puerta de entrega del resumen del titular de la tarjeta.
299cardHolderZipCodeAlfanuméricoOpcionalCódigo postal de entrega del resumen del titular de la tarjeta.
305cardHolderAddressComplementAlfanuméricoOpcionalComplemento de la dirección. Piso / departamento de entrega de resumen del titular de la tarjeta.
306cardIssuingBankAlfanuméricoOpcionalBanco emisor de la tarjeta. Longitud máxima 20.
307cardBrandAlfanuméricoOpcionalMarca de la tarjeta. Longitud máxima 20.


Âncora
posticket
posticket
1.4.1.1.1 Estructura del campo posTicket

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

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

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


Propiedad

Tipo de dato

Descripción

Requerido

seq

Entero positivo

Número identificador único del elemento dentro de la transacción.


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

"-"

level4brand

Alfanumérico

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

No

"-"

descriptionAlfanumérico

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

...

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


1.4.1.2 Respuesta


Respuesta

#

FieldId

Tipo

Descripción

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

1

store

Alfanumérico

Identificador del sitio originador de la transacción

2

node

Numérico

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

22

authorizationCode

Alfanumérico

Código de autorización generado por el centro autorizador para la transacción.

23

authorizationMode

Alfanumérico

Modo de Autorización:

  • Online = La autorización fue realizada por el Centro Autorizador.
  • Offhost = La autorización fue realizada internamente por VTOL.
  • Offline = La autorización fue realizada localmente por el POS.

24

lastTrxId

Numérico

Id de transacción. En caso que el Campo 26 sea TrxIsPending, contendrá el trxId de la transacción pendiente.

25

dateTime

Numérico

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

26

responseCode

Alfanumérico

Puede contener uno de los siguientes valores:

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

27

isoCode

Numérico

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

28

responseMessage

Alfanumérico

Mensaje de la Respuesta ISO-8583

29

serialNumber

Numérico

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

30

businessNumber

Numérico

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

31

lotNumber

Numérico

Número de lote en el que se registró la transacción

32

ticket

Numérico

Número de Ticket correspondiente a la transacción. 4 dígitos como máximo.

33

creditCardIssuerName

Alfanumérico

Nombre del Centro emisor de la tarjeta

34

hostName

Alfanumérico

Nombre del canal por el cual se autorizó la tarjeta.

35

errorDescription

Alfanumérico

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

42

lotDefinitionId

Numérico

Identificador de la definición de lote.

58

workingKey

Alfanumérico

VTOL devuelve este campo tal como lo entrega el CA. Representa la llave que el PINPAD deberá usar para generar el PINBLOCK en la próxima transacción.

68

rrn

Numérico

Reference referral number.

75

accountNumber

Alfanumérico

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

81

responseAuth

Alfanumérico

Mensaje de repuesta para ser mostrado en el diplay del POS donde se indican promociones.
También es utilizado en la operación de Cash Back, cuando el autorizador responde con código de respuesta 98. En este campo se informará el importe máximo que puede solicitarse.

82

softwareVersion

Alfanumérico

Versión de la aplicación.

102

chipTokens

Alfanumérico

En las respuestas hacia el POS se actualiza con el valor que envió el CA.

110

requeredAdvice

Alfanumérico

Con valor true si se requiere que se envíe el advice para la autorización. En este caso la terminal lógica queda en estado AdvicePending.

130

posPeriod

Numérico

Periodo enviado por el POS. Longitud 5

131

turn

Numérico

Turno. Longitud 2

132

operatorCode

Alfanumérico

Código de operador. Longitud 20

133

operatorName

Alfanumérico

Nombre de operador. Longitud 50

134

sellerCode

Alfanumérico

Código del vendedor. Longitud 20

135

sellerName

Alfanumérico

Nombre del vendedor. Longitud 50

136

attentionMode

Alfanumérico

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

165

publicKey

Alfanumérico

Clave Pública utilizada en la encripción punto a punto POS - VTOL. Viaja cuando la clave expiró y se generó una nueva; o bien, cuando es necesario sincronizar claves entre POS y VTOL.

166

trxReferenceNumber

Numérico

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

201

additionalMessageData

Alfanumérico

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

263vtolTokenAlfanuméricoCuando se efectúa una transacción Sale, VoidSale, Refund o VoidRefund tokenizada, se puede recibir el Token VTOL
267vtolTokenExpireNumérico

Fecha y hora de expiración del Token VTOL en formato YYYYMMDD

...

308

vteValidation

Alfanumérico

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

...

.

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

  • cardHolderDocType
  • cardHolderDocNumber
  • cardHolderAddressNumber
  • cardHolderBirthday

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

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

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


1.4.1.3 Pre-autorización

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

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


1.4.1.4 Anulación de Pre-autorización

...

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

...

Âncora
_Toc288557357
_Toc288557357
Âncora
_Toc485222736
_Toc485222736
Âncora
_Toc145327444
_Toc145327444
1.4.12 Tercer Mensaje

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


1.4.12.1 Requerimiento


#

FieldId

Tipo

Descripción

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

1

store

Alfanumérico

Identificador del sitio originador de la transacción

2

node

Numérico

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

3

server

Alfanumérico

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

4

messageType

Alfanumérico

Tipo de Mensaje:

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

11

trxType

Alfanumérico

Tipo de Transacción:

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

19

lastTrxAction

Alfanumérico

Acción a realizar sobre la Transacción:

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

24

lastTrxId

Numérico

Id de transacción a confirmar / reversar.

25

dateTime

Numérico

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

200

EMV extra data

Alfanumérico

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

 

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

Formato del campo:

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

...

1.4.16.1 Requerimiento


Informações

Referencias

X = Obligatorio
O = Opcional
-   = No requerido


Número

Nombre del campo

Tipo de dato

SalePEI

RefundPEIQueryPEI

Descripción

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

Tipo de Mensaje:

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

8

Cvc

Numérico

X

X-

Código de seguridad de la tarjeta

9

track2

Alfanumérico

X

XX

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

10

inputMode

Alfanumérico

X

XX

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

  • MSR – Leída por banda magnética

11

trxType

Alfanumérico

X

XX

Tipo de Transacción:

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

12

amount

Importe

X

X-

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

13

currencyPosCode

Alfanumérico

X

X-

Tipos de Moneda:

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

25

dateTime

Numérico

X

XX

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

66track1AlfanuméricoXXXTrack1 de la tarjeta entero (se envía todo el contenido del track1 en este campo)
71checkPendingStringAlfanumérico

O

Default = true

O

Default = true

O

Default = true

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

  • True: activa chequeo de pendientes.
  • False: desactiva chequeo de pendientes.
153idOperationPEIAlfanumérico-X-Identificador de la operación PEI de pago que se desea devolver
155cbuAlfanumérico-O-CBU de la cuenta destino de la devolución asociada con la tarjeta Banelco. Si el dato se envía, el valor es validado por Link
156cbuAliasAlfanumérico-O-Alias del CBU de la cuenta destino de la devolución asociada con la tarjeta Banelco. Si el dato se envía, el valor es validado por Link
157customerDocAlfanumérico

X

O-Número de documento del titular de la tarjeta

158

lastFourDigits

Numérico

X

X-

Últimos 4 dígitos de la tarjeta. La solicitud de la validación de los últimos 4 dígitos de la tarjeta es configurable por prefijo

161operationConceptNuméricoO--

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

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

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

  • 1 = activado (valor por defecto)
  • 0 = desactivado
173dateTimeOriginalTrxNumérico--XFecha y hora de realización de la transacción de venta o devolución que se desea consultar en formato YYYYMMDDHHMMSS. Se debe enviar el valor del campo 25 de la transacción a consultar

...

1.4.16.2 Respuesta


Informações

Referencias

X = Obligatorio
O = Opcional
-   = No requerido


Número

Nombre del campo

Tipo de dato

SalePEIRefundPEIQueryPEI

Descripción

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

25

dateTime

Numérico

XXX

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

26

responseCode

Alfanumérico

XXX

Puede contener uno de los siguientes valores:

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

27

isoCode

Numérico

XXX

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

28

responseMessage

Alfanumérico

XXX

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

35

errorDescription

Alfanumérico

XXX

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

153

idOperationPEI

Alfanumérico

XXX

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

154idOperationOrigenPEIAlfanumérico-XOIdentificador de la operación PEI de origen con la cual se solicitó la devolución.
170idCommercePEIAlfanuméricoXXXIdentificador PEI de compañía
171idBranchPEIAlfanuméricoXXXIdentificador PEI de local
172idTerminalPEIAlfanuméricoXXXIdentificador PEI de terminal
174originalTrxStatusNumérico--O

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

Puede contener uno de los siguientes valores:

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

...

Número

Nombre del campo

Tipo de dato

SaleWallet

RefundWallet
QuerySaleWallet

Descripción

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

Tipo de Mensaje:

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

11

trxType

Alfanumérico

X

XX

Tipo de Transacción:

  • SaleWallet = Compra con billetera electrónica
  • RefundWallet = Devolución de compra realizada con billetera electrónica
  • QuerySaleWallet = Consulta de transacción de compra realizada con billetera electrónica

12

amount

Importe

X

X-

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

Nota: El importe debe ser el número correspondiente a la moneda informada

13

currencyPosCode

Alfanumérico

X

X-

Tipos de moneda:

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

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

Nota: Para Todo Pago la moneda siempre es $ -pesos argentinos-

Importante: Tener en cuenta que operando con Mercado Pago siempre debe coincidir el país de la cuenta vendedor con el país de la cuenta comprador

14paymentsNumérico--OCantidad de cuotas por las cuales se realizará el pago. 2 dígitos como máximo 
Si es sin cuotas, el valor por defecto es 1
15planAlfanumérico--OPlan. 1 caracter de longitud
16originalDateNumérico-XX

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

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

25

dateTime

Numérico

X

XX

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

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

O

Default = true

O

Default = true

O

Default = true

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

  • True: activa chequeo de pendientes.
  • False: desactiva chequeo de pendientes.
147providerPosCodeAlfanumérico--OProveedor / tarjeta seleccionada manualmente de la lista devuelta por VTOL. Por Ejemplo: Si el saleWallet retorna la lista {VI, EL}, en el querySaleWallet se debe enviar el valor seleccionado entre las dos opciones VI o EL.
268walletPosTrxIdAlfanuméricoX-O

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

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

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

269walletTypeNuméricoXXX

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

1: Mercado Pago
2: Todo Pago

270posTicketBase 64X--

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

271walletPaymentIdAlfanumérico

-

XO

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

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


Ejemplo

Request to VTOL (SaleWallet):

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

Request to VTOL (RefundWallet):

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

Request to VTOL (QuerySaleWallet):

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

...

Response from VTOL (SaleWallet):

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

Response from VTOL (RefundWallet):

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

Response from VTOL (QuerySaleWallet):

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


1.4.19 Operaciones Ecommerce

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


Las operaciones soportadas en VTOL Server para eCommerce son:


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

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


Requerimiento

Nro

Campo

Tipo

Sale

Capture

PreAuth

VoidPreAuth

Descripción

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

1

store

Alfanumérico

XXXX

Identificador del sitio originador de la transacción

3

server

Alfanumérico

XXXX

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

4

messageType

Alfanumérico

XXXX

Tipo de Mensaje:

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

6

cardNumber

Numérico

X-X-

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

7

expirationDate

Numérico

X-X-

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

8

cvc

Numérico

X-X-

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

10

inputMode

Alfanumérico

XXXX

Modo de Ingreso de la tarjeta:

3 - E-Commerce

11

trxType

Alfanumérico

XXXX

Tipo de Transacción:

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

12

amount

Importe

XXXX

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

13

currencyPosCode

Alfanumérico

XXXX

Tipos de Moneda:

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

14

payments

Numérico

XXXX

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

15

plan

Alfanumérico

XXXX

Plan. 1 caracter de longitud.

17

originalTrxTicketNr

Numérico

---X

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

Obligatorio para devoluciones.

22

authorizationCode

Alfanumérico

-X--

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

Obligatorio para Captura.

23

authorizationMode

Alfanumérico

XXXX

Modo de Autorización:

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

25

dateTime

Numérico

XXXX

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

53

paymentCondition

Alfanumérico

O-O-

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

73

interestAmount

Alfanumérico

O-O-

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

118terminalCapabilityAlfanuméricoXXXX

Capacidad de captura. Valor a enviar:

  • 1 = Manual

147

providerPosCode

Alfanumérico

O-O-

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

167originalTrxReferenceNumberAlfanuméricoOXOX

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

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

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

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

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

  • 0: Presencial
  • 1: E-Commerce
  • 2: Pago recurrente
  • 3: IVR
266cardHolderNameAlfanuméricoXOXONombre del tarjetahabiente
270posTicketAlfanuméricoOOOOInformación del ticket en formato xml y posteriormente transformado en Base 64. Ver sección Estructura del campo posTicket
265customerIdAlfanuméricoOOOONombre de usuario que realizó la transacción
290customerIpAlfanuméricoOOOOIP de origen de donde se efectuó la transacción
291customerDocTypeAlfanuméricoOOOOTipo de documento del cliente que realizó la transacción.
157customerDocAlfanuméricoOOOONúmero de documento del cliente que realizó la transacción.
292customerFirstNameAlfanuméricoOOOONombre del cliente registrado en el e-commerce que realizó la transacción.
293customerLastNameAlfanuméricoOOOOApellido del cliente registrado en el e-commmerce que realizó la transacción.
294cardHolderBirthdayAlfanuméricoXXXXFecha de nacimiento del titular de la tarjeta. Formato YYYYMMDD.
295cardHolderDocTypeAlfanuméricoXXXXTipo de documento del titular de la tarjeta.
296cardHolderDocNumberAlfanuméricoXXXXNúmero de documento del titular de la tarjeta.
297cardHolderAddressStreetAlfanuméricoOOOOCalle de entrega del resumen del titular de la tarjeta.
298cardHolderAddressNumberAlfanuméricoXXOONúmero de Puerta de entrega del resumen del titular de la tarjeta.
299cardHolderZipCodeAlfanuméricoOOOOCódigo postal de entrega del resumen del titular de la tarjeta.
305cardHolderAddressComplementAlfanuméricoOOOOComplemento de la dirección. Piso / departamento de entrega de resumen del titular de la tarjeta.
306cardIssuingBankAlfanuméricoOOOOBanco emisor de la tarjeta. Longitud máxima 20.
307cardBrandAlfanuméricoOOOOMarca de la tarjeta. Longitud máxima 20.


Respuesta

Nro

Campo

Tipo

Descripción

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

1

store

Alfanumérico

Identificador del sitio originador de la transacción

2

node

Numérico

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

22

authorizationCode

Alfanumérico

Código de autorización generado por el centro autorizador para la transacción.

23

authorizationMode

Alfanumérico

Modo de Autorización:

  • Online = La autorización fue realizada por el Centro Autorizador.
  • Offhost = La autorización fue realizada internamente por VTOL.
  • Offline = La autorización fue realizada localmente por el POS.

24

lastTrxId

Numérico

Id de transacción. En caso que el Campo 26 sea TrxIsPending, contendrá el trxId de la transacción pendiente.

25

dateTime

Numérico

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

26

responseCode

Alfanumérico

Puede contener uno de los siguientes valores:

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

27

isoCode

Numérico

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

28

responseMessage

Alfanumérico

Mensaje de la Respuesta ISO-8583

29

serialNumber

Numérico

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

30

businessNumber

Numérico

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

31

lotNumber

Numérico

Número de lote en el que se registró la transacción

32

ticket

Numérico

Número de Ticket correspondiente a la transacción. 4 dígitos como máximo.

33

creditCardIssuerName

Alfanumérico

Nombre del Centro emisor de la tarjeta

34

hostName

Alfanumérico

Nombre del canal por el cual se autorizó la tarjeta.

35

errorDescription

Alfanumérico

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

42

lotDefinitionId

Numérico

Identificador de la definición de lote.

75

accountNumber

Alfanumérico

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

166

trxReferenceNumber

Numérico

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

201

additionalMessageData

Alfanumérico

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



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

...

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


Â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, con una breve descripción de cada una:

Código

Descripción

601Fraude – Val BlackList602

de respuesta al POS

Descripción del módulo antifraude
801Tarjeta no autorizadaFraude por validación de BlackList
802Tarjeta no autorizadaPosible Fraude
por BlackList
803
603
Operación no autorizadaFraude
por Velocity Check
604
804Operación no autorizadaPosible fraude
por Velocity Check
805
605
Operación no autorizadaError
val
en validación concurrente, posible fraude
606Error val velocitycheck, posible fraude607Error gral validación de Antifraude610
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
req.
requerimiento


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

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


Código

Descripción

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

...

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

adviceChipTokens


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

...

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

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

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

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

Las reglas de antifraude disponibles son las siguientes:

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

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

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

  • Blacklist:
    • cardNumber (número de tarjeta)
  • Velocity checks:
    • posChannelOrigin (canal de origen de la transacción)
    • cardNumber (número de tarjeta)
    • user customerId (nombre o id de usuario o cliente informadoque efectuó la transacción)
    • userIp customerIp (IP de usuariode origen de donde se efectuó la transacción)
    • cardHolderName (titular de tarjeta)
    • vtolToken (token VTOL)
    • posTicket (ticket con los items adquiridos)

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


1.13 Tokenización

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

...