Trabajando con el Validador de Tarjetas de Crédito - API de Verificación de BIN

Necesitas verificar los detalles de la tarjeta rápidamente, reducir intentos fraudulentos y enrutar pagos correctamente, todo sin construir una pila completa de inteligencia de tarjetas. Al final de este artículo, podrás validar el BIN (primeros 6 dígitos) de una tarjeta de crédito y leer de vuelta el emisor, la marca, el tipo y las señales del país con el Validador de Tarjetas de Crédito - API de Verificación de BIN en Zyla API Hub.

Qué hace esta API y cuándo usarla

La API de Validador de Tarjetas de Crédito - Verificación de BIN te permite validar el BIN de una tarjeta de crédito (los primeros seis dígitos) y recuperar puntos de datos estructurados útiles para flujos de trabajo financieros y de pagos. Con una sola solicitud GET, puedes saber si un BIN es válido y recibir datos como la marca de la tarjeta, el tipo de tarjeta, el nivel, el nombre del emisor (cuando esté disponible) y las señales del país del emisor. Los usos típicos incluyen:

• Pre-validación en flujos de pago para reducir rechazos más adelante en el ciclo de vida de la transacción.
• Lógica de enrutamiento para selección de PSP o adquirente por marca o región del emisor.
• Pipelines de puntuación de riesgo y fraude que combinan inteligencia de BIN con geolocalización, dispositivo y verificaciones de velocidad.
• Enriquecimiento en métodos de pago almacenados para apoyar el servicio al cliente o paneles de análisis.

Puedes explorar más APIs de finanzas y pagos en Zyla API Hub, que proporciona una cuenta, una clave API y un modelo de suscripción que cubre miles de APIs.

Comenzando en Zyla API Hub

Para implementar tu integración esta semana:

1. Abre la lista de APIs: Comienza prueba de 7 días en Validador de Tarjetas de Crédito - API de Verificación de BIN.
2. Haz clic en Suscribirse o Comenzar Prueba Gratuita (cuando esté disponible) para obtener tu clave API. Zyla utiliza suscripción + cuota, no pago por llamada.
3. Autentica las solicitudes con el encabezado Authorization: Bearer YOUR_API_KEY.

Las opciones de acceso típicamente incluyen una prueba de 7 días o 50 solicitudes para una primera API; consulta la página de la API para las opciones de acceso y precios actuales.

Referencia de endpoint

La API de Validador de Tarjetas de Crédito - Verificación de BIN expone un único endpoint en Zyla:

• Verificador de BIN
  Método: GET
  URL: https://zylalabs.com/api/40/credit-card-validator-bin-checker-api/1885/bin-checker
  Propósito: Validar una tarjeta de crédito basada en sus primeros seis dígitos (BIN/IIN) y recibir detalles de la tarjeta y del emisor.
  Parámetro de consulta requerido:
  • bin (cadena, requerido): Los primeros 6 dígitos del número de tarjeta. Ejemplo: 346350

La respuesta indica si el BIN es válido y devuelve metadatos asociados como marca, tipo, nivel, datos del emisor e información del país (si está disponible).

Ejemplo de respuesta JSON oficial

Este es el ejemplo de carga útil oficial para el endpoint de Verificación de BIN. Tus valores reales dependerán del BIN que consultes.

{
"status": 200,
"success": true,
"isValid": true,
"message": "The BIN number is valid.",
"data": {
"bin_iin": "346350",
"card_brand": "AMERICAN EXPRESS",
"card_type": "CREDIT",
"card_level": "------",
"issuer_name_bank": "------",
"issuer_bank_website": "API Only",
"issuer_bank_phone": "API Only",
"iso_country_name": null,
"iso_country_code": null
}
}

Notas sobre los campos:

• status: Código de estado estilo HTTP incluido en el cuerpo.
• success: Booleano que indica el éxito de la solicitud.
• isValid: Si el BIN es reconocido como válido.
• message: Mensaje de estado legible por humanos.
• data.bin_iin: Repite el BIN que consultaste.
• data.card_brand: Esquema/red (por ejemplo, AMERICAN EXPRESS, VISA, MASTERCARD).
• data.card_type: Clasificación de CRÉDITO/DÉBITO o similar.
• data.card_level: Nivel del producto si está disponible (por ejemplo, Platino). Los guiones indican que no se proporcionó.
• data.issuer_name_bank / issuer_bank_website / issuer_bank_phone: Metadatos del emisor cuando están disponibles. “Solo API” o guiones indican disponibilidad a través de API.
• data.iso_country_name / iso_country_code: Metadatos del país cuando están disponibles; nulo cuando no se proporciona.

Misma respuesta (forma compacta)

Aquí está el mismo ejemplo como una sola línea para instantáneas de registro o pruebas:

{"status":200,"success":true,"isValid":true,"message":"The BIN number is valid.","data":{"bin_iin":"346350","card_brand":"AMERICAN EXPRESS","card_type":"CREDIT","card_level":"------","issuer_name_bank":"------","issuer_bank_website":"API Only","issuer_bank_phone":"API Only","iso_country_name":null,"iso_country_code":null}}

Ejemplo en Python: consultar un BIN y ramificar según el resultado

El siguiente fragmento de Python llama al endpoint, verifica la validez y extrae algunos campos de alto valor para decisiones de enrutamiento o riesgo.

import requests

API_KEY = "YOUR_API_KEY"
BIN = "346350"

url = "https://zylalabs.com/api/40/credit-card-validator-bin-checker-api/1885/bin-checker"
headers = {
"Authorization": f"Bearer {API_KEY}"
}
params = {"bin": BIN}

resp = requests.get(url, headers=headers, params=params, timeout=10)
resp.raise_for_status()
data = resp.json()

if not data.get("success"):
raise RuntimeError(f"La verificación del BIN falló: {data}")

is_valid = data.get("isValid")
message = data.get("message")
card_info = data.get("data", {}) or {}

brand = card_info.get("card_brand")
card_type = card_info.get("card_type")
issuer = card_info.get("issuer_name_bank")
country_code = card_info.get("iso_country_code")

print(f"isValid={is_valid} message={message}")
print(f"brand={brand} type={card_type} issuer={issuer} country={country_code}")

# Ejemplo de ramificación:
if is_valid and brand == "AMERICAN EXPRESS":
# Enrutar a un adquirente o PSP específico para Amex
pass
elif is_valid and card_type == "DEBIT":
# Aplicar lógica de SCA diferente o pesos de riesgo
pass
else:
# Manejo de respaldo para BINs inválidos o desconocidos
pass

Mapeo de campos que probablemente usarás

• data.card_brand → Enrutamiento de pagos, reglas de recargo o ajustes de UI (por ejemplo, mostrar el logotipo de la marca).
• data.card_type → Diferencias en políticas de riesgo para tarjetas de crédito vs. débito.
• data.issuer_name_bank → Herramientas de servicio al cliente o enrutamiento basado en el emisor.
• data.iso_country_code → Cumplimiento basado en la región, flujos 3DS vs. no 3DS, y heurísticas KYC.

Muchos equipos persisten solo un subconjunto de estos campos, especialmente la marca, el tipo y el código del país, junto con el BIN para un posterior enriquecimiento.

Idempotencia, reintentos y caché

• Idempotencia: GET es seguro para reintentar en errores de transporte. Agrega retroceso y jitter.
• Caché: Los metadatos del BIN cambian con poca frecuencia. Almacena en caché las respuestas por BIN (por ejemplo, 24 horas o tu política de operaciones) para reducir la latencia y las llamadas.
• Manejo de nulos: Algunos campos pueden ser nulos o enmascarados (por ejemplo, “Solo API”). Trata los valores faltantes como desconocidos y evita suposiciones frágiles.
• Cuotas: Zyla utiliza suscripción + cuota. Consulta la página de la API para la asignación de tu plan y las opciones de acceso actuales.

Casos de uso financieros en el mundo real

• Pre-verificación de BIN en el checkout: Tan pronto como el cliente ingrese seis dígitos, consulta la API y decide si mostrar un aviso de CVV específico de Amex o un camino SCA distinto.
• Selección de adquirente: Prefiere diferentes adquirentes por marca o región del emisor para optimizar las tasas de aprobación.
• Defensas contra el fraude: Marca regiones desajustadas (por ejemplo, país del BIN vs. país de IP de envío) para verificación adicional.
• Soporte al cliente: Cuando un pago falla, muestra la marca y el emisor detectados basados en el BIN para acelerar el triaje.

Ejemplo de contrato (para pruebas y simulaciones)

Al escribir pruebas de contrato, puedes afirmar contra esta estructura conocida como buena para asegurar que los analizadores y validadores posteriores sean estables.

{
"status": 200,
"success": true,
"isValid": true,
"message": "The BIN number is valid.",
"data": {
"bin_iin": "346350",
"card_brand": "AMERICAN EXPRESS",
"card_type": "CREDIT",
"card_level": "------",
"issuer_name_bank": "------",
"issuer_bank_website": "API Only",
"issuer_bank_phone": "API Only",
"iso_country_name": null,
"iso_country_code": null
}
}

Llamando a la API desde agentes de IA a través de MCP

Puedes orquestar esta API dentro de entornos de codificación de IA que soporten el Protocolo de Contexto del Modelo (MCP), como Claude Code, Cursor o Windsurf. El endpoint MCP de Zyla centraliza el acceso a cualquier API a la que te hayas suscrito utilizando tu clave de Zyla.

• Endpoint: MCP
• Enfoque: Configura tu cliente compatible con MCP con el endpoint MCP de Zyla y tu clave. Indica al agente que realice un GET HTTP a la URL del Verificador de BIN con el encabezado de Autorización configurado a Bearer YOUR_API_KEY y el parámetro de consulta bin=346350.
• Validación: Analiza los campos isValid y data del JSON para ramificar la lógica del agente (por ejemplo, explica al desarrollador qué enrutamiento de adquirente usar según la marca).

Debido a que MCP centraliza las credenciales, evitas incrustar claves en los prompts y mantienes las llamadas consistentes a través de herramientas.

Lista de verificación operativa

• Seguridad: Nunca registres PANs completos. Solo necesitas los primeros seis dígitos (BIN) para esta API.
• Timeouts: Establece timeouts razonables (por ejemplo, 5–10 segundos). Reintenta solo en errores de red transitorios.
• Observabilidad: Registra el ID de solicitud, BIN y resumen de respuesta (estado, éxito, isValid, marca, tipo). Evita registrar PII más allá del BIN donde la política lo requiera.
• Resiliencia: Si los campos son nulos, predetermina flujos conservadores (por ejemplo, requiere 3DS o verificación adicional).
• Liberación: Activa reglas de control de BIN para que los equipos de producto puedan ajustar la lógica sin redeplegar.

Resolución de problemas y validación

Si encuentras nulos inesperados o valores enmascarados, confirma que tu integración está leyendo el JSON correctamente y no asumiendo campos faltantes. Usa el ejemplo conocido como bueno para verificar tu analizador:

{
"status": 200,
"success": true,
"isValid": true,
"message": "The BIN number is valid.",
"data": {
"bin_iin": "346350",
"card_brand": "AMERICAN EXPRESS",
"card_type": "CREDIT",
"card_level": "------",
"issuer_name_bank": "------",
"issuer_bank_website": "API Only",
"issuer_bank_phone": "API Only",
"iso_country_name": null,
"iso_country_code": null
}
}

Comprobaciones comunes:

