Comercio electrónico: El número de tarjeta bancaria

2

Como gestores de TI es más que probable que nos encontremos en la situación de tener que implementar de alguna u otra manera un sistema de pago electrónico. Yo ya me he tenido que enfrentar a este reto en varias ocasiones y me he encontrado que hay mucho conocimiento que es importante aprender y que no hay tanta literatura disponible, y menos en castellano. Así que empiezo una serie de artículos explicándoos todo lo que he aprendido estos años.

DISCLAIMER: Aunque voy a intentar ser todo lo preciso que pueda, no puedo garantizar que lo que indico sea 100% correcto. Por lo que, aunque esta explicación pueda ser de utilidad para iniciarte, no debe ser tu única fuente de verdad y en caso de duda deberías consultar con un experto.

Pasado el disclaimer, vamos con el tema de hoy, ¿Qué es el número de tarjeta bancaria? ¿De qué está formado? ¿Cómo nos puede ayudar?

El número de tarjeta bancaria

Es el número que tienen las tarjetas de débito, crédito o de otros tarjetas similares que tienen impreso en grande en su parte frontal.

Lo más habitual es que sea un número de 16 cifras. De hecho en España casi todas son de 16 dígitos. Pero nos podemos encontrar tarjetas con menos dígitos o con más. El rango va desde las 8 cifras (aunque yo nunca he visto menos de 12) hasta las 19. Así que si en un campo esperamos guardar una tarjeta de crédito, no podemos limitarnos a 16 dígitos. Incluso yo no lo limitaría a 19, ya que el estándar que rige estos números esta vivo, y nadie te asegura que no vaya a ampliarse. Veo muchas veces que para el número de tarjeta en algunos formularios se pone un campo que espera cuatro grupos de cuatro dígitos, teniendo en total 16. Esta es la estructura normal que vemos en las VISA o en las Master Card. Pero si lo hacemos nos estamos cerrando a otros tipos, como el siguiente ejemplo:

https://www.flickr.com/photos/fonalite/2780198933

En este ejemplo podemos ver como American Express (AMEX para los amigos) usa 15 números agrupados en 4, 6 y 5 dígitos. Así que si alguien intenta usar AMEX y le ponemos 4 grupos de 4 dígitos, afectaremos gravemente al pago, o lo haremos imposible.

De hecho las agrupaciones de números no significan nada. Al final un número de tarjeta bancaria es una secuencia de números, sin agrupaciones. Las agrupaciones las crea cada entidad a su gusto y su criterio.

Dependiendo del documento que trabajemos, este número recibe muchos nombres:

  • Número de tarjeta, Card Number.
  • Número de tarjeta bancaria, Bank Card Number.
  • Número de tarjeta de pago, Payment Card Number.
  • Número de cuenta primario, Primary Account Number.

Pero el que quizás es más común entre los técnicos es usar “PAN”, que son las siglas de Primary Account Number. En casi todos los documentos de especificaciones técnicas para una integración se refieren a este número como el PAN. Así que a partir de ahora, hablaremos del PAN.

Otros conceptos que no son un PAN y pueden aparecer en documentos de integraciones son los siguientes. Os los incluyo para dejaros claro que no tienen nada que ver con el PAN:

  • Código identificador de Comercio.
  • Cuenta Bancaria
  • Código internacional de cuenta bancaria
  • Código SWIFT
  • Código de identificación de pagos universales

Todos los anteriores se refieren de una u otra manera a cuentas bancarias. En principio como técnicos, no deberíamos enfrentarnos a tratar con cuentas bancarias en el comercio electrónico, pero es posible que en los documentos aparezcan. Son algo diferente así que no confundirlos.

Como dato curioso, aunque no os servirá de mucho, deciros que los PAN se rigen por la ISO/IEC 7812. Así que si queréis tener todos los detalles, a leeros la norma. Aunque creo que no hace falta tanto.

Estructura del PAN

Sea la entidad que sea el PAN sigue siempre la misma estructura:

  • 6 u 8 dígitos del IIN, también conocido como BIN.
  • Hasta 12 dígitos de número de cuenta
  • 1 dígito opcional de control

