DEV Community

Cover image for Visa y Mastercard no son bancos: qué hacen las redes de tarjetas
lu1tr0n
lu1tr0n

Posted on Originally published at elsolitario.org

Visa y Mastercard no son bancos: qué hacen las redes de tarjetas

Cuando pagás con tarjeta en Costco en Estados Unidos, notás algo raro: ese local no acepta Mastercard, solo Visa. Ese detalle cotidiano esconde una arquitectura de cuatro actores que define cómo se mueve casi todo el dinero digital del planeta, y que la mayoría de los desarrolladores que integran pagos jamás terminan de entender del todo.

Visa y Mastercard no emiten tarjetas, no son bancos y no procesan tu compra directamente. Son redes de tarjetas: intermediarios técnicos y financieros que conectan a quien te presta el dinero con quien le cobra al comercio. Entender esa distinción cambia cómo diseñás una integración de pagos, por qué un cobro tarda en liquidarse y por qué ciertas comisiones no dependen de tu proveedor de pagos sino de la red misma.

TL;DR

  • Visa y Mastercard no emiten tarjetas ni son bancos: son redes que conectan emisores y adquirentes.- El BIN (los primeros 6 a 8 dígitos del PAN) identifica al banco emisor, como una IP identifica un host.- Cada transacción pasa por autorización, clearing y settlement: tres pasos distintos, no uno solo.- Visa usa settlement neto diario: suma débitos y créditos de cada participante y mueve el saldo una sola vez.- Mastercard llama switching al enrutamiento de mensajes entre emisor y adquirente.- El data center insignia de Visa, Operations Center East, tiene 140.000 pies cuadrados y resiste vientos de 170 mph.- El modelo es de cuatro partes: tarjetahabiente, emisor, comercio y adquirente.

Qué son las redes de tarjetas

La confusión es comprensible: para el usuario final, la tarjeta, el banco y la red se sienten como una sola cosa. Pero un artículo reciente sobre redes de tarjetas repasa, con la experiencia de alguien que trabajó años en la industria de pagos, qué hace realmente Visa (y por extensión Mastercard, que opera de forma casi idéntica con otros nombres).

Primero, lo que NO hacen. No son card issuers: no emiten la tarjeta que tenés en la billetera, eso lo hace un banco (Chase, BBVA, Banorte, Bancolombia). No son bancos, aunque casi todas tus tarjetas están emitidas por uno. No distribuyen terminales de punto de venta ni checkouts online, tarea de los payment processors como Stripe, Adyen o dLocal en la región. No hacen merchant acquiring, es decir, no dan de alta ni evalúan el riesgo de un comercio: eso lo hacen bancos con cuentas de comercio o, cada vez más, los mismos procesadores modernos. Tampoco fabrican tarjetas físicas ni terminales POS.

Lo que sí hacen es operar una red que conecta a cuatro participantes: el tarjetahabiente, el banco emisor, el comercio y el banco adquirente. Ese modelo de cuatro partes tiene cuatro responsabilidades centrales: correr la red de telecomunicaciones que enruta los mensajes de transacción, coordinar la red bancaria que mueve y liquida el dinero, fijar incentivos para que bancos y comercios usen la red, y establecer y hacer cumplir reglas, incluyendo un mecanismo de disputas (los chargebacks). Ese modelo de cuatro partes es, en esencia, la definición operativa de las redes de tarjetas modernas.

Contexto e historia de las redes de tarjetas

Este modelo no nació de un diseño técnico moderno: es la evolución de un negocio bancario de mediados del siglo pasado. Visa surgió del programa BankAmericard que Bank of America lanzó en California en 1958 y que se independizó como red compartida entre bancos en 1970, adoptando el nombre Visa en 1976 para operar globalmente sin depender de un solo banco emisor. Mastercard tiene un origen paralelo: nació como Master Charge, una alianza de bancos competidores de BankAmericard, y pasó a llamarse Mastercard a fines de los años setenta.

La razón de ese diseño es económica antes que técnica: ningún banco individual podía convencer a comercios de todo el país, y después del mundo, de aceptar su tarjeta propia. La solución fue crear una red compartida y neutral entre bancos emisores, que cualquier banco pudiera sumar y que cualquier comercio pudiera aceptar sin negociar con cada emisor por separado. Ese es, en esencia, el mismo problema que hoy resuelven redes de pagos instantáneos como Pix en Brasil o SPEI en México, aunque con arquitecturas de liquidación distintas.

Detalles técnicos: cómo operan las redes de tarjetas

