Comprobaciones de validez telefónica en el registro: modelo de cuatro ramas

El problema: una llamada, cuatro significados

Muchos manejadores de registro reducen la comprobación telefónica a aprobar o rechazar. Ese atajo falla en cuanto la comprobación no puede responder. El resultado puede ser desconocido, o la llamada al proveedor puede haber fallado. Rechazar ambos casos convierte una carencia temporal en un registro perdido. Dejar pasar ambos sin un siguiente paso trata la falta de evidencia como éxito. Su decisión es tratar el resultado como cuatro ramas, no dos resultados, y asignar un responsable a cada una. El ejemplo las modela como normal, unknown, provider_failure y otp. Todas devuelven mode synthetic_fixture, otp_sent false y live_line_type_available false. Los campos relevantes son state, valid, line_type y next.

Validez no es posesión ni identidad

Una comprobación telefónica describe el número. No establece que la persona que escribe lo controle, que pueda recibir un mensaje ni quién es esa persona. La posesión requiere una prueba separada, como un OTP enviado por un proveedor que ya utiliza. La identidad requiere una verificación de identidad aparte. La ruta de producción gratuita actual, Basic Lookup, se ofrece a empresas elegibles como complemento de la aplicación, con un límite técnico de 60 solicitudes por minuto. No solicita tipo de línea, titularidad, alcanzabilidad ni entrega de OTP. Por eso la rama normal del fixture muestra line_type mobile solo como valor sintético, mientras live_line_type_available sigue en false. No construya reglas que dependan del tipo de línea en la ruta gratuita.

Escenario hipotético con salidas esperadas del fixture

Hipotético: una pequeña herramienta B2B añade un campo de teléfono a la creación de cuentas y ejecuta las cuatro ramas localmente antes de conectar cualquier consulta real. El ejemplo requiere Python 3.10 o superior, sin credenciales ni red. Salidas esperadas: normal devuelve state simulated, valid true, line_type mobile, next continue_customer_policy. Unknown devuelve state unknown, valid null, line_type null, next review_or_existing_otp. Provider_failure devuelve state unknown, valid null, line_type null, next bounded_retry_then_review. Otp devuelve state unsupported, valid null, line_type null, next customer_otp_provider. Observe que unknown y provider_failure comparten state y valid; solo next los distingue. Su código debe ramificar según next, no solo según valid. Un nombre de rama no admitido lanza UNSUPPORTED_FIXTURE.

Manejo de fallos sin rechazo automático

Diseño de aplicación propuesto, no comportamiento implementado: para unknown, mantenga el registro pendiente y ponga en cola una revisión humana o, si su política lo permite, pida a su proveedor de OTP existente una prueba de posesión. Para provider_failure, reintente un número pequeño y fijo de veces con espera, y luego pase a revisión; nunca en bucle indefinido. Para otp, llame a su propio proveedor de OTP; el fixture nunca envía un código y otp_sent siempre es false. Para normal, aplique su propia política; valid true es una entrada, no una aprobación. Registre la rama y el valor de next en cada intento para que los revisores vean por qué se pausó un registro. El ejemplo solo nombra estos pasos. Los reintentos, las colas de revisión y las llamadas OTP pertenecen a su aplicación.

Qué demuestra y qué no demuestra el ejemplo

Implementado: una función local que devuelve resultados sintéticos fijos para cuatro ramas, más pruebas de ingeniería que cubren transiciones simuladas. No implementado: consultas reales, adaptador de proveedor, envío de OTP ni tipo de línea real. Las pruebas no demuestran éxito en producción, adopción externa ni disponibilidad de la ruta real, que requiere confirmación aparte. Una ejecución local correcta significa que su manejador lee bien los campos. No significa que se comprobara un número real ni que exista permiso comercial alguno.

Lista de aceptación

Antes de conectar una ruta real: 1. Las cuatro ramas se ejecutan localmente y coinciden con las salidas esperadas. 2. Su manejador ramifica según next y trata valid null como ausencia de conclusión, nunca como inválido. 3. Unknown y provider_failure nunca provocan rechazo automático. 4. Provider_failure tiene un número acotado de reintentos y luego revisión. 5. La rama otp llama a su proveedor existente y su interfaz nunca supone que la comprobación envió un código. 6. Ninguna regla depende del tipo de línea de la ruta gratuita. 7. Nada en sus registros etiqueta un número válido como poseído o como identidad. 8. Su tasa de solicitudes se mantiene por debajo de 60 por minuto. 9. La disponibilidad real se confirma por separado antes de que un registro real dependa de ella.

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_failure

Fuentes 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.