API – Developers Docs API – Developers Docs
  • Cyberpac
  • Addon Payments
  • Pagos integrados en TPV
  • Inglés
API – Developers Docs API – Developers Docs
API – Developers Docs
  • Cyberpac
  • Addon Payments
  • Pagos integrados en TPV
  • Inglés

Pagos integrados en TPV

  • Icono de carpeta cerrada Icono de apertura de carpetaPago integrado con TPV Android
    • InStore Payment API Android
    • InStore Payment API Windows
    • InStore Payment REST API
  • Icono de carpeta cerrada Icono de apertura de carpetaPago integrado con Smartphone TPV
    • Integración de pago con Smartphone TPV
  • Icono de carpeta cerrada Icono de apertura de carpetaPagos integrados en TPV
    • Transacciones
      • Tokenización
    • Reportes
    • Dispositivo
  • Icono de carpeta cerrada Icono de apertura de carpetaIntegración Host2Host – Protocolo POI-Switch
  • Icono de carpeta cerrada Icono de apertura de carpetaFichas Técnicas TPVs

InStore Payment API Windows

  • Versión: 2.08.04

Introducción

Con el InStore Payment Api Service podrás realizar pagos de forma fácil y segura desde una caja registradora o quiosco de Windows utilizando un terminal de pago en modo inalámbrico.

Esta guía describe cómo instalar el servicio en un dispositivo Windows y cómo comunicarse con él mediante REST API.

Consulta la siguiente sección para probar esta API en un «modo dummy», es decir, sin conexión con un aplicación de pago real.

Avisos importantes

Por favor, sigue estas advertencias importantes:

  1. No copiar archivos entre PCs: Bajo ninguna circunstancia se deben copiar los archivos o carpetas asociados a este software de un ordenador a otro. Hacerlo puede provocar errores críticos, corrupción de datos o fallos irreversibles en el sistema. Este software ha sido configurado específicamente para el equipo en el que fue proporcionado. Transferir los archivos a otro dispositivo sin la debida autorización o configuración está estrictamente prohibido y no es compatible.
  2. Clonación o creación de imágenes de PCs: Si se va a clonar o crear una imagen de un PC, debe desinstalarse el servicio WECR antes de crear la imagen y reinstalarse después en el nuevo sistema. No seguir este procedimiento puede causar conflictos de configuración, fallos del servicio o comportamientos inesperados. Cada instancia del servicio WECR debe instalarse y registrarse de forma única en su respectivo equipo.
  3. Utilizar solo el archivo ejecutable (.exe) proporcionado: No intentes mover, duplicar o modificar ninguno de los archivos de soporte o directorios asociados.

El incumplimiento de estas instrucciones puede hacer que la aplicación deje de funcionar y anular cualquier acuerdo de soporte o garantía.

Archivos proporcionados

Con esta guía recibirás un archivo InStorePaymentApiInstallerVxx.xx.exe.

Muy importante:

El archivo InStorePaymentApiInstallerVxx.xx.exe debe ejecutarse en modo administrador:

  • Copia el archivo InStorePaymentApiInstallerVxx.xx.exe en la carpeta desde la que lo vas a ejecutar.
  • Abre/Utiliza una de estas opciones:
    • Usa una ventana de Cmd con permisos de administrador con el parámetro /s.
    • Usa PowerShell (Terminal de administrador).

Instalar InStorePaymentApi con el archivo del instalador de Windows

1. Haz doble clic en InStorePaymentApiInstallerVxx.xx.exe o escribe el siguiente comando en la consola, como se muestra en la imagen:

2. Una vez que ejecutes este archivo .exe, el servicio se instalará y se ejecutará automáticamente.

3. Puedes seguir el proceso en la consola, como se muestra en esta imagen:

4. La consola se cerrará automáticamente 5 segundos después de que finalice el proceso.

