The purpose of this article is to familiarize merchants and payment service providers with the concept of ACH and credit card transaction descriptors.
A descriptor is a description of a product or service purchased by a customer from a certain merchant that appears on the customer’s statement, explaining a charge (or refund) of the merchant.
Descriptors are fixed in length. For instance, standard credit card transaction descriptor length is 22 characters at most. These, generally, include the DBA name of a merchant and the name of the product/service, separated by asterisk (*) symbol. Some processors also allow to specify telephone number or web-site of a merchant in descriptors; some banks do not display all this information on cardholders’ statements, but most do.
What are descriptors intended for?
A descriptor is designed to remind a customer what the transaction was, and what the money was charged for (in order to avoid groundless chargebacks). Consequently, it is critical for ACH and credit card transaction descriptors to be as informative as possible, especially on recurring billing transactions.
Credit card transaction descriptor configurations
Depending on the processor and the platform, credit card transaction descriptors can be either dynamic or static.
A static descriptor is associated with the merchant ID. This means that one merchant ID corresponds to one descriptor. All transactions associated with a given merchant ID bear the same descriptor (e.g. look the same on the statement).
A dynamic descriptor is specified at the transaction level, i.e. different transactions with different descriptors can go through one merchant ID. Even though the same merchant ID is used for all transactions, each transaction can have its own descriptor (verbage).
Dynamic descriptors are the more preferable and flexible option.
Depending on capabilities of a given platform, the information about descriptors can be submitted at different times:
- Authorization-only – some platforms accept descriptor information at the moment of transaction authorization.
- Settlement-only – some platforms accept descriptor information at the moment of transaction settlement.
- Authorization and settlement – some platforms accept descriptor information during both transaction authorization and transaction settlement.
Ability to submit descriptor information during both authorization and settlement is nice, but authorization-only option is sufficient. Settlement-only option is less ideal, so some banks do display transaction description online as soon as the transaction is authorized.
ACH transaction descriptors
Many banks within the US utilize NACHA file format for ACH processing. NACHA format allows to use descriptors in a way similar to the one used for dynamic descriptors. When a file is sent, ACH transactions are grouped into batches, and every batch can have its own unique descriptor, comprised of the merchant name and item description. Although, dynamic descriptor effect can be emulated to some extent, the approach doesn’t really allow to have a unique descriptor of every single transaction processed.
Examples of ACH transaction groups to be marked with unique descriptors are: utility payments, recurring dues, club membership dues, etc.
Descriptors for aggregators and payment service providers
Dynamic ACH and credit card transaction descriptors are particularly important for businesses, that use aggregation model. The reason is that dynamic descriptors allow aggregators and payment service providers to specify which of their merchants originated a given transaction (or batch). In such cases the following descriptor format is used:
[Aggregator name (up to 6 digits)]*[sub-merchant company name]
Here are some common descriptor formats and examples.
PSP*convenient store NY
Best clothes*jeans black
It is preferable for businesses (especially, for those using subscription-based or aggregation revenue models) to cooperate with credit card processors and payment gateways supporting dynamic descriptors.