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 of 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 only:
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.
Here are a few examples:
DateMateSub 596 289 100 UK
In this example, we see the name of the subscription, the number to contact, and the country.
MuzikS www.muzikstream.de DE
Apart from the DBA, this example also includes the website and the service provider's country.
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.
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.
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 possibility to contact the merchant.
And the merchant should have the chance to resolve the issue before a chargeback happens.
For both parties, it's the most welcome path.
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:
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.