Diagnosticar rechazos con BIN
decline bin tarjeta · autorizacion rechazada bin · issuer decline bin
Un rechazo de autorización puede venir del emisor, del adquirente, de 3DS, de límites de producto o de reglas internas. El BIN aporta contexto para agrupar
Por DN01 Network Team
Un rechazo de autorización puede venir del emisor, del adquirente, de 3DS, de límites de producto o de reglas internas. El BIN aporta contexto para agrupar patrones por banco, país o tipo de tarjeta. Use el BIN Checker de DN01 en /es/bin-checker cuando necesite leer contexto de los primeros seis u ocho dígitos sin introducir un PAN completo.
Si muchos rechazos comparten prefijo, revise si el emisor tiene restricciones, si el producto es prepago, si la moneda dispara riesgo o si su PSP enruta mal esa red. No concluya que la tarjeta es inválida solo por el BIN. Esta guía se centra en operaciones reales: soporte, prevención de fraude, checkout, analítica y documentación interna. No promete validar si una tarjeta existe, está activa o tiene fondos.
Para completar el recorrido, compare esta lectura con guías relacionadas como /es/articles/3ds-sca-bin-checker, /es/articles/checkout-ecommerce-bin, /es/articles/3ds-sca-bin-checker y /es/articles/card-testing-ataques-bin. Mantener estas referencias juntas reduce errores entre equipos de soporte, riesgo y desarrollo.
Cuándo usar esta comprobación
Use /es/bin-checker cuando tenga un prefijo aislado de seis a ocho dígitos y quiera entender red, país, emisor o tipo de producto. El caso típico es un ticket donde el cliente no debe compartir datos completos de la tarjeta, pero el equipo necesita contexto para interpretar un rechazo o una regla de riesgo.
También sirve para revisar patrones agregados: muchos fallos del mismo emisor, diferencias entre país de tarjeta y país de compra, campañas de card testing o cambios tras migrar de PSP. En todos esos casos, el BIN es una señal de clasificación, no una decisión final.
Si el flujo involucra IP sospechosas, complemente la revisión con /es/blacklist-checker. Si necesita automatizar consultas de prefijos en jobs internos, revise /es/api-docs y solicite acceso en /es/api-register-access.
Checklist práctico
1. Copie solo los primeros seis u ocho dígitos desde una fuente permitida, como el panel del PSP o un log ya truncado. No copie ni pegue el número completo de tarjeta en herramientas internas, hojas de cálculo o chats.
2. Busque el prefijo en DN01 y documente red, país, tipo, emisor y hora de consulta. Si el resultado no aparece, pruebe con ocho dígitos cuando los tenga de forma segura y marque el dato como no concluyente.
3. Cruce el resultado con señales independientes: código de rechazo, resultado 3DS, país de IP, moneda, historial de cuenta, velocity, método de envío y respuesta del adquirente. Una discrepancia aislada rara vez basta para bloquear.
4. Conserve evidencia mínima y segura: prefijo truncado, ID de transacción del PSP, regla aplicada y conclusión. Evite exportar campos sensibles a sistemas sin necesidad operacional.
Errores frecuentes
El primer error es tratar el BIN como una consulta bancaria en tiempo real. No lo es: trabaja con rangos publicados o agregados y puede quedar desactualizado, especialmente con fintechs, tarjetas virtuales y rangos de ocho dígitos.
El segundo error es convertir una señal estadística en un bloqueo automático. Si todas las tarjetas de un país, banco o producto quedan rechazadas sin revisión, puede dañar conversión, soporte y reputación con clientes legítimos.
El tercer error es romper la higiene PCI por comodidad. Pedir capturas del anverso de la tarjeta, guardar PAN completo o compartirlo por mensajería crea más riesgo que el problema que se intenta resolver.
Cómo enlazarlo con procesos internos
Incluya esta guía en runbooks junto con /es/bin-checker y artículos hermanos como /es/articles/3ds-sca-bin-checker y /es/articles/checkout-ecommerce-bin. Así cada analista sabe qué mirar primero y qué límites comunicar al cliente.
Para producto, defina qué decisiones pueden usar BIN de forma automática y cuáles requieren revisión humana. Por ejemplo, mostrar métodos alternativos puede ser automático; cancelar una cuenta por mismatch de país debería requerir más evidencia.
Para ingeniería, versionar reglas y respuestas de enriquecimiento ayuda a explicar cambios históricos. Si una tabla de BIN cambia, un reporte antiguo debe indicar con qué fuente y fecha se tomó la decisión.
Preguntas frecuentes
- ¿Puedo introducir el número completo de tarjeta?
No. Use solo los primeros seis u ocho dígitos. DN01 BIN Checker está diseñado para trabajar con prefijos y reducir exposición PCI; no necesita PAN completo para estas comprobaciones.
- ¿El resultado confirma que la tarjeta está activa?
No. Un BIN/IIN lookup no autoriza pagos, no consulta saldo y no confirma existencia de una tarjeta concreta. Solo aporta metadata del rango emisor cuando está disponible.
- ¿Qué hago si el BIN no aparece?
Pruebe con ocho dígitos si los tiene de forma segura, revise los campos del PSP y documente la incertidumbre. BIN no encontrado no significa automáticamente fraude.
- ¿Puedo automatizar este flujo?
Sí, para casos permitidos puede usar la API de DN01 con prefijos truncados. Registre acceso en /es/api-register-access y evite enviar datos de tarjeta completos.