Statement descriptors: how the line on a card statement causes or prevents disputes

A customer buys a jacket from a brand they like. A week later they check their card statement and see a line of capitals they have never seen: the name of a holding company, in a city they do not know. They do not remember a purchase from that name, so they call their bank. The sale was genuine, the jacket arrived, and the merchant now has a dispute.

This article explains why unclear descriptors cause disputes, what Visa and providers require, how long a descriptor can be, when dynamic descriptors help, and what to set for each brand and market. It covers the descriptor only. For the wider process, see chargeback management for cross-border merchants.

What is a statement descriptor?

A statement descriptor is the text that identifies a merchant on a customer’s card or bank statement. Visa’s rules call it the merchant name, and providers also call it a billing descriptor or soft descriptor. Stripe describes two forms: a static descriptor that appears on every payment, and, for card payments, a static prefix joined to a dynamic suffix that can change per payment.

The merchant name is only part of what travels with a card payment. Visa’s data standards also define a merchant city field, and Adyen says the city and country are always added to the description you set, even when it is customised. Together these form the line the customer reads.

Why do unclear descriptors cause disputes?

Because a charge a customer cannot place looks like fraud. Visa’s Dispute Management Guide for Merchants, updated in October 2026, says one of the most common reasons customers contact their bank is that they do not recognise a transaction on their statement. It adds that in many cases the transaction was valid, but the business name, billing descriptor or transaction details were unfamiliar.

The same guide lists customers not recognising the business name on their statement among the simple, preventable causes of disputes. It also says Visa dispute condition 10.4, card-absent fraud, can arise when the cardholder does not recognise the charge or does not recall what they agreed to. So a genuine sale can land in your fraud numbers, where it counts against you. Our article on the VAMP programme explains why those numbers matter. Adyen makes the same point: if shoppers do not recognise a charge, the chance of a chargeback rises, and card schemes may fine you based on your chargeback rate.

Visa’s manual puts it plainly: the merchant name is “the most important factor in cardholder recognition of transactions”. Stripe says clear and accurate descriptors can reduce chargebacks and disputes. We have no reliable public figure for how much, because it depends on how poor the original descriptor was.

What do Visa and providers require?

Visa’s Merchant Data Standards Manual, in its October 2026 edition, sets the core rule. The merchant name must be the name most prominently displayed by the merchant and by which cardholders recognise it, while also reflecting its doing-business-as (DBA) name. Mastercard’s rulebooks set their own requirements, so check them with your acquirer.

The manual adds several points that are easy to miss:

• Names must make sense out of context. A name that is clear on the premises may confuse on a statement. If the name is inconsistent with the merchant category code, it must carry extra words that identify the business type.
• Abbreviate, do not truncate. Names over 25 characters must be abbreviated, not just cut after the 25th character, and the part that uniquely identifies the merchant must not be abbreviated.
• Give the customer a way to reach you. For card-absent payments, the city field must contain the merchant’s customer service telephone number, URL or internet or email address.
• Extra data has limits. Supplementary data is not allowed if it makes the name field confusing or breaks other requirements.
• Facilitators and marketplaces have set formats. A sponsored merchant may use its own name, or the facilitator’s name, an asterisk and the merchant’s name, and should choose whichever cardholders recognise more. A marketplace may use its own name alone, or its name, an asterisk and the seller’s.

Providers add their own rules. Stripe says the complete descriptor must contain only Latin characters, include at least one letter, avoid <, >, \, ', " and *, reflect your DBA name, and contain more than a single common term. It accepts a website address alone only if it gives a clear and accurate description of the transaction. Adyen allows letters, digits, spaces and a short list of punctuation. Cielo in Brazil bars special characters and says soft descriptors are not available to merchants with MCCs from 5960 to 5969.

How long can a descriptor be?

Plan for 22 characters. Visa’s systems hold 25, but your provider sets the working limit, and Stripe and Adyen both stop at 22.

Source	Field	Limit
Visa	Merchant name	25 characters, including spaces and symbols
Visa	Merchant city	13 characters
Stripe	Complete descriptor	5 to 22 Latin characters
Stripe	Static prefix	2 to 10 characters
Stripe	Japanese descriptor, kanji	17 characters in total
Stripe	Japanese descriptor, kana	22 characters in total
Adyen	Name, dynamic value or both	22 characters including spaces
Cielo	Trade name, asterisk and soft descriptor	25 on Visa, 22 on Mastercard, Elo and Amex

What happens past the limit also varies. Adyen cuts off anything over 22 characters. Stripe truncates a static descriptor used as a prefix to 10 characters if you have not set one. A cut-off name can end up meaning nothing, which is why it pays to write the short form yourself.

Example figures, for illustration only. A retailer trades as Northwind Outdoor Supplies, which is 26 characters.

