Retail: checkout con OTP

Este caso compone la experiencia de varios retailers de la región; ningún dato corresponde a una empresa identificable. El punto de partida es común: contracargos por compras con tarjetas robadas concentradas en eventos como el CyberDay, y un equipo de producto que se niega a agregar un paso a cada compra porque cada campo adicional en el checkout mide una caída de conversión de uno o dos puntos.

El equipo de riesgo llegó con un dato duro: el 70% de los contracargos del trimestre se concentraba en el 4% de las órdenes con mayor monto o con una dirección de despacho distinta a las anteriores del cliente. Eso cambió la conversación: no había que verificar a todos, sino encontrar ese 4% antes de despachar.

El diseño

En lugar de verificar a todos, el OTP se gatilla por riesgo: dirección de despacho nueva, dispositivo no visto, o monto sobre el percentil 90 del cliente. El resto compra sin fricción. Para invitados sin cuenta, se verifica el teléfono de contacto solo si la orden supera un umbral, y el umbral se recalibra cada semana con los datos de contracargo real, no con una estimación inicial.

La implementación técnica separó el motor de riesgo del envío del código: el primero decide si corresponde verificar, el segundo solo entrega y valida. Esa separación permitió iterar las reglas de riesgo sin tocar la integración con el proveedor de SMS, que es la parte más costosa de cambiar porque involucra contratos y pruebas de entregabilidad.

• OTP por chat primero, SMS de respaldo a los 10 segundos.
• Autocompletado con WebOTP en móvil.
• Capacidad de verificación dimensionada para 8 veces el tráfico normal en eventos.
• Reglas de riesgo recalibradas semanalmente con datos de contracargo.

Lo que aprendimos

El aprendizaje principal fue operativo: durante el evento, una ruta de SMS degradó su latencia, y el p95 de tiempo a verificar fue la alarma que permitió mover tráfico a otra ruta antes de perder ventas. La verificación por riesgo, no universal, fue lo que hizo aceptable el cambio para el negocio.

Un efecto secundario positivo fue el soporte: antes, un porcentaje de los reclamos por «no reconozco este cargo» terminaba siendo fraude confirmado, y el equipo de atención perdía horas investigando compras legítimas. Al concentrar el OTP en las órdenes de riesgo real, bajó también el volumen de esos reclamos ambiguos.

Midiendo el cambio

El experimento de abajo simula, a escala de juguete, el tipo de decisión que toma el motor de riesgo: si el monto o la dirección ameritan pedir un código antes de confirmar la orden.

 // Verify every order, regardless of signal
 async function checkout(order) {
   const code = await mx.otp.issue(order.phone);
   await mx.sms.send({ to: order.phone, text: "Código: " + code });
   return mx.otp.verify(order.phone, await promptUser());
 }