Saltar al contenido
XSIS
Hable con un ingeniero

Integraciones

Integración de pagos y POS

Pagos con tarjeta y POS conectados de extremo a extremo, del terminal a la contabilidad

Integraciones ISO 8583 y con pasarelas de pago, terminales EMV, archivos de liquidación del adquirente y sincronización de ventas e inventario entre el POS y el ERP.

Visión general

Un pago con tarjeta pasa por varios sistemas en pocos segundos: el terminal o el proceso de pago en línea, una pasarela de pago, el adquirente, la red de tarjetas y el emisor. Un día después, el dinero y las comisiones llegan en archivos de liquidación que alguien tiene que conciliar con las ventas de su ERP. Una venta en tienda también modifica el inventario, los precios y la contabilidad. Cuando estos sistemas no coinciden, el equipo de finanzas persigue las diferencias a mano.

Integramos terminales EMV y procesos de pago en línea con pasarelas de pago y adquirentes, usando ISO 8583 cuando el adquirente lo admite y la API de la pasarela cuando no. Procesamos los archivos de liquidación y de comisiones, y conectamos los sistemas POS con su ERP para que las ventas, las devoluciones, el inventario y los precios estén sincronizados en todas las tiendas.

Diseñamos para mantener los datos de tarjeta fuera de sus sistemas siempre que sea posible, mediante tokenización y páginas de pago alojadas, lo que reduce la parte de su entorno tecnológico a la que se aplica PCI DSS. Cada flujo se prueba en el entorno de pruebas del proveedor, se lanza primero como piloto en un número reducido de tiendas y se monitoriza una vez en funcionamiento.

Qué entregamos

  1. Mapa de pagos y POS

    Cada tipo de terminal, proceso de pago, pasarela, adquirente y sistema POS incluido en el alcance, con los formatos y el ciclo de liquidación de cada uno.

  2. Integración con pasarelas y adquirentes

    Flujos de autorización, captura, reembolso y reversión, sobre ISO 8583 o la API del proveedor, con cada código de respuesta gestionado.

  3. Integración de terminales

    Terminales EMV con chip y sin contacto conectados a su software de POS o de quiosco, con el protocolo de terminal del proveedor.

  4. Tokenización y alcance de PCI DSS

    Un diseño que sustituye los números de tarjeta por tokens y un análisis documentado de qué sistemas siguen dentro del alcance de PCI DSS.

  5. Procesamiento de archivos de liquidación

    Archivos de liquidación y de comisiones del adquirente recopilados, validados y convertidos en asientos que su ERP puede conciliar.

  6. Sincronización entre POS y ERP

    Ventas, devoluciones, anulaciones y totales de cierre del día registrados en el ERP desde cada tienda, una sola vez y sin duplicados.

  7. Precios, promociones y artículos

    Datos de artículos, precios y promociones enviados del ERP al POS, para que cada caja venda al precio correcto.

  8. Conciliación de pagos

    Conciliación de ventas, autorizaciones, liquidaciones y abonos, con las diferencias listadas para que su equipo las resuelva.

  9. Apoyo en pruebas y certificación

    Scripts de prueba y evidencias para la certificación de la pasarela o del adquirente, y apoyo en cada ronda.

  10. Monitorización y alertas

    Alertas por cambios en la tasa de rechazos, archivos de liquidación ausentes, tiendas que dejan de registrar ventas y terminales que dejan de comunicarse.

Cómo trabajamos

  1. 01

    Mapear los flujos de pago y de tienda

    Seguimos una venta desde la caja hasta la contabilidad con sus equipos de finanzas, tiendas y TI, y acordamos el alcance.

  2. 02

    Diseñar la integración

    Elegimos los protocolos, el enfoque de tokenización y los flujos de mensajes, y redactamos la especificación de interfaz.

  3. 03

    Construir y probar

    Construimos los flujos de pago, liquidación y POS con pruebas automatizadas, incluidos rechazos, tiempos de espera agotados y reembolsos.

  4. 04

    Certificar con el proveedor

    Ejecutamos los casos de prueba del proveedor en su entorno de pruebas y corregimos lo que detecte su certificación.

  5. 05

    Piloto y despliegue

    Entramos en producción primero en unas pocas tiendas o canales, comparamos los totales a diario y después implantamos tienda por tienda.

  6. 06

    Monitorizar y dar soporte

    Vigilamos las tasas de aprobación, las liquidaciones y los registros de las tiendas, y gestionamos los cambios de los proveedores a medida que se anuncian.

Cómo se conecta