5. Finalmente, si todo funciona correctamente, el sistema generará un archivo CurrentVersion.txt que incluye la versión del software que se instaló.

Estructura de carpetas después de la instalación del servicio

Una vez que ejecutes este archivo .exe para la instalación, encontrarás la siguiente estructura de carpetas:

  • Carpeta «Cer»: Certificados Signal R.
  • Carpeta db: Archivos privados.
  • Carpeta dbt: Archivos privados.
  • Carpeta «Static»: Contenido HTML de la página web de registro.
  • Archivo «Config.json»: Archivo de configuración de comunicación.
  • Archivo «InStorePaymentApi.exe»: Ejecutable de InStorePaymentApi.
  • «InStorePaymentApiRegister»: Enlace para iniciar el proceso de emparejamiento en un navegador web (necesario solo para completar el emparejamiento en Windows).
  • Archivo «Nssm.exe»: Instalador de servicios para Windows.
  • CurrentVersion.txt: Muestra la versión instalada.
  • Archivo Installer.log: Log de instalación.
  • Archivo Daemon.exe: Controlador de servicios Windows.

Estructura de carpetas después de la instalación del servicio FIX IP

Una vez que ejecutes este archivo .exe para la instalación, encontrarás la siguiente estructura de carpetas:

  • Carpeta «Cer»: Certificados Signal R.
  • Archivo «Config.json»: Archivo de configuración de comunicación.
  • Archivo «InStorePaymentApi.exe»: Ejecutable de InStorePaymentApi.
  • «InStorePaymentApiRegister»: Enlace para iniciar el proceso de emparejamiento en un navegador web (necesario solo para completar el emparejamiento en Windows).
  • Archivo «Nssm.exe»: Instalador de servicios para Windows.
  • CurrentVersion.txt: Muestra la versión instalada.
  • Archivo Installer.log: Log de instalación.
  • Archivo Daemon.exe: Controlador de servicios Windows.

Requisitos

Estos son los requisitos para integrar:

  • Un dispositivo Microsoft Windows, con Windows 7 (64-bit) o superior.
  • Debido a que la conexión con la aplicación de pago se gestiona mediante este servicio a través de Wifi o 4G, la conexión a Internet es obligatoria.
  • Necesitas deviceId del terminal de pago que recibirá la solicitud de pago.
  • Se debe realizar el proceso de emparejamiento con el terminal de pago. Ver proceso de emparejamiento.
  • El dispositivo Android debe ejecutar una versión entre Android 5.1 y Android 14, ambas inclusive.

Proceso de emparejamiento

Se pueden emparejar el terminal de pago y la ECR. Es obligatorio para permitir a la ECR administrar el id del dispositivo.

Si estás trabajando con una red Proxy, consulta esta sección.

Hay dos procesos de emparejamiento:

  1. En el terminal de pago, abre «InStorePaymentApiRegister«. Verás la siguiente pantalla:

En el PC, ve a la carpeta de instalación y haz clic en el archivo «InStorePaymentApiRegister«. La siguiente página web se abrirá en tu navegador web predeterminado:

2. Este es el flujo para emparejar el terminal con la PC:

a. En el PC haz clic en el botón de registrarse por primera vez en la página web.
b. En el Terminal, haz clic en el Escanear y lee el código QR de la página web.
c. Finalmente, podrás escuchar un pitido en el terminal.
d. PAIRED OK aparece en el texto del botón cuando el terminal ya está emparejado.

1. En el terminal de pago, abre «InStorePaymentApiRegister«. Verás la siguiente pantalla:

2. En la PC, ve a la carpeta de instalación y haz clic en el archivo «InStorePaymentApiRegister«. La siguiente página web se abrirá en tu navegador web predeterminado. Copia el «Device ID» mostrado en el primer paso en la casilla que aparece en la siguiente captura de pantalla, luego haz clic en «Register».

3. Después de unos segundos, el dispositivo se emparejará, y el botón «Register» cambiará a «Registered manually».

