Cinco cicatrices de operar infraestructura de pagos

Lo encontré un martes, cruzando el estado de cuenta de un proveedor de pagos contra nuestros propios libros.

El proveedor decía que le debíamos seis cifras. Nuestros sistemas decían que no le debíamos nada. La deuda no existía en ninguna parte.

Llevo años operando infraestructura de pagos y remesas. Estas son las cinco cicatrices que me dejó, y lo que me enseñó cada una.

1. La deuda que no existía. El asiento de apertura del ledger descartaba saldos negativos como "ruido". Uno de esos negativos era deuda real con un proveedor. Lección: una custodia negativa es un pasivo, no una anomalía.

2. El wallet 97% congelado. La liberación de reservas dependía de un campo colateral que un flujo nuevo no creaba. Resultado: reservas eternas sin una sola orden abierta. Lección: los holds son asientos contables de primera clase, no inferencias sobre tablas laterales.

3. Balances sumando todo el historial, en cada request. Lento, y dos requests concurrentes podían gastar el mismo saldo. Lección: el balance se materializa en la MISMA transacción que el asiento.

4. "1.500" se convirtió en 1500. Un helper decimal adivinó que el punto era separador de miles: error x1000 en un camino de dinero. Y había un test unitario que fijaba el bug como especificación. Lección: dinero = enteros en unidades mínimas + activo + exponente. Nunca floats, nunca parsers que adivinan.

5. Semanas de SQL forense. Las filas mutables solo guardan cómo se ven las cosas HOY; los estados intermedios ya no existían. Lección: append-only no es pureza académica, es poder consultar la línea de tiempo en vez de entrevistar a los sobrevivientes.

El patrón de fondo: las tablas operacionales tienen "estado actual", no verdad financiera. No es descuido, es el modelo de datos.

Por eso estoy construyendo LedgerCore: infraestructura de ledger de doble entrada, donde el asiento que no balancea no se postea, la historia no se puede editar y el dinero son enteros.