Pagos con tarjeta
Pagos con tarjeta: del terminal al adquirente y de vuelta a la contabilidad
Terminales EMV y pasarelas de pago conectados con adquirentes mediante ISO 8583 o API, con archivos de liquidación conciliados en el ERP.
Esquema
Desplácese en horizontal para ver el esquema completo.
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
- De Terminal EMV o pago en línea a Pasarela de pago: Solicitud de autorización, mediante EMV · REST/JSON (flujo principal).
- De Pasarela de pago a Adquirente: Autorización, mediante ISO 8583 (flujo principal).
- De Adquirente a Red de tarjetas y emisor: Enrutada al emisor, mediante ISO 8583 (flujo principal).
- De Adquirente a Pasarela de pago: Aprobada o rechazada, mediante ISO 8583 (asíncrono).
- De Adquirente a Capa de integración: Archivos de liquidación y comisiones, mediante SFTP (asíncrono).
- De Capa de integración a ERP: Ventas liquidadas, comisiones y abonos, mediante REST/JSON (flujo principal).
- 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).
- De Capa de integración a Equipo de operaciones de pagos: Diferencia de liquidación o contracargo (ruta de fallo).
Visión general
Este es el recorrido de un pago con tarjeta: del terminal o el proceso de pago en línea al adquirente, la red de tarjetas y el emisor, y de vuelta. El cliente espera la respuesta en la caja. El dinero, descontadas las comisiones, llega después en un archivo de liquidación que hay que conciliar con las ventas de su ERP.
El diseño de referencia envía las autorizaciones a través de una pasarela de pago que tokeniza la tarjeta y dirige la solicitud al adquirente, mediante ISO 8583 o la API del adquirente. La capa de integración recoge los archivos de liquidación y de comisiones, los concilia con las ventas originales y los registra en el ERP como ventas, comisiones y abonos.
El diseño también cubre lo que sale mal. Una solicitud que no recibe respuesta a tiempo se revierte, para que al cliente no se le cobre dos veces. Una liquidación que no concilia, o un contracargo, pasa a su equipo de operaciones de pagos con la venta original adjunta.
Cómo funciona el flujo
- 01
Empezar en el terminal o en el proceso de pago
El terminal EMV lee la tarjeta con chip o sin contacto, o el proceso de pago en línea recoge la tarjeta mediante una página alojada, y envía una solicitud de autorización a la pasarela.
- 02
Autorizar a través de la pasarela
La pasarela sustituye el número de tarjeta por un token y envía la autorización al adquirente, mediante ISO 8583 o la API del adquirente.
- 03
Dirigir al emisor
El adquirente dirige la solicitud a través de la red de tarjetas hasta el emisor, que la aprueba o la rechaza.
- 04
Devolver la respuesta
La aprobación o el rechazo vuelve por el mismo camino hasta el terminal o el proceso de pago, con su código de respuesta.
- 05
Recibir la liquidación
Más tarde, el adquirente envía los archivos de liquidación y de comisiones, que la capa de integración recoge y valida.
- 06
Conciliar y registrar
La capa concilia las transacciones liquidadas con las ventas originales y registra en el ERP las ventas, las comisiones y los abonos.
Cuando algo falla
No hay respuesta a tiempo
Si la pasarela no recibe respuesta dentro del plazo del adquirente, envía una reversión, un mensaje ISO 8583 0400 o su equivalente en la API, para que nunca se cobre al cliente una venta que no se completó.
Se rechaza un pago
El código de respuesta llega a la caja o al proceso de pago con un mensaje claro. Las tasas de rechazo se monitorizan, de modo que un aumento brusco que apunta a un fallo técnico genera una alerta.
La liquidación no concilia
Un importe liquidado distinto del de la venta, o una venta sin liquidación, pasa a una lista de revisión de su equipo de operaciones de pagos, con ambos registros uno junto al otro.
Un titular de tarjeta disputa un pago
El informe de disputas del adquirente se importa y se vincula con la venta y la liquidación originales, para que su equipo responda con todas las evidencias en un solo lugar.
Estándares y sistemas
- Estándares y canales bancarios
- SFTP (H2H)
- Pagos
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
- Integración
- REST
- Webhooks
Preguntas y respuestas
¿Qué diferencia hay entre una pasarela y un adquirente?
El adquirente es el banco o la entidad autorizada que procesa los pagos con tarjeta por usted y le abona el dinero. La pasarela es el servicio técnico situado delante, que acepta las solicitudes de los terminales y los procesos de pago, tokeniza las tarjetas y las dirige. Algunos proveedores son ambas cosas. El diseño funciona en los dos casos y mantiene ambos papeles bien diferenciados.
Enlace a esta pregunta¿Esto mantiene los datos de tarjeta fuera de nuestros sistemas?
Ese es el objetivo del diseño. Los números de tarjeta los captura el terminal certificado o una página de pago alojada, y la pasarela los sustituye por tokens, de modo que su POS, su ERP y sus almacenes de datos solo ven tokens. Así se reduce la parte de su entorno tecnológico a la que se aplica PCI DSS. Su auditor confirma el alcance final.
Enlace a esta pregunta¿ISO 8583 es igual para todos los adquirentes?
No. ISO 8583 define una estructura, y cada adquirente o red publica su propia especificación de campos, tipos de mensaje y códigos. Por eso trabajamos a partir de la especificación del adquirente y ejecutamos sus pruebas de certificación. Una API de pasarela delante del adquirente oculta estas diferencias, lo que a menudo resulta más sencillo para los comercios minoristas.
Enlace a esta pregunta¿Por qué la liquidación llega más tarde que la venta?
La autorización solo reserva los fondos. El adquirente liquida por lotes, tras descontar sus comisiones y las tasas de la red de tarjetas, y abona según su propio calendario. Por eso el diseño trata la autorización y la liquidación como eventos distintos y los concilia, para que finanzas vea lo que se vendió, lo que se liquidó y lo que aún está por llegar.
Enlace a esta pregunta¿Admiten EMV 3-D Secure para pagos en línea?
Sí. Para los pagos con tarjeta en línea integramos EMV 3-D Secure a través de la pasarela, para que el emisor pueda autenticar al titular cuando la normativa o el riesgo lo exijan. Gestionamos los flujos con desafío y sin fricción en el proceso de pago y probamos ambos con las tarjetas de prueba del proveedor.
Enlace a esta pregunta¿Podemos usar más de un proveedor de pagos?
Sí. La capa de integración mantiene un único modelo interno de pago y lo adapta a cada proveedor, de modo que usted puede dirigir los pagos por canal, país o tipo de tarjeta, o trasladar volumen entre proveedores. Cada proveedor sigue necesitando su propia integración y certificación, que planificamos proveedor por proveedor.
Enlace a esta preguntaCué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