¿Debe un resultado telefónico desconocido rechazar un registro?
Un formulario de registro llama a una verificación telefónica y a veces recibe algo que no es ni válido ni inválido: o el resultado es desconocido, o la llamada al proveedor falló. El atajo tentador es rechazar todo lo que no sea un aprobado limpio. Este artículo argumenta en contra de ese atajo y recorre el ejemplo sintético de cuatro ramas para mostrar cómo enrutar cada resultado. La distinción central es sencilla: un resultado desconocido es evidencia ausente, no evidencia negativa. Si rechaza por evidencia ausente, cada caída del proveedor se convierte en un usuario bloqueado.
curl https://gridzen.ai/console/api/quickstart/trial \
-H 'Content-Type: application/json' \
-d '{"task": "signup_phone", "scenario": "success"}'El problema y la decisión que le corresponde
La decisión que tiene delante no es si un número es bueno. Es qué debe hacer su flujo de registro cuando la verificación no puede responder. Hay tres resultados que se parecen en el código, pero significan cosas distintas. Un número confirmado como inválido es evidencia. Un resultado desconocido significa que la verificación no devolvió ninguna señal utilizable. Un fallo del proveedor significa que la verificación nunca se completó. Solo el primero justifica un bloqueo por motivos de formato. Los otros dos necesitan una ruta explícita: recuperación acotada, revisión manual o un paso de posesión mediante el proveedor de OTP que usted ya opera. Tenga presente lo que ninguna verificación telefónica establece. La validez y el tipo de línea son distintos de la posesión y la identidad. La ruta de producción gratuita actual no solicita tipo de línea, titularidad, alcanzabilidad ni entrega de OTP. Su piloto controlado aprobado cubre solo el formato y la validez básicos del número.
Qué implementa el ejemplo descargable
El ejemplo descargable se ejecuta sin conexión con Python 3.10 o superior. No requiere credenciales y no realiza llamadas de red. Tiene cuatro ramas: normal, unknown, provider_failure y otp. Cada salida incluye los campos mode, branch, state, valid, line_type, next, otp_sent y live_line_type_available. Dos tipos de valor nunca cambian entre ramas. El campo mode siempre es synthetic_fixture. El campo otp_sent siempre es false, por lo que el ejemplo nunca envía un código. El campo live_line_type_available siempre es false, lo que refleja que la ruta gratuita no devuelve tipo de línea. El tipo de línea mobile que verá en la rama normal son datos de fixture, no algo que devolvería una verificación en vivo. Cualquier nombre de rama distinto de los cuatro provoca UNSUPPORTED_FIXTURE. Este ejemplo no es lo mismo que la prueba HTTP anónima, que cubre tres escenarios. No trate los resultados de uno como resultados del otro.
Escenario hipotético: cuatro registros, cuatro rutas
Imagine un marketplace hipotético que recibe cuatro registros en una hora. Las salidas esperadas del fixture se corresponden con ellos así. El primer registro sigue la rama normal. La salida es state simulated, valid true, line_type mobile y next continue_customer_policy. Sus propias reglas deciden qué ocurre después; la verificación por sí sola no admite al usuario. El segundo registro sigue la rama unknown. La salida es state unknown, valid null, line_type null y next review_or_existing_otp. La cuenta queda en espera de revisión o pasa a su paso de OTP existente. No se rechaza. El tercer registro sigue la rama provider_failure. La salida también es state unknown, con valid y line_type en null, pero next es bounded_retry_then_review. Reintenta un número limitado de veces y luego pasa el caso a revisión. El cuarto registro sigue la rama otp, que modela una solicitud para demostrar posesión. La salida es state unsupported, valid null, line_type null y next customer_otp_provider. GridZen no envía nada aquí; ese paso corresponde a su proveedor de OTP. Las cuatro salidas llevan otp_sent false.
Diseño propuesto para su aplicación: manejo de fallos
Lo siguiente es orientación de diseño para su aplicación, no un comportamiento que implemente el fixture. Acote los reintentos con un número fijo de intentos y un plazo límite, para que un fallo del proveedor no entre en un bucle infinito ni bloquee el formulario indefinidamente. Guarde los resultados desconocidos y fallidos como un estado propio, separado de inválido. Así, los revisores y la analítica no confundirán una caída con fraude. Cuando la ruta sea la revisión, decida qué puede hacer el usuario mientras espera. Por ejemplo, puede permitirle navegar, pero bloquear pagos o publicaciones hasta que se resuelva el caso. Si enruta a OTP, llame a su proveedor existente y registre su resultado por separado del resultado de la verificación telefónica. No permita que un valor valid nulo se convierta en false en ninguna parte de su código.
Límites que conviene declarar con claridad
El fixture produce solo salidas sintéticas. Demuestra el manejo de ramas en su código, no el éxito en producción. Sus pruebas cubren transiciones simuladas, vinculaciones, callbacks duplicados, reinicios y tiempos de espera. No demuestran precisión en vivo, adopción externa ni superioridad de Agentes. Una recomendación de OTP no envía ningún código ni establece la posesión. La disponibilidad de la ruta en vivo requiere una confirmación aparte. Las verificaciones telefónicas en producción se limitan al piloto controlado, y la verificación en vivo de autoservicio está desactivada.
Lista de aceptación
Antes de publicar, confirme cada uno de los siguientes puntos: - Al ejecutar las cuatro ramas se reproducen exactamente los valores de next indicados arriba. - Su código trata un valid nulo como desconocido, nunca como inválido. - La rama unknown nunca rechaza automáticamente un registro. - La rama provider_failure reintenta un número acotado de veces y luego pasa a revisión. - La rama otp llama solo a su propio proveedor de OTP y registra otp_sent como false del lado de GridZen. - Ninguna lógica lee line_type de un resultado en vivo. - Su código maneja UNSUPPORTED_FIXTURE. - Las pruebas unitarias pasan. - La documentación no afirma titularidad, alcanzabilidad ni identidad a partir de una verificación telefónica.
Ejecutar el ejemplo sintético comprobado
Descargue y extraiga https://gridzen.ai/downloads/verification-delivery.zip, entre en verification_delivery y ejecute con Python 3.10+. El ejemplo local no hace llamadas de red. Use una base nueva para otra prueba de identidad.
python3 delivery.py phone --branch unknown
python3 delivery.py phone --branch provider_failureFuentes y alcance
https://gridzen.ai/guides/signup-phone-check/ https://gridzen.ai/guides/current-capabilities/ Basado en las fuentes comprobadas y el ejemplo local; las reglas propuestas son recomendaciones de diseño, no comportamiento de producción demostrado. Redacción asistida por IA con revisión independiente.
Probar por separado tres resultados del sandbox Crear una cuenta para continuar la integración
Una descarga no demuestra una ejecución correcta. Los ejemplos locales y el sandbox en línea se prueban por separado.