Versões comparadas

Versão antiga 23

changes.mady.by.user Andrea Estefania Ufre Bracho

Gravado em

comparado com

Nova versão 24

changes.mady.by.user Andrea Estefania Ufre Bracho

Gravado em

Chave

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

...

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


Expandir
titleExpandir revisiones


Fecha

Revisión

Cambios – Motivo

06/01/2014

1.0

Creación del documento

17/08/2015

1.1

Definición de librería como servicio. Explicación de integración

23/10/2015

1.2

Agregado de Operación Procesar Mensaje Crédito Débito. Incorporación de identificador único de transacción en VTOL Server, campo: 166-trxReferenceNumber

09/11/2015

1.3

Agregado de campo 1102–Proveedor seleccionado en mensaje Procesar Operación con Tarjeta

13/05/2016

1.4

Agregado de campo 137–ConfVersion en GetConfiguration, 10–inputMode en Sale/VoidSale/Etc y 1010–currentSessionId en el mensaje Crear sesión

16/05/2016

1.5

Revisión del documento

06/06/2016

1.6

Agregado del valor FORCED_CLOSE en el campo 1008–closeSessionAction del mensaje Cerrar Sesión

14/07/2016

1.7

Agregados los tipos de transacciones ServicePayment y VoidServicePayment

18/08/2016

1.8

Agregado del anexo "Mecanismo de Autorización Telefónica"

15/09/2016

1.9

Agregado de campo 57 - Tipo de Cuenta en la respuesta al POS para el procesamiento de operación con tarjeta.

19/09/2016

1.10

Se modifica la condición del campo 1113 – cardIsDebit.

21/09/2016

1.11

Posibilidad de recibir desde el POS, el valor que indica la capacidad de captura de la terminal.

23/09/2016

1.12

Agregado del tipo de operación "Cancelar Lectura de Tarjeta"

06/10/2016

1.13

Se incorpora definición de timeout de EMVKIT.
Se eliminan los campos: Store y Node de los mensajes: Leer Datos de la Tarjeta - Cancelar Lectura de Tarjeta - Procesar Operación con Tarjeta - Procesar Mensaje Crédito Debito - Obtener Configuración de POS - Cerrar Sesión

05/04/2017

1.14

Agregado de propiedad approveInSecondInstance en sección de Configuración de PINPAD

16/05/2017

1.15

Modificación del apartado Mecanismo de Autorización Telefónica

17/05/2017

1.16

Agregado del valor MSR Chip en campo inputMode

30/05/2017

1.17

Agregado del apartado "Circuito Operativo de la EMVKIT"

06/06/2017

1.18

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

1.19

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

20/07/2017

1.20

Incorporación del campo opcional 1025 – transactionalControl en la operación "Crear Sesión"
Incorporación de campo 24 - lastTrxId en operación "Leer Datos de la Tarjeta"
Agregado del anexo "Control Transaccional"

27/07/2017

1.21

Modificación del apartado "Pre requisitos"
Incorporación del apartado "Configuración de enlace con VTOL"

02/08/2017

1.22

Agregación de campo 22 – authorizationCode en el requerimiento de la operación "Leer Datos de la Tarjeta"
Eliminación de campo 22 – authorizationCode en el requerimiento de la operación "Procesar Operación con Tarjeta"

06/10/2017

1.23

Actualización de la estructura y numeración del documento
Agregación del campo dateTime como valor requerido en los requerimientos de "Procesar Operación con Tarjeta" y "Procesar Mensaje Crédito Débito"
Actualización del anexo "Timeout de la EMVKIT"

14/11/2017

1.24

Incorporación del apartado "Instalación"
Actualización del apartado "Configuración"

01/02/2018

1.25

Aclaración sobre requerimiento de software

23/04/20181.26

Revisión general del documento.

Agregado de apartado Pagos Parciales.

13/06/20181.27Agregado de procesamiento de tarjetas de empleados
12/07/20181.28Agregado de campos 6 - cardNumber, 9 - track2, 66 - track1 y 145 - exceptionBinName en la respuesta de la operación "Procesar Operación con Tarjeta"
06/08/20181.29Incorporación de la funcionalidad PEI en la mensajería
17/08/20181.30Agregado de campo 1104 - prefixesList en la respuesta de la operación "Leer Datos de la Tarjeta"
14/01/20191.31Incorporación de las funcionalidades de impresión de vouchers en la mensajería
25/01/20191.32

