Técnico

ISO 8583

ISO 8583 — estándar de mensajes de tarjetas (adquirencia, autorización)

Estándar ISO publicado en 1987 que define el formato de los mensajes intercambiados entre los actores de tarjetas (terminal POS, PSP adquirente, scheme, emisor). Sigue siendo el estándar dominante de la autorización, la adquirencia y la liquidación de tarjetas. Visa, Mastercard, CB y Amex lo usan todos.

Definición

ISO 8583 es el estándar ISO (1987, revisado en 1993 y 2003) que define el formato de los mensajes intercambiados entre los actores del pago con tarjeta: terminal POS, PSP adquirente, switch de la red (Visa, Mastercard, CB) y banco emisor.

Es el estándar dominante de la autorización, la adquirencia y la liquidación de tarjetas. Formato binario basado en un MTI (Message Type Indicator, 4 dígitos: 0100 request, 0110 response…), un bitmap que indica los campos presentes y hasta 128 data elements. Diseñado en 1987, sigue siendo ineludible — Visa (BASE I/II), Mastercard (MIP/MDS), CB, Amex, JCB y UnionPay lo usan todos, con variantes propietarias.

Estructura de un mensaje

MTI            : 0100 (Authorization Request)
Bitmap         : 7234050108E18000... (indique champs présents)
DE2  PAN       : 4242424242424242
DE3  Proc Code : 000000 (purchase)
DE4  Amount    : 000000050000 (50.00 €)
DE7  Trans DT  : 0419103045 (avril 19, 10:30:45)
DE11 STAN      : 123456 (System Trace Audit Number)
DE22 POS Entry : 051 (chip + PIN)
DE32 Acquirer  : 12345678 (BIN PSP)
DE41 TID       : 00012345 (terminal)
DE42 MID       : 123456789012345 (merchant)
DE49 Currency  : 978 (EUR)
DE52 PIN Block : ... (encrypted)
DE55 EMV Data  : 9F26... (chip data)

Un mensaje pesa aproximadamente de 300 a 500 bytes, transmitido en menos de 200 ms.

El ciclo de vida de una transacción

Tres etapas: la autorización (online en menos de un segundo), el clearing (batch diario) y el settlement (liquidación neta entre emisor y adquirente vía red, en T+1 o T+2).

Variantes por red

Cada red deriva ISO 8583 en su propio formato: Visa (BASE I para la auth, BASE II para el clearing), Mastercard (MIP + MDS), CB (cercano a Visa), Amex (propietario), así como JCB, Discover y UnionPay. Un PSP adquirente multirred (Stripe, Adyen, Worldline) debe, por tanto, gestionar varios dialectos.

ISO 8583 vs ISO 20022

AspectoISO 8583 (1987)ISO 20022 (2004)
FormatoBitmap binarioXML / JSON
LegibilidadBajaBuena
RiquezaLimitadaMuy rica
Latencia< 200 msMás pesado (parsing XML)
DominioTarjetasTodo (pagos, valores, FX)
AdopciónUniversal (tarjetas)Universal (SEPA / SWIFT MX)

ISO 8583 resiste por cuatro razones: latencia ultrabaja (auth crítica en < 200 ms), compacidad (~300 bytes vs varios KB en XML), 40 años de legado en los sistemas core y un coste de migración estimado en miles de millones de dólares. Visa y Mastercard, no obstante, trabajan en una transición gradual (Visa Direct y Mastercard Send ya están en ISO 20022), con un clearing de tarjeta en ISO 20022 previsto después de 2030.

Actores

  • Redes: Visa, Mastercard, Amex, JCB, Discover, UnionPay, CB (FR).
  • Switches / procesadores: Worldline (FR), Nexi (IT), Fiserv, TSYS / Global Payments, FIS.
  • Herramientas: jPOS (la biblioteca Java open-source de referencia), OpenISO8583.Net, iso8583py y HSM Thales o Utimaco para los criptogramas.

Lo que ISO 8583 no es

  • No es un estándar universal de pago: es específico de las tarjetas; transferencias y adeudos directos corresponden a ISO 20022.
  • No es un protocolo de transporte: describe el formato de los mensajes, siendo el transporte TCP/IP (o X.25 históricamente).
  • No es necesario para los nuevos rails: FedNow, TIPS y SCT Inst están en ISO 20022.
  • No está cifrado por defecto: hacen falta capas adicionales (TLS, P2PE, HSM).
  • No está estrictamente estandarizado: cada red tiene su variante ("sabor" Visa, Mastercard, CB).

En el ecosistema PSD2 / Open Finance

ISO 8583 es invisible para los TPP de la PSD2 (que trabajan en API REST/JSON), pero omnipresente del lado de la tarjeta: los adquirentes (Stripe, Adyen) traducen sus API REST a ISO 8583, los emisores BaaS (Treezor, Swan, Solaris) traducen el ISO 8583 recibido a sus API de negocio, y parte de los desafíos 3DS transitan por él. Sigue siendo, por tanto, fundamental para entender el pago con tarjeta, incluso en la era del Open Banking.

Ejemplos concretos

  • Stripe: recibe una solicitud de pago, la traduce a ISO 8583 hacia Visa BASE I, recibe el 0110 de aprobación y confirma al comercio.
  • Treezor: recibe un 0100 del switch de tarjeta, comprueba saldo y scoring y devuelve un 0110 approve/decline.
  • Worldline: opera varios switches FR y UE que procesan más de 50 M de transacciones al día.
  • jPOS: biblioteca open-source usada por cientos de procesadores y fintech emisoras.
  • Migración ISO 20022: Visa Direct y Mastercard Send (push payments) ya migrados, pero el 0100/0110 histórico seguirá en 8583 hasta después de 2030.
  • Dos mundos: un desarrollador de fintech de crédito ve JSON/REST; un desarrollador de PSP adquirente ve bitmap 8583 en hexadecimal.

Fuentes

Profundizar

En el blog

Lecturas más completas para ir más allá de la definición.

7 de abril de 2026
técnico

Arquitectura técnica de una API DSP2: lo que hay que saber antes de escribir la primera línea de código — Leer el artículo

Panorama técnico de la DSP2 para CTO, desarrolladores y PM técnicos: estándares de API, seguridad (mTLS, certificados eIDAS), OAuth2, flujos SCA, gestión del consentimiento, trampas de implementación.

6 de abril de 2026
regulación

Entender la PSD2: lo que cambia para sus clientes y su negocio — Leer el artículo

Todo lo que un directivo, un product manager o un equipo de negocio debe entender de la PSD2 (DSP2). Actores, consentimiento, oportunidades, sin jerga técnica.