Para un producto financiero, un pago no es una funcionalidad de una lista - es el momento de la verdad. Es ahí donde el cliente completa la transacción o abandona el carrito, y donde cuadras los saldos al céntimo o te pasas una semana buscando la diferencia. La integración de pagos decide por tanto la conversión, la confianza y la capacidad de finanzas para cerrar el día.
Por nuestra experiencia en proyectos de banca y fintech, lo difícil no es conectar la primera pasarela, sino mantener muchos métodos de pago, muchos proveedores y muchos estándares dentro de un conjunto predecible que no se caiga al primer timeout. Así que este artículo trata de cómo construir una capa de pagos que dure años, y de quién debería construirla.
¿Por qué es tan difícil la integración de pagos?
Porque un pago no es un sistema, sino una cadena de participantes independientes, cada uno de los cuales puede fallar por su cuenta. Entre el clic en «Pagar» y el apunte de los fondos, el flujo pasa por una pasarela, un adquirente, un esquema de tarjetas o un sistema de transferencias, el banco emisor y tu propio backend - y cada eslabón tiene un SLA distinto y una forma distinta de reportar errores.
A eso se suma el número de estándares que hay que soportar en paralelo: tarjetas y 3-D Secure, transferencias inmediatas, esquemas locales, monederos móviles y, cada vez más, open banking. Cada estándar trae sus propias reglas de autorización, devoluciones y disputas, y la regulación (PSD2, SCA) añade requisitos encima. La integración de pagos es por tanto un proyecto en el punto de encuentro entre tecnología, finanzas y compliance - y ese punto de encuentro es exactamente donde a un solo equipo de producto se le suele acabar el fondo.
¿Qué son las pasarelas de pago y los PSP, y en qué se diferencian?
Conviene separar cuatro términos que se mezclan en las conversaciones de negocio:
- una pasarela de pago es la capa técnica que acepta los datos del pago, los cifra y los transmite - el «enchufe» entre tu aplicación y el mundo de las liquidaciones,
- un PSP (payment service provider) te da no solo una pasarela, sino también la agregación de muchos métodos de pago, la liquidación y el reporting en un mismo sitio,
- un adquirente gestiona el movimiento real del dinero entre bancos,
- un orquestador de pagos se sitúa por encima de los PSP y permite cambiar de proveedor y enrutar transacciones sin reescribir la integración.
La decisión de «un PSP o varios» da forma a toda la arquitectura: varios proveedores exigen una capa de abstracción, para que añadir otro método de pago no signifique reconstruirlo todo - y esa capa es la que más a menudo diseñamos con los clientes.
¿Cómo funcionan las transferencias inmediatas y qué estándares aplican?
Las transferencias inmediatas cambiaron las expectativas del cliente: el dinero debería llegar en segundos, a cualquier hora, fines de semana incluidos. Técnicamente eso significa operar 24/7 sin ninguna de las ventanas de mantenimiento que la banca tradicional se permitía antes. Un sistema de pagos inmediatos no perdona las caídas - la transacción pasa al instante o el cliente sabe al instante que algo falló.
En Europa el estándar que ordena esto es SEPA Instant Credit Transfer, junto a los esquemas locales de cada mercado. Cada uno de esos sistemas impone sus propios límites, formatos de mensaje (cada vez más basados en ISO 20022) y reglas de confirmación. Nuestros ingenieros lo abordan diseñando el pago como un proceso asíncrono con estados explícitos, no como una única petición - porque es la única forma honesta de manejar a la vez un éxito inmediato y una confirmación o un rechazo diferidos.
¿Cómo se gestionan la tokenización y la seguridad (PCI DSS)?
Los datos de tarjeta son un material que más vale no guardar uno mismo. La base de una integración segura es por tanto sacar los datos sensibles de tus propios sistemas y reducir al mínimo el alcance de PCI DSS:
- la tokenización sustituye el número de tarjeta por un token que por sí solo no sirve de nada a un atacante,
- los campos alojados y las redirecciones evitan que los datos de tarjeta lleguen a tocar tu servidor,
- el cifrado en tránsito y en reposo protege lo que sí tienes que almacenar,
- la segmentación de entornos y el control de acceso recortan el alcance de la auditoría PCI DSS,
- 3-D Secure y la autenticación reforzada (SCA) trasladan parte del riesgo al emisor y cumplen el requisito regulatorio.
El cumplimiento de PCI DSS no es un certificado puntual, sino una forma de diseñar el sistema. Planteamos la arquitectura para que la huella de datos sensibles sea lo más estrecha posible - cuantos menos datos de tarjeta circulen por tus sistemas, más barata es la auditoría y menor es la superficie de ataque.
¿Cómo se garantizan la fiabilidad, el manejo de errores y la conciliación?
Esta parte solo se ve cuando algo sale mal, que es justo por lo que es tan fácil pasarla por alto. Un pago es distribuido, así que hay que asumir que una respuesta se perderá, llegará tarde o llegará dos veces. Diseñamos las operaciones para que sean idempotentes, con una clave de transacción única, de modo que reintentar una petición nunca cobre dos veces al cliente y cualquier estado se pueda reconstruir desde el log.
La otra mitad de este trabajo es la conciliación: el cuadre diario entre lo que ve tu sistema y lo que reportan el PSP y el banco. Sin ella, los saldos empiezan a separarse y las disputas se acumulan. Construimos el casado automático de transacciones, informes de diferencias y un camino claro para devoluciones y chargebacks, además de monitorización y alertas a nivel de cada método de pago - porque el fallo de una pasarela no debería parecer un fallo de todo el producto.
¿Qué competencias aportamos a un proyecto de pagos?
Aquí no tenemos una receta única para la forma del equipo - ajustamos la alineación a la etapa y a la arquitectura. Lo más habitual es que cubramos los perfiles que de verdad deciden la calidad de la capa de pagos:
- desarrolladores backend (Java, .NET, Node) que construyen integraciones con pasarelas, PSP y sistemas de transferencias,
- un arquitecto de solución que diseña la abstracción sobre los proveedores y el modelo de transacción,
- especialistas de DevOps / SRE que se ocupan de la fiabilidad, la monitorización y la operación 24/7,
- ingenieros de QA que prueban caminos de error, timeouts, devoluciones y conciliación,
- competencias de seguridad y compliance que dan apoyo a PCI DSS y a los requisitos regulatorios.
Una advertencia importante: aquí hablamos de competencias, no de un producto de pagos listo para usar. Aportamos a las personas que lo van a construir - ingenieros con experiencia en proyectos de banca y fintech, enchufados a tu equipo y a tus procesos.
¿Con qué rapidez puede incorporarse un equipo a un proyecto de pagos?
La velocidad importa, porque la ventana de mercado para un nuevo método de pago puede ser corta. Como partner nearshore desde Polonia trabajamos en una zona horaria cercana, así que nuestros especialistas entran en tu ritmo de revisiones de código y reuniones sin una larga puesta en marcha. Normalmente cerramos el proceso de selección en unas tres semanas y verificamos las competencias antes de empezar - en pagos, la experiencia en proyectos regulados no es algo que se dé por supuesto.
¿Cómo lo hacemos en RITS?
Lo hacemos como partner nearshore desde Polonia que suma competencias donde faltan y asume la responsabilidad de una parte del sistema:
- cubrimos los perfiles de backend, arquitectura, DevOps y QA alrededor de tu arquitectura de pagos concreta,
- diseñamos la capa de abstracción sobre pasarelas y PSP, para que cambiar de proveedor no sea una reescritura,
- automatizamos la conciliación, las devoluciones y el manejo de errores, y enchufamos al equipo a tus procesos y herramientas.
La mayoría de las veces esto es software a medida construido por nuestro equipo y, cuando hay que sumar competencias rápido, refuerzo de equipo.
¿Por dónde empezar con la integración de pagos?
Empieza por el camino de pago más importante (p. ej. un pago con tarjeta con 3-D Secure o una transferencia inmediata) y por la pregunta de cómo será su conciliación. Eso guía tu elección de PSP, tu modelo de transacción y los perfiles que necesitas. Repasamos las diferencias entre modelos de colaboración en nuestro artículo sobre modelos de colaboración en TI.
¿Vas a construir o rehacer una integración de pagos? Hablemos - buscamos un equipo y una arquitectura para tu producto financiero.