Incorporación de la mensajería PEI en las operatorias de "Leer datos de Tarjeta" y "Procesar Operación con Tarjeta"

Incorporación de la mensajería QueryPEI con PinPad

15/02/20191.33Incorporación de la funcionalidad Billeteras Electrónicas QR (Mercado Pago y Todo Pago)
03/04/20191.34Agregado del campo 0 (compañía) en todos los tipos de transacciones.
17/05/20191.35Incorporación de la funcionalidad Cuenta DNI y Promociones PEI.
20/05/20191.36Incorporación de apartado de compatibilidad con VTOL Server.
02/08/20191.37Incorporación de funcionalidad de Billeteras electrónicas con manejo de cuotas.
08/08/20191.38Incorporación de funcionalidad Contactless con pinpad de First Data.
09/08/20191.39Incorporación de apartado para integrar operaciones con tarjetas Contactless.
24/10/20191.40Agregado del campo 1138 (emvData) en la operatoria "Procesar Operación con Tarjeta". Los datos de este campo retornan al POS para ser impresos en el ticket.
25/11/20191.41Agregado de anexo 6.10 Vouchers con la especificación de los campos de los comprobantes según los Autorizadores
27/12/20191.42Actualización del apartado Procedimiento de Instalación
06/01/20201.43Incorporación de funcionalidad Contactless con pinpad de Prisma.
10/03/20201.44Incorporación de mensaje de Sincronización de transacciones entre EMVKit y el POS.
29/04/20201.45Incorporación de la carpeta doc a la instalación
30/07/20201.46Incorporación de funcionalidad de Billeteras Mercado Pago con retiro de efectivo.
22/09/20201.47Se actualiza el campo 54 (additionalAmount) como tipo de dato Importe, en la mensajería de Billeteras electrónicas.
26/11/20201.48Agregado del campo Descripción en Configuración de POS para indicar la descripción sobre un plan de pago.
11/12/20201.49Incorporación de funcionalidad QR Adquiriente.
16/12/20201.50Incorporación del campo afApplicationCondition para validar la aplicación de reglas antifraudes por el módulo AF de VTOL.
05/03/20211.51Se actualiza el nombre y la descripción del campo 406 en la respuesta de la mensajería de QR Adquiriente.
13/04/20211.52Incorporación de mensaje para Consultar Bines de Excepción
05/05/20211.53Incorporación de mensaje para Consultar tarjetas de Fidelidad
11/05/20211.54Se quitan las referencias de la billetera Todo Pago, ya que dicha Billetera está incluida dentro de la funcionalidad "QR Adquiriente Prisma".
19/05/20211.55Incorporación de mensajería para Billetera Yacaré. Se incluye dentro del apartado "J. Procesar mensaje Billeteras Electrónicas"
24/06/20211.56Incorporación de Operaciones Contactless con doble interacción.
23/08/20211.57En Billetera QR Adquiriente, en el campo WalletType se diferencian por id las billeteras Bimo, Modo y Todo Pago. Incorporación disponible a partir de la versión 3.8.0.12b de VTOL Server.
01/10/20211.58Incorporación de mensajería para Billetera Plus Pagos. Se incluye dentro del apartado "J. Procesar mensaje Billeteras Electrónicas"
25/01/20221.59Incorporación de mensajería para QR Adquiriente Fiserv. Se incluye dentro del apartado "P. Procesar mensaje QR Adquiriente Fiserv".
03/03/20221.60Incorporación de mensajería para Operaciones con PayStore. Se incluye dentro del apartado "T. Procesar mensaje PayStore".
16/03/20221.61Agregado del campo Marca de tarjeta en el "Formato Configuración POS", dentro de la tabla "Provider".
06/05/20221.62

Incorporación de mensajería para Billetera Rappi Payless. Se incluye dentro del apartado "J. Procesar mensaje Billeteras Electrónicas"

11/11/20221.63

Incorporación de mensajería para Operaciones con Ationet. Se incluye el apartado "U. Procesar mensaje Ationet"

04/12/20231.64

Cambios incorporados en EMVKIT en situaciones de rechazo en tercera instancia.

19/12/20231.65

Se incluye en el apartado "P. Procesar mensaje QR Adquiriente Fiserv" la mensajería de la operación RefundWalet RefundWallet y se actualizan los diagramas para el pago tarjeta y pago con saldo en cuenta.



