Merchant Descriptors as a Customer Dispute Prevention Tool

Emily VuittonFraud Prevention7 Comments

How to create a merchant descriptor

While it may seem surprising, your merchant descriptor is one of the strongest lines of defense against customer disputes. A merchant descriptor is what appears on a cardholder’s statement after they make a purchase; it’s goal is to identify the transaction to the cardholder. The descriptor your customers see depends on their issuing bank.

But, there are steps merchants can take to ensure their descriptor is as representative of the company and relevant to the customer as possible.

Poor Descriptors = ‘Unrecognized’ Chargebacks

Fraud or No Authorization chargebacks represent the bulk of customer disputes merchants see. Included in this category are transactions that the cardholder does not recognize, regardless of whether or not they believe it could be fraudulent.

The situation leading up to an unrecognized transaction is fairly constant. A cardholder reviews their statement, sees a transaction they don’t remember purchasing, aren’t given any helpful information in the descriptor, and subsequently contact their bank to dispute the transaction. Visa, Mastercard, American Express, and Discover each have specific reason codes to represent unrecognized transactions.

Reason Code Definition
American Express reason code F29 Cardholder Denies Participation in a Card Not Present Transaction
 Discover reason code AA Transaction Is Not Recognized
Mastercard reason code 4863 Cardholder Does Not Recognize Potential Fraud – US Only

However, there could be a multitude of circumstances contributing to the unrecognized transaction, in addition to a poor merchant descriptor. For example, the cardholder could have given permission to their son to purchase clothing from an online store. The purchase was indeed authorized by the cardholder, but they simply don’t recognize the merchant name on their statement.

Another example is a cardholder making a purchase at an establishment whose merchant description is actually that of the business’ parent company. This obviously causes confusion for the cardholder. They would likely recognize the transaction if it used the name of the establishment, but the parent company’s name is not effective at jogging their memory.

Types of Merchant Descriptors

The contents of your merchant descriptor depends on the customer’s issuing bank. But, working with your payment service provider to ensure your business is properly identified on cardholder statements is critical to reduce unrecognized chargebacks.

Soft or Pending Descriptors

Soft descriptors, also called pending descriptors, appear after a transaction has been authorized but is not yet settled. Pending transactions will always display soft descriptors. While the soft descriptor is typically representative of the static descriptor, some issuing banks will display the payment service provider name instead of the merchant’s name.

Merchant’s using Stripe as their payment service provider will appear as “Stripe” in American Express pending transactions. Once the transaction is settled, typically within 48 hours, “Stripe” is replaced with your merchant descriptor. Stripe acknowledges this frustration, but reminds merchants that pending transactions can’t be disputed, so little hassle should be created.

Hard, Default Billing, or Static Descriptors

Static descriptors, also called hard descriptors or default billing descriptors, appear after a transaction is settled. This is what’s permanently displayed on the cardholder’s billing statement.

Static descriptors typically consist of two variables: a DBA name and location information. Your DBA, or doing business as, name must be less than 22 characters and the location information field must be less than 11 characters. For many businesses, using the city field for a web address or phone number is a better use of the 11 characters of space.

Common basic formats of static descriptors include:


But remember, how your static descriptor appears all depends on what the customer’s bank decides to display. In the Capital One online portal, static descriptors are displayed alongside a wealth of supplemental information provided by the issuer. A line in the cardholder’s online portal from Audible expands to appear as:

Audible Merchant Descriptor in Capital One

The additional information populated by Capital One is incredibly helpful for cardholder’s who might not recall making a purchase. Seeing the merchant’s logo and having a direct link to the website alone could be enough to jog a customer’s memory. But as you can see, the static descriptor as it appears on paper customer statements is:

  • Audible NJ 07102 US

Using Capital One’s portal as an example again, you can see that the descriptor populated for this location of Chipotle includes a Google Map of the location of the restaurant:

Chipotle Merchant Descriptor in Captial One