Cómo configurar el modo proxy

1. Cambia el modo de configuración en el archivo config.json. Establece «mode» de «B» a «S».

				
					i. {
"port": "3000",
"key":"2",
"mode":"S",
"retries" :600
}
				
			

2. Lado del servidor proxy:

  • Puertos que deben estar abiertos en el lado del servidor proxy:

    1. 53, 80, 443, 883, 1883
  • URLs que deben permitirse en el lado del servidor proxy:

    1. https://login.microsoftonline.com
    2. https://ingenicoapi.azurewebsites.net
    3. https://ingenicoapi.service.signalr.net

3. Emparejamiento manual en modo proxy:

  • Copia el número “ID de dispositivo” del terminal en el cuadro de texto «Terminal name» o “Nombre del terminal” en la página web.
  • Pulsa el botón Registrar.
  • «Registered Manually» o «Registrado manualmente» aparecerá cuando el registro se realice correctamente.

Volver al modo de funcionamiento estándar

Si deseas que InStorePaymentApi funcione en una red sin tecnología Proxy (y previamente cambiaste al modo Proxy), necesitarás volver al modo de operación estándar.

En caso de que el sistema requiera volver al funcionamiento normal (sin modo proxy), sigue estos pasos:

  • Detén InStorePaymentApi
  • Borra las carpetas db y dbt de la ruta de instalación: C:\Comercia\InStorePaymentApi
  • Cambia el modo de configuración en el archivo config.json. Establece «mode» de «S» a «B».
				
					i. {
"port": "3000",
"key":"2",
"mode":"B",
"retries": 600
}
				
			
  • Inicia InStorePaymentApi
  • Empareja de nuevo en el terminal en modo QR con ECR. Consulta la sección de emparejamiento QR de esta guía.

Secure Sockets Layer (HTTPS) (Modo predeterminado)

Si deseas que InStorePaymentApi funcione en modo SSL, sigue las siguientes instrucciones:

  • Añade el siguiente campo en el archivo config.json.
    • «SSL»:»True»
				
					i. {
"port": "3000",
"key":"2",
"mode":"B",
"SSL":"True",
"retries": 600
}
				
			
  • Usa IngenicoPaymentServiceRegisterHttps para registrar el dispositivo en modo HTTPS.

Nota: Esta versión utiliza el modo HTTPS de forma predeterminada.

Proceso de emparejamiento usando IP Fija

Si quieres que InStorePaymentApi funcione con IP Fija, sigue las siguientes instrucciones:

  • Fija la IP fija en «terminalIp».
  • Fija el modo en «F».
				
					{
"port": "3000",
"url": "localhost",
"terminalIp": "192.168.55.105:3000",
"staticIptimeOut": 5,
"key":"3",
"mode":"F",
"SSL":"True",
"startTecnology": "pushy",
"loopsBefore": 2,
"timeStop": 240,
"retries": 600
}
				
			

Nota: Ver Anexo 1 para ver como fijar una IP en un terminal Ingenico.

Llamar a endpoints HTTPS con un certificado personalizado

Para explicar cómo se pueden establecer conexiones HTTPS seguras, se proponen las siguientes recomendaciones, utilizando el programa Postman como ejemplo de una caja ECR.

El problema

Al realizar una llamada a un endpoint HTTP, normalmente Postman verifica que el certificado del servidor sea válido y haya sido generado por una autoridad conocida.

Cuando el servidor utiliza un certificado personalizado, este no ha sido generado por una autoridad conocida y, por defecto, la solicitud se bloquea mostrando el siguiente mensaje:

"Error: Unable to get local issuer certificate"

Que básicamente nos indica que no es capaz de no relacionar el certificado con una autoridad conocida. 

Soluciones

Este problema tiene 2 soluciones posibles.

1. Desactivar la verificación de certificado SSL

Esta solución desactiva la verificación de certificados SSL en Postman, lo que permitirá certificados personalizados. Sigue estos pasos:

  1. Entra a Postman.
  2. En la barra superior clica el engranaje y luego en Settings.
  3. En la pestaña de General, desmarca la opción SSL certificate verification.

2. Añadir el certificado como válido

Para esta solución, sigue estos pasos:

  1. Añade una entrada al archivo «hosts» de Windows para resolver el nombre DNS establecido en el certificado hacia la IP del terminal. Este archivo se encuentra en Windows en: «C:\Windows\System32\drivers\etc\hosts».
  2. Añade la siguiente línea: {device-ip} instorepaymentapi.globalpayments.es {device-ip} es la IP del dispositivo Android que tiene la API REST.
  3. Asegúrate que la opción de SSL certificate verification está MARCADA. «Settings» > «General» > «SSL certificate verification».
  4. En la barra superior clica el engranaje y luego en Settings.
  5. En la pestaña Certificates, activa la opción CA Certificates.
  6. Añade el certificado en formato PEM.

Comprueba que el certificado se ha resuelto correctamente siguiendo estos pasos:

    1. Realiza la llamada a la API utilizando el nombre DNS establecido en el archivo «hosts».
    2. Por ejemplo, para solicitar la versión serial: https://instorepaymentapi.globalpayments.es:3000/v1/getVersion
    3. Si el certificado se ha resuelto correctamente, el icono de conexión segura (círculo con candado) aparece gris, en vez de rojo. 

Instalar certificados CA en Windows

Para la aplicación API Rest, es necesario instalar los certificados. En esta sección, se explica paso a paso cómo hacerlo en Windows.

Es probable que, en algunas aplicaciones desarrolladas a medida, sea necesario consultar con el desarrollador para determinar la ruta correcta en la que deben instalarse estos certificados.

Este manual proporciona una guía paso a paso para instalar los certificados y verificar que la instalación se ha realizado correctamente.

Requisitos previos:

  • CGP v04.11.07 o superior
  • instprepaymentapi
  • instprepaymentapirest
  • instprepaymentapisecurity
  • HAL

Paso 1: Añade la dirección IP de tu terminal en la siguiente ruta:

  • C:\Windows\System32\drivers\etc

Abre el archivo hosts como administrador y añade la dirección IP junto con la URL correspondiente: 

Paso 2: Abre la siguiente URL en tu navegador web para probar la conexión:

  • https://instorepaymentapi.globalpayments.es:3000/v1/getVersion

Paso 3: Descarga el certificado «caroot.cert» y cámbiale el nombre a «caroot.cer«

  • caroot.cer

Paso 4: Haz doble clic en el arcivo y sigue el proceso de instalación: 

Puedes ver el proceso en las siguientes capturas: 

Anterior
Siguiente
Paso 5: Abre la siguiente URL en tu navegador para comprobar la conexión:
  • https://instorepaymentapi.globalpayments.es:3000/v1/getVersion

Solución para solicitudes CORS

Si recibes este mensaje: «Las solicitudes CORS se han implementado y configurado correctamente para permitir el acceso seguro a nuestros recursos desde diferentes orígenes.» o «CORS requests have been successfully implemented and configured to allow secure cross-origin access to our resources.».

Esta es la explicación:

  • CORS (Cross-Origin Resource Sharing) es una característica de seguridad implementada por los navegadores que restringe o permite que las páginas web de un dominio realicen solicitudes para acceder a recursos en otro dominio. Al configurar correctamente los encabezados CORS, garantizamos que solo los dominios autorizados puedan acceder a nuestros recursos, evitando posibles vulnerabilidades de seguridad.

Configuración de la arquitectura del cliente (URLs e IPs que añadir)