...

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

Flujo y Diagrama de secuencia del "Pago con Tarjeta" (una interacción). Finaliza el flujo con un cerrar sesión (CLOSE)

Informações
titleImportante:

El proceso se puede realizar en una interacción únicamente si el POS envía en el SaleWallet el campo 147 "provider", luego VTOL deberá validar el BIN y el provider enviado desde el POS. Si la validación es correcta, se finaliza el flujo enviando el cerrar sesión (CLOSE) por el POS.

A continuación, se define el flujo de la operación:

  1. El POS envía un SaleWallet con el

...

  1. ammount (campo 12), paymments (campo 14) y el provider (campo 147).
  2. VTOL le envía a Fiserv la solicitud de compra con billetera digital, enviado el message Code 0200 y el processing code 0060031.
  3. Fiserv responde con la información del código QR mediante el message code 9600 y el  processing code 940400 y VTOL confirma la recepción del QR con el código de mensaje 9610.
  4. VTOL envía el código QR en el campo 410 "QRCode" y luego se despliega en el pinpad el QR dinámico para ser escaneado por la billetera virtual del cliente.
  5. El cliente escanea el QR y selecciona la Tarjeta para confirmar el pago.
  6. VTOL responde al POS el código 657

...

  1. "QR recibido, consulte el procesamiento del pago

...

  1. ".
  2. VTOL valida el BIN y compara con el provider (campo 147) enviado por el POS, luego le envía a Fiserv la respuesta con los datos para autorizar el pago.
  3. Fiserv autoriza el pago y le envía a VTOL la respuesta con los datos de la solicitud (message code 0210).
  4. El POS envía un

...

  1. QueryWallet

...

  1. para obtener los datos del pago.
    1. Si el

...

    1. pago está aprobado, VTOL le responde al POS el código 00 "Aprobado"
  2. El POS confirma la operación enviando un Cierre de sesión en estado CLOSE.
  3. VTOL envía la confirmación de la compra (message code 0202) y Fiserv responde con el código 0212.
  4. Finaliza el flujo.

Image Added



Flujo y Diagrama de secuencia del "Pago con Tarjeta"

Image Removed

Flujo del Pago con saldo en cuenta:

...

(una interacción). Finaliza el flujo con un cerrar sesión (CANCEL)

En este flujo se presenta un error en VTOL al validar el BIN y al comparar el provider (campo 147) enviado por el POS. Por este motivo, el flujo finaliza con un cerrar sesión (CANCEL). A continuación, se define el flujo de la operación:

  1. El POS envía un SaleWallet con el ammount (campo 12), paymments (campo 14) y el provider (campo 147).
  2. VTOL le envía a Fiserv la solicitud de compra con billetera digital, enviado el message Code 0200 y el processing code 0060031.
  3. Fiserv responde con la información del código QR mediante el message code 9600 y el  processing code 940400 y VTOL confirma la recepción del QR con el código de mensaje 9610.
  4. VTOL envía el código QR en el campo 410 "QRCode" y luego se despliega en el pinpad el QR dinámico para ser escaneado por la billetera virtual del cliente.
  5. El cliente escanea el QR y selecciona la Tarjeta para confirmar el pago.
  6. VTOL responde al POS el código 657 "QR recibido, consulte el procesamiento del pago".
  7. Error en VTOL al validar el BIN y comparar con el provider (campo 147) enviado por el POS, luego VTOL le envía a Fiserv la solicitud de Cancel (message code 0420).
  8. Fiserv responde la solicitud del cancel (message code 0430)
  9. El POS envía un QueryWallet para obtener los datos del pago. VTOL responde el código 553 "Pago rechazado".
  10. El POS cancela la operación enviando un cierre de sesión en estado CANCEL.
  11. Finaliza el flujo.

Image Added



Aviso
titleNota:

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.


Flujo del "Pago con Tarjeta" (dos interacciones)

  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 657 (QR recibido, consulte el procesamiento del 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)
    2. Si el pago aún no se ha realizado, VTOL le responde al POS con el código 516
    8. “Pago aún no realizado, Consulte o Cancele el pago”
    1. "Pago aún no realizado".
  9. El POS envía un nuevo QueryWallet para consultar el estado del pago. Si el pago está autorizado, VTOL responde con los datos del pago y le envía al POS el código 00 "Aprobado".
  10. El POS confirma la operación enviando un Cierre de sesión en estado CLOSE.
  11. VTOL envía la confirmación de la compra (message code 0202) y Fiserv responde con el código 0212.
  12. Finaliza el flujo.