Option	Descriptor	Length	Comment
Automatic cut	NORTHWIND OUTDOOR SUPPLIE	25	Fails Visa’s rule on truncation
Abbreviated for Visa	NORTHWIND OUTDOOR SUPPLY	24	Fine on Visa’s field, too long at 22
Short form	NORTHWIND OUTDOOR	17	Clear, and fits every limit in the table
Prefix and suffix	NORTHWIND* ORDER 20931	22	Uses all 22 characters with an order reference

When should you use a dynamic descriptor?

When one fixed name cannot tell the customer what they bought. Stripe suggests a prefix and suffix if you sell several products or services, or if customers may not understand a single value. Its suffix is joined to the prefix with an asterisk and a space, and those two characters count towards the 22. With a 7-character prefix, 13 remain.

Visa’s manual allows additional information after the merchant name and an asterisk, to show an order number, reference number or other detail that identifies the transaction. Instalment details, such as 1 of 2, must appear after the asterisk. Hotels and vehicle rental merchants must not truncate their name to make room.

A good suffix helps the customer match the line to something they hold. An order number from the confirmation email works. So does a product family or a brand within a group. Avoid random internal codes, which add nothing a customer can check. Stripe also describes a fraud use: put a short code in the descriptor and ask a customer you suspect to read it back from their statement. That adds friction, so keep it for doubtful orders.

Check support before you plan around it. Stripe supports dynamic suffixes only on card payments. Adyen needs dynamic values switched on: if they are off, the value in your request does not appear, and if they are on but you send nothing, it uses your DBA name. Cielo allows soft descriptors only on credit transactions.

What should you set per brand and market?

One name per customer-facing brand, then check each market. The table sets out the main cases.

Situation	What to do	Source
One brand, one website	Use a static descriptor with your brand name or website domain	Stripe
Several brands or websites	Give each its own descriptor and contact details through a separate account or merchant ID. Each site selling distinct goods needs the MCC that fits it	Stripe, Visa
Many products under one brand	Use a brand prefix with an order or product suffix	Stripe, Visa
Apple Pay and Google Pay	Wallets holding a supported card brand use the card setup at Adyen. Set the name in Apple Wallet separately with the merchantName property	Adyen, Apple
Brazil, cards	Allow for the format: a 12-character trade name leaves 12 characters on Visa and 9 on the other brands at Cielo	Cielo
Brazil, Pix	Expect a provider’s name. Stripe says Pix does not support custom descriptors, and that Ebanx appears on the bank statement, with your name in the identifier field	Stripe
Vouchers such as Boleto and OXXO	Expect a processor’s name, or none. Reach says its vouchers and receipts may not name the merchant	Reach
Japan	Set kanji, kana and Latin versions if you are a Japanese business. Issuers choose which to show	Stripe, Adyen

The Japan case has extra conditions. Stripe says Japanese descriptors apply only when the card is a Visa or Mastercard issued in Japan and the charge is processed by or for a Japanese business. Adyen adds that cross-border transactions always use the standard statement field.

Where the descriptor cannot carry your name, other messages have to do the work. Visa’s guide says receipts, order confirmations and account emails should show your business name, date, amount, currency, order reference and customer service contacts. It recommends the same name, logo, website and support details at every touchpoint, and prompt confirmations. Telling the customer at checkout and in the confirmation email how the charge will appear is a simple step that covers the gap.

How do you check what customers really see?

Do not trust the configuration screen. Stripe says most banks display descriptors consistently, but some display them incorrectly or not at all. It also says some issuers show a friendly name chosen from several data points, mainly to reduce disputes, so the mapping varies by issuer. Reach warns that a pending authorisation can differ from the final descriptor, and Stripe says Japanese descriptors are sent at capture, so they can take a few days to appear.

Run this check for each brand and main market, and repeat it after any change of provider.

1. Make a real purchase with a card from that market.
2. Check the line while the payment is pending, then again after it posts.
3. Repeat through a wallet and each main local method.
4. Compare the result with your brand name, checkout page and confirmation email.
5. Search the line as a customer would. The top results should lead to you.
6. Confirm the support contact works and that the team knows the descriptor.
7. Record the expected descriptor for each provider and account.
8. Review disputes and support tickets for unrecognised charges each month.

Step 7 matters most for merchants with several providers. If a payment can go to any of three providers, a customer may see three different lines for the same shop. Set them to match as closely as each provider allows.

How does Omno help with statement descriptors?

Descriptors are set by the provider or acquirer that processes each payment, usually per merchant account, and each provider onboards you separately, so agree them during that onboarding. Omno’s full transaction trail shows which provider took each payment, which helps support answer a customer who does not recognise a charge, and multi-brand access keeps every brand’s transactions in one place. The reporting and analytics page shows the data available.