Para garantizar el correcto funcionamiento de la solución InStorePaymentApi, se recomienda tener en cuenta una lista de ciertas URL e IP en el router o punto de acceso del cliente, ya que estas direcciones pueden ser invocadas eventualmente por los diferentes elementos involucrados en todo el proceso de pago: el servicio InStorePaymentApi, el propio TPV, entre otros.

IPs para dispositivos Android

Estas son las direcciones que siempre deben estar permitidas en cualquier arquitectura que utilice la solución InStorePaymentApi en dispositivos Android:

URL / IP / Port
2.android.pool.ntp.org
asia.pool.ntp.org
http://connectivitycheck.gstatic.com
http://play.googleapis.com
http://www.googleapis.com/generate_204
http://developers.google.com
https://www.google.com
https://api.pushy.me/
supl.qxwz.com
https://info.izatcloud.net
https://gtp1.izatcloud.net:443/uds/v2 / /v3
http://*.izatcloud.net / https://*.izatcloud.net
time.xtracloud.net

IPs para servicios Windows

Estas son las direcciones que siempre deben estar permitidas en cualquier arquitectura que utilice la solución InStorePaymentApi en servicios Windows:

URL / IP / Port
https://login.microsoftonline.com/
14508.ingest.sentry.io:443
.ingest.sentry.io:443
47.107.21.255:1900
https://ajax.aspnetcdn.com/ajax/jQuery/jquery-3.2.1.min.js

Servicios Personalizados o Compartidos

Estas son las direcciones que siempre deben estar permitidas en cualquier arquitectura que utilice la solución InStorePaymentApi:

URL / IP / Port
https://servicioterminalesautoinstalablesingenico.cestrack.net/…
https://ingenicoclientprostorage.z6.web.core.windows.net
https://apps.comerciacloud.com/api/
https://parameters.comerciacloud.com/parameters/api/
https://ticketdigital.in/
https://ingenicoapi.table.core.windows.net/
https://ingenicoapi.azurewebsites.net
https://ingenicoapi.service.signalr.net
https://tpvandroid.gmedia.ovh/
comswtfppzne02.trafficmanager.net:10020
51.138.108.206:10020
https://axyun.unimarspay.com:4443
https://axyun.ingenico-axcloud.net:8100/8101
http://firmwareota.unimarspay.com/aposfile/
http://axyun.ingenico-axcloud.net:81/aposFile/
https://slm-portal.icloud.ingenico.com/
tem-terminals-eu.icloud.ingenico.com:1883
Además, se debe permitir el protocolo ICMP, ya que los terminales utilizan esta tecnología y, por lo tanto, algunas comunicaciones no están asociadas a ningún puerto.

IPs de QA

A continuación tienes las IPs que tienes que añadir para QA: 

comswtfppzne03.trafficmanager.net:10020
https://tem-terminals-eu.preprod.icloud.ingenico.com 7037
https://tem-terminals-eu.preprod.icloud.ingenico.com 1883
https://tem-terminals-eu.preprod.icloud.ingenico.com 7022
https://cgp-terminalstest-apim-dev-dmz.azure-api.net/parameters/api/terminalparams
213.0.68.223:10011
35.233.8.200: 7046
comswtfprzwe07.trafficmanager.net:10020
comswtfprzwe03.trafficmanager.net:10020
20.73.126.179:10020
https://appspre.comerciacloud.com/api/raw/
Ingenicoapi-signalr-qa-as.azurewebsites.net

 

Definición API

La API REST está definida en Swagger. Visítalo para verificar la API. Puedes probarlo usando la aplicación POSTMAN o similar en tu dispositivo Windows. 

Extensión del esquema ECR de Windows

Esta sección amplía la explicación del esquema de caja registradora con el sistema operativo Windows, analizando los flujos de comunicación entre componentes, además de los diferentes tiempos de espera que se manejan, posibles errores que el integrador debe tener en cuenta, entre otros.

La solución que opera en ordenadores con Windows emparejadas con los terminales de pago Comercia es la que facilita a los integradores que han desarrollado una solución de caja registradora la posibilidad de ejecutar pagos de manera sencilla en el TPV.

