Validar una tarjeta
La API Validar Tarjeta de Crédito aplica el checksum de Luhn a un número de tarjeta y le dice, en una sola llamada, si esos dígitos podrían formar una tarjeta real: sin contactar al emisor, sin intentar ningún cobro y sin guardar nada. Existe para un problema acotado pero constante: el cliente que teclea mal un dígito en el checkout, algo que esta verificación atrapa antes de que el formulario siquiera llegue a un procesador de pagos.
Ejecutar — gratis
Corre en su navegador. Gratis y sin límite: sus datos no salen de esta página.
Qué atrapa en realidad el checksum de Luhn
El algoritmo de Luhn duplica cada segundo dígito del número de tarjeta contando desde la derecha, suma los resultados junto con los dígitos que no se tocaron, y verifica que el total sea múltiplo de diez; todo número de tarjeta emitido correctamente se construye para cumplir esa aritmética. Eso significa que un solo dígito mal tecleado, dos dígitos adyacentes intercambiados o un dígito que se perdió por completo casi siempre rompen el checksum, que es exactamente el tipo de error que comete una persona al teclear dieciséis dígitos en un campo móvil pequeño. Esta api algoritmo de luhn corre ese cálculo exacto en el servidor y devuelve un resultado simple de aprobado o rechazado, además de la red de tarjeta detectada según el prefijo y la longitud del número.
Lo que deliberadamente no hace
Que un número pase la verificación de Luhn significa que está bien formado matemáticamente, nada más: no confirma que la tarjeta exista, esté activa, tenga fondos o pertenezca a quien la está ingresando. Esa distinción importa: este endpoint es un primer filtro rápido y barato para errores de tecleo obvios, no un sustituto de la autorización a través de una red de tarjetas o un procesador de pagos, y nunca debería presentarse a un usuario como prueba de que una tarjeta es válida para cobrar.
La petición y lo que se devuelve
Llame a POST /verify/card-luhn con el número de tarjeta y recibe un task_id de inmediato; la verificación corre de forma asíncrona para que un flujo de checkout nunca quede esperando una llamada bloqueante. La respuesta indica si el checksum de Luhn pasó y, a partir de los dígitos iniciales y la longitud del número, con qué red coincide: Visa, Mastercard, Amex u otras. Nada del número de tarjeta se conserva más allá de la ventana de retención, y nunca se usa para otra cosa que no sea responder esa única petición. Una tarea que falla de plano se reintenta tres veces antes de devolver un error claro, y una tarea fallida jamás se cobra.
Un checksum anterior a los pagos en línea
El algoritmo lleva el nombre de Hans Peter Luhn, un ingeniero de IBM que lo patentó en 1954, décadas antes de convertirse en el esquema de dígito verificador por defecto para las tarjetas de pago. Se diseñó para poder calcularse a mano o con las calculadoras mecánicas de la época, y esa misma sencillez es la razón por la que sigue siendo barato de ejecutar a escala hoy: un solo recorrido sobre los dígitos, sin tablas de referencia, sin llamadas de red, solo aritmética. Esa simplicidad es también su límite honesto: atrapa errores de transcripción, no fraude.
Dónde encaja en un flujo de checkout
Como el resultado llega como JSON estructurado por webhook, los equipos lo llaman en el instante en que el campo del número de tarjeta pierde el foco, mostrando una corrección en línea antes de que el cliente llegue al paso de pago, mucho más barato que un rechazo del procesador. El acceso requiere saldo prepago, lo que mantiene el endpoint rápido y libre de abuso, y cada verificación tiene un precio fijo publicado de $0.002, sin créditos inventados, sin datos de tarjeta almacenados y sin nada reciclado como dato de entrenamiento.
Qué puede hacer con ella
Validación en línea en el checkout
Un checkout de comercio electrónico corre la verificación de Luhn en el instante en que el campo del número de tarjeta pierde el foco, marcando un error de tecleo evidente antes de que el cliente llegue al paso de pago.
Filtro previo a la autorización
Una pasarela de pagos filtra números de tarjeta con una verificación rápida de Luhn antes de enviarlos a autorización, evitando una comisión de rechazo del procesador sobre un número que nunca iba a ser válido.
Captura manual de pedidos
Un sistema de pedidos de call center valida el número de tarjeta mientras un agente lo teclea durante una llamada, atrapando de inmediato un dígito mal escuchado o mal tecleado en lugar de detectarlo después de enviarlo.
Componente de campo de tarjeta en un form builder
Una plataforma de creación de formularios ofrece la validación de Luhn como un tipo de campo integrado, dando a sus clientes retroalimentación en tiempo real sin que tengan que implementar su propia librería de checksum.
Preguntas frecuentes
¿Cómo valido un número de tarjeta de crédito con una API?
Envíe POST /verify/card-luhn con el número de tarjeta. La api algoritmo de luhn devuelve un task_id de inmediato y entrega el resultado del checksum a su webhook o a un enlace firmado al terminar la verificación.
¿Que pase la verificación de Luhn significa que la tarjeta es válida para cobrar?
No. Significa que los dígitos cumplen matemáticamente el checksum de Luhn. No confirma que la tarjeta exista, esté activa o tenga fondos disponibles; eso requiere una autorización real a través de una red de tarjetas.
¿Es gratis validar números de tarjeta?
La herramienta de arriba es gratis en su navegador. La API es de pago: cada llamada se descuenta de su saldo prepago de ForHosting KIT — se recarga desde $10.00 (no caduca), se paga el precio publicado de cada solicitud, y una llamada sin saldo devuelve HTTP 402. Sin suscripción, sin tokens, y una tarea fallida no se cobra.
¿Guarda los números de tarjeta que envío?
No. Los números de tarjeta se usan solo para calcular el checksum y se eliminan al cerrar la ventana de retención; nada se conserva más tiempo, y nada se usa jamás para entrenar nada.
¿Qué redes de tarjeta detecta?
El endpoint identifica redes principales como Visa, Mastercard y American Express a partir del prefijo y la longitud del número, junto con el resultado de aprobado o rechazado de Luhn.
¿Puedo validar muchos números de tarjeta en lote?
Sí. Envíe cada número en su propio POST y las tareas corren en paralelo; cada petición se cobra por separado y una tarea fallida se reintenta y nunca se cobra.
¿Por qué un formulario de pago necesita validar Luhn si el procesador igual lo revisa?
Atrapar un error de tecleo antes de enviar el formulario evita un intento de autorización innecesario y su comisión de rechazo asociada, y le da al cliente una corrección inmediata y específica en lugar de un error de pago genérico.
¿Cómo se entregan los resultados?
De dos formas: un webhook firmado que enviamos a su servidor apenas termina la verificación, lo recomendado, o un enlace firmado válido por 24 horas que puede consultar cuando quiera.
Para desarrolladores — acceso por API
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.
Endpoint de API
¿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, y pronto desde nuestra app, el email y Telegram.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/verify/card-luhn \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"items":["valor-1","valor-2"]}'const res = await fetch("https://api.kit.forhosting.com/verify/card-luhn", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"items": [
"valor-1",
"valor-2"
]
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/verify/card-luhn",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"items": [
"valor-1",
"valor-2"
]
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/verify/card-luhn", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"items":["valor-1","valor-2"]}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"items":["valor-1","valor-2"]}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/verify/card-luhn", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"items": [
"valor-1",
"valor-2"
]
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "verify.card_luhn",
"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.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |