Devlog: cómo construimos el registro, el KYC y el login de Movo (y los 3 bugs que encontramos en el camino)

Trabajamos en sprints de dos semanas, con una demo al final de cada uno. Este es el resumen del sprint que le dedicamos a la parte que sostiene todo lo demás en una plataforma P2P: que dos desconocidos puedan confiar el uno en el otro para que uno le entregue un paquete al otro.

Lo hicimos todo contra infraestructura real desde el primer día: base de datos, el proveedor de verificación de identidad y el envío de SMS de verdad, nada de mocks. Nos tomó más tiempo que simular esas piezas, pero fue justamente eso lo que nos hizo encontrar bugs que un entorno de pruebas simulado no iba a mostrarnos nunca.

Cerramos el módulo de Identidad y Confianza: una persona nueva se puede registrar, verificar su número de teléfono con un código por SMS (usamos Twilio), validar su identidad con documento y reconocimiento facial (eso lo tercerizamos con Didit.me, un proveedor especializado en KYC), iniciar sesión de forma segura y consultar o editar su perfil.

No es la parte más vistosa del producto, pero es la que habilita todo lo demás. Sin identidad verificada no hay reputación, y sin reputación un modelo P2P de logística no cierra: nadie le da un paquete a un desconocido sin ninguna garantía de que existe y de que es quien dice ser.

Toda la plataforma corre sobre microservicios: usuarios, envíos, precios y pagos viven cada uno en su propio servicio, aislado de los demás. Eso da flexibilidad para tocar uno sin romper otro, pero deja una pregunta abierta: ¿quién se fija que un pedido venga autenticado antes de que llegue a cualquiera de esos servicios?

La resolvimos con un único punto de entrada, un API Gateway, que valida identidad, rol y un límite de pedidos por minuto por usuario antes de dejar pasar nada. Así ningún servicio interno tiene que reimplementar esa lógica, y no queda ningún endpoint expuesto sin protección por un descuido.

Didit.me documenta tres resultados posibles para una verificación de identidad: aprobado, rechazado o revisión manual. Cuando empezamos a integrar el flujo contra su sandbox real, los estados que efectivamente llegaban por webhook eran Approved, Declined e In Review —nombres distintos a los que habíamos usado para diseñar nuestra propia máquina de estados.

Paramos, revisamos el comportamiento real del proveedor y ajustamos el modelo para reflejarlo: agregamos el estado manual_review, que se resuelve solo cuando llega el webhook con el resultado final, o que se puede consultar activamente contra la API de Didit si esa notificación nunca llega. Fue medio día de trabajo extra, pero mejor eso que lanzar con un caso sin contemplar.

Cuando algo depende del comportamiento de un tercero, conviene validarlo contra el entorno real del proveedor antes de darlo por cerrado. La documentación es un punto de partida, no la última palabra.

Y cuando en el camino encontramos una decisión de seguridad que había quedado abierta —en este caso, dos rutas de verificación de identidad que no exigían estar autenticado y aceptaban un id de usuario adivinable en la URL— la cerramos en el mismo sprint, en vez de anotarla como deuda técnica para después.

Con la identidad resuelta pasamos al módulo de Ejecución del Envío: que un emisor pueda publicar un envío y que quien lo recibe pueda confirmarlo.