Chipotle includes the restaurant address of the transaction in the descriptor. This allows Capital One to display a map, further aiding in customer recall of purchase. The descriptor appears on the customer statement as:

  • CHIPOTLE 1104 SANDY UT 84070 US

On the other end of the spectrum, PNC Bank displays limited static descriptors and places an importance on the type of transaction represented. Before the static descriptor is provided, PNC lists whether the transaction was a POS purchase, an ATM withdrawal, a debit card purchase, a credit card purchase, or a deposit.

Obviously, this leaves space very restricted for your static descriptor. Which means that merchants need to get creative with the space they’re allotted. Examples of static descriptors as they appear in the PNC portal include:

  • 5555 Debit Card Purchase Apl* Itunes.Com/Bill
  • 5555 Debit Card Purchase Harmonsgrocery.Com
  • 5555 Debit Card Purchase Wpchrg.Com 8772733049

Dynamic Descriptors

Some payment service providers offer dynamic merchant descriptors that vary depending on the product, merchandise purchased, etc. The merchant’s dynamic descriptor is passed to the cardholder’s issuing bank typically via an API. Different payment service providers offer different support for dynamic descriptors. Some may only use dynamic descriptors for pending transactions, while some support pending and static dynamic descriptors.

Merchant Descriptor Best Practices

There are a handful of best practices to follow to get the most out of your merchant descriptor as a customer dispute prevention tool.

Display a Recognizable Company Name

It’s critical to display a business name that the customer will recognize. The name you choose to represent the transaction to the cardholder should be one with which they’re familiar. This is especially critical if your legal company name differs from what a customer will recognize. For the most part, additions like “Ltd.” or “Inc.” aren’t useful for cardholder recognition.

Always Include Contact Information

Along with a recognizable company name, include a way for cardholders to communicate with you. If a customer doesn’t recognize a transaction, they’ll initiate a dispute if they can’t immediately figure out how to identify or contact the merchant. But, if it’s just as easy to call a customer service number or head to a website indicated in your merchant descriptor, they’ll likely do that first, giving you a chance to sort out the issue before a chargeback happens.

As you saw with the merchant descriptors shown by PNC, each of the descriptors include a URL that directs cardholders to a page that clearly represents the content of the transaction. Doing so points the cardholder in a good direction if they fail to immediately recognize the purchase.

Use Dynamic Descriptors Wisely

Dynamic descriptors can be configured on a per transaction level, giving the merchant who offers multiple products or services an opportunity to provide additional detail specific to each customer. While including a product name or category can be helpful, including relevant contact information for the transaction is always a good use of dynamic descriptors.

Take the PNC transaction “5555 Debit Card Purchase Apl* Itunes.Com/Bill” provided previously. A customer using Itunes will likely be purchasing media with varying levels of obscure titles. Instead of populating a transaction-specific product descriptor, Apple provides a link to a page that provides information on how Itunes appears on cardholder statements.

Test Transactions in Different Portals

After you create your merchant descriptors, whether dynamic or static, run test transactions through different issuing banks. Doing so allows you to view the descriptor as it will appear to customers and the different formats it may take. This way, you can ensure your descriptor is easily understandable and immediately recognizable to the cardholder.

Poor merchant descriptors will lead to chargebacks. If the customer doesn’t recognize a transaction, there’s no reason for them not to dispute it. Unrecognized-related chargebacks will often appear to merchants categorized under Visa reason code 83. This reason code represents a card not present transaction that the customer either believes is fraudulent, does not recognize, or did not provide authorization at the time of purchase.

Responding to this chargeback means proving that the customer authorized the transaction. To make your representment process a bit easier, we’ve created a chargeback response template specifically for Visa reason code 83 disputes. Learn more and download the Visa reason code 83 chargeback response template for free to start responding to and recovering revenue from unrecognized-related chargebacks.

Download the Visa Reason Code 83 Response Template