SDK Integración Caja POS

Tabla de Contenido

1 Tabla de Contenido
2 CONCEPTO
3 VERSION ACTUAL
4 INSTALACIÓN
4.1 En Windows
4.1.1 Paso 1: Copiar Backend del SDK
4.1.2 Paso 2: Instalar Driver del cable (solo para conexión por cable)
4.1.3 Paso 3: Configuración del Backend
4.1.4 Paso 4: Levantar el backend
4.1.5 Paso 5: Levantar el Simulador para pruebas
4.2 En Linux
4.2.1 Paso 1: Copiar backend del SDK
4.2.2 Paso 2: Verificar puerto en el que se conectó el POS (en caso de ser conexión directa por cable)
4.2.3 Paso 3: Configuración del Backend
4.2.4 Paso 4: Asignar permisos y ejecutar backend
4.2.5 Paso 5: Asignar permisos y levantar simulador para realizar pruebas
5 CONFIGURACIONES
5.1 Backend como servicio de Windows
5.2
5.2.1 Paso 1: Instalar SrvStart
5.2.2 Paso 2: Modificar el archivo BancardSDK.ini
5.2.3 Paso 3: Utilizar el simbolo de Sistema para crear el nuevo servicio
5.2.4 Controlar servicio desde el Símbolo de Sistema
5.3 Backend como servicio de Linux
5.3.1 Paso 1: Crear archivo de configuración para systemctl
5.3.2 Paso 2: Activar y controlar el servicio
6 SERVICIOS REST DISPONIBLES
6.1 Solicitud Venta Contado
6.2 Solicitud Venta Cuotas
6.3 Solicitud Venta Forzado Débito
6.4 Solicitud Venta Forzado Crédito
6.5 Envío de Monto
6.6 Verificación de conexión de POS - Mensaje ECO
7 TABLA DE ISSUER ID's

CONCEPTO
El SDK de integración Caja POS es un Servicio REST empaquetado que se instala en el equipo donde se encuentra conectado el POS, su función es
traducir las peticiones que recibe como JSON al protocolo RS232 que es interpretado por el POS, esto facilita a los desarrolladores a realizar la
integración con su sistema de caja.

A continuación vemos una imagen del funcionamiento de la integración Caja POS.

VERSION ACTUAL
La versión actual del SDK es la 1.5.0 y lo podemos descargar (dependiendo de nuestro S.O y arquitectura) desde el siguiente enlace: https://gitlab.
com/larojas/bancard-integracion-cajapos/-/tree/v1.5.0

INSTALACIÓN
En Windows

Para la instalación del SDK es necesario primeramente descargar el backend que nos servirá para levantar el Web Services REST al
que realizaremos las peticiones para la comunicación con el POS de Bancard, podemos ver la última versión disponible aquí.

Paso 1: Copiar Backend del SDK

Mover la carpeta de backend que corresponde a la arquitectura de nuestro Sistema Operativo en la ubicación que deseamos. En el ejemplo la
carpeta sdk-backend-windows-x64 en el disco C:

El contenido de la carpeta será el siguiente:

apidoc: Archivos necesarios para ver la documentación del WS una vez levantado el backend.
logs: Carpeta donde se guardará el log del backend.
config.json: Archivo de configuración del backend (más adelante veremos su contenido).
index.exe: Archivo ejecutable para levantar el WS del backend.
serialport.node: Librería para la comunicación con el POS.

Paso 2: Instalar Driver del cable (solo para conexión por cable)
Descargar e instalar el Driver necesario para el cable de comunicación con el POS, podemos obtener el driver ingresando en la sección de
Windows del repositorio del SDK que tenemos aquí.

Una vez instalado conectamos el cable a la PC y verificamos en que puerto lo está reconociendo, este dato nos servirá para configurar el
backend antes de iniciarlo. Para ello ingresamos a "Mi PC" Propiedades Administrador de dispositivos
Ver la opción "Ports" o "Puertos" donde se despliegan los dispositivos conectados. El correspondiente a USB-Serial CH 340 es el dispositivo
POS. Por tanto nuestro puerto COM será el 4 según el ejemplo mostrado en la imagen:

Paso 3: Configuración del Backend

El archivo config.json contiene toda la configuración necesaria para el WS y la comunicación con el POS de Bancard. Veamos su contenido:
 config.json

