Open any banking app, scroll a recent transaction feed, and the friction usually starts in the same place: a row of cryptic capital letters where a merchant name should be. That row is the payment description - the short text string that comes through with the transaction and lands in the app next to the amount. It is the single field that most determines whether a customer recognises what they bought, who they paid, and whether the charge is legitimate. Banks rarely control it, and in its raw form, it is rarely good enough to display.
What is a payment description?
A payment description is the merchant-facing text that appears next to a transaction in a bank statement or banking app. On a card payment, it comes from a field called the payment descriptor (also known as a statement descriptor or transaction descriptor) - a short string the merchant submits to the card network alongside the transaction. On a bank transfer or open banking flow, it comes from a different field entirely: the message-to-recipient or payment reference set by the payer or the originating system. Either way, it is the line of text the customer reads to identify the charge.
For card transactions, the format is severely limited. Across most legacy processors, the merchant DBA name field is capped at 22 characters, with an additional 11 characters for a city or contact field. A complete statement descriptor must contain between 5 and 22 characters, contain only Latin characters, contain at least one letter, and exclude special characters such as <, >, , ', ", and *. Some networks allow up to 25, but 22 is the practical ceiling most merchants design against. Compress a name like "Marks & Spencer - Simply Food, Prague" into 22 characters and you start to see why the output is so often unreadable.
The descriptor is set by the merchant or their payment processor. The bank receives it. Apart from rejecting or formatting the string, the bank has no editorial control over what arrives.
For a deeper look at the full set of fields that arrive with a card transaction, like terminal IDs, merchant IDs, MCC, descriptors, or ISO 18245, see what transaction data actually contains and where it comes from.
Different sources mean different descriptions
The payment description does not have a single source. It depends on which payment rail the transaction travelled on, and each rail produces a different kind of string with a different level of structure.
Card transactions (Visa, Mastercard): The description comes from the merchant statement descriptor - a constrained, abbreviated field set by the merchant or processor. This is the source most people associate with unreadable transaction text.
Bank transfers (SEPA, BACS, Faster Payments, CERTIS): The description comes from a free-text reference field set by the payer. It is usually longer than a card descriptor (140 characters on SEPA), but the content is whatever the sender typed.
Open banking data (PSD2 AISP): When a bank or fintech reads transactions through open banking APIs, the description field can carry a different value again. Sometimes it’s the merchant string, sometimes the payment reference, sometimes a counterparty name pulled from the bank's own records.
A banking app feed mixes all of these. The user does not know which rail a given transaction came in on, and they should not have to. To present a consistent feed, the bank has to normalise descriptions from multiple sources into a single, recognisable merchant identity.
Hard descriptor vs. soft descriptor vs. dynamic descriptor
For card payments specifically, three terms get used loosely across the industry, and they describe two different things.
Hard and soft are about timing. A soft descriptor appears during the authorisation hold - the pending charge a cardholder sees online before settlement. A hard descriptor is the final string written to the statement once the transaction settles. The two are often, but not always, the same.
Static and dynamic are about whether the string changes per transaction. A static descriptor is set at the merchant account level and never varies - every charge from that MID lands as the same text. A dynamic descriptor is generated programmatically per transaction, typically combining a fixed prefix (the DBA name) with a suffix that carries detail like an order reference, a product line, or a marketplace seller name.
A real example of each:
- Static / hard: JOHN LEWIS LONDON GB - the same string lands on every J. Lewis transaction.
- Dynamic / soft: MKTPLC*VENDOR-44871 - a marketplace platform passes through a per-vendor identifier during authorisation.
- Dynamic / hard: RUNCLUB* OCT MARATHON - Stripe-style format where the first 7 characters are the DBA prefix and the rest describe the specific purchase.
A merchant can run a hard, static descriptor (most small businesses do), or a hard, dynamic descriptor (marketplaces, subscription platforms, multi-product retailers). The terms compose, they do not exclude each other.
Why payment descriptions are often unrecognisable
The descriptor field was designed in an era of paper statements, where customers had time to decode "TETSPC #4781" into Tesco Hypermarket. In a real-time banking app feed, that same string causes confusion.
Four structural problems explain why the raw description is rarely good enough to display.
Character limits force aggressive abbreviation. A 22-character cap on card descriptors means anything longer than a single short word gets cut, abbreviated, or dropped.
Parent company names appear instead of trading names. A purchase at a high-street coffee chain might surface as the holding company that operates the franchise, not the brand on the cup.
Payment processor names leak in. Online checkouts routed through Stripe, PayPal, Adyen, or Square frequently surface the gateway in the description instead of the actual seller. Tapix addresses this directly through a Payment Gateways enrichment module, resolving transaction patterns from major gateways.
Inconsistent formatting across acquirers and rails. The same merchant routed through two different acquirers can emit two different descriptor strings. The same recipient on a bank transfer can appear under different reference texts depending on who initiated the payment.
The result, observed on real production data: chaotic strings like "F.LLI MARINO SNC" or "B2B PRIME" landing in apps with no context, no logo, and no category.
The business impact
Unrecognisable descriptions are not a cosmetic problem. They show up in three measurable places.
Chargebacks and friendly fraud: When a customer cannot identify a charge on their statement, the path of least resistance is to dispute it. Each dispute carries direct cost (the chargeback fee, the lost goods or service) and the indirect cost of investigation time on both the merchant and bank side.
Customer service load: Every "I don't recognise this transaction" call that turns out to be legitimate is a call that should never have happened. At the volumes most banks process, even a small percentage of unidentified-transaction queries is a permanent line item in the support budget.
Trust erosion in the app itself: A transaction feed that the customer cannot read at a glance is a feed they stop trusting. They check less, engage less, and use the app less for the things banks actually want them to use it for - spending insights, subscription management, budgeting, dispute resolution.
What enrichment delivers that description cannot
Enrichment replaces the raw description with something the customer recognises. Specifically, it produces three outputs the descriptor alone cannot.
A verified, canonical merchant name: Not "MKTPLC*VENDOR-44871" but "Marks & Spencer." The clean name is resolved against a merchant database, validated against multiple signals, and consistent across descriptor variants for the same merchant.
A merchant logo: Visual recognition is faster than reading. A Tesco logo next to a transaction is identified in milliseconds; the string "TESCO STORES 2401" requires the customer to read, think, and connect.
A category and tag: Beyond identifying the merchant, enrichment places the transaction into a category like Groceries, Transport, Subscriptions, or Dining. When merchant categorisation based on MCC alone is compared with comprehensive categorisation taking more factors into account, only 63% of transactions are correctly matched based on the MCC code. MCC alone is not enough; the descriptor plus MCC plus contextual signals together produce a category the customer can rely on.
How Tapix resolves description ambiguity
Tapix treats the descriptor as one input among several. The matching logic combines descriptor text with the merchant identifier (MID), the merchant category code (MCC), terminal location data, and a continuously updated merchant graph that maps known descriptor patterns to verified brands.
The data model behind this is hierarchical. A POS terminal links to a shop (with GPS, address, and category). A shop links to a merchant (with the canonical name and logo). When a new descriptor variant appears, the system can resolve it against the existing graph rather than treating it as an unknown string.
The output is what the customer should have seen in the first place: a recognisable merchant name, a logo, a category, and a resolved gateway-to-merchant mapping that strips the processor noise and surfaces the actual seller. Across 1.5 billion+ monthly transactions and 800k+ unique merchants in the database, this runs at 99.99% data accuracy with an average response time of 3ms per transaction.
The point is not that the descriptor field needs to be fixed. It does not. Card descriptors will keep arriving in their raw, abbreviated form because that is the field the payment networks defined and the merchants populate. The point is that no banking app should ever display the raw description to a customer. Enrichment is the layer between what arrives on the rails and what the customer reads, and it is the layer that determines whether the rest of the app is trusted.
For a deeper look at how enrichment infrastructure should be designed in production, the transaction enrichment API best practices guide covers integration patterns, error handling, and the difference between coverage and accuracy.
