Estas son las preguntas que suelen aparecer en la primera reunión técnica, cuando un exchange, un bróker o una fintech evalúan si el gesto único encaja en su operativa real. No hay respuestas de folleto: cada punto describe qué se puede hacer hoy, qué depende del dispositivo del usuario y qué conviene dejar documentado antes de activar el flujo en producción.
El usuario confirma la compra o la orden apoyando el dedo en el sensor o mirando la cámara del dispositivo. Esa captura se compara con la plantilla cifrada que ya está registrada y, si coincide, se genera el token de pago que viaja al comercio. No hay contraseña intermedia ni código enviado por otro canal: la verificación y la autorización ocurren en la misma secuencia. En un exchange, esto se traduce en que una compra recurrente de un producto de inversión se cierra sin salir de la pantalla donde el usuario tomó la decisión.
En móvil el sensor suele estar integrado y la latencia es baja. En web depende del hardware conectado: un lector externo, la cámara del portátil o el sensor del teléfono cuando el navegador lo expone. Por eso el protocolo contempla detección de capacidades antes de ofrecer el gesto biométrico, y solo lo muestra si el equipo puede completarlo. Cuando no puede, el flujo deriva a un método alternativo sin romper la operación que el usuario ya había iniciado.
El reintento es parte del diseño, no una excepción. Tras un fallo de lectura o una comparación negativa, el sistema permite volver a intentarlo un número acotado de veces y, agotado ese margen, ofrece la ruta de respaldo que el comercio haya definido. Mantener ese camino activo es obligatorio en la práctica: ningún sensor es infalible y la operación no puede quedar bloqueada por un dedo húmedo o una cámara con poca luz.
Cada gesto deja un evento con marca temporal, identificador de operación, resultado de la verificación y método utilizado. En una fintech que unifica onboarding y pago, esos eventos se separan por finalidad: uno corresponde al alta del usuario y otro a la autorización del cobro, aunque ambos provengan del mismo gesto. Esa separación es la que permite responder ante una revisión sin mezclar el consentimiento de identidad con el de pago.
Tres, al menos. La dependencia del hardware del dispositivo, que varía entre modelos y sistemas operativos. La necesidad de un mecanismo de respaldo siempre disponible. Y las diferencias regulatorias por jurisdicción, que afectan al consentimiento, al cifrado de las plantillas y al tiempo que se conservan los datos. Ninguno de los tres se resuelve con configuración: se resuelven con decisiones de producto tomadas antes de la primera operación real.
Si tu equipo está definiendo el recorrido entre autorización y liquidación, en la página de preguntas encontrarás el detalle ampliado de cada etapa, y en contacto puedes plantear un caso concreto con tu operativa actual.