Why merchant names get cut off on your statement

The character limit that cuts every name

Card networks cap the merchant name field that travels with each transaction. The number varies by network — Visa provides 25 characters for the merchant name, Mastercard allows up to 22, and American Express supports more with separate fields for city and contact info — but payment processors almost universally enforce a 22-character cap because it is the limit that works across every network.

Stripe’s documentation states it plainly: only the first 22 characters of the full statement descriptor are sent for card payments. Everything after the 22nd character simply does not exist from the bank’s perspective.

Why the prefix eats the real name

Processors and payment facilitators put their own name first. A coffee shop paid through Square shows up as SQ *DAILY GRIND CAFE; a restaurant on Toast shows as TST* RIVERSIDE DINER; a seller on PayPal shows as PAYPAL *NOVELTYSHOP. The processor prefix is not decoration — card network rules require payment facilitators to identify themselves on the descriptor.

That prefix consumes characters from the 22-character budget, which is why the merchant’s own name is what gets cut. Square documents the effect directly: after the SQ * prefix, the business name is limited to 20 characters and is truncated if it exceeds that.

The asterisk is a separator, not decoration

The * symbol is a structural marker: everything before it is the static processor or merchant prefix, everything after it is the dynamic suffix (often the merchant’s name or a store identifier). The combination of prefix, asterisk, separator space, and suffix is capped at 22 characters total.

So SQ *DAILY GRIND CAFE breaks down as: SQ (Square’s facilitator marker), * (separator), DAILY GRIND CAFE (the merchant’s name as configured). When the real name is longer than the budget, the suffix is truncated first — the prefix is preserved because it is the part the networks require.

Why your app shows more than the statement

Banks receive a rich transaction file that can include a longer merchant record than the cardholder descriptor. Many banking apps display that friendlier, fuller name, while the printed statement uses the truncated descriptor. That is why the same purchase can look like a complete name in the app and a stub on paper.

When they disagree, the descriptor on the statement is the one the bank’s records used for that card transaction — and the one other services (like a decoder) can match against.

1. Read the part before the * That is the processor: SQ* Square, TST* Toast, PAYPAL* PayPal, PADDLE* Paddle. It tells you how the merchant gets paid, not who they are.
2. Read the part after the * That is the merchant. The name is often truncated mid-word — mentally complete it with the city or a store you recognize.
3. Match the amount and date The amount and date are more reliable than the name. A truncated name plus a matching amount is usually enough to place the purchase.
4. Paste it into the decoder The decode tool on this site matches truncated descriptors against known processor and merchant patterns.

When truncation hides a real problem

A truncated name is normal. An unrecognizable name plus an unrecognizable amount is worth a closer look — but check the date and the processor first, because most "who is this?" charges are legitimate purchases from merchants whose names simply got cut.

If a charge stays unidentified after matching date, amount, and processor, contact the merchant or your bank. And remember the bigger principle from the descriptor guide: the name you see is only the 22-character version of a longer record, so a stub can represent a company you know perfectly well.