Respuesta corta: Una descripción de pago, también llamada descriptor de extracto o descriptor de transacción, es la breve cadena de texto que acompaña a una transacción con tarjeta y aparece junto al importe en un extracto bancario o aplicación. En los pagos con tarjeta, la establece el comercio o su procesador de pagos y tiene un límite de unos 22 caracteres, razón por la cual suele aparecer como letras aleatorias en lugar de un nombre reconocible. Cuando un cargo muestra un prefijo de pasarela como PAYPAL o SQ, el comercio real suele estar codificado en la cadena después del asterisco, pero resolverlo de forma fiable a gran escala es un problema de enriquecimiento.
Es el único campo que determina en mayor medida si un cliente reconoce lo que compró, a quién pagó y si el cargo es legítimo. Los bancos rara vez lo controlan y, en su forma original, casi nunca es lo suficientemente claro para mostrarlo.
¿Qué es una descripción de pago?
Como se ha mencionado, una descripción de pago es el texto orientado al comercio que aparece junto a una transacción en un extracto bancario o aplicación bancaria. En un pago con tarjeta, proviene de un campo llamado descriptor de pago (también conocido como descriptor de extracto o descriptor de transacción), una cadena corta que el comercio envía a la red de tarjetas junto con la transacción. En una transferencia bancaria o en un flujo de banca abierta, proviene de un campo totalmente distinto: el mensaje al destinatario o la referencia de pago establecida por el pagador o el sistema de origen. En cualquier caso, es la línea de texto que el cliente lee para identificar el cargo.
Para las transacciones con tarjeta, el formato es muy limitado. En la mayoría de los procesadores heredados, el campo del nombre comercial (DBA) está limitado a 22 caracteres, con otros 11 caracteres adicionales para un campo de ciudad o contacto. Un descriptor de extracto completo debe tener entre 5 y 22 caracteres, contener solo caracteres latinos, incluir al menos una letra y excluir caracteres especiales como <, >, , ', ", y *. Algunas redes permiten hasta 25, pero 22 es el límite práctico para el que la mayoría de los comercios diseñan sus sistemas. Comprima un nombre como "Marks & Spencer - Simply Food, Prague" en 22 caracteres y empezará a entender por qué el resultado suele ser ilegible.
El descriptor lo establece el comercio o su procesador de pagos. El banco lo recibe. Aparte de rechazar o dar formato a la cadena, el banco no tiene control editorial sobre lo que llega.
Para obtener una visión más profunda del conjunto completo de campos que llegan con una transacción con tarjeta, como ID de terminal, ID de comercio, MCC, descriptores o ISO 18245, consulte qué contienen realmente los datos de las transacciones y de dónde provienen.
Fuentes diferentes significan descripciones diferentes
La descripción de pago no tiene una única fuente. Depende de la red de pago por la que haya viajado la transacción, y cada red produce un tipo de cadena diferente con un nivel de estructura distinto.
Transacciones con tarjeta (Visa, Mastercard): La descripción proviene del descriptor del extracto del comercio: un campo limitado y abreviado establecido por el comercio o el procesador. Esta es la fuente que la mayoría de la gente asocia con textos de transacciones ilegibles.
Transferencias bancarias (SEPA, BACS, Faster Payments, CERTIS): La descripción proviene de un campo de referencia de texto libre establecido por el pagador. Suele ser más largo que un descriptor de tarjeta (140 caracteres en SEPA), pero el contenido es lo que haya escrito el remitente.
Datos de banca abierta (PSD2 AISP): Cuando un banco o una empresa fintech lee transacciones a través de API de banca abierta, el campo de descripción puede volver a tener un valor diferente. A veces es la cadena del comercio, a veces la referencia de pago y, otras veces, el nombre de la contraparte extraído de los propios registros del banco.
El feed de una aplicación bancaria mezcla todo esto. El usuario no sabe a través de qué canal llegó una transacción determinada, y no debería tener por qué saberlo. Para presentar un feed coherente, el banco debe normalizar las descripciones de múltiples fuentes en una única identidad de comercio reconocible.
Descriptor fijo (hard) frente a descriptor temporal (soft) frente a descriptor dinámico
Específicamente para los pagos con tarjeta, se utilizan tres términos de forma imprecisa en el sector, y describen dos cosas diferentes.
Los términos "fijo" (hard) y "temporal" (soft) se refieren al momento en que ocurren. Un descriptor temporal (soft) aparece durante la retención de autorización: el cargo pendiente que el titular de la tarjeta ve en línea antes de la liquidación. Un descriptor fijo (hard) es la cadena final que aparece en el extracto una vez que se liquida la transacción. Ambos suelen ser iguales, pero no siempre.
Los términos "estático" y "dinámico" se refieren a si la cadena cambia según la transacción. Un descriptor estático se establece a nivel de cuenta de comercio y nunca varía: cada cargo de ese MID aparece con el mismo texto. Un descriptor dinámico se genera mediante programación para cada transacción, combinando normalmente un prefijo fijo (el nombre comercial o DBA) con un sufijo que contiene detalles como una referencia de pedido, una línea de producto o el nombre de un vendedor en un marketplace.
Un ejemplo real de cada uno:
- Estático / fijo (hard): JOHN LEWIS LONDON GB: la misma cadena aparece en todas las transacciones de J. Lewis.
- Dinámico / temporal (soft): MKTPLC*VENDOR-44871: una plataforma de marketplace transmite un identificador por vendedor durante la autorización.
- Dinámico / fijo (hard): RUNCLUB* OCT MARATHON: formato al estilo Stripe donde los primeros 7 caracteres son el prefijo DBA y el resto describe la compra específica.
Un comercio puede utilizar un descriptor estático fijo (como hace la mayoría de las pequeñas empresas) o un descriptor dinámico fijo (mercados, plataformas de suscripción, minoristas multiproducto). Estos términos se complementan, no son excluyentes entre sí.
Cómo identificar al comercio detrás de un cargo de PayPal o Stripe
Las pasarelas de pago son la razón más común por la que una descripción nombra a la entidad incorrecta. Cuando un pago se procesa a través de PayPal, Stripe, Square, Adyen o un procesador similar, la cadena que llega al banco suele comenzar con el nombre de la pasarela, no con el del vendedor. El comercio real, si es que aparece, queda relegado a un sufijo. Para un banco o una empresa de tecnología financiera que desarrolla un feed de transacciones, conocer estos patrones marca la diferencia entre una cadena resoluble y un marcador de posición de "comercio desconocido".
PayPal: Un cargo procesado por PayPal suele aparecer como "PAYPAL" seguido de un identificador de vendedor comprimido: PAYPAL*EBAYNCSHIP,PAYPAL*STEAMGAMES,PAYPAL*JOHNSMITH. El nombre del vendedor después del asterisco está recortado y, a menudo, sin espacios, por lo que EBAYNCSHIP es eBay, no un comercio llamado "Ebayncship". En el caso de pagos entre particulares o a pequeños vendedores, el sufijo puede ser el nombre de una persona o un identificador comercial que no corresponde a ninguna marca pública.
Stripe: Los descriptores de Stripe tienen una estructura diferente. Stripe divide el descriptor en un prefijo de estado de cuenta (la plataforma o empresa que el cliente debería reconocer) y un sufijo que contiene el producto o pedido específico; por ejemplo, RUNCLUB*OCT MARATHON, donde RUNCLUB es la empresa y el resto es la compra. Dado que Stripe impulsa a miles de empresas independientes, el mismo patrón visual (NOMBRE* detalle) abarca desde un gimnasio hasta una suscripción SaaS. El prefijo es la señal del procesador de pagos y el sufijo es el contexto.
Square, Adyen y otros: Square suele utilizar el prefijo SQ* (SQ*COFFEE BAR), donde el sufijo es el nombre configurado por el propio comercio. Adyen y otros procesadores de plataformas pueden transmitir el nombre de la plataforma, el nombre del subcomercio o una combinación de ambos, dependiendo de cómo la plataforma haya configurado su cuenta.
La conclusión práctica es que el prefijo de la pasarela es una señal que debe resolverse. Leer PAYPAL*EBAYNCSHIP y mostrar "PayPal" en el feed es un error, ya que el cliente pagó a eBay. Resolver esto de forma fiable implica comparar el patrón del descriptor con un comercio conocido. Tapix gestiona esto a través de un módulo de enriquecimiento de pasarelas de pago que reconoce los patrones de las pasarelas de los principales procesadores y asigna el sufijo codificado al vendedor verificado, de modo que el feed muestre el comercio con el que el cliente realizó la transacción.
Por qué las descripciones de los pagos suelen ser irreconocibles
El campo de descripción se diseñó en la era de los extractos bancarios en papel, cuando los clientes tenían tiempo para descodificar "TETSPC #4781" en Tesco Hypermarket. En el feed de una aplicación bancaria en tiempo real, esa misma cadena genera confusión.
Cuatro problemas estructurales explican por qué la descripción original rara vez es suficiente para mostrarla al usuario.
Los límites de caracteres obligan a realizar abreviaturas agresivas. El límite de 22 caracteres en las descripciones de las tarjetas hace que cualquier texto más largo que una palabra corta se corte, se abrevie o se elimine.
Aparecen los nombres de las empresas matrices en lugar de los nombres comerciales. Una compra en una cadena de cafeterías conocida podría aparecer como la sociedad holding que opera la franquicia, no como la marca que figura en el vaso.
Se filtran los nombres de los procesadores de pagos. Los pagos en línea procesados a través de Stripe, PayPal, Adyen o Square suelen mostrar la pasarela en la descripción en lugar del vendedor real. Tapix soluciona esto directamente mediante un módulo de enriquecimiento de pasarelas de pago, que resuelve los patrones de transacciones de las principales pasarelas.
Formato inconsistente entre adquirentes y redes de pago. El mismo comercio, al ser procesado a través de dos adquirentes distintos, puede generar dos cadenas de descripción diferentes. El mismo destinatario en una transferencia bancaria puede aparecer con textos de referencia distintos según quién haya iniciado el pago.
El resultado, observado en datos reales de producción: cadenas caóticas como "F.LLI MARINO SNC" o "B2B PRIME" que aparecen en las aplicaciones sin contexto, sin logotipo y sin categoría.
El impacto en el negocio
Las descripciones irreconocibles no son un problema meramente estético. Se manifiestan en tres áreas cuantificables.
Devoluciones de cargos y fraude amistoso: Cuando un cliente no puede identificar un cargo en su extracto, el camino de menor resistencia es disputarlo. Cada disputa conlleva un coste directo (la comisión por devolución, la pérdida de bienes o servicios) y el coste indirecto del tiempo de investigación tanto para el comercio como para el banco.
Carga de trabajo del servicio de atención al cliente: Cada llamada del tipo "no reconozco esta transacción" que resulta ser legítima es una llamada que nunca debería haberse producido. Con los volúmenes que procesan la mayoría de los bancos, incluso un pequeño porcentaje de consultas sobre transacciones no identificadas supone una partida presupuestaria permanente en el departamento de soporte.
Erosión de la confianza en la propia aplicación: Un feed de transacciones que el cliente no puede leer de un vistazo es un feed en el que deja de confiar. Lo consulta menos, interactúa menos y utiliza menos la aplicación para las funciones que los bancos realmente quieren que usen: análisis de gastos, gestión de suscripciones, presupuestos y resolución de disputas.
Lo que el enriquecimiento ofrece y la descripción no puede proporcionar
El enriquecimiento sustituye la descripción original por algo que el cliente reconoce. Concretamente, genera tres resultados que el descriptor por sí solo no puede ofrecer.
Un nombre de comercio verificado y canónico: No "MKTPLC*VENDOR-44871", sino "Marks & Spencer". El nombre limpio se resuelve comparándolo con una base de datos de comercios, se valida mediante múltiples señales y es coherente en todas las variantes de descriptor para un mismo comercio.
Un logotipo del comercio: El reconocimiento visual es más rápido que la lectura. El logotipo de Tesco junto a una transacción se identifica en milisegundos; la cadena "TESCO STORES 2401" requiere que el cliente lea, piense y relacione.
Una categoría y una etiqueta: Más allá de identificar al comercio, el enriquecimiento clasifica la transacción en categorías como Alimentación, Transporte, Suscripciones o Restauración. Cuando se compara la categorización de comercios basada únicamente en el MCC con una categorización integral que tiene en cuenta más factores, solo 63% de las transacciones se clasifican correctamente basándose en el código MCC. El MCC por sí solo no es suficiente; el descriptor, junto con el MCC y las señales contextuales, genera una categoría en la que el cliente puede confiar.
Cómo resuelve Tapix la ambigüedad de las descripciones
Tapix trata el descriptor como una entrada más entre varias. La lógica de coincidencia combina el texto del descriptor con el identificador del comercio (MID), el código de categoría de comercio (MCC), los datos de ubicación del terminal y un gráfico de comercios actualizado continuamente que asigna patrones de descriptores conocidos a marcas verificadas.
El modelo de datos subyacente es jerárquico. Un terminal TPV se vincula a una tienda (con GPS, dirección y categoría). Una tienda se vincula a un comercio (con su nombre canónico y logotipo). Cuando aparece una nueva variante de descriptor, el sistema puede resolverla comparándola con el gráfico existente en lugar de tratarla como una cadena desconocida.
El resultado es lo que el cliente debería haber visto desde el principio: un nombre de comercio nombre del comerciante, una logotipo, una categoría, y una resolución de asignación de pasarela a comerciante que elimina el ruido del procesador y revela al vendedor real. A través de 4.000 millones+ de transacciones enriquecidas mensuales y 1,4 millones+ de comercios reconocidos en la base de datos, esto funciona con una precisión de datos del 99,99% con un tiempo de respuesta promedio de 6 ms por transacción.
El punto no es que el campo de descripción deba corregirse. No es así. Las descripciones de las tarjetas seguirán llegando en su forma original y abreviada porque ese es el campo que definieron las redes de pago y que completan los comercios. El punto es que ninguna aplicación bancaria debería mostrarle al cliente la descripción original. El enriquecimiento es la capa intermedia entre lo que llega a través de los canales de pago y lo que lee el cliente, y es la capa que determina si el resto de la aplicación es confiable.
Para obtener un análisis más profundo sobre cómo debe diseñarse la infraestructura de enriquecimiento en producción, la guía de mejores prácticas de la API de enriquecimiento de transacciones cubre los patrones de integración, el manejo de errores y la diferencia entre cobertura y precisión.