{
"com": "com4", // Puerto de conexión del dispositivo POS.
"reintentos": 3, // Reintentos de conexión al POS, se sugiere dejar en 3.
"transaction_timeout": 1, // Tiempo en minutos para que el backend devuelva timeout.
"server": {
"port": 3000 // Puerto en el que se levantará el Web Services de backend.
},
"log": {
"maxSize": 5, // Tamaño en MB de los archivos de logs.
"backups": 3, // Cantidad de archivos de logs que serán generados.
"absolutePath": "C:/sdk-backend-windows-x64/logs/application.log" // Ruta absoluta del log.
},
"tam":100, // Tamaño en bytes de cada mensaje que se envía al pos.
"delayTime":100, // Tiempo en milisegundos que espera para enviar entre los mensaje partidos.
"baudRate": 9600, // Configuraciones propias de la librería serialport que se deben quedar fijos.
"bufferSize": 250, // Configuraciones propias de la librería serialport que se deben quedar fijos.
"useTCP": false, // Indica si se debe utilizar o no conexión TCP/IP para comunicarse con el POS.
"tcpPOS": { // Se utiliza si no se envía los valores en el queryParams de las invocaciones.
"host": "192.168.1.102", // IP asignada al POS (solo si useTCP está en true).
"port": 15000, // Puerto del POS (solo si useTCP está en true).
}
}

Paso 4: Levantar el backend

Para levantar el backend vamos a la carpeta donde se encuentran nuestros archivos del SDK y ejecutamos el index.exe, con esta acción se
levantará una consola con la versión y puerto en el que está escuchando el servicio.

Observación

El backend estará activo siempre que la ventana de la consola se encuentre abierta, si queremos poner como servicio de Windows de
forma que arranque al iniciar el Sistema Operativo vayamos a la sección de Configuraciones

Paso 5: Levantar el Simulador para pruebas

Mover la carpeta llamada simulador-cajapos-win32-x64 (para arquitectura de 64 bits) al disco C:
Hacer clic en el ejecutable simulador-cajapos.exe y se levantará la aplicación de pruebas, allí tendremos la opción de Listar Puertos para ver
en que puerto se encuentra conectado nuestro POS y podremos usar las opciones disponibles en el backend para venta contado o en cuotas.
Para hacer las pruebas debemos cargar la IP y PUERTO del backend así como también podemos activar el protocolo TCP/IP si tenemos
configurada esta opción en el backend.

En Linux
 Para la instalación del SDK es necesario primeramente descargar el backend que nos servirá para levantar el Web Service REST al
que realizaremos las peticiones para la comunicación con el POS de Bancard, podemos ver la última versión disponible para nuestro
Sistema Operativo aquí.

Paso 1: Copiar backend del SDK

Mover la carpeta de backend que corresponde a la arquitectura de nuestro Sistema Operativo en /opt/. En el ejemplo la carpeta sdk-backend-
linux-x64.

El contenido de la carpeta será el siguiente:

apidoc: Archivos necesarios para ver la documentación del WS una vez levantado el backend.
logs: Carpeta donde se guardará el log del backend.
config.json: Archivo de configuración del backend (más adelante veremos su contenido).
index.exe: Archivo ejecutable para levantar el WS del backend.
serialport.node: Librería para la comunicación con el POS.

Paso 2: Verificar puerto en el que se conectó el POS (en caso de ser conexión directa por cable)
Par saber en que puerto se encuentra conectado el POS debemos ingresar a la terminal y ejecutar el siguiente comando:

Comando

dmesg | grep tty

Se listan los dispositivos conectados. Utilizaremos el código tty0, tty1, etc según el número de puerto habilitado para el POS para agregar en el
archivo de configuración.

Paso 3: Configuración del Backend

El archivo config.json contiene toda la configuración necesaria para el WS y la comunicación con el POS de Bancard. Veamos su contenido:
 config.json

