As the name implies, a transaction descriptor describes a payment. It is created for customers’ convenience to make the transaction listed on a bank statement easily recognizable.
Why should customers be interested in transaction descriptors at all? The answer is quite simple — because it’s their money.
Imagine the customer has made a couple of transactions during the month, and when reviewing the bank statement they find it difficult to recall all of them. Small amounts don’t seem suspicious, so they probably ignore them.
Yet, if they happen to make larger purchases, it can be problematic if it’s impossible to identify the transactions correctly.
And if the customer is not 100% sure the transaction is legitimate or suspects fraud, they might call their issuing bank and trigger the costly dispute procedure.
Since chargeback requests are often initiated by customers who don’t recognize the transaction, it is in the interest of the merchants to avoid such situations. And that’s when transaction descriptors come in handy.
Types of Descriptors
Before determining descriptors for your products or services, it’s good to assess your needs, get familiar with their usability, and consider potential advantages and problems they may cause. So, what options can merchants consider? Let’s dive deeper below.
Static Transaction Descriptors
Static descriptors, otherwise known as hard descriptors, are unchangeable for every transaction processed via a given merchant. They are set for all transactions, regardless of the product or service bought.
Hard descriptors appear after a transaction is settled and are permanently displayed on the statement.
They consist of two elements:
-
DBA name
-
Contact information
The DBA name is nothing other than the “doing business as” name. It has to be described shortly, with less than 22 characters. The character limit for contact information is even more restrictive — the merchant has only 11 characters at their disposal.
Dynamic Transaction Descriptors
Dynamic descriptors are required when describing a specific product or service, not the merchant in general. They are configured for every transaction via the API precisely when being processed. For this reason, the descriptions differ depending on the product or service being purchased.
Why would merchants need dynamic descriptors? They are useful when selling products or services more recognizable than the company’s name.
Soft Descriptors (Pending)
These descriptors are temporary. They are used for pending transactions — transactions that have been authorized but have yet to be captured. As soon as the payment is processed, the soft descriptor is replaced with the permanent one.
The content for soft descriptors is usually identical to static ones. Yet, the bank might display the payment provider’s name instead of the merchant’s. It’s also important to acknowledge that pending transactions can’t be disputed.
Best Practices to Consider
Do transaction descriptors guarantee that customers will recognize the transaction at first glance? No.
However, there are many ways to optimize information displayed on a bank statement, thus reducing the risk of chargebacks. Here are a few to consider.
Easy-to-Identify Business Name
The full name of the company is only sometimes the best choice when it comes to transaction descriptors. Why? Because the customers might be more familiar with the brand or trading name than the company’s name.
Here’s an example —Imagine we have a bookstore named “4READERS”, which is relatively easy to remember. Yet, the registered name of this bookstore is BKS, Inc.
Since the legal name differs from the one used daily, the customer will find it difficult to identify the transaction described as “BKS YOURWEBSITECOM 111-222-1234“.
Instead, they will probably have fewer or no problem identifying “4READERS YOURWEBSITECOM 111-222-1234“.
In some cases, it’s the product that should be mentioned in the transaction description, especially if it’s completely different from the brand name.
Whatever option is chosen, the descriptor’s purpose is to make it easier for the customers to recall the transaction. Needless to say, none of the meaningless elements, such as “Inc.”, “Ltd.” or similar, should appear in the descriptor. If it doesn’t provide added value or information for your customers, there’s no place for it.
Contact Information
Undoubtedly, it’s much more effective to answer the call from the client than to deal with the costly chargeback. For this reason, the contact information included in the descriptor may (literally) save the merchant’s money.
If the client has trouble recognizing the purchase, they should have the ability to contact the merchant and the merchant should have the chance to resolve the issue before a chargeback happens. It’s the most welcome path for both parties.
Website Address
Putting the website address in the descriptor is also wise, especially for online merchants. In some situations, the website address will ring a bell and might be sufficient to recall the purchase, thus avoiding possible chargebacks.
To sum it up, the ideal descriptor should contain the following:
- Company name
- Website address
- Company location
- Contact information
It’s all in the Name
It’s the issuing bank that determines how a customer sees the descriptor. As a rule, it comes as the following: COMPANYNAME 123-123-1234 ZIP CODE UK or COMPANYNAME COMPANYSITECOM ZIP CODE CH.
Yet, sometimes the bank may display only a part of the descriptor; hence, keeping it simple, short, and easy-to-identify increases the merchant’s chances of avoiding misunderstandings on the customer’s side. This diminishes the risk of costly and time-consuming chargeback disputes. Clear and relevant descriptors mean fewer chargebacks and better customer relationships.