• Ortografía del encabezado: Asegúrate de que “Authorization: Bearer YOUR_API_KEY” sea exacto.
• Parámetro de consulta: La clave debe ser “bin” y el valor debe ser solo los primeros seis dígitos.
• Método HTTP: Debe ser GET para este endpoint.

Flujo de ejemplo de extremo a extremo

1. El usuario ingresa el número de tarjeta; tan pronto como están presentes seis dígitos, extrae el BIN.
2. GET el endpoint del Verificador de BIN con ?bin=346350 y tu encabezado de Autorización.
3. En la respuesta: si éxito y isValid:
   • Almacena la marca y el tipo para enrutamiento y UI.
   • Si la marca es AMERICAN EXPRESS, ajusta la etiqueta de CVV y la ruta del adquirente.
   • Si iso_country_code es nulo, no asumas enrutamiento nacional; maneja como desconocido.
4. Si no es válido, solicita al usuario temprano o pide un método de pago alternativo.
5. Almacena en caché la respuesta indexada por BIN para reducir búsquedas duplicadas.

Otro par de cURL y JSON oficial para pruebas rápidas

Usa esta solicitud exacta y espera la misma forma a continuación (los valores variarán para otros BINs):

curl -s -X GET "https://zylalabs.com/api/40/credit-card-validator-bin-checker-api/1885/bin-checker?bin=346350" \
-H "Authorization: Bearer YOUR_API_KEY"

{
"status": 200,
"success": true,
"isValid": true,
"message": "The BIN number is valid.",
"data": {
"bin_iin": "346350",
"card_brand": "AMERICAN EXPRESS",
"card_type": "CREDIT",
"card_level": "------",
"issuer_name_bank": "------",
"issuer_bank_website": "API Only",
"issuer_bank_phone": "API Only",
"iso_country_name": null,
"iso_country_code": null
}
}

Por qué construir en Zyla API Hub

Zyla API Hub centraliza la autenticación y facturación a través de más de 10,000 APIs públicas. Usas una cuenta, una clave y facturación de suscripción + cuota para integrar múltiples servicios rápidamente. Explora APIs de finanzas y pagos, incluyendo el Verificador de BIN, desde un solo lugar: zylalabs.com.

FAQ

¿Esta API devuelve una validación completa de PAN?
No. Valida y enriquece el BIN (primeros seis dígitos) y devuelve metadatos de tarjeta/emisor. La validación de PAN y CVV son manejadas por pasarelas de pago o adquirentes durante la autorización.

¿Qué autenticación se requiere?
Usa el encabezado Authorization: Bearer YOUR_API_KEY en cada solicitud. Obtén tu clave de la lista de APIs después de suscribirte.

¿Puedo almacenar en caché los resultados?
Sí. Los metadatos del BIN son relativamente estables. Almacena en caché por BIN (por ejemplo, 24 horas) para reducir la latencia y las llamadas, luego actualiza periódicamente.

¿Cuáles son los límites y precios del plan?
Zyla utiliza suscripción + cuota, no pago por llamada. La primera API generalmente ofrece una prueba de 7 días o 50 solicitudes. Consulta la página de la API para las opciones de acceso y precios actuales.

¿Cómo uso esto desde un agente de codificación de IA?
Configura tu cliente compatible con MCP para usar el endpoint MCP de Zyla y tu clave API. Indica al agente que realice una solicitud GET a la URL del Verificador de BIN con el encabezado de Autorización y el parámetro de consulta bin. Analiza los campos isValid y data para guiar decisiones.

Obtén tu clave y envía

Implementa la validación de BIN en minutos. Suscríbete y obtén tu clave en la lista de APIs: Comienza prueba de 7 días en Validador de Tarjetas de Crédito - API de Verificación de BIN. Luego llama al endpoint, almacena en caché los resultados por BIN y conecta los campos a tu lógica de enrutamiento de pagos y riesgo.