{
"com": "/dev/ttyUSB0", // Puerto de conexión del dispositivo POS con cable USB.
"reintentos": 3, // Reintentos de conexión al POS, se sugiere dejar en 3.
"transaction_timeout": 1, // Tiempo en minutos para que el backend devuelva timeout.
"server": {
"port": 3000 // Puerto en el que se levantará el Web Services de backend.
},
"log": {
"maxSize": 5, // Tamaño en MB de los archivos de logs.
"backups": 3, // Cantidad de archivos de logs que serán generados.
"absolutePath": "C:/sdk-backend-windows-x64/logs/application.log" // Ruta absoluta del log.
},
"tam":100, // Tamaño en bytes de cada mensaje que se envía al pos.
"delayTime":100, // Tiempo en milisegundos que espera para enviar entre los mensaje partidos.
"baudRate": 9600, // Configuraciones propias de la librería serialport que se deben quedar fijos.
"bufferSize": 250, // Configuraciones propias de la librería serialport que se deben quedar fijos.
"useTCP": false, // Indica si se debe utilizar o no conexión TCP/IP para comunicarse con el POS.
"tcpPOS": { // Se utiliza si no se envía los valores en el queryParams de las invocaciones.
"host": "192.168.1.102", // IP asignada al POS (solo si useTCP está en true).
"port": 15000, // Puerto del POS (solo si useTCP está en true).
}
}

Paso 4: Asignar permisos y ejecutar backend

Para levantar el backend debemos asignar permisos de ejecución a los archivos y correr la aplicación llamada index

Comando

cd /opt/sdk-backend-linux-x64 # Ingresar a la carpeta donde se encuentra el backend

sudo chmod 775 -R /opt/sdk-backend-linux-x64/ # Asginar permisos de ejecución
./index # Levantar el backend del SDK

Al levantar el backend veremos en pantalla la versión y el puerto en el que se encuentra escuchando el Web Services como se muestra en la
imagen.

Paso 5: Asignar permisos y levantar simulador para realizar pruebas

Mover la carpeta llamada simulador-cajapos-linux-x64 (para arquitectura de 64bits) al directorio /opt/ y luego asignar los permisos de
ejecución para el ejecutable.

Comando

sudo chmod 775 -R /opt/simulador-cajapos-linux-x64/simulador-cajapos # Asignar permisos

./simulador-cajapos # Ejecutar simulador

También podemos levantar el simulador para pruebas por entorno gráfico haciendo doble clic en el ejecutable simulador-cajapos y se
levantará la aplicación de pruebas, allí tendremos la opción de Listar Puertos para ver en que puerto se encuentra conectado nuestro POS y
podremos usar las opciones disponibles en el backend para venta contado o en cuotas. Para hacer las pruebas debemos cargar la IP y PUERTO
del backend así como también podemos activar el protocolo TCP/IP si tenemos configurada esta opción en el backend.
CONFIGURACIONES
Backend como servicio de Windows

Paso 1: Instalar SrvStart

Para realizar esta tarea, lo primero que debemos hacer es copiar los archivos contenidos en la carpeta SrvStart.zip estos lo podemos alojar en el
directorio C:\Windows

Paso 2: Modificar el archivo BancardSDK.ini

Debemos modificar el archivo para agregar la dirección donde se encuentra nuestro SDK, en el ejemplo nuestro directorio es C:\sdk-backend-
windows-x64\index.exe
Paso 3: Utilizar el simbolo de Sistema para crear el nuevo servicio
El siguiente paso es utilizar el comando Controlador de servicios de Windows (SC) para crear el nuevo servicio basado en los criterios
establecidos en el archivo de configuración. Abrimos el símbolo de sistema, haz clic en el menú Inicio, escribe “Símbolo de Sistema”, luego clic
derecho y “Ejecutar como administrador” en la ventana de control de cuentas damos clic en Sí.

En el símbolo de sistema, utiliza el siguiente comando para crear el nuevo servicio:

Comando

SC CREATE BancardSDK Displayname= "BancardSDK" binpath= "srvstart.exe BancardSDK -c C:

\Windows\BancardSDK.ini" start= auto

Cuando se ejecute el comando, debes recibir un mensaje satisfactorio como en la imagen siguiente:

Observación

Cuando se crea el servicio la primera vez debemos arrancarlo, caso contrario recién estará corriendo al reiniciar el equipo.

De ahora en adelante, tu nuevo servicio se ejecutará cada vez que se inicie Windows. Si abres la interfaz de servicios de Windows (haz clic en
Inicio y escribe «Servicios»), puedes encontrar y configurar el nuevo servicio al igual que con cualquier otro.
Controlar servicio desde el Símbolo de Sistema

Comandos

SC start BancardSDK # Levanta el servicio

SC stop BancardSDK # Detiene el servicio
SC delete BancardSDK # Elimina el servicio