Pagos con tarjeta: autorizados en caja, liquidados después, conciliados en el ERPEl terminal o el proceso de pago en línea consulta a la pasarela, la pasarela al adquirente, y el adquirente enruta la operación a la red de tarjetas y al emisor. Los archivos de liquidación llegan después y se concilian con las ventas y las comisiones en el ERP. Un tiempo de espera agotado activa una reversión, de modo que nunca se cobra dos veces al cliente.POSTerminal EMV opago en líneaChip, sin contacto ycomercio electrónicoPasarelaPasarela de pagoTokenización yenrutamientoBancoAdquirenteAutorización yliquidaciónTerceroRed de tarjetas yemisorAprueba o rechazaERPERPVentas, comisiones yabonosXSISCapa deintegraciónLectura y conciliaciónde liquidacionesPersonasEquipo deoperaciones depagosDiferencias, disputasy contracargos1EMV · REST/JSON2ISO 85833ISO 85834ISO 85835SFTP6REST/JSON7ISO 8583 04008

Pagos con tarjeta: autorizados en caja, liquidados después, conciliados en el ERP

El terminal o el proceso de pago en línea consulta a la pasarela, la pasarela al adquirente, y el adquirente enruta la operación a la red de tarjetas y al emisor. Los archivos de liquidación llegan después y se concilian con las ventas y las comisiones en el ERP. Un tiempo de espera agotado activa una reversión, de modo que nunca se cobra dos veces al cliente.

  • Flujo principal
  • Asíncrono
  • Ruta de fallo

El flujo, paso a paso

  1. De Terminal EMV o pago en línea a Pasarela de pago: Solicitud de autorización, mediante EMV · REST/JSON (flujo principal).
  2. De Pasarela de pago a Adquirente: Autorización, mediante ISO 8583 (flujo principal).
  3. De Adquirente a Red de tarjetas y emisor: Enrutada al emisor, mediante ISO 8583 (flujo principal).
  4. De Adquirente a Pasarela de pago: Aprobada o rechazada, mediante ISO 8583 (asíncrono).
  5. De Adquirente a Capa de integración: Archivos de liquidación y comisiones, mediante SFTP (asíncrono).
  6. De Capa de integración a ERP: Ventas liquidadas, comisiones y abonos, mediante REST/JSON (flujo principal).
  7. De Pasarela de pago a Terminal EMV o pago en línea: Sin respuesta a tiempo: reversión automática, mediante ISO 8583 0400 (ruta de fallo).
  8. De Capa de integración a Equipo de operaciones de pagos: Diferencia de liquidación o contracargo (ruta de fallo).
Del POS al ERP: cada venta registrada una sola vezLas ventas fluyen de las cajas al ERP como eventos, y los precios y el inventario vuelven en sentido contrario. Una tienda que pierde la conexión sigue vendiendo y se pone al día después. Un registro que falla se reintenta y, si sigue fallando, pasa a una persona.POSTerminales POSCada caja de cadatiendaAlmacén de datosServidor de tiendao POS en la nubeSigue vendiendo sinconexiónXSISCapa deintegraciónCola de eventos,mapeo, proteccióncontra duplicadosERPERPVentas, inventario yfinanzasServicioCola de reintentosReintentos con esperaprogresiva y luego unacola de mensajesfallidosPersonasEquipo de tiendas12REST/JSON3OData · REST/JSON4REST/JSON5REST/JSON678

Del POS al ERP: cada venta registrada una sola vez

Las ventas fluyen de las cajas al ERP como eventos, y los precios y el inventario vuelven en sentido contrario. Una tienda que pierde la conexión sigue vendiendo y se pone al día después. Un registro que falla se reintenta y, si sigue fallando, pasa a una persona.

  • Flujo principal
  • Asíncrono
  • Ruta de fallo

El flujo, paso a paso

  1. De Terminales POS a Servidor de tienda o POS en la nube: Ventas, devoluciones y anulaciones (flujo principal).
  2. De Servidor de tienda o POS en la nube a Capa de integración: Eventos de venta y totales de cierre del día, mediante una cola de eventos, mediante REST/JSON (asíncrono).
  3. De Capa de integración a ERP: Ventas e inventario registrados, mediante OData · REST/JSON (flujo principal).
  4. De ERP a Capa de integración: Precios, promociones y datos de artículos, por API o exportación de archivos, mediante REST/JSON (flujo principal).
  5. De Capa de integración a Servidor de tienda o POS en la nube: Actualizaciones de precios e inventario, mediante REST/JSON (flujo principal).
  6. De Capa de integración a Cola de reintentos: Registro fallido (ruta de fallo).
  7. De Cola de reintentos a Capa de integración: Reintentado (ruta de fallo).
  8. De Cola de reintentos a Equipo de tiendas: Sigue fallando: alerta con los detalles (ruta de fallo).