Diagrama de secuencia del "Pago con Tarjeta" (dos interacciones)

Image Added



Flujo del Pago con dinero en cuenta:

  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 Cuenta para confirmar el pago.
  4. VTOL responde al POS el código 657 (QR recibido, consulte el procesamiento del pago)
  5. El POS envía un QueryWallet para obtener los datos del pago.
    1. Si el pago se realizó, VTOL le responde al POS los datos del pago y el código 00 “Aprobado”.
  6. El POS confirma la operación enviando un Cierre de sesión en estado CLOSE.
  7. VTOL envía a Fiserv la confirmación y Fiserv responde el código 0212.
  8. Finaliza el flujo.

Diagrama de secuencia del "Pago con saldo dinero en cuenta"

Image RemovedImage Added


A continuación, se detallan 3 flujos alternativos del Diagrama Pago con saldo dinero en cuenta:

a._ La caja desea cancelar el pago con saldo en cuenta y NO es permitido:

Si la caja desea enviar un reverso de un pago con saldo dinero en cuenta, la caja le deberá enviar primero a VTOL un QueryWallet con el campo 420 "precancel" en valor true, el cual indica que es una consulta previa para ejecutar un cancel. Es , es decir, no se puede enviar un reverso directamente.

Si la respuesta de la QueryWallet que tiene el precancel activado en true informa el pago Aprobado (00), entonces se le informa el POS que NO se puede cancelar el pago y luego el POS envía el cerrar sesión (CLOSE).  Nota: en este escenario se puede proceder con la devolución del pago ya que se encuentra aprobado.

En el diagrama de secuencia se encuentra resaltado en rojo el resumen del flujo de este escenario:

Image RemovedImage Added



b._ La caja desea cancelar el pago con saldo en cuenta y SI es permitido

Si la caja desea enviar un reverso de un pago con saldo dinero en cuenta, la caja le deberá enviar primero a VTOL un QueryWallet con el campo 420 "precancel" en valor true, el cual indica que es una consulta previa para ejecutar un cancel. Es decir, no se puede enviar un reverso directamente.

Si la respuesta de la QueryWallet que tiene el precancel activado se le informa al POS que el pago aún no está Aprobado (código 516) le permite al POS realizar la acción de cerrar sesión (CANCEL)

En el diagrama de secuencia se encuentra resaltado en azul el resumen del flujo de este escenario:

Image Removed

c._ Error en la comunicación entre Fiserv y VTOL.

VTOL no recibe información de Fiserv acerca del pago en el tiempo definido, por este motivo, VTOL le envía un reverso a Fiserv el cual responde con el código B6 "No se puede realizar el reverso del pago porque está autorizado".

A continuación, se especifica el flujo:

...

, es decir, no se puede enviar un reverso directamente.

Si la respuesta de la QueryWallet que tiene el precancel en true se le informa al POS que el pago aún no está Aprobado (código 516) le permite al POS realizar la acción de cerrar sesión (CANCEL)

En el diagrama de secuencia se encuentra resaltado en azul el resumen del flujo de este escenario:

Image Added

c._ Error en la comunicación entre Fiserv y VTOL.

Si VTOL no recibe información de Fiserv acerca del pago en el tiempo definido, VTOL le envía un reverso a Fiserv al cual le responde con el código B6 "No se puede realizar el reverso del pago porque está autorizado".

A continuación, se especifica el flujo:

  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 Cuenta y confirma el pago.
  4. VTOL responde al POS el código 657 (TQR recibido, consulte el procesamiento del pago).
  5. El POS envía un QueryWallet para obtener los datos del pago. El pago aún no se ha realizado, por lo cual, VTOL responde con el código 516 “Pago aún no realizado, Consulte o Cancele el pago”.
  6. Fiserv autoriza el pago, pero hay un error en la comunicación, por este motivo, Fiserv no le puede enviar a VTOL la respuesta del pago.
  7. VTOL le envía la solicitud de reverso a Fiserv, debido a que se excede el tiempo establecido para recibir los datos del pago.
  8. VTOL recibe la respuesta de Fiserv con el código B6 “No se puede realizar el reverso del pago porque está autorizado".
  9. El POS envía un QueryWallet y VTOL le consulta a Fiserv por el pago pendiente. Fiserv le responde a VTOL los datos del pago Aprobado.
  10. El POS confirma la operación enviando un Cierre de sesión en estado CLOSE.
  11. VTOL envía un commit con la confirmación y Fiserv responde el código 0212 con la confirmación.

