ForHosting KIT · Datos y archivos

Validar una tarjeta de crédito con el algoritmo de Luhn

Este validador elimina los espacios y guiones habituales del número proporcionado, comprueba que todos los caracteres restantes sean dígitos y aplica la suma de control determinista de Luhn.

● BetaGratis · en su navegador
Úselo desde WebAPIEmailTelegramApp pronto

También indica la red probable a partir de prefijos reconocidos de Visa, Mastercard, American Express y Discover. El resultado permite detectar errores frecuentes antes de solicitar un pago, pero no demuestra que la cuenta exista, esté activa, pertenezca al cliente ni pueda completar una compra.

Cómo funcionan la normalización y el control de entrada

Introduzca el número de tarjeta como una cadena, ya sea únicamente con dígitos o con un formato habitual separado por espacios o guiones. El validador elimina exclusivamente esos dos separadores. Después exige que cada carácter restante sea un dígito ASCII. Las letras, los signos de puntuación, las barras, los guiones bajos y cualquier otro símbolo provocan un error de entrada, en lugar de eliminarse sin aviso. Esta conducta estricta es importante: una limpieza demasiado permisiva podría convertir accidentalmente un valor incorrecto en otro número y ofrecer un resultado engañoso. También se rechazan una cadena vacía, un valor compuesto solo por separadores o cualquier valor que no sea una cadena. El objeto de respuesta nunca repite el número normalizado; contiene únicamente el resultado de la suma de control y la red probable. Trate la entrada original como dato de pago confidencial en su aplicación, aunque este cálculo sea local y no requiera consultas al emisor, autorizaciones, solicitudes de red, valores aleatorios ni estado persistente.

Qué significa el resultado de Luhn

El algoritmo de Luhn calcula un dígito de control pensado para descubrir errores comunes de transcripción. Desde el dígito situado más a la derecha, el validador alterna entre conservar un dígito y duplicarlo. Cuando un valor duplicado supera nueve, se le resta nueve; después se suman todos los valores y el número supera la prueba si el total es divisible por diez. Un resultado positivo solo significa que la secuencia concuerda matemáticamente con su dígito de control final. No demuestra que un banco haya emitido el número, que la cuenta continúe abierta, que haya saldo ni que la persona esté autorizada para utilizarla. Una secuencia inventada puede superar Luhn, mientras que una tarjeta auténtica con un dígito mal escrito normalmente falla. Utilice este resultado como ayuda temprana en el formulario o control de calidad de datos y confíe después en un procesador de pagos conforme para tokenización, autenticación, autorización, controles antifraude y la decisión final sobre la operación.

Cómo se identifica la red probable

La red se deduce del prefijo de identificación del emisor y no mediante una consulta a un registro remoto. Un número que empieza por 4 se informa como Visa. Mastercard incluye el intervalo tradicional de 51 a 55 y el más reciente de 2221 a 2720. American Express utiliza los prefijos 34 y 37. Discover comprende 6011, 65, el intervalo de 644 a 649 y el bloque asignado de 622126 a 622925. Si ninguna regla coincide, la red se devuelve como desconocida, aunque el resultado de Luhn se calcula con normalidad. Es importante hablar de red probable: las asignaciones cambian, existen productos compartidos y esta herramienta reconoce deliberadamente solo las cuatro redes solicitadas. La detección del prefijo y la suma de control son independientes; un número puede parecer de una red y fallar Luhn, o superar Luhn y conservar una red desconocida. Cada solicitud utiliza el precio base publicado de $0.002, sin cargo variable por longitud ni por red detectada.

Avisos al rellenar el pago

Detecte un posible dígito mal escrito antes de entregar los datos a un procesador conforme para su autorización.

Control de registros importados

Compruebe la estructura de números procedentes de archivos antiguos sin afirmar que las cuentas siguen activas.

Pruebas de formularios de pago

Verifique que se admitan separadores de formato y que los caracteres incorrectos se rechacen de forma coherente.

¿Superar Luhn demuestra que la tarjeta es real?

No. Solo demuestra que los dígitos cumplen una suma de control. La existencia, titularidad, vigencia, fondos y autorización requieren una respuesta del procesador y del emisor.

¿Qué caracteres de formato se admiten?

Puede incluir espacios y guiones. Se eliminan antes del cálculo; cualquier otro carácter que no sea un dígito genera un error de entrada.

¿Qué redes de tarjetas se pueden identificar?

Las reglas de prefijos reconocen probablemente Visa, Mastercard, American Express y Discover. Los demás prefijos se informan como desconocidos.

¿Un prefijo reconocido puede tener una suma inválida?

Sí. La clasificación del prefijo y el cálculo de Luhn son independientes, por lo que un prefijo de Visa no garantiza que se supere la prueba.

¿El validador contacta con un banco o una red?

No. El resultado procede de aritmética determinista y reglas de prefijos, sin consulta remota ni intento de autorización.

Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.

POSThttps://api.kit.forhosting.com/data/credit-card-luhn-validate

¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.

curl -X POST https://api.kit.forhosting.com/data/credit-card-luhn-validate \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"number":"4111 1111 1111 1111"}'
{
  "number": "4111 1111 1111 1111"
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "data.credit_card_luhn_validate",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.

Por solicitud$0.002

Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.

max_mb25
HTTPCódigoSignificado
401unauthorizedAPI key ausente o inválida.
402insufficient_balanceEl saldo no cubre el precio de la tarea.
404unknown_typeEl tipo de tarea no existe.
429rate_limitedDemasiadas peticiones. Use el webhook en vez de sondear.

Ver la documentación completa del KIT →