Tecnologías

Lenguajes
  • Java
  • Kotlin
Datos y analítica
  • Apache Kafka
Sistemas ERP
  • SAP S/4HANA
  • Oracle NetSuite
  • Microsoft Dynamics 365 Business Central
  • Odoo
Estándares y canales bancarios
  • SFTP (H2H)
Pagos
  • ISO 8583
  • EMV
  • EMV 3-D Secure
  • PCI DSS
Integración
  • REST
  • Webhooks
  • RabbitMQ

Formas de trabajar con nosotros

Preguntas y respuestas

¿Trabajan directamente con ISO 8583?

Sí, cuando el adquirente o el procesador lo ofrece. ISO 8583 es un marco más que un formato único: cada adquirente publica su propia especificación de campos, tipos de mensaje y gestión de red. Construimos a partir de esa especificación, gestionamos autorizaciones, reversiones y mensajes de aviso, y probamos cada código de respuesta. Cuando una pasarela ofrece una API moderna por delante del adquirente, a menudo recomendamos esa opción.

Enlace a esta pregunta
¿Cómo nos mantienen fuera del alcance de PCI DSS?

No podemos eliminar PCI DSS, pero sí reducir la parte de su entorno tecnológico a la que se aplica. Usamos páginas de pago alojadas, cifrado punto a punto en el terminal y tokens de la pasarela, de modo que los números de tarjeta nunca lleguen a su POS, su ERP ni su almacén de datos. Documentamos los flujos de datos para que su evaluador pueda ver qué sistemas tratan datos de tarjeta y cuáles no.

Enlace a esta pregunta
¿Qué terminales de pago pueden integrar?

Integramos terminales EMV con chip y sin contacto mediante el protocolo que facilita su proveedor, normalmente una API local o en la nube entre el POS y el terminal. El terminal y su aplicación de pago están certificados por el proveedor, por lo que nos integramos con ellos en lugar de modificarlos. Confirmamos con usted y con el proveedor los modelos y protocolos exactos al inicio.

Enlace a esta pregunta
¿Qué ocurre cuando una tienda pierde la conexión?

La tienda sigue vendiendo. Las ventas se almacenan localmente en el POS o en el servidor de la tienda y se envían al ERP cuando vuelve la conexión, cada una con un identificador único para que nada se registre dos veces. Que los pagos con tarjeta puedan continuar sin conexión depende de las reglas de su adquirente y de su apetito de riesgo, y lo diseñamos con usted.

Enlace a esta pregunta
¿Cuánto tarda la certificación de pagos?

Depende en gran medida de la pasarela o del adquirente: sus ventanas de prueba, el número de casos de prueba y cuántas rondas se necesitan. Preparamos los scripts de prueba y las evidencias antes de que se abra la ventana, lo que acorta las rondas, y planificamos el resto del trabajo en función del calendario del proveedor. Compartimos ese plan en cuanto el proveedor confirma su proceso.

Enlace a esta pregunta
¿De qué depende el costo?

Del número de proveedores, tipos de terminal y canales de venta, de si el adquirente usa ISO 8583 o una API, de los pasos de certificación que exige cada proveedor y del número de tiendas en las que implantar. Las reglas de liquidación y conciliación añaden esfuerzo cuando las comisiones y los abonos son complejos. Estimamos por proveedor y por flujo tras la fase de mapeo.

Enlace a esta pregunta
¿Gestionan reembolsos y contracargos?

Sí. Los reembolsos y las reversiones forman parte de los flujos de pago que construimos. Para los contracargos, importamos los informes de disputas del adquirente, vinculamos cada uno con la venta y la liquidación originales y entregamos a su equipo una lista para gestionar con las evidencias adjuntas. Cómo se responde a cada disputa sigue siendo decisión suya.

Enlace a esta pregunta
¿Quién es propietario del código y del trabajo que producen?

La propiedad intelectual del trabajo que desarrollamos para usted es suya desde el primer commit, sin ningún trámite de cesión al final. Esto incluye el código a medida, la documentación y los demás entregables creados para usted. Lo que aportamos y ya existía antes, como herramientas o bibliotecas internas, sigue siendo nuestro, y usted recibe una licencia para usarlo en sus sistemas. Los componentes de código abierto mantienen sus propias licencias, y se los enumeramos.

Enlace a esta pregunta

Cuéntenos qué necesita desarrollar o conectar.

Describa los sistemas, los plazos y las restricciones. Los ingenieros adecuados se encargan a partir de ahí.

  • Nuestro equipo le llamará en un plazo de 24 horas, en la franja horaria que usted prefiera
  • Nuestro equipo está disponible 24/7