En pagos, lo correcto le gana a lo ingenioso.
Un producto de pagos se juzga por los días en que sale mal. La idempotencia, la reconciliación y un rastro de auditoría claro son todo el trabajo.
Qué lo hace diferente
El software de pagos tiene una propiedad poco común: el camino feliz es fácil y casi irrelevante. Lo que determina si una plataforma es confiable es qué pasa cuando una petición se vence después de que el cargo salió bien, cuando un webhook llega dos veces, o cuando dos sistemas no coinciden sobre un saldo.
Construimos estos productos alrededor de esos casos primero. Toda operación que mueve dinero es idempotente, así que un reintento no puede cobrar dos veces. Toda integración tiene un proceso de reconciliación que detecta la discrepancia en vez de esperar a que un cliente la reporte. Todo cambio de estado deja un rastro de auditoría que le puedes entregar a un regulador.
En PCI DSS, el primer movimiento siempre es la reducción de alcance. El trabajo de cumplimiento más barato es el que logras no necesitar por decisión de ingeniería.
- Movimiento de dinero idempotente, así un reintento nunca es un segundo cargo
- Reconciliación que detecta automáticamente la desviación entre sistemas
- Alcance PCI DSS reducido por diseño antes de agregar controles
- Rastros de auditoría en cada cambio de estado, construidos para ser revisados
Qué construimos aquí
Plataformas de pago
Pasarelas, billeteras, y los flujos de vinculación que las escalan.
Crédito y cobranza
Administración de cartera, pagos, y herramientas para el deudor.
Reconciliación
Detección automática de las discrepancias que cuestan dinero real.
PCI DSS
Reducción de alcance primero, y después los controles que exige lo que queda.
Integración con procesadores
Stripe y otros, con idempotencia y reintentos manejados como se debe.
Visibilidad operativa
Tableros que muestran las fallas, no solo el volumen.
Pruebas de este segmento
Paymentez creció de 85 a 4.700 revendedores LAN house en un año, con las transacciones diarias subiendo de 4.000 a 120.000 y la conversión un 42% arriba en seis meses. Payix bajó la vinculación de clientes de meses a una fracción de eso.
La experiencia de usuario de hoy es completamente distinta a la del pasado. Ahora los usuarios ven solamente las acciones y los flujos que les son directamente relevantes.
Dónde suelen salir mal los proyectos de pagos
Cuatro fallas explican la mayor parte del dinero que se pierde en este segmento, y ninguna es exótica. Son los casos que nunca llegan a un demo, que es exactamente la razón por la que siguen ahí en el lanzamiento.
- Un camino de reintento que nunca se probó bajo un vencimiento, así que a un cliente se le cobra dos veces y soporte se entera antes que ingeniería
- Webhooks tratados como confiables, así que una entrega duplicada mueve dinero una segunda vez y una caída pierde una liquidación en silencio
- La reconciliación aplazada a una fase posterior, lo que significa que la primera discrepancia entre sistemas la descubre un cliente
- El alcance PCI aceptado como dado en vez de reducido por ingeniería, así que la cuenta de cumplimiento queda fijada antes que la arquitectura
Cómo se dimensiona y se cotiza el trabajo en fintech
Las construcciones de pagos y de crédito las entregan AI Pods contra un alcance comprometido, estimadas en story points y cotizadas antes de empezar. La estimación sale de un inventario de integraciones, porque la superficie de procesadores y de libros contables es lo que aquí de verdad mueve el esfuerzo.
El trabajo de cumplimiento es la excepción y nunca se cotiza en story points. La auditoría y la certificación se dimensionan como un fijo mensual o una tarifa fija, porque el entregable es una opinión y no una funcionalidad.
Preguntas que vale la pena hacer
¿Qué implica en realidad el desarrollo de software fintech?
¿Pueden reducir nuestro alcance PCI DSS?
¿Cómo evitan que un reintento cobre dos veces?
¿Trabajan con nuestro procesador actual?
¿Pueden construir crédito y cobranza, no solo pagos?
A dónde ir después
Aquí el inventario de integraciones es lo que fija la estimación. Estos tres casos de estudio muestran en qué terminó ese inventario.
- Payix
Caso de estudio: una plataforma de pagos rígida donde montar un cliente tomaba meses, reconstruida para que ya no
- Paymentez
Caso de estudio: un rediseño que llevó las transacciones diarias de 4.000 a 120.000
- Tuily
Caso de estudio: crédito corporativo para PyMEs colombianas, construido desde una idea y adquirido por Bold
- Integraciones y Datos
La capacidad en la que más se apoya este segmento, con la reconciliación que detecta la desviación antes que un cliente
Tráenos el backlog.
En 30 minutos te mostramos qué entregaría primero un Pod y cómo lo cotizaríamos.