Tu primera verificación

Vamos a construir la verificación más simple que funciona: emitir un código para un número, enviarlo por SMS y validarlo. El playground de abajo corre tu código en un entorno aislado con un SDK simulado llamado mx. No hay red ni cobros: todo ocurre en tu navegador y la transcripción del teléfono muestra lo que vería el usuario.

El flujo mínimo

Tres llamadas componen el flujo. mx.otp.issue(phone) genera y guarda un código de seis dígitos asociado al número. mx.sms.send({ to, text }) lo entrega; observa cómo la burbuja pasa de enviado a entregado, igual que los recibos de entrega (DLR) que entregan los operadores. Finalmente mx.otp.verify(phone, code) devuelve true una sola vez.

El texto del mensaje importa

El SMS de verificación es un pequeño contrato con el usuario. Debe nombrar la marca al inicio, mostrar el código de forma evidente, indicar la vigencia y advertir que no se comparte. Esa última línea no es decorativa: reduce de forma medible la ingeniería social del tipo «te llamo del banco, dime el código que te llegó».

En la práctica, muchos equipos en Chile redactan primero el mensaje en una hoja de cálculo compartida con legal y marketing, porque el remitente alfanumérico queda fijo por meses ante el operador y corregirlo implica un nuevo trámite. Vale la pena congelar el texto antes de integrar el envío, no después.

Un error frecuente es duplicar el envío porque el frontend reintenta la llamada de red sin que el backend confirme si ya se emitió un código vigente. La solución es idempotencia: si ya existe una verificación pending para ese teléfono y esa acción, reutilízala en lugar de emitir una nueva en cada click del botón «Enviar».

Del playground a producción

En producción, issue vive en tu backend, el código se guarda como hash (no en texto plano) con su expiración y contador, y verify compara en tiempo constante. El cliente nunca recibe el código: solo un identificador de verificación. En el próximo capítulo modelamos esos estados explícitamente.