Cómo funcionan los pagos con tarjeta: modelo de cuatro partes, autorización y PCI DSS

Pagar acercando una tarjeta es una de las pocas experiencias de consumo que esconden toda una industria detrás de un segundo de latencia. En ese segundo, una petición viaja desde un terminal hasta un banco adquirente, cruza la red de una marca de tarjetas, llega al sistema de autorización de un banco emisor y vuelve con un código de aprobación. Después, durante los días siguientes, un conjunto de ficheros completamente distinto mueve el dinero, aplica las comisiones y, de vez en cuando, lo revierte todo.

Los ingenieros suelen ver solo una parte de todo esto —un formulario de pago o el SDK de un terminal— y heredan un vocabulario que parece arbitrario hasta que se ve el cuadro completo. Esta guía te lo ofrece. Da por conocidos los conceptos de libro mayor y liquidación que explican los fundamentos de los sistemas de pago; la tarjeta es solo un instrumento que se apoya en ellos.

El modelo de cuatro partes

La transacción clásica con tarjeta implica a cuatro instituciones y una asimetría muy útil.

• El titular tiene una tarjeta emitida a su nombre.
• El emisor es el banco del titular. Es dueño de la cuenta, decide si aprueba una transacción y asume la mayor parte de las pérdidas por fraude en las transacciones autenticadas.
• El comercio vende algo y quiere cobrarlo.
• El adquirente es el banco del comercio. Lo da de alta, recibe sus transacciones y le paga descontando las comisiones.
• La marca —la red de tarjetas— se sitúa entre emisor y adquirente y aporta la red de conmutación, el reglamento, el arbitraje de disputas y el cálculo de la liquidación. No es parte de la venta.

La asimetría consiste en que el titular y el comercio no tienen ninguna relación con el banco del otro y, aun así, la transacción funciona porque ambos bancos siguen el mismo reglamento. Es ese reglamento, y no un contrato bilateral, lo que permite usar una tarjeta en un país que nunca has visitado.

Un modelo de tres partes reúne emisor, adquirente y marca en una sola empresa con relación directa tanto con el titular como con el comercio. Eso le da un control más estricto sobre precios y aceptación, a cambio de una red de comercios que crece mucho más despacio. En la práctica, las grandes marcas combinan hoy ambos modelos.

Entre el comercio y el adquirente, la mayoría de las empresas modernas intercalan un proveedor de servicios de pago (PSP) o pasarela, que aporta las API, el checkout alojado, los tokens y a menudo el motor de riesgo. Algunos proveedores tienen además su propia licencia de adquirencia.

La tarjeta, el número y el chip

El número de cuenta principal (PAN) suele tener 16 dígitos, aunque el estándar permite hasta 19. Los primeros dígitos forman el issuer identification number (históricamente el BIN), que identifica la entidad emisora, la marca y el tipo de producto, y es la base de las decisiones de enrutamiento y aceptación antes de cualquier llamada a la red. El último dígito es un dígito de control calculado con el algoritmo de Luhn.

Validate 4111 1111 1111 1111

Starting from the rightmost digit, double every second digit
(the check digit itself is never doubled). If a doubled value
exceeds 9, subtract 9.

  digits   4  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
  double   x     x     x     x     x     x     x     x
  becomes  8  1  2  1  2  1  2  1  2  1  2  1  2  1  2  1

  sum = 8 + (7 x 2) + (8 x 1) = 8 + 14 + 8 = 30
  30 mod 10 == 0  ->  the number is internally consistent

Para generar un dígito de control en lugar de verificarlo, aplica la misma ponderación al número con un cero en la última posición y calcula (10 - sum mod 10) mod 10.

function luhnValid(pan) {
  let sum = 0;
  for (let i = 0; i < pan.length; i++) {
    let d = pan.charCodeAt(pan.length - 1 - i) - 48;
    if (d < 0 || d > 9) return false;
    if (i % 2 === 1) { d *= 2; if (d > 9) d -= 9; }
    sum += d;
  }
  return pan.length >= 12 && sum % 10 === 0;
}

Físicamente, la tarjeta ha recorrido un largo camino desde la banda magnética, que guardaba una copia estática de los datos y, por tanto, podía clonarla cualquiera que la leyera una sola vez. Las tarjetas con chip EMV la sustituyen por un pequeño ordenador que firma un criptograma sobre los datos de la transacción con una clave que nunca sale del chip, de modo que una comunicación interceptada no se puede reproducir. El contactless es la misma criptografía sobre una interfaz de radio, con límites offline y peticiones periódicas de PIN para acotar el riesgo de una tarjeta perdida.

En un wallet del móvil o del reloj, la tarjeta está tokenizada por la red: el wallet no guarda el número real, sino un token PAN específico del dispositivo, emitido por el servicio de tokens de la marca, con su propio criptograma en cada transacción. Si el token se filtra, no sirve en otro dispositivo, y no hace falta reemitir la tarjeta subyacente. La tokenización de tarjetas guardadas (card-on-file) aplica la misma idea a las suscripciones, con un efecto secundario agradable: las actualizaciones de la fecha de caducidad se propagan sin que el cliente tenga que hacer nada.

Los tres o cuatro dígitos impresos en la tarjeta (el código de seguridad) existen únicamente para demostrar que se tiene la tarjeta en las transacciones a distancia. Guardarlos después de la autorización está terminantemente prohibido: no hay ninguna configuración conforme en la que puedas conservarlos.

Autorización, captura, compensación y liquidación

Cuatro palabras que los principiantes usan como sinónimos y que significan cuatro cosas distintas.

La autorización pide al emisor, en tiempo real, que compruebe la cuenta y retenga el importe. La respuesta es un código de aprobación o un motivo de denegación. No se mueve dinero; la retención reduce el saldo disponible del titular y caduca tras un plazo definido por la marca si no se utiliza.

La captura (o finalización) comunica al adquirente que la mercancía se ha enviado y que el comercio reclama ya el importe. Muchas empresas autorizan en el checkout y capturan al despachar el pedido; los hoteles y los surtidores de combustible autorizan una estimación y capturan un importe final distinto, dentro de ciertos límites.

La compensación (clearing) es el intercambio, a través de la marca, de los registros de transacciones capturadas entre adquirente y emisor, normalmente en lotes diarios, aplicando por el camino la tasa de intercambio y las comisiones de la marca.

La liquidación (settlement) es el movimiento real de fondos entre los bancos, neteado por la marca, seguido del pago del adquirente al comercio según su propio calendario.

Day 0  10:32  Authorization request  (terminal -> acquirer -> scheme -> issuer)
       10:32  Approval, funds reserved on the cardholder account
Day 1  09:00  Capture / presentment batch sent by the acquirer
Day 1  22:00  Clearing: scheme computes net positions, applies fees
Day 2  08:00  Interbank settlement
Day 3        Merchant credited, net of the merchant service charge
Day 40       Cardholder disputes -> chargeback -> possible representment

Las comisiones fluyen en sentido contrario al dinero. El comercio paga a su adquirente una tasa de descuento, de la que el adquirente paga la tasa de intercambio al emisor y una comisión a la marca. La tasa de intercambio es lo que permite a los emisores ofrecer tarjetas gratuitas y programas de recompensas, y también la razón por la que los reguladores de varias regiones la han limitado en las tarjetas de consumo. Toma aquí la mecánica como algo conceptual: las tarifas cambian y dependen de cada jurisdicción.

Los contracargos (chargebacks) son el mecanismo de disputa. Un titular reclama a su emisor, el emisor recupera los fondos del adquirente con un código de motivo (fraude, falta de entrega, importe incorrecto, cargo duplicado) y el comercio puede responder aportando pruebas en una representación. Las marcas vigilan los ratios de contracargos, y un ratio alto de forma persistente le cuesta al comercio la posibilidad de aceptar tarjetas. En la práctica, esto significa que tus sistemas deben poder presentar, meses después, la prueba de lo que se pidió, autenticó, envió y entregó: un buen argumento para mantener registros inmutables de pedidos y autenticaciones.

Autenticación: 3-D Secure y SCA

Las transacciones a distancia no tienen un chip que demuestre que la tarjeta está presente, así que las marcas crearon 3-D Secure: un paso de autenticación entre el comercio, el servidor de directorio (directory server) de la marca y el servidor de control de acceso (ACS) del emisor. La primera generación era la famosa ventana emergente con contraseña. La generación actual se basa en el riesgo: el comercio envía un conjunto amplio de datos del dispositivo, de la transacción y de comportamiento, y el emisor decide entre una aprobación frictionless y un challenge (normalmente una notificación push en la app del banco).

Según la normativa europea, la autenticación reforzada de clientes (SCA) exige dos factores independientes de entre conocimiento, posesión e inherencia en la mayoría de los pagos electrónicos, con exenciones definidas: transacciones de bajo importe, pagos recurrentes de importe fijo a partir del primero, comercios que el titular ha incluido en su lista de confianza y análisis de riesgo de la transacción por debajo de un umbral de tasa de fraude. El contexto regulatorio es el mismo que se describe en PSD2 y open banking.

De ahí se derivan dos consecuencias de ingeniería. La primera: la autenticación es asíncrona y puede redirigir o abrir una app, así que tu checkout tiene que poder reanudarse; un cliente que se autentica en el móvil y vuelve dos minutos después no debe perder la cesta. La segunda: una autenticación correcta suele trasladar la responsabilidad por fraude al emisor, de modo que el motivo para lanzar un challenge no es solo el cumplimiento normativo, sino que cambia quién paga si la transacción resulta fraudulenta.

{
  "amount": { "currency": "EUR", "value": 4990 },
  "paymentMethod": { "type": "scheme", "token": "tok_9f3c1a7b" },
  "authentication": {
    "threeDSRequestorChallengeIndicator": "no-preference",
    "exemption": "transaction-risk-analysis"
  },
  "merchantOrderReference": "ORD-2026-114522",
  "shopperInteraction": "Ecommerce"
}

PCI DSS y cómo mantener un alcance pequeño

El Payment Card Industry Data Security Standard se aplica a cualquier organización que almacene, procese o transmita datos de titulares de tarjeta. Sus requisitos abarcan la segmentación de red, el cifrado en tránsito y en reposo, el control de acceso, el registro de eventos, la gestión de vulnerabilidades y las pruebas periódicas; el esfuerzo de validación va desde un breve cuestionario de autoevaluación hasta una auditoría presencial, según el volumen y el tipo de integración.

La decisión de arquitectura más valiosa, con diferencia, es quedarte completamente fuera del entorno de datos del titular. De la menos a la más gravosa:

1. Redirección o página de pago alojada. El cliente introduce la tarjeta en la página del proveedor. Tus servidores nunca ven un PAN.
2. Campos alojados / iframe. El proveedor renderiza los campos de la tarjeta dentro de tu checkout, así que el aspecto es tuyo y los datos son suyos. Suele ser el punto óptimo.
3. Cifrado en el cliente o API directa al proveedor. El navegador cifra los datos de la tarjeta o los envía directamente al proveedor; tu backend solo recibe un token.
4. Recogida en el servidor. Tu aplicación recibe PAN en claro. Alcance de auditoría completo, pruebas de penetración, segmentación, gestión de claves: solo compensa si hay una razón de peso.

Elijas lo que elijas, las defensas habituales siguen aplicando: nunca registres en logs un PAN ni un código de seguridad (fíltralo en el framework de logging, no en cada punto de llamada), enmascara dejando los seis primeros y los cuatro últimos dígitos cuando de verdad haga falta mostrarlo, guarda tokens en lugar de números en tu base de datos y trata la página de pago como crítica para la seguridad, porque un script inyectado ahí anula cualquier iframe. Las guías de OWASP Top 10 y arquitectura de seguridad de aplicaciones cubren la higiene que la rodea.

Integración con un proveedor

Una checklist de integración práctica, aprendida por las malas por muchos equipos:

• Idempotencia en todas las llamadas que modifican estado. Una captura reintentada no debe capturar dos veces; envía una clave estable derivada de tu identificador de pedido.
• La fuente de verdad son los webhooks, no la respuesta HTTP. Los resultados de autorización, los contracargos y las notificaciones de liquidación llegan de forma asíncrona, a veces desordenados y más de una vez. Verifica las firmas, deduplica por el id del evento y haz que los handlers sean idempotentes.
• Guarda las referencias del proveedor —código de autorización, id de transacción, token, referencia de la marca— junto a tu pedido. Cada conversación con soporte y cada disputa las necesitará.
• Concilia a diario el informe de liquidación con tus propios registros, cruzando por la referencia del proveedor, y genera alertas sobre las partidas sin casar en ambas direcciones.
• Modela explícitamente las capturas parciales, los reembolsos parciales y las caducidades. No son casos límite: son el día a día.
• Prueba las denegaciones, no solo las aprobaciones. Los proveedores publican tarjetas de prueba para fondos insuficientes, tarjetas caducadas, «do not honour», challenge de 3-D Secure y timeouts. Un checkout que solo gestiona el éxito está a medio escribir.
• Nunca construyas tu propio bucle de reintentos sobre una denegación. Las marcas penalizan los intentos repetidos sobre una tarjeta denegada, y así es como un comercio acaba en un programa de supervisión.

Diseña la frontera de la API de forma que el proveedor sea sustituible: una pequeña abstracción de pagos interna, con tu propio vocabulario de estados y traducida en el borde, te ahorra reescribirlo todo cuando cambian las condiciones comerciales. Los principios generales del diseño de API REST se aplican directamente.

Ideas clave

• Cuatro instituciones —emisor, adquirente, marca y comercio, normalmente con un PSP de por medio— cooperan bajo el reglamento de una marca que ni el titular ni el comercio firman.
• El PAN codifica el emisor en sus primeros dígitos y termina en un dígito de control de Luhn que detecta errores de tecleo y nada más.
• Los criptogramas EMV y los tokens de red sustituyen datos de tarjeta estáticos y clonables por una prueba propia de cada transacción; por eso los wallets son más seguros que los números que hay detrás.
• La autorización retiene, la captura reclama, la compensación intercambia registros y la liquidación mueve el dinero, con días de diferencia y disputas que pueden llegar meses después.
• 3-D Secure y la autenticación reforzada añaden fricción, pero trasladan la responsabilidad por fraude; construye un checkout que pueda interrumpirse y reanudarse.
• Elige una integración que mantenga los datos de tarjeta fuera de tus servidores: el alcance de PCI DSS lo decide la arquitectura mucho antes que el papeleo.