Billing Descriptors: What Visa Actually Requires

Billing descriptors are the text a cardholder sees on their statement next to your charge. Get it wrong and you generate disputes from customers who simply don't recognise the name, which is one of the cheapest chargeback sources to fix and one of the most commonly ignored.

Visa doesn't use the phrase "billing descriptor" in its rulebook. It regulates the underlying thing as the Merchant name, and the requirements are stricter than most merchants realise. They're in section 1.5.1.12 of the Visa Core Rules and Visa Product and Service Rules (18 April 2026).

The Rule: One Name, Spelled the Same Way Everywhere#

Visa requires the name identifying a merchant to be the name it "primarily uses to identify itself to its customers," and to be displayed at each merchant outlet or on the merchant's website or app.

Then comes the requirement that catches people. That name must be "used consistently, including spelling, in every place that it is used," and the rules list where (ID# 0027816):

• The transaction receipt given to the cardholder
• The authorization request
• The clearing record
• Dispute, dispute response, and acquirer-initiated pre-arbitration records

So the name on your checkout page, the name in the authorization, the name on the statement, and the name on your dispute paperwork are all supposed to be the same string. Not similar. The same, spelling included.

Most descriptor problems are a mismatch between the trading name a customer knows and the legal entity name that ended up in the clearing record at boarding.

Your Acquirer Is Required to Fix a Confusing One#

This is the sentence worth knowing:

"The Acquirer must correct non-compliant Merchant names or those causing Cardholder confusion."

That's an obligation on the acquirer, not a favour. If your descriptor is generating "I don't recognise this charge" disputes, asking your acquirer to change it isn't a special request outside normal process. It's something the rules require them to do.

Worth knowing before you accept "that's just how it was set up" as an answer.

Two Exceptions Worth Understanding#

The rules allow a couple of specific departures, and both explain descriptors that otherwise look wrong.

Abbreviations in the clearing record. The merchant name in the clearing record may differ from the name on the transaction receipt "if abbreviations are required or supplementary data is used." Statement fields are short, so truncation is expected. What isn't permitted is a name that resolves to a different business.

A website address for e-commerce. For e-commerce transactions the website address may be used, unless it isn't directly related to the merchant name. If you trade as one brand and your domain is something unrelated, you don't get to put the unrelated domain on the statement.

Why Aggregator Descriptors Look Like That#

If you've ever wondered why a charge from a small shop shows up as a payment company's name plus the shop name, the receipt rules explain it.

Table 5-33 requires the merchant name to be "the name used by the Merchant to identify itself to its customers," with named exceptions:

• For a transaction involving a payment facilitator, both the name of the payment facilitator and the name of the sponsored merchant, or an abbreviation of it
• For a marketplace, the name of the marketplace and the name of the retailer
• For a back-to-back transaction involving a digital wallet operator, the name of the DWO and the retailer

That's the rule behind the aggregator-prefix descriptor. It's also a real difference between processing through a payment facilitator and holding your own merchant account. On your own MID, the statement can carry your name alone.

What Else Has to Be on the Receipt#

Descriptors don't work alone. A transaction receipt must include the last four digits of the payment credential with the rest suppressed on the cardholder's copy, the authorization code where the issuer authorized it, the card network name, a description of the goods or services, and the city and state or province of the merchant outlet.

The location element matters more than it looks. A recognisable name plus a plausible city is often what turns "I don't know this charge" into "oh, that was the hotel."

Getting Yours Right#

A few practical rules that hold up:

Use the trading name customers actually see, not the LLC on your incorporation paperwork, unless those are the same thing.

Include a contact route in the descriptor where the field allows it. A short phone number or domain gives the customer somewhere to go other than their bank.

Keep it consistent across every MID you run. Merchants operating multiple MIDs frequently end up with drifting descriptor text across them, which quietly undoes the recognisability you were building.

Check what the customer actually sees. Ask your processor for the exact string as it appears on a statement, including truncation, rather than the value in the boarding form.

Then look at the dispute data. If unrecognised-charge disputes fall after a descriptor change, that's the cheapest chargeback reduction available to you. If they don't, the problem is elsewhere and worth chasing properly through dispute reason codes.