Pagos que no pueden fallar
Un sistema de pagos tiene una propiedad incómoda: la mayoría de sus fallos no se ven. Una API que devuelve 200 y no registró el movimiento, un reintento que cobra dos veces, un webhook que llega fuera de orden. Nada de eso enciende una alarma; aparece semanas después, en una conciliación que no cuadra o en un cliente que reclama.
Por eso empiezo siempre por el modelo de datos y no por el framework. Antes de proponer arquitectura necesito saber de dónde sale cada peso, dónde queda registrado, y quién tendrá que auditarlo seis meses después. En pagos el modelo de datos es el producto; el resto es plomería alrededor.
De ahí salen las decisiones que importan: idempotencia real en cada operación que mueve dinero, un libro de asientos inmutable como fuente de verdad, el patrón outbox para que nunca haya un evento publicado sin su escritura correspondiente, y sagas con compensación explícita en lugar de transacciones distribuidas que nadie puede razonar.
- Dominio
- Pagos y banca
- Volumen
- 2M tx/día
- Norma
- PCI DSS
- Fraude
- Tiempo real
¿Qué involucra?
- 01Procesamiento de pagos seguro
- 02Sistemas de gestión de riesgos
- 03Plataformas de trading
- 04Soluciones de cumplimiento regulatorio
- 05Dashboards financieros en tiempo real
¿Cómo se aborda?
Paso 01
Modelo contable antes que API
Partida doble, asientos inmutables y estados de transacción explícitos. Un pago no se 'actualiza': genera asientos que se pueden reconstruir. Con eso, la conciliación deja de ser un proceso de rescate mensual y pasa a ser una consulta.
Paso 02
Idempotencia y entrega exactamente una vez
Toda operación que mueve dinero recibe una clave de idempotencia y se prueba contra reintentos, duplicados y desorden. El patrón outbox garantiza que el evento y la escritura viajen juntos; los consumidores se diseñan para poder recibir el mismo mensaje dos veces sin consecuencias.
Paso 03
Cumplimiento desde el primer día
PCI DSS, tokenización y minimización de datos entran como restricciones de diseño, no como una auditoría al final. Sale más barato y produce mejores sistemas: si nunca almacenas el PAN, no tienes que protegerlo.
Paso 04
Observabilidad con SLO sobre el dinero
Los indicadores no son CPU y memoria: son tasa de autorización, latencia p99 del checkout, transacciones sin conciliar a las 24 horas. Se instrumenta con OpenTelemetry y se define un presupuesto de error, porque sin él nadie sabe cuándo parar de lanzar features.
La pregunta que revela una plataforma en dos minutos
Cuando entro a una plataforma de pagos existente hago siempre la misma pregunta antes que cualquier otra: ¿cuántas transacciones quedaron sin cuadrar ayer, y por qué? Si el sistema no puede responderla en el momento, todo lo demás que me cuenten sobre su arquitectura es una hipótesis.
No es una pregunta de proceso, es de diseño. Un sistema que puede responderla tiene asientos inmutables, estados explícitos y un identificador que sobrevive a los reintentos. Uno que no puede, tiene actualizaciones en sitio y un equipo que reconstruye la verdad a mano cada cierre.
En Cencosud eso significó conciliar del orden de dos millones de transacciones semanales contra SAP; en Yummy, sostener dos millones diarias. Son escalas distintas con el mismo requisito: que la conciliación sea una consulta y no un rescate mensual.
- Partida doble con asientos inmutables como fuente de verdad
- Clave de idempotencia en toda operación que mueve dinero
- Patrón outbox: el evento y la escritura viajan juntos o no viajan
- Estados de transacción explícitos, nunca actualización en sitio
- Transacciones sin conciliar a 24 h como indicador de servicio
¿Dónde lo he hecho?
- Yummy Inc. · Pagos y Finanzas
- Medios de pago y microservicios para una super-app de LATAM, hoy en producción
- 2M tx/día
- Wompi (Grupo Bancolombia)
- Integraciones con entidades bancarias y rediseño de backend para Open Banking
- 99,9% disponibilidad
- Cencosud S.A. · Conciliación
- Contabilidad integrada con SAP sobre volumen semanal de retail
- 2M+ tx/semana
- bcv-exchange-rate · Código abierto
- Tasas oficiales BCV, TRM y PTAX con scraping resiliente, cache y reintentos; publicada en npm
- ~700 desc./mes
Las cifras vienen de sistemas en producción. La trayectoria completa está en Sobre mí.
Prácticas y entregables
Prácticas
- Event sourcing
- Patrón outbox
- Sagas con compensación
- Idempotencia
- Contract testing
- OpenTelemetry
- SLO y error budgets
- Domain-Driven Design
Entregables
- Modelo de dominio y esquema contable
- Especificación de API e idempotencia
- Matriz de riesgos y controles PCI DSS
- Suite de pruebas de contrato
- Tableros de conciliación y SLO
Stack
- Node.js
- NestJS
- PostgreSQL
- Kafka
- Redis
- Azure
- AWS
Lo que suelen preguntarme
- ¿Construyes la pasarela o integras una existente?
- Casi siempre lo segundo, y suele ser la respuesta correcta. Construir una pasarela desde cero tiene sentido en muy pocos casos; integrar bien varias, con enrutamiento, reintentos y conciliación propia, resuelve el 90% de los problemas reales.
- ¿Qué es lo primero que revisas en una plataforma existente?
- La conciliación. Si el sistema no puede decirme cuántas transacciones quedaron sin cuadrar ayer y por qué, todo lo demás que me cuenten sobre su arquitectura es una hipótesis.
- ¿Trabajas con Open Banking?
- Sí, tanto en agregación como en iniciación de pagos. Es donde el modelo de consentimiento y la trazabilidad dejan de ser buenas prácticas y pasan a ser requisitos regulatorios.
- ¿Puedes auditar sin rediseñar?
- Sí, y suele ser el mejor primer paso. Una auditoría de dos a tres semanas produce un informe priorizado por riesgo; a partir de ahí decides qué se toca y qué se deja.
Otros frentes
- Liderazgo técnicoDirección estratégica y liderazgo para equipos de desarrollo y proyectos tecnológicos.
- BackofficeAutomatización y optimización de procesos internos y operaciones de backoffice empresarial.
- ArquitecturaDiseño de arquitecturas de software escalables, resilientes y mantenibles para sistemas empresariales.
- Seguridad y complianceImplementación de soluciones de seguridad y cumplimiento normativo para sistemas financieros.
- Infraestructura cloudDiseño e implementación de infraestructuras cloud escalables, seguras y optimizadas en costos.
- Inteligencia artificialAgentes de IA aplicados a sistemas financieros y de backoffice, incluida la infraestructura para que operen dinero con límites y auditoría.