Una vez realizado estos pasos nuestra API se estará ejecutando cada vez que iniciemos el Sistema Operativo.

Backend como servicio de Linux

Paso 1: Crear archivo de configuración para systemctl

Para realizar esta tarea, lo primero que debemos hacer es situarnos en la ruta donde se guardan todos los servicios de Linux y luego crear y
editar el siguiente archivo llamado bancard-integracion.service

Comando

cd /etc/systemd/system/ # Ingresar al directorio de los servicios

sudo nano bancard-integracion.service # Editar un archivo nuevo con el editor nano

Ahora debemos agregar el siguiente contenido para crear nuestro servicio personalizado y hacer, además, que se ejecute automáticamente al
inicio de nuestro servidor Linux:

bancard-integracion.service

[Unit]
Description=Bancard SDK Integracion Caja POS
After=multi-user.target

[Service]
Type=simple
ExecStart=/opt/sdk-backend-linux-x64/index # Solo funcionará si nuestro SDK se encuentra en /opt/
User=root
StandardOutput=syslog
StandardError=syslog

[Install]
WantedBy=multi-user.target

Guardamos y salimos con Ctrl+o y Ctrl+x, y ya tenemos el servicio definido y configurado en /etc/systemd/system/bancard-integracion.service

Paso 2: Activar y controlar el servicio

 Ahora vamos a incluirlo en la secuencia de arranque y activarlo con los siguientes comandos:

Comandos

sudo systemctl enable bancard-integracion.service # Habilita el servicio creado

sudo systemctl start bancard-integracion.service # Levanta el servicio la primera vez

Otros comandos útiles para el manejo del servicio

sudo systemctl stop bancard-integracion.service # Detiene el servicio

sudo systemctl restart bancard-integracion.service # Reinicia el servicio
sudo systemctl daemon-reload # Recarga todos servicios de systemctl

Una vez realizado estos pasos nuestra API se va a ejecutar cada vez que iniciemos el Sistema Operativo.

SERVICIOS REST DISPONIBLES

Una vez levantada la API en la PC se puede comunicar con el POS a través de peticiones REST. Se cuenta con dos opciones de venta.

Solicitud Venta Contado: Opción utilizada para realizar pago al contado y descuentos por BIN si los hubiera (no discrimina tipo de tarjeta
se realiza la transacción en un solo pago).
Solicitud Venta Cuotas: Opción utilizada para venta en cuotas.

Luego de obtener la respuesta del servicio solicitado se envía el monto a cobrar al siguiente servicio:

Envio del Monto: Opción para enviar Descuento o Monto de Transacción si no hubiera descuento por BIN.

También se tiene una llamada para verificar si el POS se encuentra conectado.

Mensaje Eco: Esta opción podría servir para agregar antes de hacer un pedido de venta y asegurarnos que el POS se encuentre conectado.

Solicitud Venta Contado

Método POST

URL localhost:port/pos/venta-ux

Query Opcionales.
Params
postHost: IP del POS.

posPort: Puerto del POS.

 JSON Entrada
Body

{
"facturaNro": 123456789,
"monto": 50000
}

Donde:

facturaNro: int(12) Corresponde al número de factura generado por el sistema.

monto: int(12) es el valor del monto inicial de la transacción mayor a 0.

Success HTTP/1.1 200 OK

Response
Body

{
"bin": "9999999999",
"nsu": "999999"
}

Donde:

bin: string(10) Corresponde al número BIN de la tarjeta asociada a la operación. Se puede utilizar este valor para realizar
descuentos según el tipo de tarjeta.

nsu: string(6) Código de operación interna entre el POS y el SDK. Este número debe ser enviado junto con el monto en el
servicio de Envío de monto.

Una vez recibido los datos del Servicio se envía el monto a cobrar y el nsu al servicio de Envío de monto

Error Status 500 : Error interno del SDK

Response
Status 400: Error de validación, error de transacción con el POS. Si la operación no se logra

Body

{
"statusCode": 400,
"error": "Bad Request",
"message": "No se pudo establecer conexión con el POS"
}

Es importante usar el campo message para mostrar en la pantalla del Sistema para una mejor interpretación
del usuario

Solicitud Venta Cuotas

Si ya cuenta con la versión del SDK 1.4.1 o superior basta con cambiar la URL del servicio por la que se encuentra a continuación y
esto debería funcionar igual.

Método POST

