david@medellin:~/fintech$ cat intro.md
Ayudo a founders técnicos a integrar pagos en Colombia sin repetir los errores que cuestan plata real: montos mal calculados, webhooks que se pierden en silencio, secretos desincronizados entre servicios. Los cinco casos de abajo son reales, de un ecosistema fintech propio en producción — no un curso, cicatrices.
$ cat ./casos-reales/*.log
De un ecosistema fintech propio en Cloudflare Workers: wallet, exchange, trading, pagos con Wompi/Bancolombia/Truora en producción.
Wompi recibe el monto en COP tal cual — el peso no tiene subunidades. Tres lugares distintos del código multiplicaban por 100 "porque cents", cobrando $4.000.000 en vez de $40.000. Volvió a pasar semanas después, esta vez citando mal la propia documentación de Wompi.
El test que debía atraparlo comparaba un substring del URL — "40000" es substring de "4000000", así que el test pasaba con o sin el bug. Se corrigió para comparar el valor exacto parseado.
Un bypass de autenticación para el webhook de Wompi (que obviamente no manda JWT) nunca se generalizó a Bancolombia ni a Truora. Sus confirmaciones reales de transferencia y verificación KYC se rechazaban antes de llegar a verificar su propia firma HMAC.
Corriendo por primera vez una suite de tests que llevaba meses sin poder ejecutarse por un compatibilityDate faltante y dos tablas sin crear en el schema de prueba. Los tests ya estaban escritos esperando el comportamiento correcto.
JWT_SECRET tiene que ser idéntico en los 7 workers que verifican sesión. Uno quedó con un valor distinto y, encima, un bug de encoding decodificaba el secreto como base64 antes de firmar — ningún valor de secreto lo iba a arreglar.
El wallet completo no podía autenticar contra exchange, transactions, economy ni trader. Se corrigió el código y se rotaron los 7 secretos en el mismo cambio — rotar uno sin los demás tumba todo otra vez.
GET /accounts del servicio de pagos a terceros de Wompi devolvía 403 "identity-based policy". Se asumió configuración suelta durante semanas.
"Pagos a Terceros" es un producto aparte del checkout normal en Wompi, con su propio plan y modalidad — nunca se había activado. No era un dato faltante, era un servicio apagado.
El webhook de confirmación de Wompi solo procesaba el estado APPROVED y descartaba en silencio DECLINED/VOIDED/ERROR. Un pago rechazado por el banco quedaba como "pendiente" para siempre — indistinguible de un cliente que nunca llegó a pagar. Un mismo usuario reintentó 3 veces en 31 minutos el día del lanzamiento.
Al ir a desplegar el fix, el worker no compiló: el config apuntaba a un KV namespace que ya no existía en la cuenta. Llevaba quién sabe cuánto tiempo sin poderse actualizar en absoluto — el bug de arriba nunca se hubiera podido corregir sin encontrar primero esto.
$ cat stack.list
$ man dslt-fintech
$ policy --verify-live
Un test en verde no prueba que el dinero se movió bien. Reviso contra el proveedor real cuando el monto lo amerita.
$ policy --no-fabricate
Si un 403 o un ID faltante no tiene explicación clara, la busco — no se rellena con un UUID inventado.
$ policy --explain
Cada corrección queda documentada: qué pasaba, por qué, y qué prueba evita que vuelva a pasar.
$ echo "hablemos" | mail dsltdev
Contame en qué estás y en qué se traba — auditoría puntual de una integración, o construir la pieza de pagos completa.