Lo único necesario es que tanto el ordenador con Windows como el terminal de pago tengan acceso a Internet y que ambos dispositivos estén emparejados entre sí.

El esquema arquitectónico que sigue esta solución es el siguiente:

Esta solución está compuesta por los siguientes elementos:

  • Conector ECR: Es una aplicación instalada en la caja registradora (Windows ECR) que implementa un servicio API-REST para escuchar las llamadas provenientes de la aplicación del integrador.
  • InStorePaymentApi: Es una aplicación instalada en el terminal de pago (Android) que está constantemente escuchando solicitudes del tipo PUSH o WEBSOCKETS, originadas por el conector ECR.
  • Conector AzureCloud: Es el servicio en la nube Azure encargado de gestionar la base de datos que registra todas las transacciones realizadas en el terminal de pago, además de permitir la conexión entre la caja registradora (ECR) y los terminales de pago.
  • Servidor Pushy.me: Es un servicio en la nube que facilita la conexión entre la caja registradora (ECR) y los terminales de pago.

La conexión y comunicación entre la caja registradora (ECR) y los terminales se puede realizar mediante notificaciones de tipo PUSH o a través de WEBSOCKETS mediante un servicio de Azure llamado SignalR:

  • Pushy: Es una solución multiplataforma basada en el protocolo MQTT que permite enviar notificaciones PUSH utilizando identificadores únicos y autogenerados para cada dispositivo, evitando así problemas como las direcciones IP dinámicas.
  • SignalR: Es un sistema de llamadas entre dispositivos y un servidor Azure realizado a través de websockets, que permite ejecutar cualquier tarea que el servidor Azure sea capaz de realizar. De esta manera, se pueden establecer canales de comunicación entre diferentes dispositivos utilizando identificadores, así como registrar el uso de la API en una base de datos.

De forma predeterminada, esta solución utiliza la conexión mediante notificaciones PUSH, pero está diseñada para que, en caso de interrupciones en la comunicación o fallos en el servicio, el sistema cambie automáticamente de tecnología, manteniendo siempre un canal de comunicación operativo.

Además del flujo normal que siguen las transacciones (flechas rojas), existe otro uso del AzureCloud Connector, que es el registro de todas las operaciones realizadas en los terminales de pago (flechas naranjas). Para ello, tanto el conector ECR como el InStorePaymentApi se registran automáticamente en dicha nube, siendo el InStorePaymentApi el encargado de actualizar la base de datos gestionada por el AzureCloud Connector al final de cada transacción.

Las conexiones establecidas por el terminal con los servidores Pushy.me y Azure se realizan cada vez que el terminal se enciende y se mantienen de manera indefinida, siempre y cuando no haya interrupciones en la conexión u otros errores. En caso de que el terminal detecte el cierre de alguna de estas conexiones, procederá a registrarse nuevamente. Esto puede ocurrir, por ejemplo, cuando el terminal cambia de router al conectarse a una red WiFi, o cuando cambia de operador móvil mientras está en roaming.

Flujo de transacción básico

Una transacción estándar, por ejemplo, una venta, será iniciada en la aplicación del integrador. A través del servicio API-REST del conector ECR, se informará el tipo de transacción que se está solicitando, incluido el importe. Un ejemplo de una venta de 10.00 € sería:

				
					{ 
    "deviceId": "{{DeviceID}}", 
    "transactionId": "{{transactionId}}", 
    "paymentApp": "comercia", 
    "amount": 1000, 
    "currencyCode": "EUR", 
    "otherData": { 
        "printReceipt": 0 
    } 
}
				
			

A continuación, el conector ECR enviará la solicitud al terminal de pago a través del canal de comunicación activado en ese momento: Pushy o SignalR. El canal de comunicación no se cambiará a menos que ocurra algún tipo de problema, como la imposibilidad de conectar con los servidores; pero si no hay errores, siempre se mantendrá el mismo canal.