URL localhost:port/pos/venta-ux
Query Opcionales.
Params
postHost: IP del POS.

posPort: Puerto del POS.

JSON Entrada
Body

{
"facturaNro": 123456789,
"monto": 50000,
"cuotas": 12,
"plan": 1
}

Donde:

facturaNro: int(12) Corresponde al número de factura generado por el sistema.

monto: int(12) Monto inicial de venta.

cuotas: int(4) Cantidad de cuotas para el pago.

Valor 0 para ventas en un solo pago.

Valor mayor a 1 para ventas en cuotas (con valor 1 retornaría un error).

plan: int(4) Plan de pago para promociones o descuentos:

Valor 1 para pago en cuotas (cuando las cuotas son mayores a 1).
Valor 0 para ventas en un solo pago.

Success HTTP/1.1 200 OK

Response
Body

{
"bin": "9999999999",
"nsu": "999999"
}

Donde:

bin: string(10) Corresponde al número BIN de la tarjeta asociada a la operación. Se puede utilizar este valor para realizar
descuentos según el tipo de tarjeta.

nsu: string(6) Código de operación interna entre el POS y el SDK. Este número debe ser enviado junto con el monto en el
servicio de Envío de monto.

Una vez recibido los datos del Servicio se envía el monto a cobrar y el nsu al servicio de Envío de monto
 Error Status 500: Error interno del SDK
Response
Status 400: Error de validación, error de transacción con el POS. Si la operación no se logra

Body

{
"statusCode": 400,
"error": "Bad Request",
"message": "No se pudo establecer conexión con el POS"
}

Es importante usar el campo message para mostrar en la pantalla del Sistema para una mejor interpretación
del usuario

Solicitud Venta Forzado Débito

Esta opción se utiliza para forzar que la operación sea con una tarjeta de débito, por lo tanto si se utiliza este endpoint dará un error al
pasar una tarjeta de crédito.

Método POST

URL localhost:8081/pos/venta/debito

Query Opcionales.
Params
postHost: IP del POS.

posPort: Puerto del POS.

JSON Entrada
Body

{
"facturaNro": 123456789
}

Donde:

facturaNro: int(12) Corresponde al número de factura generado por el sistema.

Success HTTP/1.1 200 OK

Response
Body

{
"bin": "9999999999",
"nsu": "999999"
}

Donde:

bin: string(10) Corresponde al número BIN de la tarjeta asociada a la operación. Se puede utilizar este valor para realizar
descuentos según el tipo de tarjeta.

nsu: string(6) Código de operación interna entre el POS y el SDK. Este número debe ser enviado junto con el monto en el
servicio de Envío de monto.

Una vez recibido los datos del Servicio se envía el monto a cobrar y el nsu al servicio de Envío de monto
 Error Status 500: Error interno del SDK
Response
Status 400: Error de validación, error de transacción con el POS. Si la operación no se logra

Body

{
"statusCode": 400,
"error": "Bad Request",
"message": "No se pudo establecer conexión con el POS"
}

Es importante usar el campo message para mostrar en la pantalla del Sistema para una mejor interpretación
del usuario

Solicitud Venta Forzado Crédito

Esta opción se utiliza para forzar que la operación sea con una tarjeta de crédito, por lo tanto si se utiliza este endpoint dará un error
al pasar una tarjeta de débito

Método POST

URL localhost:port/pos/venta/credito

Query Opcionales.
Params
postHost: IP del POS.

posPort: Puerto del POS.

JSON Entrada
Body

{
"facturaNro": 123456789,
"cuotas": 12,
"plan": 1
}

Donde:

facturaNro: int(12) Corresponde al número de factura generado por el sistema.

cuotas: int(4) Cantidad de cuotas para el pago.

Valor 0 para ventas en un solo pago.

Valor mayor a 1 para ventas en cuotas (con valor 1 retornaría un error).

plan: int(4) Plan de pago para promociones o descuentos:

Valor 1 para pago en cuotas.

Valor 0 para ventas en un solo pago.
 Success HTTP/1.1 200 OK
Response
Body

{
"bin": "9999999999",
"nsu": "999999"
}

Donde:

bin: string(10) Corresponde al número BIN de la tarjeta asociada a la operación. Se puede utilizar este valor para realizar
descuentos según el tipo de tarjeta.

nsu: string(6) Código de operación interna entre el POS y el SDK. Este número debe ser enviado junto con el monto en el
servicio de Envío de monto.