Diagrama de secuencia

En el diagrama se encuentra resaltado en verde el resumen de este proceso:

Image Added


Flujo de la Devolución (RefundWallet):

El flujo consiste en:

  1. El POS envía a VTOL un RefundWallet con el número de operación de la compra y el monto original para solicitar la devolución.
  2. VTOL envía la solicitud de la devolución a Fiserv con el código de mensaje 0400 y el código de procesamiento correspondiente a la transacción original.
  3. Fiserv responde con la información del código QR y VTOL confirma la recepción del QR.
  4. VTOL envía los datos del código QR para que el usuario pueda seleccionar desde la aplicación la opción de “Devolución”.
  5. Se despliega en el pinpad el QR dinámico para ser escaneado por la billetera virtual del cliente.El cliente escanea el QR y selecciona la Cuenta y confirma el pago.
  6. VTOL responde al POS el código 657 (TQR recibido, consulte el procesamiento del pago).
  7. El POS envía un QueryWallet para obtener los datos del pago. El pago aún no se ha realizado, por lo cual, VTOL responde con el código 516 “Pago aún no realizado, Consulte o Cancele el pago”.
  8. Fiserv autoriza el pago, pero hay un error en la comunicación, por este motivo, Fiserv no le puede enviar a VTOL la información del pago.
  9. VTOL le envía la solicitud de reverso a Fiserv, debido a que se excede el tiempo establecido para recibir los datos del pago.
  10. VTOL recibe la respuesta de Fiserv con el código B6 “No se puede realizar el reverso del pago porque está autorizado"y luego confirmar la Devolución de la transacción en la aplicación.
  11. Fiserv le envía la respuesta a VTOL para confirmar la devolución con el código 0410.
  12. El POS envía un QueryWallet y VTOL le consulta a Fiserv por el pago pendiente. Fiserv le responde a VTOL los datos del pago Aprobadoa VTOL para obtener los datos de la devolución.
  13. VTOL responde los datos de la devolución.
  14. El POS confirma la operación enviando un Cierre de sesión en estado CLOSECerrar sesión (Commit) a VTOL.
  15. VTOL envía un commit con la confirmación y Fiserv responde el código 0212 con la confirmaciónmensaje a Fiserv para confirmar la Devolución mediante el código de mensaje 0202.
  16. Fiserv responde la confirmación de la Devolución a VTOL mediante el código de mensaje 0212.
  17. Finaliza el flujo.


Diagrama de secuencia:

Image RemovedImage Added


  • Requerimiento
Informações
titleReferencias

X = Obligatorio
O = Opcional
- = No requerido

...

Número

Nombre del campo

Tipo de dato

SaleWallet

RefundWallet

QueryWallet

Descripción

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éricoXXO

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éricoXXO

Tipos de moneda:

  • $ = Pesos
14paymentsNuméricoO-O

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

Para operar con Tarjeta de Débito, enviar 1.
Para operar con Tarjeta de Crédito, enviar mayor a 0.
Para operar con Dinero en Cuenta, enviar 0 o no enviar el campo.

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
147providerPosCodeAlfanuméricoO--Proveedor/tarjeta seleccionada por el cliente en su billetera virtual al momento de efectuar el pago.
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:

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

1410QRCodeBooleanoOO-

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

420precancelAlfanumérico--O

El POS enviará si desea ejecutar un cancel. Valores posibles:

True: indica que es una consulta previa a ejecutar un cancel

No se envía el campo: Es una consulta que no es parte de un flujo de cancel (Consulta normal)

Importante: solo aplica para el caso de pago con dinero en cuenta y se requiera cancelar la operación.

...

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.
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érico--X

Código de autorización informado por el Autorizador

24trxIdNuméricoXXXIdentificador de 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 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

XXX

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

147providerPosCodeAlfanumérico--OProveedor/tarjeta seleccionada por el cliente en su billetera virtual al momento de efectuar el pago.
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é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éricoOXOX-Se 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éricoXXXIdentificador de la sesión
1027libResponseCodeNuméricoXXX

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éricoXXXMensaje descriptivo del código de respuesta de la librería

...