Aunque la suma máxima de dígitos pueda ser 21 (8 de IIN, 12 de cuenta y 1 de control) la norma indica que en ningún caso superarán los 19.

Vamos a ver estas tres partes.

IIN o BIN

Los primeros dígitos del PAN se corresponden al IIN, que son las siglas de Issuer Identification Number o número de identificación del emisor. Como la inmensa mayoría de las veces el emisor es un banco, lo más habitual es hablar de BIN (Bank Identification Number). De hecho es mucho más común hablar de BIN que de IIN. Así que por no perder la costumbre le seguiré llamando BIN.

Los distintos emisores de tarjetas (como AMEX, VISA o Master Card) disponen de rangos de BIN’s. Así por ejemplo es común escuchar que todas las que empiezan por 4 son VISA. las que empiezan por 34 o 37 son AMEX. Pero nadie nos garantiza que en el futuro no se asignen BIN’s que empiecen por cuatro a otras entidades. Por ejemplo, las 55 están asignadas a Master Card, pero hay tarjetas Diners Club que empiezan por 55. Por lo tanto mi consejo es no pasarse de listo si no estamos muy seguros.

Un BIN completo normalmente no sólo identifica el tipo de tarjeta (Como VISA Electron) sino que también identifica al banco emisor. Así una tarjeta que comience por 400115, es decir, que su BIN es 400115, podemos asegurar que es una Visa Electron de Barclays.

Hasta hace poco el BIN siempre era de 6 dígitos. Pero debido a que se estaban agotando algunos rangos, en 2017 se revisó el estándar y ahora se están asignando BIN’s de 8 dígitos, siendo el objetivo de que finalmente todos los BIN’s sean de 8 dígitos. Pero esto en el momento de escribir estas líneas es puramente anecdótico. Ahora mismo los BIN’s son de 6 dígitos, y ya veremos como va cambiando.

Como dato curioso decir que el primer número del BIN es el MII (Major Industry Issuer). Indica el sector del emisor de la tarjeta. Así, una tarjeta que comience por 1 sabemos que el emisor es de una aerolínea. Pero como he dicho, esto es sólo un dato curioso.

Saber que los primeros números son el BIN es super potente, porque significa que podemos obtener mucha información de la tarjeta. Existen bases de datos de BIN’s en el mercado y servicios web que dando un BIN nos entregan mucha información sobre el emisor. Es habitual poder obtener el siguiente tipo de información del BIN:

  • Marca de tarjeta (VISA, AMEX, …)
  • Tipo (Débito, crédito, …)
  • Nivel (Normal, Oro, Corporativa, …)
  • Banco emisor y otros datos del banco como dirección, teléfono o web.
  • Nacionalidad

Esto es muy interesante y se puede utilizar en algunos casos. Por ejemplo, si nuestro comercio electrónico sólo sirve a nivel nacional, podemos prohibir el uso de tarjetas que no sean de nuestro país, sólo consultando el BIN. O si le pedimos la nacionalidad al cliente, podemos comprobar que coincida con el emisor de la tarjeta, ya que si no puede oler a fraude. O en otros casos sólo dejaremos actuar con tarjetas de crédito o de determinadas marcas.

Y en algunos sectores es útil para el personal de negocio tener esta información, para poder contactar con el banco en caso de problemas.

Número de cuenta

Identifica de forma unívoca a la tarjeta. Poco más se puede decir. Simplemente que lo que no sea BIN y dígito de control, es número de cuenta.

Dígito de control

El último dígito es de control, y se calcula a partir del resto. Según la literatura que consulte hay quien dice que hay emisores que no lo implementan y otros que dicen que siempre se implementa. Mi experiencia es que en todos los casos que he visto se implementaba, por lo que recomiendo hacer un control de validación del campo en base a este dígito de control.

Este dígito se calcula mediante el algoritmo de Luhn, que es muy simple y si buscáis por Internet, seguro que encontraréis implementaciones en cualquier lenguaje.

Validar que los PAN cumplan la validación de este dígito de control os permitirá detectar los errores del usuario al introducir el número, ya que el algoritmo está diseñado para detectar los errores más comunes al copiarlo manualmente como por ejemplo:

  • Sustituir un número por otro.
  • Intercambiar dos números consecutivos.
  • Obviar un número.
  • Poner un número de más,