Una transacción con tarjeta no es un solo evento: son al menos tres pasos separados en el tiempo, y confundirlos es un error común entre desarrolladores nuevos en pagos.
EtapaQué pasaQuién participaCuándo ocurreAutorizaciónSe verifica que la cuenta existe y tiene fondos o línea disponible; se coloca un hold temporalComercio, adquirente, red, emisorEn el momento del pago, en milisegundosClearingEl comercio envía el monto final (puede variar por propina o ajustes) para iniciar la transferenciaComercio, adquirente, red, emisorHoras después de la autorización, por lotesSettlementSe mueve el dinero real entre bancos, casi siempre neteando débitos y créditos del díaRed, bancos emisores y adquirentesAl cierre del ciclo diario de la red
El número de tarjeta (PAN, Primary Account Number) funciona de forma parecida a una dirección IP: los primeros 6 a 8 dígitos son el BIN (Bank Identification Number) e identifican al banco emisor. Cuando un mensaje de autorización llega a la red, esos dígitos le dicen hacia qué banco reenviarlo, igual que un router mira los primeros bits de una IP para decidir la siguiente ruta.
El PAN completo nunca debería viajar ni guardarse sin cifrar en tus sistemas.
Mastercard llama a esta tarea de enrutamiento switching: la red actúa literalmente como un switch de telecomunicaciones entre el adquirente y el emisor. Así se ve el flujo completo de una autorización dentro de las redes de tarjetas:

sequenceDiagram
    participant CH as Tarjetahabiente
    participant M as Comercio
    participant A as Adquirente
    participant N as Red de tarjetas
    participant I as Emisor
    CH->>M: presenta la tarjeta
    M->>A: solicita autorización
    A->>N: enruta el mensaje
    N->>I: reenvía la solicitud
    I-->>N: aprueba o rechaza
    N-->>A: reenvía la respuesta
    A-->>M: confirma la autorización
    Note over M,I: el clearing y el settlement llegan horas o días después
Enter fullscreen mode Exit fullscreen mode

La infraestructura detrás de ese enrutamiento no es un detalle menor. El data center insignia de Visa, conocido como Operations Center East, ocupa 140.000 pies cuadrados, está diseñado para resistir terremotos y vientos de hasta 170 millas por hora, y su acceso físico incluye bolardos hidráulicos capaces de detener un vehículo que circule a 50 millas por hora. Esa obsesión por la resiliencia tiene sentido: si esa red cae, no procesa un sitio web, procesa una fracción significativa del comercio físico y digital del planeta.

💭 Clave: la red neta a cada participante una sola vez al día. En lugar de mover dinero por cada transacción individual, Visa suma todos los débitos y créditos de cada banco y transfiere solo el saldo neto, lo que reduce drásticamente el número de movimientos bancarios reales.

Cómo empezar a integrar con las redes de tarjetas

Si trabajás integrando pagos en LATAM, no vas a hablar directo con Visa o Mastercard: vas a integrar un procesador (Stripe, Adyen, dLocal, Mercado Pago) que ya resuelve la conexión con las redes de tarjetas y con los bancos adquirentes. Pero entender el BIN y el algoritmo de Luhn te sirve todos los días para validar tarjetas en el frontend antes de gastar una llamada real a la red.

Primero, instalá Node.js si no lo tenés, necesario para correr los ejemplos siguientes:

# macOS (con Homebrew)
brew install node

# Linux (Debian/Ubuntu)
curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt install -y nodejs

# Windows (con winget)
winget install OpenJS.NodeJS.LTS
Enter fullscreen mode Exit fullscreen mode

Con Node instalado, este es el algoritmo de Luhn, el checksum que toda red de tarjetas usa para descartar números mal escritos antes de gastar una autorización real:

function esPanValido(pan) {
  const digitos = pan.replace(/\s+/g, '').split('').map(Number);
  let suma = 0;
  for (let i = digitos.length - 1, posicion = 0; i >= 0; i--, posicion++) {
    let d = digitos[i];
    if (posicion % 2 === 1) {
      d *= 2;
      if (d > 9) d -= 9;
    }
    suma += d;
  }
  return suma % 10 === 0;
}

console.log(esPanValido('4111111111111111')); // true: PAN de prueba de Visa
Enter fullscreen mode Exit fullscreen mode

Ese chequeo solo valida el formato, no si la cuenta existe o tiene fondos. Para identificar al emisor a partir del BIN, un ejemplo realista consultando una API pública de lookup:

async function identificarEmisor(pan) {
  const bin = pan.slice(0, 8);
  const respuesta = await fetch(`https://lookup.binlist.net/${bin}`, {
    headers: { 'Accept-Version': '3' }
  });
  if (!respuesta.ok) throw new Error('BIN no encontrado');
  const datos = await respuesta.json();
  return {
    marca: datos.scheme,       // "visa" o "mastercard"
    tipo: datos.type,          // "credit" o "debit"
    banco: datos.bank?.name,
    pais: datos.country?.name,
  };
}