Una vez que la solicitud sea recibida en el terminal de pago, la aplicación InStorePaymentApi lanzará la transacción en la aplicación de pago Comercia C2.0 mediante una conexión AIDL. La aplicación de pago, identificada como “My POS”, es la encargada de ejecutar todo el proceso de pago:

  • Lectura de la tarjeta: en caso de error de lectura, realiza reintentos hasta obtener una correcta o agotar los intentos, cancelando la transacción si no se logra.
  • Solicitud del PIN, si es necesario.
  • Comunicación con el servicio autorizador de Comercia: en caso de fallos de conexión, realiza automáticamente las cancelaciones pertinentes, informando al terminal de caja Windows del resultado.
  • Muestra del resultado final (transacción aceptada o rechazada) en pantalla para que el cliente pueda verificarlo.

Cuando la transacción financiera se haya completado en My POS, se preparará una respuesta que será enviada de regreso a la aplicación del integrador, utilizando el mismo canal de comunicación que se empleó en la solicitud original.

El siguiente diagrama representa el flujo de una transacción estándar sin fallos:

Funcionamiento del conector ECR

El servicio API-REST que implementa el conector ECR en equipos con sistema operativo Windows se mantiene en escucha constante mientras está en ejecución.

Cuando recibe una solicitud para realizar una transacción desde la aplicación integradora, el conector ECR transfiere la solicitud al terminal de pago y espera una respuesta con el resultado final de la transacción. Es en el momento de recibir dicha respuesta cuando informa a la aplicación integradora a través de la API-REST.

Mientras el conector ECR espera la respuesta del terminal de pago, establece internamente tiempos máximos de espera para mitigar demoras en caso de fallos, como la caída de la red o el apagado inesperado del terminal de pago. Este tipo de errores podrían hacer que el conector ECR espere indefinidamente una respuesta, lo que impediría a la aplicación integradora saber si la transacción fue aceptada o rechazada, causando posibles perjuicios.

El proceso que sigue el conector ECR para evitar esta situación consiste en consultar al POS cada 10 segundos si el proceso de pago sigue en curso. Si la transacción aún está en proceso y el terminal de pago sigue conectado a Internet, este enviará una respuesta al conector ECR indicando que todo sigue correcto, aunque aún no haya un resultado final. Cabe destacar que una transacción estándar puede tardar entre 30 y 40 segundos, y más de 1 minuto si se requiere la introducción del PIN de la tarjeta.

Si el conector ECR recibe una respuesta indicando que no hay transacción en curso, se realizará una consulta a la base de datos para verificar cómo terminó la operación. Esto permite mitigar posibles errores en el envío de la respuesta desde el terminal de pago hacia el sistema ECR de Windows.

Por otro lado, si el conector ECR no recibe respuesta en esta situación, realizará 2 intentos adicionales para conocer el estado del terminal de pago. Si tras el tercer intento (es decir, 30 segundos después de iniciar la transacción) no se obtiene respuesta, se realizará un cambio de tecnología: de Pushy a SignalR o viceversa.

Una vez realizado este cambio a la tecnología de respaldo, se realizarán nuevas consultas al terminal de pago para conocer su estado. Si nuevamente se producen 3 intentos sin respuesta, el conector ECR finalizará la conexión y notificará a la aplicación integradora que la transacción ha concluido con un error de tiempo de espera (timeout error).

El siguiente flujo explica los reintentos en caso de que el terminal de pago se haya desconectado de Internet:

Anexo 1: Cómo configurar una IP fija en el Terminal Android de Ingenico

El propósito de este anexo es proporcionar una guía para configurar una IP estática en los terminales AXIUM y APOS.

