"Inténtalo más tarde" no es "inválido": cómo tratar una verificación de teléfono que no puede responder ahora
Una pregunta pública describe que Google Play Console muestra "We can't verify your phone number right now. Try again later." No podemos diagnosticar esa plataforma, no representamos a quien preguntó, y nada aquí arregla Google Play. Pero el mensaje plantea una decisión cercana para tu propio flujo de registro. Cuando tu verificación de teléfono no puede responder, ¿el usuario ve un rechazo, un callejón sin salida o un reintento acotado con un siguiente paso claro? Este artículo usa solo el ejemplo sintético verificado de cuatro ramas para separar la ruta provider_failure de un resultado realmente inválido. Propone un manejo de fallos a cargo de quien llama e incluye salidas exactas del fixture contra las que puedes hacer aserciones.
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
"Inténtalo más tarde" le dice al usuario que el sistema verificador no llegó a una conclusión. No dice que el número sea incorrecto. Si tu código de registro trata cualquier resultado distinto de un aprobado como fallo, una caída temporal se convierte en un rechazo permanente. El usuario también puede reintentar sin fin y sin recibir ninguna respuesta. Tienes que decidir tres cosas. Primero, a qué estado corresponde un fallo temporal. Segundo, cuántos reintentos permites y en qué intervalo. Tercero, adónde va el caso cuando se agotan los reintentos. El fixture no toma estas decisiones por ti; solo nombra un siguiente paso. Tu aplicación es dueña del presupuesto de reintentos, del mensaje al usuario y de la cola de revisión. Esto es diseño de aplicación propuesto, no comportamiento que el ejemplo implemente.
Lo que el fixture devuelve realmente
El ejemplo descargable ejecuta cuatro ramas sintéticas: normal, unknown, provider_failure y otp. Requiere Python 3.10 o posterior, no usa credenciales y no hace llamadas de red. Cada rama devuelve los campos mode, branch, otp_sent, live_line_type_available, state, valid, line_type y next. Para provider_failure, la salida esperada es mode synthetic_fixture, branch provider_failure, otp_sent false, live_line_type_available false, state unknown, valid null, line_type null y next bounded_retry_then_review. Compárala con unknown, que devuelve el mismo state unknown y valid null, pero next review_or_existing_otp. Solo normal devuelve valid true, line_type mobile y next continue_customer_policy. La rama otp devuelve state unsupported y next customer_otp_provider, y no se envía ningún código. Cualquier otro nombre de rama lanza UNSUPPORTED_FIXTURE. Ten en cuenta que valid null no es valid false. Ninguna rama de este fixture significa "número inválido", y ninguna debe interpretarse como un rechazo.
Un escenario hipotético resuelto
Imagina un formulario de registro hipotético de un pequeño equipo B2B. Un usuario introduce un número y la verificación de teléfono de tu backend agota el tiempo de espera. En el sandbox representas esto ejecutando la rama provider_failure. El manejador que propones lee state unknown y next bounded_retry_then_review. No marca la cuenta como rechazada. Guarda el intento con un contador y muestra al usuario un mensaje neutral: la verificación no está disponible y el registro no se ha denegado. Reintenta según un calendario que tú defines, por ejemplo un número pequeño y fijo de intentos. Si esos intentos siguen devolviendo unknown, el manejador pasa el caso a revisión humana en lugar de seguir en bucle. Si tu política permite que el usuario continúe, cualquier acción que dependa de la verificación queda retenida. Los recuentos y los tiempos son elecciones tuyas para ilustrar el caso. No son comportamiento del fixture ni un valor de producción recomendado.
Límites que conviene decir con claridad
El ejemplo es sintético y nunca es un adaptador de proveedor en vivo. Un valid true en la rama normal es un dato predefinido. No demuestra titularidad, alcanzabilidad por SMS ni identidad. La ruta gratuita actual de producción, Basic Lookup, no solicita tipo de línea, titularidad, alcanzabilidad ni entrega de OTP. Por eso live_line_type_available es false en todas las ramas. Esa ruta requiere una inscripción de cuenta aparte y tiene un límite técnico de 60 solicitudes por minuto. Una ráfaga de reintentos de usuarios podría, por tanto, empeorar tus propios fallos. La rama otp recomienda usar tu proveedor de OTP existente y no envía nada. La descarga de cuatro ramas no es lo mismo que la prueba HTTP anónima de tres escenarios, así que no trates una como evidencia de la otra.
Manejo de fallos alrededor del fixture
Mantén "no disponible" e "inválido" como estados almacenados distintos, aunque tu interfaz los redacte de forma parecida. Limita los reintentos por registro y por ventana de tiempo, y mantente por debajo del límite de velocidad. Registra cada intento con el resultado de su rama para que los revisores vean por qué llegó el caso. Nunca permitas que un bucle de reintentos se convierta en silencio en un rechazo o una aprobación automáticos. Trata explícitamente la entrada inesperada: en el fixture, una rama no soportada lanza un error en vez de adivinar. Tu adaptador debería hacer lo mismo. Las pruebas de ingeniería incluidas cubren transiciones simuladas, vinculaciones, callbacks duplicados, reinicios y tiempos de espera. No demuestran éxito en producción.
Lista de aceptación
Ejecuta las cuatro ramas y comprueba las salidas exactas indicadas arriba. Confirma que provider_failure nunca produce una cuenta rechazada. Confirma que unknown lleva a revisión o a tu paso de OTP existente. Confirma que otp_sent sigue en false y que tu código no espera un código que el fixture nunca envió. Verifica que los reintentos se detienen en el límite que definiste y que después se crea un elemento de revisión. Verifica que el usuario ve un mensaje que no lo acusa. Comprueba que live_line_type_available es false y asegúrate de que ninguna lógica dependa de line_type en uso real. Deja constancia de que pasar en el sandbox no es un permiso de negocio real. Si esto encaja con tu tarea, el siguiente paso es ejecutar el tutorial sintético y, opcionalmente, guardar una solicitud de sandbox. La disponibilidad de la ruta en vivo requiere una confirmación aparte.
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.