Billing Descriptors: Rules, Examples, and How to Stop 'I Don't Recognize This Charge' Chargebacks

A customer opens their banking app, sees a charge under a name they do not recognize, and taps Dispute. Nothing about the sale was wrong. The product shipped, the price matched the checkout page, and the only problem was the line on the statement: it showed the name on your incorporation papers instead of the name on your storefront. Visa's Merchant Data Standards Manual calls the merchant name "the most important factor in cardholder recognition of transactions," and it is the one part of a transaction most merchants have never looked at from the cardholder's side.

This guide covers what the descriptor is, what to put in it, examples that meet the rules, what changes under a payment facilitator or a subscription, how descriptors drive chargebacks, and how to audit yours — current as of Visa's April 2026 manual and Mastercard's June 2024 Transaction Processing Rules.

What is a billing descriptor?

A billing descriptor is the set of fields your acquirer sends in the authorization and clearing records for every transaction: the merchant name, the merchant city, and the state or country. The issuer prints that data on the statement, shows it in the banking app, and pushes it in purchase alerts. It is not one field, and it is not something the issuer invents — Visa obliges issuers to pass it through. A December 2020 reminder to acquirers cites a rule (ID 0004080) requiring the issuer to include on the billing statement the clearing-record data that identifies the merchant, or the sponsored merchant and its payment facilitator, and that enables the cardholder to contact the merchant.

In the name field, Visa's authorization and clearing systems provide 25 characters, and acquirers are required to be able to use all 25. Many platforms give you fewer: Stripe sends only the first 22 characters of a statement descriptor for card payments and requires the whole string to be between 5 and 22. If your processor caps you at 22, plan around 22. The city field carries 13 characters, and for card-absent transactions Visa says it must contain the merchant's customer service telephone number, URL or email address rather than a city. That is the field that lets a cardholder find you before they find the dispute button.

One caveat: the issuer controls what the cardholder finally sees. Stripe's documentation notes that most banks display the information consistently, but some display it incorrectly or not at all. A good descriptor lowers your dispute rate; it does not guarantee a particular rendering.

What should I put as my statement descriptor?

Put the name the customer saw when they bought, not the name on your bank account. Visa's wording is that the merchant name "must be the name most prominently displayed by the Merchant and by which cardholders recognize the Merchant," while also reflecting the doing-business-as name. Its 2020 reminder adds the part merchants most often get wrong: the legal or company registration name should not be used if it is not also the name presented to and recognized by the cardholder in-store or online. Mastercard's Transaction Processing Rules likewise require the DBA merchant name on receipts, taken from the same acceptor name field the statement uses.

The same logic answers the broader question of what to write in a payment description: your stable, recognizable name to the left of the asterisk, a per-transaction detail such as an order or reference number to the right of it, and — for card-absent sales — a phone number, URL or email in the city field so the cardholder can reach you from the statement itself.

Visa then requires that name to be used consistently, including spelling, everywhere it appears: the receipt, the authorization request, the clearing record, and every dispute and pre-arbitration record. It "must not be modified or periodically changed, for example, to mask its identity from any compliance programs." For a high-risk merchant that sentence matters more than any other in this guide. The network monitoring programs count disputes per merchant, and a merchant running slightly different descriptors on different MIDs to keep each one under a threshold is doing exactly what the rule names. Acquirers look for the same pattern when they investigate transaction laundering, and treat it the same way.

There is one situation where Visa asks you to add to the name rather than shorten it: when the merchant name is inconsistent with the merchant category code, the descriptor must carry extra information identifying the type of business. A supplement brand with a single abstract word for a name, or a coaching business named after its founder, is in this position — recognizable on the checkout page, a stranger on a statement.

Billing descriptor examples

The networks publish worked examples, and they are the fastest way to see the rules in practice.