Guía paso a paso para terminales AXIUM:

  1. Desliza la barra de notificaciones y haz clic en «Ajustes».
  2. Introduce la contraseña de configuración y haz clic en «Aceptar».
  3. Haz clic en «Redes e Internet».
  4. Selecciona «Wi-Fi».
  5. Elige la red preferida de las opciones disponibles.
  6. Haz clic en el ícono del lápiz en la esquina superior derecha.
  7. Selecciona «Opciones avanzadas».
  8. Busca la opción de protocolo «DHCP» y cámbiala a «IP estática».
  9. Introduce la dirección IP y la puerta de enlace.
  10. Haz clic en «Guardar».
Comparte este documento

InStore Payment API Windows

Copiar el enlace

Icono del portapapeles
Tabla de Contenidos

Productos

  • Cyberpac
  • Addon Payments
  • Pagos integrados en TPV
  • Universal Pay
  • Addon 1 - XML API Integration

Ventas

Cuéntanos cómo es tu negocio para ofrecerte la mejor solución.

Contacta con un experto

Soporte técnico

¿Ya eres cliente y necesitas ayuda? Contacta con nosotros, estamos a tu disposición.

Ayuda

Socios

Trabajamos con los mejores partners de soluciones in-store y eCommerce. ¿Quieres unirte?

Únete a nosotros

© Comercia Global Payments

Política de privacidad
Ejercicio de Derechos
Información a Clientes
Canal de denuncia
Aviso Legal
Política de cookies
Pregúntale a la IA
Escribe tu pregunta. Por ejemplo: ¿Cómo creo un enlace de pago?
La SmartWiki puede omitir datos. Verifica la información o contacta con soporte.

SmartWiki, Impulsada por IA

API - Developers Docs
Gestionar el consentimiento de las cookies
Para ofrecer las mejores experiencias, utilizamos tecnologías como las cookies para almacenar y/o acceder a la información del dispositivo. El consentimiento de estas tecnologías nos permitirá procesar datos como el comportamiento de navegación o las identificaciones únicas en este sitio. No consentir o retirar el consentimiento, puede afectar negativamente a ciertas características y funciones.
Funcional Siempre activo
El almacenamiento o acceso técnico es estrictamente necesario para el propósito legítimo de permitir el uso de un servicio específico explícitamente solicitado por el abonado o usuario, o con el único propósito de llevar a cabo la transmisión de una comunicación a través de una red de comunicaciones electrónicas
Preferencias
El almacenamiento o acceso técnico es necesario para la finalidad legítima de almacenar preferencias no solicitadas por el abonado o usuario
Estadísticas
El almacenamiento o acceso técnico que es utilizado exclusivamente con fines estadísticos. El almacenamiento o acceso técnico es necesario para la finalidad legítima de almacenar preferencias no solicitadas por el abonado o usuario
Marketing
El almacenamiento o acceso técnico es necesario para crear perfiles de usuario para enviar publicidad, o para rastrear al usuario en una web o en varias web con fines de marketing similares.
Administrar opciones Gestionar los servicios Gestionar {vendor_count} proveedores Leer más sobre estos propósitos
Ver preferencias
{title} {title} {title}

Cyberpac

Consulta la documentación de Cyberpac. Aquí tienes las distintas secciones:

Canales

Módulos de integración

Integraciones a medida

Consulta la documentación de las distintas secciones de integraciones:

Comienza a integrar

undraw_add_to_cart_re_wrdo 1 (1) (1)

Plugins para CMS

Complementa la integración

SDKs

Métodos de pago

Herramientas

Addon Payments

Consulta la documentación de Addon Payments. Aquí tienes las distintas secciones:

Integraciones

Consultas frecuentes

Portal Backoffice

Pagos integrados en TPV

Crea una solución que te ayudará a automatizar procesos. Incluso, podrás agregar procesos de pago en terminales físicos.

Pago integrado con TPV Android

Pago integrado con Smartphone TPV

Fichas Técnicas TPVs