Una vez recibido los datos del Servicio se envía el monto a cobrar y el nsu al servicio de Envío de monto

Error Status 500: Error interno del SDK

Response
Status 400: Error de validación, error de transacción con el POS. Si la operación no se logra

Body

{
"statusCode": 400,
"error": "Bad Request",
"message": "No se pudo establecer conexión con el POS"
}

Es importante usar el campo message para mostrar en la pantalla del Sistema para una mejor interpretación
del usuario

Envío de Monto
Método POST

URL IP:PORT/pos/descuento

Query Params postHost: IP del POS.

Opcional posPort: Puerto del POS.

JSON Entrada {
"bin": "9999999999",
"nsu": "999999",
"monto": 150000
}

Donde:

bin: string(10) Es el número BIN que fue respuesta del Paso 1.

nsu: string(6) Código de la operación que fue respuesta del Paso 1.

monto: int(12) Es el valor de descuento o monto de la transacción.

 Success HTTP/1.1 200 OK
Response
Body

{
"codigoAutorizacion": "575849",
"nroBoleta": "000270613845",
"codigoComercio": "5051107",
"nombreTarjeta": "VISA - PREPAGA - BANCO ITAU PY",
"pan": "1234",
"mensajeDisplay": "APROBADA",
"saldo": 150000,
"nombreCliente": "GONZALEZ/JOSE",
"issuerId": "VS"
"montoVuelto": 30000,
}

Donde:

codigoAutorizacion: string(6) Es el código de autorización generado por el POS.

nroBoleta: string(12) Corresponde al número de ticket.

codigoComercio: string(12) Identificador del comercio generado por el POS.

nombreTarjeta: string(40) Identificador de la tarjeta.

pan: string(4) Personal Account Number. Son los últimos 4 dígitos de la tarjeta.

mensajeDisplay: string(40) Mensaje enviado por el POS según el estado de la transacción.

saldo: int(12) Se envía cuando son tarjetas de débito que tienen saldo en cuenta.

nombreCliente: string(26) Nombre de la persona registrada en la tarjeta.

issuerId: string(2) Identificador del tipo de tarjeta utilizado.

montoVuelto: integer(12) Monto del vuelto ingresado en el POS.

Algunos campos pueden no aparecer, dependiendo del tipo de tarjeta utilizada, ningún campo puede ser
utilizado como requerido por el sistema.

Error Status 500: Error interno en el sdk

Response
Status 400: Transacción cancelada, transacción rechaza, pin inválido o error de validación

{
"statusCode": 400,
"error": "Bad Request",
"message": "Mensaje enviado por el POS"
}

Es importante usar el campo message para mostrar en la pantalla del Sistema para una mejor interpretación
del usuario

Verificación de conexión de POS - Mensaje ECO

Método POST

URL IP:PORT/pos/eco

Query Params postHost: IP del POS.

Opcional posPort: Puerto del POS.

 JSON Entrada {
"eco": 1,
}

Donde:

eco: int(2) Corresponde a un número de hasta dos dígitos a ser enviado al POS.

Success Response HTTP/1.1 200 OK

{
"eco": 1,
}

Donde:

eco: int(2) El POS retorna el mismo número enviado inicialmente

Error Response Status 500: Error interno del SDK

Status 400: Error de validación, error de transacción con el POS. Si la operación no se logra

{
"statusCode": 400,
"error": "Bad Request",
"message": "No se pudo establecer conexión con el POS"
}

Status 400: Error de rango. El número proporcionado supera el rango permitido, de 0 a 99

{
"statusCode": 400,
"error": "Bad Request",
"message": "Error de rango: 299"
}

TABLA DE ISSUER ID's

Marca Tipo IssuerID

AMERICAN EXPRESS Crédito AC

BANCARD Crédito BC

CABAL Crédito CB

CARTA CLAVE Crédito CL

CREDICARD Débito IC

CREDICARD Crédito PC

CREDIFIELCO Crédito CC

DINERS CLUB Crédito DC

INFONET Débito ID

MASTERCARD Crédito MC

MASTERCARD Débito MD

PANAL Crédito CP

UNICA Débito UD

VISA Crédito VC
VISA Débito VD

VISA LOCAL Crédito VS

TARJETA CREDITO Crédito TC

TARJETA DEBITO Débito TD