Descriptor
What is a descriptor?
Descriptor is the text label shown on a 's card or bank statement to identify a purchase and the merchant behind it. It usually combines the merchant's business name with a contact detail or a short reference to the goods or services bought.
Merchants set their descriptor when opening an account with a or , and it then attaches to every card charge routed through that account. Because it's often the only detail a cardholder sees when scanning a statement, the descriptor is what turns an anonymous line item into a recognizable purchase.
Key facts
- Also known as: statement descriptor, merchant descriptor, payment descriptor, or transaction descriptor; closely related to the stored and sent for billing.
- What it includes: the merchant or name, a contact detail such as a phone number, URL, or city, and often a short product or order reference.
- Types: static (the same on every charge) and dynamic (changes per transaction).
- Set by: the merchant, configured through the payment processor or acquirer at account setup.
- Length: capped by card network and processor rules, which differ by provider, so long brand names are often shortened.
- Applies to: card payments across networks, on both one-off and recurring charges.
What a descriptor contains
A descriptor is short and length-limited, so merchants compress the essentials into a compact string. A common format puts a company prefix first, then an asterisk, then a product or service identifier – for example a brand name followed by the specific subscription. The field can also carry a customer-service phone number, a website, or the billing city, giving the cardholder a way to check a charge before disputing it.
- Brand only (fictional brand): BRIGHTLY APP
- Brand plus product: BRIGHTLY*PREMIUM ANNUAL
- Brand plus contact: BRIGHTLY.COM 8005550100
- Facilitator prefix plus seller: a short code for the , an asterisk, then the seller's name, used when one provider processes payments on behalf of many smaller merchants.
Static and dynamic descriptors
Descriptors come in two forms. A static descriptor stays the same on every statement, showing the merchant's registered name whatever was bought. A dynamic descriptor changes per transaction to reflect the specific purchase, so a marketplace or subscription business can display the seller name or the exact product a cardholder paid for. Dynamic descriptors cut "I don't recognize this charge" disputes on accounts that sell many different items under one account.
Some processors call the fixed, account-level part the hard or primary descriptor, and the per-transaction text appended to it the soft descriptor. Terminology varies by processor, so the same field can appear under different names in different payment APIs.
Pending and posted descriptors
The text a cardholder sees can change between and . While a charge is pending, the statement shows the merchant details sent with the authorization request; once the transaction settles, the posted entry uses the details sent in the clearing record. When the two differ, a pending charge and the final line item read slightly differently even though they're the same purchase.
Why a descriptor can look unfamiliar
A charge looks unfamiliar when the name on the statement differs from the name the cardholder remembers from checkout. The causes are structural:
- Legal entity instead of brand: the account is registered under the company's legal name rather than its trading name. Registering a DBA name with the acquirer lets the statement show the brand instead.
- Third-party seller of record: when a or payment facilitator processes the payment, its name or prefix appears alongside or instead of the brand the cardholder bought from.
- Truncation: length limits cut long brand or product names, so the statement shows an abbreviation.
- Bank-side formatting: apps that enrich transaction data replace the raw descriptor with a cleaned-up merchant name and logo, so the same charge can read differently in the app and on the paper statement.
- Delayed renewals: on , a renewal posts weeks or months after signup, when the cardholder no longer connects the descriptor to the original purchase.
Descriptor vs billing descriptor
"Descriptor" and "billing descriptor" are frequently used to mean the same thing. The distinction is one of scope: billing descriptor points to the formatted string as it's configured and sent for billing, while descriptor is the broader label the cardholder reads on the statement. For how that string is formatted and configured, see .
Why it matters
- An unrecognized descriptor feeds : a cardholder who can't match a charge to a purchase files a instead of contacting the merchant, and the merchant then has to fight or absorb it.
- A clear descriptor lets the cardholder self-serve – recognizing the charge, using the phone number or URL it carries, and resolving a question with the merchant directly rather than through their bank.
- Consistent descriptors help cardholders and finance teams statements, matching each line item to an order without guesswork.
- Every chargeback filed over an unrecognized descriptor counts toward the merchant's , which card networks track against monitoring-program thresholds.