• Abbreviating a long name. Names longer than 25 characters, counting spaces and symbols, must be abbreviated — abbreviated, not cut off after the 25th character. Visa's worked example is NEW YORK HOME HARDWARE DISTRIBUTORS, 35 characters, shortened to "N Y HOME HARDWARE DISTR." or "NEW YORK HOME HDW DISTR." The common words get compressed; the part that uniquely identifies you survives intact.
• Adding a category word. Visa's examples for a name that does not match its category code: a parking garage still called John's Farm must appear as "John's Farm Parking," and a restaurant named Ship Chandler as "Ship Chandler Restaurant."
• A dynamic descriptor. A static prefix, an asterisk, then a per-charge suffix: "RUNCLUB* OCT MARATHON." On Stripe the prefix is 2 to 10 characters and the whole string is capped at 22, so a prefix of RUNCLUB leaves 13 characters for the suffix.
• Instalments. Visa requires the instalment count (1 of 2, 2 of 2) after the asterisk. Mastercard's example puts "PYMT 2 of 4" at the end of the acceptor name field.
• Invoiced recurring bills. Mastercard recommends the merchant name followed by the word BILL and the bill reference number.
• A domain as the descriptor. Acceptable only if it clearly and accurately describes the transaction on its own. If customers know you by your domain, the domain is legitimate. If your domain is a generic phrase, it is not.

Character rules matter too. Stripe's are a useful proxy for what most modern gateways enforce: Latin characters only, at least one letter, none of the characters < > \ ' " or *, and a descriptor that reflects the DBA name and contains more than a single common term.

Dynamic descriptors and what the asterisk means

A static descriptor is the same on every transaction. A dynamic descriptor, sometimes called a soft descriptor, keeps a fixed prefix and adds something specific to the charge. Visa permits this for purchases of goods or services: additional information may follow the merchant name and an asterisk to indicate an order number, reference number or other information identifying the transaction. The one case where the addition is mandatory is instalments.

The asterisk is not decoration. Visa's 2020 reminder describes it as the separator between an acceptance entity and the underlying seller — the same character that separates a payment facilitator from its sponsored merchant — so everything to the left of it should be your stable, recognizable name. For supplementary text that is part of the name itself, such as a location or store number, Visa's manual says it must be static and appear in all transactions, and its only named exceptions are airline ticket numbers and the words No Show; per-transaction items such as an order number after the asterisk are permitted separately by the manual's table. If you add a store number for one outlet, every outlet must carry the same kind of information.

Other gateways implement the same idea under different parameter names; ask yours what the prefix limit is before you design suffixes around it. One group is excluded entirely: Visa's manual says acquirers must prohibit their agents from using dynamic descriptors for gambling merchants.

Who is allowed in the name field, and who is not

Visa's reminder draws a hard line. Payment facilitators, staged digital wallets and bill-payment aggregators are required to identify themselves in the name field, separated from the seller by an asterisk. Everyone else in the chain is prohibited from appearing: the reminder names pass-through digital wallets, third-party agents, gateways, processors, independent sales organizations, merchant services providers and software platforms, and adds that the field must not carry anything unrelated to the transaction, such as marketing statements. If your gateway or ISO's brand shows on your customers' statements and you are not a sponsored merchant of a registered payment facilitator, that is a setup error your acquirer should fix.

For merchants who sell through a payment facilitator, Visa's April 2026 manual gives the facilitator a choice: the sponsored merchant's name alone, or the facilitator's name or abbreviation, an asterisk, and the sponsored merchant's name — and it "should choose the name that is the more recognizable to the cardholder." The facilitator's name becomes mandatory in one case: when a cardholder starts on the site or app of a merchant that is not high-risk and is forwarded to a high-risk internet payment facilitator to pay. Marketplaces follow the same pattern, using the marketplace name alone or marketplace-asterisk-seller. Mastercard likewise expects the aggregator's name ahead of the sub-merchant's name.

This is why merchants on aggregated platforms sometimes cannot get the descriptor they want. On Stripe Connect, whether the statement shows the platform's descriptor or the connected business's depends on how the platform structured the charge. If the descriptor is costing you disputes, the fix usually runs through the platform, not your own settings, and owning the field outright is one practical reason growing merchants move to a dedicated merchant account.

Subscriptions and free trials

