A Beginner’s Guide To Transaction Descriptors
Whenever a customer reads their card and/or bank statements, they most likely see dates and amounts of transactions, perhaps the account balance after each of them, and – depending on the bank – maybe some additional information as well. But among this data, they surely see transaction descriptors. As the name suggests, a transaction descriptor is meant to describe a particular payment in order to help to identify the transaction.
What are the benefits?
The natural thing is to ask how we can benefit from this.
Cardholders simply get clearer readability of their statements and are able to easily recognize their transactions.
Merchants get even more – setting good descriptors allows them to reduce the risk of chargebacks, which in turn simply means saving money.
The said benefits are actually connected. Chargeback requests are often made by consumers who don’t recognize certain transactions and don’t know how to identify them (or just don’t bother to do so). If a payment is well labeled and/or gives a hint how to identify it unambiguously – a chargeback is much less likely to arise.
How to choose a transaction descriptor
There are two main types of transaction descriptors:
- Static descriptors are set for all payments charged by a particular merchant.
- Dynamic descriptors can be used to describe a specific product or service – they can vary for one merchant.
Which option is better?
That depends on your case. Let’s take a look at some simple examples.
If a merchant owns an e-shop and sells books, he will most likely want to use a static descriptor. A book title may not necessarily ring a bell (frankly, book titles can be really peculiar nowadays) and there’s always the problem what to do, if someone buys more than one book.
Whereas, using the brand name as a descriptor, will surely help customers to associate purchases with the shop. People usually remember where they were shopping – and even if not, it’s easier to locate and contact a merchant by its name.
A company that produces software will probably choose dynamic descriptors. Their customers usually know the name of an application they buy, but may not know the name of the company behind it. Choosing the product name as a descriptor would be advisable in such cases.
Good practices
Providing a descriptor does not mean that consumers will always recognize transactions. There are various ways to optimize such descriptions.
Use brand/trading name
Remember that your customers don’t have to know your company to buy goods from you. Provide them with a name which they will be able to recognize easily – don’t use your legal name. It may differ from your trading name or brand name that you advertise, but even if it’s quite similar, the “Ltd.”, “Inc.”, or “and sons” don’t make it easier to remember.
Make it easy to contact you
When consumers fail to recall a transaction, they usually request a chargeback. Frankly, they don’t have much choice here. That’s why it’s good to give them that choice and allow them to contact you to sort out the issue.
A good and common practice is to place a phone number and/or an email address in a descriptor. This way if customers have any doubts, they can easily contact the merchant and have everything explained to them before requesting a chargeback.
There was also a popular case by 37signals a few years ago, where they presented an alternate approach and placed a custom website address in their descriptors. Consumers could visit the site, which explained clearly what could a payment refer to. 37signals claim that this way they reduced chargebacks by 30%.
By the way, the company is also a fine example on how to use dynamic descriptors – whereas not everybody has to know 37signals, their customers most likely know that they purchased from Basecamp or Highrise.
Conclusion
A few years ago, it wasn’t that difficult to encounter badly chosen or completely unreadable descriptors, but today the situation is much better and improves along with merchants’ awareness of the subject. They tend to ask for such services, or even require them, and are surely not satisfied with just e.g. payment gateway’s name and/or transaction IDs.
However, it’s worth for every merchant to explore what actually works in their particular case and adapt such practices. Whereas it is technically possible to use a different descriptor for every transaction, there’s rarely (if ever) any good reason to do so. In many cases (e.g. recurring payments, where customers expect consistency) this can even cause lots of confusion. Putting some thought into choosing a good descriptor takes relatively little time and effort, but can save you a lot of money in the long run.
