...
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. |
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" |
27/07/2017 | 1.21 | Modificación del apartado "Pre requisitos" |
02/08/2017 | 1.22 | Agregación de campo 22 – authorizationCode en el requerimiento de la operación "Leer Datos de la Tarjeta" |
06/10/2017 | 1.23 | Actualización de la estructura y numeración del documento |
14/11/2017 | 1.24 | Incorporación del apartado "Instalación" |
01/02/2018 | 1.25 | Aclaración sobre requerimiento de software |
| 23/04/2018 | 1.26 | Revisión general del documento. Agregado de apartado Pagos Parciales. |
| 13/06/2018 | 1.27 | Agregado de procesamiento de tarjetas de empleados |
| 12/07/2018 | 1.28 | Agregado 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/2018 | 1.29 | Incorporación de la funcionalidad PEI en la mensajería |
| 17/08/2018 | 1.30 | Agregado de campo 1104 - prefixesList en la respuesta de la operación "Leer Datos de la Tarjeta" |
| 14/01/2019 | 1.31 | Incorporación de las funcionalidades de impresión de vouchers en la mensajería |
| 25/01/2019 | 1.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/2019 | 1.33 | Incorporación de la funcionalidad Billeteras Electrónicas QR (Mercado Pago y Todo Pago) |
| 03/04/2019 | 1.34 | Agregado del campo 0 (compañía) en todos los tipos de transacciones. |
| 17/05/2019 | 1.35 | Incorporación de la funcionalidad Cuenta DNI y Promociones PEI. |
| 20/05/2019 | 1.36 | Incorporación de apartado de compatibilidad con VTOL Server. |
| 02/08/2019 | 1.37 | Incorporación de funcionalidad de Billeteras electrónicas con manejo de cuotas. |
| 08/08/2019 | 1.38 | Incorporación de funcionalidad Contactless con pinpad de First Data. |
| 09/08/2019 | 1.39 | Incorporación de apartado para integrar operaciones con tarjetas Contactless. |
| 24/10/2019 | 1.40 | Agregado 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/2019 | 1.41 | Agregado de anexo 6.10 Vouchers con la especificación de los campos de los comprobantes según los Autorizadores |
| 27/12/2019 | 1.42 | Actualización del apartado Procedimiento de Instalación |
| 10/03/2020 | 1.43 | Incorporación de mensaje de Sincronización de transacciones entre EMVKit y el POS. |
| 30/07/2020 | 1.44 | Incorporación de funcionalidad de Billeteras Mercado Pago con retiro de efectivo. |
| 22/09/2020 | 1.45 | Se actualiza el campo 54 (additionalAmount) como tipo de dato Importe, en la mensajería de Billeteras electrónicas. |
| 26/11/2020 | 1.46 | Agregado del campo Descripción en Configuración de POS para indicar la descripción sobre un plan de pago. |
| 27/08/2021 | 1.47 | Se quitan las referencias a la Billetera Todo Pago, ya que la misma fue desarrollada en versiones posteriores, dentro de la funcionalidad "QR Adquiriente Prisma". |
| Âncora | ||||
|---|---|---|---|---|
|
...
- Mercado Pago: La plataforma de pagos online más importante de América LatinaTodo Pago: La plataforma de pagos de Prisma
Las operaciones soportadas en VTOL Server para Billeteras electrónicas son:
...
- Una vez recibida la respuesta de operación Aprobada por parte de Mercado Pago, se puede realizar lo siguiente:
- Para una venta con productos y cashout. Permite anular:
- Los productos y el cashout, todo junto. Esto se logra enviando un UnSyncCompletion=rollback
- Para una venta sólo con productos. Permita anular:
- Todos los productos. Esto se logra enviando un UnSyncCompletion=rollback.
- Para una venta con productos y cashout. Permite anular:
- No es posible realizar anulaciones intermedias.
Procedimiento para Todo Pago
El proceso de pagos con billetera virtual de Todo Pago difiere respecto de Mercado Pago, ya que el cliente en su app mobile simplemente selecciona la tarjeta con la cual realizará el pago, y luego el resto de la operatoria la deberá realizar el cajero, es decir, el ingreso de las cuotas, promociones, etc. El proceso se realizará de la siguiente manera:
- Se inicia con el envío de una orden de venta (transacción SaleWallet) por parte del POS a VTOL.
- Recién en ese momento el comprador podrá efectuar la lectura del código QR impreso en la caja mediante su smartphone. Seleccionará la tarjeta con la cual realizará el pago. Y luego aceptará la tarjeta elegida en su app mobile.
- VTOL recibirá la información de la tarjeta del cliente, por medio de Todo Pago, y le responderá al POS que se deben ingresar las cuotas según los planes de pago disponibles (sólo para aquellos comercios que permitan pagos en cuotas).
- El POS ingresará las cuotas, y enviará la información a VTOL por medio de la transacción QuerySaleWallet.
- El POS recibirá la respuesta de la transacción a través de VTOL, quien informará si la operación resultó autorizada por Todo Pago.
- Puede darse el caso que VTOL responda "Consulte el pago por tiempo expirado". Este escenario puede surgir por algún problema de conexión y VTOL no pudo obtener el mensaje sobre el resultado de Todo Pago. Con este mensaje se le informa al POS que para conocer el resultado de la operación, deberá realizar una nueva consulta (transacción QuerySaleWallet). Las respuestas del QuerySaleWallet pueden ser las siguientes:
- VTOL responde "Aprobado". Indica que el pago fue autorizado por Todo Pago. El paso siguiente del POS es confirmar o cancelar la transacción, con un tercer mensaje.
- VTOL responde "Pago Rechazado". Indica que el pago no fue autorizado por Todo Pago. Por lo tanto la operación no puede continuar. El POS deberá iniciar una nueva transacción.
- Puede darse el caso que VTOL responda "Consulte el pago por tiempo expirado". Este escenario puede surgir por algún problema de conexión y VTOL no pudo obtener el mensaje sobre el resultado de Todo Pago. Con este mensaje se le informa al POS que para conocer el resultado de la operación, deberá realizar una nueva consulta (transacción QuerySaleWallet). Las respuestas del QuerySaleWallet pueden ser las siguientes:
- Por último, el POS deberá confirmar la operación, mediante el cierre de sesión (en estado Close).
- Requerimiento
| Informações |
|---|
Referencias: X = Obligatorio |
...
Número
...
Nombre del campo
...
Tipo de dato
...
SaleWallet
...
Descripción
...
11
...
trxType
...
Alfanumérico
...
X
...
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
...
- Requerimiento
| Informações |
|---|
Referencias: X = Obligatorio |
Número | Nombre del campo | Tipo de dato | SaleWallet | RefundWallet | QuerySaleWallet | Descripción |
|---|---|---|---|---|---|---|
11 | trxType | Alfanumérico | X | X | X | Tipo de Transacción:
|
12 | amount | Importe | X | X | - | Monto de la transacción. 12 dígitos como máximo. Se envía sin coma. Los dos últimos dígitos representan los decimales. Ej: 1000 equivale a 10.00 Nota: El importe debe ser el número correspondiente a la moneda informada |
13 | currencyPosCode | Alfanumérico | X | X | - | Tipos de moneda:
Nota: En el punto de venta se deberá informar la moneda de la cuenta vendedor de Mercado Pago (si el retailer posee una cuenta argentina en Mercado Pago entonces tendrá que informar la moneda $ -pesos argentinos-) 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 |
| 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 |
| 54 | additionalAmount | Importe | O | O | - | Contiene el Importe del "Cashout". 12 dígitos como máximo. Valor entero. Los últimos 2 dígitos corresponden a los decimales. Para devoluciones, se debe enviar el monto total del cashout. Para devolver sólo el cashout, se debe enviar el campo 12 (amount) con valor 0. Sólo disponible para billetera de Mercado Pago. |
| 268 | walletPosTrxId | Alfanumérico | X | - | O | Identificador único de la transacción de billetera para la compañía. Es originado por el POS para realizar una compra con billetera Formato: Opcional en QuerySaleWallet: Se informa este campo o el campo walletPaymentId para localizar una transacción de compra |
| 269 | walletType | Numérico | X | X | X | Tipo de billetera por la cual se cursará la transacción en el POS. Opciones: 1: Mercado Pago |
| 270 | posTicket | Base 64 | X | - | - | Información del ticket en formato xml y posteriormente transformado en Base 64. Ver sección Estructura del campo posTicket |
| 271 | walletPaymentId | Alfanumérico | - | X | O | Identificador del número de pago informado por el Autorizador en el campo 271 de la respuesta de la operación SaleWallet Opcional en QuerySaleWallet: Se informa este campo o el campo walletPosTrxId para localizar una transacción de compra |
...