VTOL EMVKIT AR 1.11.X - Fiserv QR Mensajería
Revisiones
Fecha | Versión | Descripción |
|---|---|---|
| 01/07/2024 | 1.0 | Creación del documento |
| 14/04/2025 | 1.1 | Se agregan los campos PAN (cardNumber - 06) y Terminal lógica (SerialNumber – 29) en las respuestas de la QueryWallet de un pago aprobado con FiservQR. |
| 29/08/2025 | 1.2 | Se corrige ejemplo de log de la respuesta del SaleWallet en el campo 26 donde llega la respuesta "QR recibido, consulte el procesamiento del pago". El campo 26 en esa respuesta retorna con valor "ISO8583" en versión de VTOL 3.8.1.2 o superior. |
1. Introducción
1.1. Propósito
Definir los procesos, y la mensajería para operar con FISERV QR.
2. Procesar mensaje FISERV QR
2.1 Integración
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 = Permite realizar una devolución con Adquiriente 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
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.
Manejo 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.
Flujo y Diagrama de secuencia del "Pago con Tarjeta" (una interacción). Finaliza el flujo con un cerrar sesión (CLOSE)
Importante
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:
- El POS envía un SaleWallet con el ammount (campo 12), paymments (campo 14) y el provider (campo 147).
- VTOL le envía a Fiserv la solicitud de compra con billetera digital, enviado el message Code 0200 y el processing code 0060031.
- 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.
- 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.
- El cliente escanea el QR y selecciona la Tarjeta para confirmar el pago.
- VTOL responde al POS el código 657 "QR recibido, consulte el procesamiento del pago".
- 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.
- Fiserv autoriza el pago y le envía a VTOL la respuesta con los datos de la solicitud (message code 0210).
- El POS envía un QueryWallet para obtener los datos del pago.
- Si el pago está aprobado, VTOL le responde al POS el código 00 "Aprobado"
- El POS confirma la operación enviando un Cierre de sesión en estado CLOSE.
- VTOL envía la confirmación de la compra (message code 0202) y Fiserv responde con el código 0212.
- Finaliza el flujo.
Flujo y Diagrama de secuencia del "Pago con Tarjeta" (una interacción) con error. 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:
- El POS envía un SaleWallet con el ammount (campo 12), paymments (campo 14) y el provider (campo 147).
- VTOL le envía a Fiserv la solicitud de compra con billetera digital, enviado el message Code 0200 y el processing code 0060031.
- 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.
- 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.
- El cliente escanea el QR y selecciona la Tarjeta para confirmar el pago.
- VTOL responde al POS el código 657 "QR recibido, consulte el procesamiento del pago".
- 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).
- Fiserv responde la solicitud del cancel (message code 0430)
- El POS envía un QueryWallet para obtener los datos del pago. VTOL responde el código 553 "Pago rechazado".
- El POS cancela la operación enviando un cierre de sesión en estado CANCEL.
- Finaliza el flujo.
Nota
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 6 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.
Diagrama y Flujo del "Pago con Tarjeta" (dos interacciones) y Pago con dinero en cuenta
Flujo de Pago Unificado:
Inicio del flujo (común para ambos tipos de pago)
El POS envía un SaleWallet con el monto y las cuotas de la operación (
cuotas=0).Se despliega el QR dinámico en el pinpad para ser escaneado por la billetera virtual del cliente.
A. Pago con Tarjeta
El cliente escanea el QR y selecciona la Tarjeta en su app bancaria.
VTOL responde al POS con el código 657 (QR recibido, consulte el procesamiento del pago).
El POS envía un QueryWallet para obtener los datos del pago.
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.
El POS envía un nuevo QueryWallet, enviando los campos de monto y cuotas, pudiendo modificar ambos datos.
a. Si el POS no envía los campos de monto y cuotas, VTOL responderá nuevamente con el código 654 (Valide monto y cuotas según tarjeta elegida).
b. Si el pago aún no se ha realizado, VTOL le responde al POS con el código 516 ("Pago aún no realizado").
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".
El POS confirma la operación enviando un Cierre de sesión en estado CLOSE.
VTOL envía la confirmación de la compra (message code 0202) y Fiserv responde con el código 0212.
Finaliza el flujo.
B. Pago con Dinero en Cuenta
VTOL responde al POS con el código 657 (QR recibido, consulte el procesamiento del pago).
El cliente escanea el QR y selecciona la Cuenta bancaria para confirmar el pago.
El POS envía un QueryWallet para obtener los datos del pago.
a. Si el pago se realizó, VTOL le responde al POS con los datos del pago y el código 00 "Aprobado".
El POS confirma la operación enviando un Cierre de sesión en estado CLOSE.
VTOL envía a Fiserv la confirmación y Fiserv responde con el código 0212.
Finaliza el flujo.
Importante
En los pagos con Transferencia (Dinero en cuenta) no es posible modificar el importe de la transacción. El importe que se informa en el mensaje "SaleWallet" es el monto que pagará el cliente.
En caso de querer aplicar un descuento promocional, se deberá realizar el cálculo del descuento antes, y luego se deberá enviar el monto con el descuento aplicado en el envío del "SaleWallet".
Flujos alternativos de secuencia del "Pago con dinero en cuenta"
A continuación, se detallan 3 flujos alternativos del Diagrama Pago con 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 dinero en cuenta, la caja 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 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:
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 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 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:
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:
- El POS envía un SaleWallet con el monto y las cuotas de la operación.
- 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.
- VTOL responde al POS el código 657 (TQR recibido, consulte el procesamiento del pago).
- 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”.
- 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.
- VTOL le envía la solicitud de reverso a Fiserv, debido a que se excede el tiempo establecido para recibir los datos del pago.
- VTOL recibe la respuesta de Fiserv con el código B6 “No se puede realizar el reverso del pago porque está autorizado".
- 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.
- El POS confirma la operación enviando un Cierre de sesión en estado CLOSE.
- 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:
Flujo de la Devolución (RefundWallet):
Tener en cuenta
El POS deberá enviar un mensaje RefundWallet con los datos de la venta original.
- Para realizar una Devolución de un pago realizado con Billetera utilizando Tarjeta, en la caja se desplegará un QR. En la app MODO el usuario deberá seleccionar el pago que desea anular > luego aparecerá una opción “Cómo cancelar este pago?” y luego deberá escanear el QR generado para dicha anulación.
- Para realizar una Devolución de un pago realizado con Billetera utilizando Dinero en cuenta, no se generará ningún QR. Por lo tanto no se deberá escanear ningún QR desde la app. El POS recibirá una respuesta de APROBADA por parte de EMVKIT (si es autorizada por el Autorizador). El POS deberá cerrar sesión con acción CLOSE. Y al breve tiempo se impactará la devolución en la app del cliente.
El flujo consiste en:
- 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.
- 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.
- Fiserv responde con la información del código QR y VTOL confirma la recepción del QR.
- VTOL envía los datos del código QR para que el usuario pueda seleccionar en su billetera la opción de “Devolución” sobre el pago que quiere anular.
- Se despliega en el pinpad el QR dinámico para ser escaneado por la billetera virtual del cliente y luego confirmar la Devolución de la transacción en la aplicación.
- Fiserv le envía la respuesta a VTOL para confirmar la devolución con el código 0410.
- El POS envía un QueryWallet a VTOL para obtener los datos de la devolución.
- VTOL responde los datos de la devolución.
- El POS confirma la operación enviando un Cerrar sesión (Commit) a VTOL.
- VTOL envía un mensaje a Fiserv para confirmar la Devolución mediante el código de mensaje 0202.
- Fiserv responde la confirmación de la Devolución a VTOL mediante el código de mensaje 0212.
- Finaliza el flujo.
Diagrama de secuencia
2.2 Mensajería
- Requerimiento
Referencias
X = Obligatorio
O = Opcional
- = No requerido
Número | Nombre del campo | Tipo de dato | SaleWallet | RefundWallet | QueryWallet | Descripción |
|---|---|---|---|---|---|---|
| 11 | trxType | Alfanumérico | X | X | X | Tipo de Transacción:
|
| 12 | amount | Numérico | X | X | O | 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". |
| 13 | currencyPosCode | Alfanumérico | X | X | O | Tipos de moneda:
|
| 14 | payments | Numérico | O | - | O | Cantidad de cuotas. 2 dígitos como máximo. Para operar con Tarjeta de Débito, enviar 1. |
| 16 | originalDate | Numérico | - | X | X | Fecha de realización de la compra con billetera electrónica en formato YYYYMMDD |
| 24 | lastTrxId | Numérico | O | O | O | Utilizado cuando está activo el control transaccional. En este campo el POS debe enviar la última transacción procesada correctamente. |
| 25 | dateTime | Numérico | X | X | X | Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS |
| 147 | providerPosCode | Alfanumérico | O | - | - | Proveedor/tarjeta seleccionada por el cliente en su billetera virtual al momento de efectuar el pago. |
| 268 | walletPosTrxId | Alfanumérico | X | X | O | Identificador único de la transacción de billetera para la compañía. Es originado por el POS para realizar una compra con billetera. Formato: Opcional en QueryWallet: Se informa este campo o el campo walletPaymentId para localizar una transacción de compra. |
| 269 | walletType | Numérico | X | X | X | Tipo de billetera por la cual se cursará la transacción en el POS. Opciones: 7: QR Adquiriente Fiserv |
| 270 | posTicket | Alfanumérico | X | - | - | Información del ticket en formato xml y posteriormente transformado en Base 64. Ver sección Estructura del campo posTicket |
| 271 | walletPaymentId | Alfanumérico | - | X | O | Identificador del número de pago informado por el Autorizador en el campo 271 de la respuesta de la operación SaleWallet. Opcional en QueryWallet: Se informa este campo o el campo walletPosTrxId para localizar una transacción de compra. |
| 1410 | QRCode | Booleano | O | O | - | 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 |
| 420 | precancel | Alfanumé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. |
Nota
Los valores de compañía, tienda y caja serán obtenidos de la sesión.
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 |
|---|---|---|---|---|
| totDiscount | Numérico | Importe total de descuento que calcula el POS. Será la sumatoria de descuentos que se apliquen a los artículos. | No | 0 |
| totTaxes | Numérico | Importe total de impuesto que calcula el POS. Será la sumatoria de impuestos que se apliquen sobre la compra. | No | 0 |
La manera de ejecutar un comando es utilizando una etiqueta con la forma <elemento-comando>. El elemento "item" identifica a los artículos. De esta manera, si se desea, por ejemplo, agregar un nuevo artículo el comando a utilizar será <item-add>. En el cuerpo del mensaje podrá contener uno, ninguno o varios de estos comandos.
Cada uno de los comandos que se envían posee diversos atributos, los cuales identifican al elemento que se está enviando y definen diversas propiedades que poseen los mismos. Poseerá un número de secuencia, el cual identifica cada elemento unívocamente:
Propiedad | Tipo de dato | Descripción | Requerido |
|---|---|---|---|
seq | Entero positivo | Número identificador único del elemento dentro de la transacción. | Sí |
Cada comando posee una serie de atributos que definirán las distintas propiedades del elemento que se está agregando (además del número de secuencia antes mencionado).
Para el elemento ítem, los atributos serán los siguientes:
Elemento | Atributo | Tipo de dato | Descripción | Requerido | Valor ante ausencia |
|---|---|---|---|---|---|
Ítem | unitprice | Numérico positivo | Precio unitario del artículo en cuestión. | Si | |
xprice | Numérico positivo | Precio extendido del artículo en cuestión. Es igual a la cantidad por el precio unitario. | Si | ||
qty | Entero positivo | Cantidad de artículos en la línea. | Si | ||
magnitude | Numérico positivo | Si el artículo es mensurable por otro unidad que no sea la cantidad, deberá ser expresad en esta propiedad. | No | 0 | |
code | Alfanumérico | Código propio del artículo. | No | "-" | |
brand | Alfanumérico | Marca del artículo. | No | "-" | |
supplier | Alfanumérico | Proveedor al que pertenece el artículo. | No | "-" | |
discountable | Alfanumérico | Si el artículo es puede recibir descuentos o no. | No | "-" | |
level1 | Alfanumérico | Nivel 1 de categorización del artículo. Anteriormente este nivel se conocía con el nombre de Departamento. | No | "-" | |
level2 | Alfanumérico | Nivel 2 de categorización del artículo. Anteriormente este nivel se conocía como la Familia del artículo. | No | "-" | |
level3 | Alfanumérico | Nivel 3 de categorización del artículo. Anteriormente este nivel se conocía como la Categoría del artículo. | No | "-" | |
level4 | Alfanumérico | Nivel 4 de categorización del artículo. Anteriormente este nivel se conocía como la subcategoría del artículo. | No | "-" | |
| description | Alfanumérico | Descripción del ítem | Si | ||
| currency | Alfanumérico | Moneda utilizada en el precio del ítem Nota: En el punto de venta se deberá informar la moneda de la cuenta vendedor de Mercado Pago (si el retailer posee una cuenta argentina en Mercado Pago entonces tendrá que informar la moneda $ -pesos argentinos-). | Si | ||
| measure | Alfanumérico | Unidad de medida del ítem. Valores posibles: unit - pack | No | "unit" |
Ejemplo
<message totDiscount="10.00" totTaxes="5.00"> <item-add seq="1" code="0001" discountable="true" unitprice="25.0" qty="1.0" level1="MEN" level2="CASUAL" supplier="" brand="LEVIS" xprice="25.0" magnitude="1" description="Jean casual" currency="$" /> <item-add seq="2" code="0002" discountable="true" unitprice="28.0" qty="2.0" level1="MEN" level2="CASUAL" supplier="" brand="LEVIS" xprice="48.0" magnitude="1" description="Jean casual" currency="$" /> </message>
Importante
Esta estructura generada debe transformarse al formato Base 64 para informárselo a VTOL en el campo 270 posTicket.
- Respuesta
Referencias
X = Obligatorio
O = Opcional
- = No requerido
Número | Nombre del campo | Tipo de dato | SaleWallet | RefundWallet | QueryWallet | Descripción |
|---|---|---|---|---|---|---|
| 0 | company | Numérico | X | X | X | Identificador de la compañía donde se generó la transacción |
| 1 | store | Alfanumérico | X | X | X | Identificador del sitio originador de la transacción |
| 2 | node | Numérico | X | X | X | Identificación del nodo, en el sitio originador, donde se generó la transacción. |
| 6 | cardNumber | Alfanumérico | - | - | O | Tarjeta enmascarada seleccionada al momento de efectuar el pago QR. Campo opcional. Si se pagó con Dinero en cuenta, este campo no retorna. |
| 12 | amount | Importe | X | - | X | Contiene el importe que pagó el cliente, el cual puede variar si pagó con intereses o se aplicó algún descuento. Valor entero. Los últimos 2 dígitos corresponden a los decimales. |
| 13 | currencyPosCode | Alfanumérico | X | - | X | Tipos de moneda:
|
| 14 | payments | Numérico | X | - | O | Cantidad de cuotas seleccionadas al momento de realizar el pago QR. |
| 22 | authorizationCode | Alfanumérico | - | - | X | Código de autorización informado por el Autorizador |
| 24 | trxId | Numérico | X | X | X | Identificador de la transacción. |
25 | dateTime | Numérico | X | X | X | Fecha y hora de realización de la transacción en formato YYYYMMDDHHMMSS. El valor en este campo debe ser el mismo que el valor de la fecha y hora del requerimiento. El POS utiliza este dato para validar que se trate de la misma transacción |
26 | responseCode | Alfanumérico | X | X | X | Puede contener uno de los siguientes valores:
|
27 | isoCode | Numérico | X | X | X | Código de Respuesta emitido por el centro autorizador. 2 dígitos como máximo. Ver sección Códigos de Respuesta de VTOL Server para Billeteras Electrónicas |
28 | responseMessage | Alfanumérico | X | X | X | Mensaje de la Respuesta relacionado con el código del campo 27 |
29 | serialNumber | Numérico | - | - | X | Número que identifica la terminal lógica en la que se procesó la transacción. |
| 140 | paymentType | Numérico | - | - | X | Tipo de pago. Valores posibles: 0: Tarjeta |
| 142 | providerName | Alfanumérico | - | O | O | Proveedor de la tarjeta seleccionada al momento de efectuar el pago QR. El campo es opcional en caso de que se haya abonado con saldo de la cuenta de Mercado Pago. |
| 147 | providerPosCode | Alfanumérico | - | - | O | Proveedor/tarjeta seleccionada por el cliente en su billetera virtual al momento de efectuar el pago. En un pago con Dinero en Cuenta, este campo no retorna ya que ese dato únicamente se obtiene cuando es un pago con tarjeta. Campo que indica la tarjeta que se utilizó para pagar. |
| 166 | trxReferenceNumber | Numérico | X | X | - | Identificador único de la transacción en VTOL Server. Longitud entre 19 y 20 dígitos, debido a que utiliza el día como parte de formato |
| 271 | walletPaymentId | Alfanumérico | - | - | X | Identificador del número de pago informado por el Autorizador |
| 273 | paymentStatus | Alfanumérico | - | - | X | Estado de la transacción de pago informado por el Autorizador. Estados posibles: 0: Aprobado |
| 275 | cardType | Numérico | - | - | O | Tipo de tarjeta seleccionada al momento de efectuar el pago QR. Valores posibles: 0: Débito |
| 410 | QRCode | Alfanumérico | X | X | - | 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. |
| 511 | walletPaymentType | Alfanumérico | - | O | O | Indica la billetera que se utilizó para realizar el pago. Es un dato que retorna desde Fiserv. |
| 1010 | currentSessionId | Numérico | X | X | X | Identificador de la sesión |
| 1027 | libResponseCode | Numérico | X | X | X | Código de respuesta de la librería. |
| 1028 | libResponseMessage | Alfanumérico | X | X | X | Mensaje descriptivo del código de respuesta de la librería |
Tener en cuenta
Si la respuesta de un mensaje QueryWallet retorna con código 514 ("Tiempo expirado. Elija Consultar o Cancelar pago") el POS al aplicar la acción "Cancelar pago" sobre dicho mensaje, deberá enviar un mensaje de sincronización a EMVKit, sin incluir el id de transacción de la operación saleWallet. De esa manera EMVKit podrá sincronizar contra VTOL Server y este enviará una cancelación de la orden de compra contra la billetera virtual que se esté operando.
Ver mensaje de sincronización de transacciones
2.3 Ejemplos de logs
2.3.1 Pago con Tarjeta (dos interacciones)
***** El POS crea la intención de pago:
Request: {270:PG1lc3NhZ2U+CjxpdGVtLWFkZCBjdXJyZW5jeT0iJCIgZGVzY3JpcHRpb249IkdlbmVyaWMgRGVz
Y3JpcHRpb24iIHF0eT0iMS4wIiBzZXE9IjEiIHVuaXRwcmljZT0iMTYzMC45OCIgeHByaWNlPSIx
NjMwLjk4Ii8+CjwvbWVzc2FnZT4K;269:7;268:00000055300000000005250319161540;14:1;13:$;12:163098;11:SaleWallet;1410:true;2:5;25:20250319161540;1:5530}
Response message: {0:7TY02;1:5530;2:5;1027:000;1028:Ok;166:19032516163300002994;12:00;272:00;1010:1742411740101;24:106;25:20250319161540;410:000201010212263000112008341948301110000000000043350010com.fiserv981130692264785990200501500112008341948351260022000006800000000222295652045812530303254071630.985802AR5908DorinkaQ6012VILLA GESELL6105071656267012042000000000000000000052137888861174241179654207083788886108020080500010com.fiserv010502.020202010312250319161636040126304a0f5;26:ISO8583;27:657;28:QR recibido\, consulte el procesamiento del pago;29:37888861;30:000020083419483}
***** Consulta para obtener los datos del medio de pago:
Request: {271:19032516163300002994;16:20250319;269:7;268:00000055300000000005250319161540;13:$;11:QueryWallet;2:5;25:20250319161540;1:5530}
Response message: {0:7TY02;1:5530;2:5;1027:000;1028:Ok;12:163098;140:0;13:$;14:1;271:000190600057;273:0;1010:1742411740101;275:0;24:106;25:20250319161540;26:ISO8583;27:516;28:Pago aun no realizado\, desea seguir esperando?;511:FiservQR}
***** Otra consulta para obtener los datos del medio de pago. Retorna la tarjeta elegida por el usuario en la app bancaria:
Request: {271:19032516163300002994;16:20250319;269:7;268:00000055300000000005250319161540;13:$;11:QueryWallet;2:5;25:20250319161540;1:5530}
Response message: {0:7TY02;1:5530;2:5;1027:000;1028:Ok;140:0;12:163098;13:$;14:0;142:Master Card;271:000190600057;273:654;1010:1742411740101;275:1;147:MC;24:106;25:20250319161540;26:ISO8583;27:654;28:Valide monto y cuotas seg?n tarjeta elegida;511:FiservQR}
***** El POS envía Monto y Cuotas definitivas:
Request: {271:000190600057;269:7;16:20250319;268:00000055300000000005250319161540;14:1;13:$;12:163098;11:QueryWallet;2:5;25:20250319161623;1:5530}
Response message: {0:7TY02;1:5530;2:5;1027:000;1028:Ok;140:0;12:163098;13:$;14:1;142:Master Card;271:000190600057;273:516;1010:1742411740101;275:1;147:MC;24:106;25:20250319161623;26:ISO8583;27:516;28:Pago aun no realizado\, desea seguir esperando?;511:FiservQR}
***** Consulta para obtener el estado del pago:
Request: {271:000190600057;269:7;16:20250319;268:00000055300000000005250319161540;14:1;13:$;12:163098;11:QueryWallet;2:5;25:20250319161623;1:5530}
Response message: {0:7TY02;1:5530;2:5;1027:000;1028:Ok;140:0;12:163098;13:$;14:1;142:Master Card;271:000190600057;273:516;1010:1742411740101;275:1;147:MC;24:106;25:20250319161623;26:ISO8583;27:516;28:Pago aun no realizado\, desea seguir esperando?;511:FiservQR}
***** Otra consulta para obtener el estado del pago. La operación retorna APROBADA:
Request: {271:000190600057;269:7;16:20250319;268:00000055300000000005250319161540;14:1;13:$;12:163098;11:QueryWallet;2:5;25:20250319161623;1:5530}
Response message: {0:7TY02;1:5530;2:5;1027:000;1028:Ok;140:0;12:163098;13:$;14:1;142:Master Card;271:000190600057;273:0;274:approved;1010:1742411740101;275:1;147:MC;6:451756xxxxxx0001;29:37888861;22:560789;24:106;25:20250319161623;26:ISO8583;27:00;28:APROBADA;511:MODO}
***** El POS cierra sesión confirmando OK:
Request: {1009:{106};1008:CLOSE;2:5;1:5530;11:closeSession}
Response message: {1010:1742411740101;1027:000;1028:Ok}
2.3.2 Pago con Dinero en Cuenta (PCT)
***** El POS inicia sesión:
Request: {25:20250401140711;2:5;1:5530;11:createSession;0:7TY02}
Response message: {1010:1743527231299;1027:000;1028:Ok}
***** El POS crea la intención de pago:
Request: {270:PG1lc3NhZ2U+CjxpdGVtLWFkZCBjdXJyZW5jeT0iJCIgZGVzY3JpcHRpb249IkdlbmVyaWMgRGVz
Y3JpcHRpb24iIHF0eT0iMS4wIiBzZXE9IjEiIHVuaXRwcmljZT0iMTk4OS4wMCIgeHByaWNlPSIx
OTg5LjAwIi8+CjwvbWVzc2FnZT4K;269:7;268:00000055300000000005250401140711;14:0;13:$;12:198900;11:SaleWallet;1410:true;2:5;25:20250401140711;1:5530}
Response message: {0:7TY02;1:5530;2:5;1027:000;1028:Ok;166:1042514081200003456;12:00;272:00;1010:1743527231299;24:403;25:20250401140711;410:000201010212263000112008341948301110000000000043350010com.fiserv981130692264785990200501500112008341948351260022000006800000000222295652045812530303254071989.005802AR5908DorinkaQ6012VILLA GESELL6105071656267012018500000000000000000052137888861174352729643407083788886108020080500010com.fiserv010502.02020201031225040114081604012630442e6;26:657;27:657;28:QR recibido\, consulte el procesamiento del pago;29:37888861;30:000020083419483}
***** Consulta para obtener los datos del medio de pago:
Request: {271:1042514081200003456;269:7;16:20250401;268:00000055300000000005250401140711;13:$;12:198900;11:QueryWallet;2:5;25:20250401140717;1:5530}
Response message: {0:7TY02;1:5530;2:5;1027:000;1028:Ok;12:198900;140:2;13:$;14:0;271:000010600049;273:0;1010:1743527231299;275:0;24:403;25:20250401140717;26:ISO8583;27:516;28:Pago aun no realizado\, desea seguir esperando?;511:FiservQR}
***** Otra consulta para obtener los datos del medio de pago. Retorna que el pago se realizó con Dinero en Cuenta:
Request: {271:1042514081200003456;269:7;16:20250401;268:00000055300000000005250401140711;13:$;12:198900;11:QueryWallet;2:5;25:20250401140717;1:5530}
Response message: {0:7TY02;1:5530;2:5;1027:000;1028:Ok;140:2;12:198900;13:$;14:0;271:000010600049;273:0;274:approved;1010:1743527231299;275:0;22:Q0M51O;24:403;25:20250401140717;26:ISO8583;27:00;28:APROBADA;511:MODO}
***** El POS cierra sesión confirmando OK:
Request: {1009:{403};1008:CLOSE;2:5;1:5530;11:closeSession}
Response message: {1010:1743527231299;1027:000;1028:Ok}
2.3.3 Devolución
Tener en cuenta
El POS deberá enviar un mensaje RefundWallet con los datos de la venta original.
- Para realizar una Devolución de un pago realizado con Billetera utilizando Tarjeta, en la caja se desplegará un QR. En la app MODO el usuario deberá seleccionar el pago que desea anular > luego aparecerá una opción “Cómo cancelar este pago?” y luego deberá escanear el QR generado para dicha anulación.
- Para realizar una Devolución de un pago realizado con Billetera utilizando Dinero en cuenta, no se generará ningún QR. Por lo tanto no se deberá escanear ningún QR desde la app. El POS recibirá una respuesta de APROBADA por parte de EMVKIT (si es autorizada por el Autorizador). El POS deberá cerrar sesión con acción CLOSE. Y al breve tiempo se impactará la devolución en la app del cliente.
***** El POS crea la intención de devolución:
Request: {271:000190600057;269:7;16:20250319;268:00000055300000000005250319161826;13:$;12:163098;11:RefundWallet;1410:true;2:5;25:20250319161826;1:5530}
Response message: {0:7TY02;1:5530;2:5;1027:000;1028:Ok;166:19032516191600002995;272:00;1010:1742411906967;24:107;25:20250319161826;410:000201010212501500112008341948351260022000006800000000222295652045812530303254071630.985802AR5908DorinkaQ6012VILLA GESELL6105071656243052137888861174241195911707083788886108020280440010com.fiserv010502.010312250319161919040126304012d;26:657;27:657;28:QR recibido\, consulte el procesamiento del pago}
***** Consulta para obtener los datos de la devolución:
Request: {271:19032516191600002995;269:7;16:20250319;268:00000055300000000005250319161826;13:$;12:163098;11:QueryWallet;2:5;25:20250319161834;1:5530}
Response message: {0:7TY02;1:5530;2:5;1027:000;1028:Ok;12:163098;140:0;13:$;14:1;271:000190600059;273:0;1010:1742411906967;275:0;24:107;25:20250319161834;26:ISO8583;27:516;28:Pago aun no realizado\, desea seguir esperando?;511:FiservQR}
***** Otra consulta para obtener los datos de la devolución:
Request: {271:19032516191600002995;269:7;16:20250319;268:00000055300000000005250319161826;13:$;12:163098;11:QueryWallet;2:5;25:20250319161834;1:5530}
Response message: {0:7TY02;1:5530;2:5;1027:000;1028:Ok;12:163098;140:0;13:$;14:1;271:000190600059;273:0;1010:1742411906967;275:0;24:107;25:20250319161834;26:ISO8583;27:516;28:Pago aun no realizado\, desea seguir esperando?;511:FiservQR}
***** Otra consulta para obtener los datos de la devolución:
Request: {271:19032516191600002995;269:7;16:20250319;268:00000055300000000005250319161826;13:$;12:163098;11:QueryWallet;2:5;25:20250319161834;1:5530}
Response message: {0:7TY02;1:5530;2:5;1027:000;1028:Ok;140:0;12:163098;13:$;14:1;142:Master Card;271:000190600059;273:654;1010:1742411906967;275:1;147:MC;24:107;25:20250319161834;26:ISO8583;27:516;28:Pago aun no realizado\, desea seguir esperando?;511:FiservQR}
***** Otra consulta para obtener los datos de la devolución. La devolución retornó Aprobada:
Request: {271:19032516191600002995;269:7;16:20250319;268:00000055300000000005250319161826;13:$;12:163098;11:QueryWallet;2:5;25:20250319161834;1:5530}
Response message: {0:7TY02;1:5530;2:5;1027:000;1028:Ok;140:0;12:163098;13:$;14:1;142:Master Card;271:000190600059;273:0;274:approved;1010:1742411906967;275:1;147:MC;22:502694;24:107;25:20250319161834;26:ISO8583;27:00;28:APROBADA;511:MODO}
***** El POS cierra sesión confirmando OK:
Request: {1009:{107};1008:CLOSE;2:5;1:5530;11:closeSession}
Response message: {1010:1742411906967;1027:000;1028:Ok}