Pero no es una protección contra ataques malintencionados. Es muy fácil generar un número que cumpla el algoritmo, por lo que no es una medida de seguridad anti-fraude.

¿Podemos grabar, manipular o procesar un PAN?

A priori te diría que por norma general no puede procesar un PAN, aunque luego no lo grabes. Aunque lo reservo para un artículo futuro, para poder procesar tarjetas de pago, hay que cumplir una normativa, el PCI DSS. A la hora de permitir que tus sistemas capturen o procesen un PAN, disponen de una serie de medidas de seguridad que hay que cumplir. Y no son pocas. Por lo que a menos que vayas a construir un sistema que proceses muchísimos pagos, no te marees y confía en un tercero para cumplir esta parte.

Lo que si permite PCI libremente es poder tener un PAN asteriscado. Esto es un PAN en el que muchos de sus números se sustituyen por asteriscos. PCI nos permite dejar sin asteriscar hasta los 6 primeros números (el BIN) y hasta los 4 últimos. Por ejemplo, para la tarjeta 1234 5678 9012 3456, al asteriscarla queda en 1234 56** **** 3456. Esto quiere decir que si confiamos en un tercero para que nos proporcione la tecnología de pago electrónico y éste nos entrega después un PAN asteriscado según este criterio, podemos guardarlo sin tener que vigilar medidas especiales de seguridad.

Un PAN asteriscado nos sirve para dos motivos:

  • Es muy útil para comprobar si una tarjeta que nos enseñan posteriormente es la misma que nos han dado. Es muy poco probable que una persona tenga acceso a dos tarjetas que coincidan con el asteriscado, además de otros datos de tarjeta.
  • Nos puede dar acceso al BIN, y de ahí saber el tipo de tarjeta, banco, etc.

Lo que no tengo ni idea es qué pasará con los BIN’s de 8 dígitos. ¿Dejará PCI dejar 8 dígitos sin asteriscar para poder tener el BIN completo? No lo sé.

Por otro lado, sobretodo si trabajamos con un tercero, es común el uso de tokens. ¿Qué es un token? Imaginemos que queremos permitir a nuestro cliente que almacene su tarjeta de crédito en nuestro sistema, para luego poder hacer compras sin necesidad de volver a introducirla, como por ejemplo hace Amazon. En estos casos, nuestro proveedor del servicio para pagos electrónicos nos puede permitir el uso de tokens. Así cuando el cliente pone la tarjeta, nuestro proveedor la guarda en un entorno super-seguro que cumple todos los requisitos de PCI y nos manda un identificador al que llama token. Con ese token nosotros podremos dar órdenes a nuestro proveedor, como por ejemplo, hazle otro cargo a esa tarjeta por ese otro importe o cosas similares. Con el token tenemos las mismas ventajas de guardar el PAN, pero sin tener que guardarlo, y sin tener que cumplir todo el estándar PCI DSS.

Conclusiones

Bueno ya te he contando todo lo que sé que hay detrás de ese número que está en las tarjetas, el PAN. Ahora puedes ir a un servicio de BIN’s con una tarjeta tuya y ver como con sólo los 6 primeros números puedes sacar mucha información.

En futuras entregas veremos más conceptos, como los otros datos de tarjeta, los CVV, los tipos de integración para pago electrónico, el fraude y otras plataformas de pago que no se basan en tarjeta, como PayPal, cheques o e-Banking.

Espero que os gusten!

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable del equipo de operaciones TI.

2 comments

  1. Julio 10 septiembre, 2018 at 12:37 Responder

    Un artículo muy interesante. He aprendido mucho y me va a venir muy bien porque a corto plazo, vamos a empezar un proyecto que necesita pago electrónico.

    Por cierto, la siguiente frase no me queda muy clara, aunque luego en el desarrollo del resto del punto, se termina de entender:
    “A priori te diría que por norma general no puede procesar un PAN, aunque luego no lo grabes”
    El contesto de procesar no me quedaba claro y luego creo que en lugar de “puede” sería “puedes”, no?

    Muchas gracias y me quedo esperando con ganas la segunda parte!

Post a new comment