La mayoría de las fallas de payouts no son algorítmicas, son operativas. Un motor de payouts que parece correcto en una demo de happy-path se rompe en cuanto agregás reintentos, fallas parciales, reconciliación y un regulador pidiéndote una traza de auditoría completa.
La idempotencia es la base
Cada solicitud de payout debe llevar una idempotency key generada por el cliente y persistida antes del primer intento. Sin eso, un reintento de red se convierte en un doble pago. Modelamos el payout como una máquina de estados — solicitado → autorizado → enviado → liquidado / fallido — y nunca borramos filas. Las transiciones son eventos append-only.
La reconciliación es una feature de primera clase
Los webhooks de los proveedores mienten, llegan dos veces o no llegan. El sistema de registro es tu ledger, no el proveedor. Corremos una reconciliación diaria a tres bandas entre ledger interno, reporte del proveedor y extracto bancario, y exponemos las diferencias antes que finanzas.
El compliance se construye adentro, no se atornilla después
El estado KYC, el screening de sanciones y los límites de transacción se evalúan al momento de autorizar, no después de que el dinero salió. Cada decisión queda registrada con los inputs que la produjeron, para que un auditor pueda reproducir cualquier payout meses después.
Esa es la diferencia entre una feature de pagos y una plataforma de pagos.