identificarEmisor('411111111234').then(console.log);
// { marca: 'visa', tipo: 'credit', banco: '...', pais: '...' }
Enter fullscreen mode Exit fullscreen mode

⚠️ Ojo: nunca loguees, guardes ni envíes por tu propio backend el PAN completo en texto plano. Delegá esa parte a tu procesador (Stripe Elements, Adyen Web Components) para no entrar en el alcance completo de PCI DSS.

Para confirmar que tu integración distingue realmente entre autorización y clearing, revisá el dashboard de tu procesador: Stripe, por ejemplo, muestra el PaymentIntent en estado requires_capture justo después de la autorización, y recién pasa a succeeded cuando se ejecuta el capture, que dispara el clearing hacia la red.

Impacto y análisis para developers

Para un desarrollador que nunca trabajó del lado de un procesador, esta arquitectura de redes de tarjetas explica comportamientos que de otra forma parecen arbitrarios. Por qué Costco solo acepta Visa: negoció una tasa de interchange más baja a cambio de exclusividad, algo que solo tiene sentido si entendés que cada red fija sus propias tasas y que un comercio grande puede negociarlas. Por qué un cobro con tarjeta puede desaparecer del estado de cuenta por un día y reaparecer con otro monto: es la diferencia entre el hold de la autorización y el monto final del clearing.

También explica por qué migrar de procesador de pagos no es solo cambiar una API key. Cada procesador tiene su propia relación de merchant acquiring con los bancos, y la certificación PCI, las reglas de disputas y los tiempos de settlement dependen en parte de esa relación, no solo de tu código.
El settlement neto diario reduce los movimientos bancarios reales entre redes y bancos.
El límite real de este modelo es la latencia del clearing y el settlement: aunque la autorización es casi instantánea, el dinero real tarda horas o días en moverse. Para un desarrollador de fintech eso importa: si tu producto promete dinero disponible al instante tras un cobro con tarjeta, en la práctica estás adelantando el capital tú mismo, o tu procesador lo hace, no la red.

Qué sigue para las redes de tarjetas

Las redes de cuatro partes ya no tienen el monopolio que tenían hace veinte años. Sistemas de pagos instantáneos como Pix en Brasil o SPEI en México mueven dinero entre cuentas bancarias sin pasar por una red de tarjetas, con settlement en segundos en lugar de días. En Europa, alianzas bancarias locales avanzan en la misma dirección para reducir la dependencia de Visa y Mastercard en pagos domésticos.

La respuesta de las redes ha sido invertir en tokenización (reemplazar el PAN real por un token específico de cada dispositivo o comercio, como hace Apple Pay) y en abrir APIs propias para casos de uso más allá del pago con tarjeta física. Para quien construye pagos en LATAM, la lectura práctica es que el modelo de cuatro partes sigue siendo el default para e-commerce, pero ya no es la única opción para mover dinero entre cuentas.

📖 Resumen en Telegram: Ver resumen

Probalo vos: corré el snippet de Luhn de arriba contra el PAN de prueba 4111111111111111 y confirmá en segundos por qué esa validación evita gastar una llamada real a la red.

Preguntas frecuentes

¿Visa o Mastercard emiten tarjetas de crédito?

No. Las tarjetas las emite un banco (el issuer); Visa y Mastercard solo operan las redes de tarjetas que conectan a ese banco con el comercio.

¿Qué es un BIN y para qué sirve?

Es el Bank Identification Number: los primeros 6 a 8 dígitos del PAN, que identifican al banco emisor y permiten enrutar la transacción hacia el banco correcto.

¿Por qué algunos comercios solo aceptan una red?

Porque cada red cobra sus propias tasas de interchange y un comercio con volumen alto puede negociar condiciones exclusivas con una sola red, como hace Costco con Visa en Estados Unidos.

¿Cuál es la diferencia entre autorización, clearing y settlement?

La autorización verifica fondos y coloca un hold en milisegundos; el clearing confirma el monto final horas después; el settlement mueve el dinero real entre bancos, casi siempre neteado al final del día.

¿Necesito hablar directo con Visa o Mastercard para cobrar con tarjeta?

No. En la práctica, integrás un procesador de pagos (Stripe, Adyen, dLocal, Mercado Pago) que ya tiene la conexión certificada con las redes y con los bancos adquirentes.

¿Qué pasa si guardo el PAN completo en mi base de datos?

Entrás en el alcance completo de PCI DSS, con auditorías y requisitos de seguridad estrictos. La práctica recomendada es delegar la captura del PAN al procesador y guardar solo un token.

Referencias

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Top comments (0)