Visa's June 2019 bulletin announcing its April 2020 subscription rules said an additional descriptor indicating a trial-period transaction, such as "trial," "trial period" or "free trial," would be required in the merchant name field for the first transaction at the end of a trial. Visa's April 2026 Merchant Data Standards Manual lists that supplementary language, with examples like "End Trial," "End Free Trial" and "End Discount," as optional rather than required, allows a URL or order number in its place, and also permits it in the city field for card-absent transactions. Since the two documents differ, treat adding the trial marker as the safe choice and confirm with your acquirer. What the 2020 rules unambiguously require is the reminder: an electronic notification with a link to online cancellation at least seven days before the first charge after a trial, introductory or promotional period ends, and again whenever the price or billing period changes.

Mastercard's negative option billing rules take a different route to the same place. For digital goods with a trial longer than seven days, the merchant must send a reminder no less than three and no more than seven days before the trial ends. For physical products, after the trial has expired the merchant must present the cardholder with, and obtain explicit consent to, the subscription start date, the amount, the payment date, cancellation instructions, and "the Merchant name as it will appear on the Cardholder's statement," before the first full-price recurring charge is authorized. The same rule requires the acquirer to process every later recurring transaction with the same merchant ID and the same merchant name as the initial transaction. A subscription merchant that changes its descriptor mid-relationship is not just confusing customers; on Mastercard physical-goods trials it is breaking a rule. These requirements are one reason subscription businesses in hard-to-place industries run on merchant accounts built for recurring billing rather than general-purpose aggregators.

How descriptors cause chargebacks — and how to cut them

A descriptor-driven dispute is friendly fraud: the cardholder authorized the sale and simply did not recognize it afterward. That is the dispute category a high-risk account can least afford, because every one of those disputes counts toward the network monitoring thresholds whether or not you later win it. If you want the mechanics of what happens after the cardholder taps Dispute, see how a chargeback moves from the cardholder's dispute to your account — and note that the window a cardholder has to dispute a charge runs long past the sale, so a confusing statement line keeps generating disputes months after the transaction cleared.

The fixes cost nothing to implement, which makes the descriptor the cheapest item on any list of ways of stopping chargebacks before they are filed: a name that matches the storefront, a phone number in the city field for card-absent sales, a stable prefix on dynamic descriptors, and a trial reminder that quotes the statement name. Services such as Visa's Order Insight (through Verifi) and Mastercard's Ethoca Consumer Clarity can push a fuller digital receipt into the banking app when a cardholder questions a charge, but they sit on top of the descriptor, which is still what appears in the alert and on the statement.

How to audit your descriptor in an afternoon

Most merchants have never seen their descriptor as a customer sees it. The audit takes an afternoon.

1. Ask your processor for the exact merchant name, city and state values on file for every MID you hold, including any on a separate gateway or platform, as sent in clearing rather than as labelled in your dashboard.
2. Run a real transaction on your own card through every checkout you operate, then look at it in your banking app, in the transaction alert, and on the statement.
3. Compare what you see against the name in your website header, on the checkout page, on the order confirmation email and on the packing slip. Visa's rules require the website, the receipt and the transaction records to carry the same name, spelled the same way; the email and packing slip should match it too.
4. Check the city field on card-not-present MIDs. If it holds a city rather than your customer service telephone number, URL or email, Visa's card-absent rule is not being met and the cardholder has no way to reach you from the statement.
5. If the name field carries a gateway, ISO or software vendor's brand and you are not a sponsored merchant of that entity, raise it with your acquirer as a compliance issue. If your brand name says nothing about what you sell, add a category word as Visa's John's Farm Parking example does, and keep it identical on every transaction.
6. For subscriptions, confirm the trial-end reminder goes out on the network's timetable, that it names the merchant exactly as it will appear on the statement, and that no MID or descriptor change happens between the trial and the recurring charge.

Getting the descriptor right from the first transaction

The descriptor is set when the account is set up, and it is far easier to configure correctly then than to repair after the disputes start. We work with high-risk merchants on how their merchant accounts are structured, including how the descriptor is configured before the first transaction runs. If you are on an aggregator that will not release the field, or you run multiple MIDs and are not sure the names on them match, contact us and we will address it.