Rechaza una CLABE mal tecleada antes de pedir una verificación de banco pagada

El problema y tu decisión

Tu alta de pagos recoge una CLABE y después, en un flujo autorizado aparte, puede solicitar una verificación pagada, como una comparación del nombre del banco. Los errores de tecleo son frecuentes: dos dígitos intercambiados, un dígito faltante, espacios sobrantes al copiar y pegar. Enviar esas entradas cuesta una solicitud y produce un fallo confuso para el usuario. La decisión es dónde detener una entrada errónea. La propuesta: ejecutar primero una validación local del dígito verificador, rechazar solo las entradas con estructura incorrecta o dígito verificador fallido, y tratar un acierto como permiso para hacer la siguiente pregunta, no como su respuesta.

Qué hace realmente la utilidad local

El comportamiento implementado es acotado. La herramienta check_clabe_format acepta una CLABE de 18 dígitos, opcionalmente separada por espacios o guiones, y se ejecuta localmente sin red. Informa structure_valid (la entrada se normaliza a 18 dígitos), checksum_valid (el dígito de control final coincide con el cálculo ponderado de los primeros 17 dígitos) e institution_code (los tres primeros dígitos). No consulta ningún banco en vivo ni afirma la titularidad de la cuenta. Un dígito verificador correcto no prueba que la cuenta exista, pueda recibir fondos o pertenezca a una persona. Todo lo demás, como dirigir al usuario o llamar a una verificación pagada, es diseño de aplicación propuesto que tu código debe asumir.

Escenario hipotético y salida esperada del fixture

Hipotéticamente, una fila de un archivo de pagos contiene el valor de ejemplo 032180000118359719. La salida local probada es: structure_valid true, checksum_valid true, institution_code "032", scope "checksum_only", account_exists null, ownership_verified false, network_calls 0, charged false. Lee cada campo literalmente. account_exists es null porque no se preguntó por la existencia, no porque se confirmara o negara. ownership_verified es false porque la titularidad nunca estuvo en el alcance. network_calls 0 y charged false confirman que la validación no costó nada ni contactó a nadie. En el diseño propuesto, esta fila puede pasar al siguiente paso autorizado. Si un operador tecleara 032180000118359791, intercambiando los dos últimos dígitos, cabe esperar checksum_valid false y que la fila se detenga antes de cualquier solicitud pagada; confirma esa expectativa en tus propias pruebas en lugar de suponerla.

Manejo de fallos

Separa tres resultados. Fallo de estructura: más o menos de 18 dígitos, o caracteres no numéricos tras quitar espacios y guiones; pide al usuario que vuelva a escribir el valor y muestra el número de dígitos. Fallo del dígito verificador: 18 dígitos, pero el dígito de control no coincide; indica que el número parece mal tecleado y pide corrección, sin sugerir que la cuenta sea fraudulenta o esté cerrada. Acierto: continúa, pero mantén el registro etiquetado como checksum_only. No conviertas un acierto en account_verified en tu base de datos ni liberes pagos automáticamente con él. En importaciones por lotes, marca cada fila fallida por separado en lugar de rechazar todo el archivo, y nunca corrijas un dígito en silencio: un dígito adivinado puede apuntar a un número de otra persona que parezca válido.

Límites que conviene decir claramente

Esta utilidad es un filtro local de entrada. No consulta bancos, no confirma que un código de institución esté activo para pagos, no verifica el nombre del beneficiario ni establece quién controla la cuenta. Los ejemplos de comercio aquí son ilustraciones sintéticas del contrato, no aceptación en vivo. Cualquier verificación pagada de identidad o de cuenta beneficiaria es un flujo aparte que requiere capacidades vigentes, autorización y una cotización aceptada. Ningún dato de uso respalda afirmaciones de ahorro o mejor conversión; los conteos observados son cero y no implican causalidad.

Lista de aceptación

Antes de publicar: la entrada de ejemplo produce exactamente los ocho campos anteriores; las formas con espacios y con guiones del mismo número dan el mismo resultado; una entrada de 17 dígitos pone structure_valid en false; una entrada con dígitos intercambiados pone checksum_valid en false y no dispara ninguna solicitud posterior; los registros guardados conservan scope checksum_only y ownership_verified false; los mensajes para fallos de estructura y de dígito verificador son distintos; ninguna ruta de código marca una cuenta como verificada ni libera fondos solo con esta validación; las importaciones por lotes informan cada fila fallida por separado; y la verificación pagada posterior solo se llama mediante su propio flujo autorizado.

Revisar este producto

https://gridzen.ai/tools/clabe-format/ · Revise entrada, salida y límites. El comando muestra el producto sin ejecutar solicitudes reales.

gridzen tools --product clabe-format

Fuentes y alcance

https://gridzen.ai/tools/clabe-format/ 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.