Billing Descriptor Guide for Merchants

A billing descriptor is the short text that appears on a customer's card or bank statement next to a charge. It is the only information the card network passes through about who charged the customer and for what — no logo, no link to an invoice, just a short string. This guide is for sellers and merchants checking their own descriptor before customers see it. It does not decode an unknown charge on a cardholder's statement.

Last updated October 30, 2026. Rules below are taken from Stripe's statement-descriptor docs, Chargeflow's billing-descriptor guide, Chargebacks911's descriptor guides, and network reason-code references, all named at the end. Your processor's own limits can be stricter than the network cap — confirm the descriptor on file with your processor.

What a billing descriptor is

A billing descriptor — also called a statement descriptor or payment descriptor — is the identifying text that appears on a customer's credit or debit card statement for a purchase. It typically includes the business name, a description of the product or service, or both; some processors add a phone number, a website or a city as a second line. It is set by the merchant or the merchant's payment processor and passed through the card network to the customer's bank, which displays it with its own formatting rules. That is the whole channel: one short string, reformatted by a bank you do not control, read by a customer who may be looking at it weeks after the purchase.

When the line does not match anything the customer remembers — a legal entity name instead of the storefront name, a brand cut to a fragment, an abbreviation that reads as a random code — the customer's next step is often the bank's dispute button rather than your support page. Chargeflow's billing-descriptor guide puts it plainly: shoppers dispute charges they do not recognise, and a clear descriptor is what lets them link the charge to the right order instead.

The rules: 22 characters, 5 minimum, Latin only

Stripe's statement-descriptor documentation, the most concrete processor reference available, sets the shape of the field:

A descriptor that breaks one of these rules does not fail loudly. Checkout still succeeds, and the network either rejects the descriptor or silently rewrites it into something the customer has even less chance of recognising. That silent failure is the reason to validate before launch rather than after the first dispute cluster arrives.

DBA*description format: the anatomy of one statement line

A dynamic descriptor has two parts joined by an asterisk and a space. Chargeflow's guide works the anatomy with Stripe's own example: RUNCLUB* OCT MARATHON, 21 of 22 characters. The prefix is the brand or DBA name; the suffix is the per-transaction detail — a plan name, an order detail, a date.

The budget math is where merchants go wrong. A 12-character prefix plus the 2-character separator has already spent 14 of 22 characters before the suffix starts, leaving 8 for the product or plan name. A suffix like "PROFESSIONAL PLAN" does not fit, and the network truncates it without warning — which is how a customer ends up staring at a fragment and concluding the charge is unfamiliar. Put the recognisable brand in the prefix, keep the prefix short, and spend the remaining characters on the one detail that helps the customer place the order.

If you sell one product, a plain static descriptor — one consistent label on every transaction — is simpler and avoids the prefix budget entirely. Dynamic descriptors earn their complexity only when you sell multiple products and the per-transaction detail genuinely helps recognition.

The 15-character safe zone: why 22 is not the real target

Processors may claim 25 characters, but issuing banks frequently truncate descriptors to 15 to 22 characters, and digital wallets can append their own prefixes that push a brand name off the screen. Chargebacks911's descriptor guides therefore recommend a "global safe zone" of 15 characters or less, and note that keeping a descriptor within 15 to 18 characters survives even the most restrictive banks.

That is the difference between the validator's three verdicts. A descriptor that fits 22 characters but exceeds 15 is not broken — it is exposed: fine at most banks, cut at strict ones. A descriptor of 15 or fewer characters with no other flags is the only kind that survives every bank intact. When a long DBA name brushes against the limits, Chargebacks911's fix is a three-step shortening: cut corporate suffixes (LLC, Inc., Corp.), delete filler words ("The", "A", "For"), then strategically shorten what remains — and run the result past strangers before shipping it, because an abbreviation that is obvious inside your company ("TACRC LLC", vowel-dropped fragments) reads as spam outside it.

The reason codes a confusing descriptor invites

When a customer cannot connect a statement line to a purchase, the dispute is usually filed as fraud, not as a billing question. The codes to watch:

Two hedges matter. First, a confusing descriptor does not "cause" a code by itself: the issuer assigns the code from the cardholder's claim, and the descriptor is the evidence the cardholder could not recognise the charge. Second, a clear descriptor does not prevent fraud disputes and does not decide any case. What it removes is the commonest honest reason a customer reaches for the dispute button instead of your support page — and honest confusion is the volume you can actually control.

This guide states no percentage for descriptor-driven disputes. A vendor claim that a large share of disputes trace to vague descriptors circulates online, but it is a single vendor's claim, not a measured network statistic, so it is not repeated here as fact. What the sources do support is the qualitative claim: unrecognised descriptors are a commonly cited trigger for "I don't recognise this charge" disputes, and descriptor clarity is a standard first item in merchant prevention checklists.

Support phone and city: a second line, not part of the 22

Some processors add a second line after the descriptor — a city or a support phone number, up to 11 extra characters in network summaries — and Chargeflow recommends adding a support phone or short URL where the processor allows it. The qualifier is the whole point: not every processor supports a phone or city line, and the line is separate from the 22-character descriptor itself. Ask your processor whether one is supported on your account, and never invent a phone number for a check or a listing. A phone line helps only if the brand is already recognisable; it cannot rescue a descriptor that arrives cut to a fragment, and a customer who cannot match the brand will not know which number to trust anyway.

Testing your descriptor: the stranger test and the live test

No validator can do the two checks that matter most, because both need real eyes and real banks. Chargebacks911's descriptor guides lay out the routine:

1. Run the stranger test.

   Show the descriptor to five people who do not know your internal operations and ask: "If you saw this on your credit card statement, would you know it was us?" If they hesitate, pick a different name. This catches the abbreviations and legal-entity names that look obvious inside the company and opaque outside it.

2. Run a live test transaction.

   Charge a real card, then view the statement line on statements from more than one bank and on more than one device. Display varies by issuer — what your bank shows is not what every customer's bank shows — and digital wallets may add prefixes of their own.

3. Search the descriptor exactly as it appears.

   Type the statement text into a search engine exactly as it appears, including asterisks and spacing, with and without quotation marks. A confused customer's first instinct, short of the dispute button, is to search the line. If your website is not among the top results, the customer may conclude the charge is fraudulent and dispute it.

4. Confirm what your processor has on file.

   A processor-side default can override what you typed in a dashboard. Verify the exact descriptor on file, and keep a central list if you run multiple merchant accounts — each MID can carry a different descriptor, and branding updates need to reach all of them.

5. Re-test after every rebrand or processor change.

   Descriptors are not a one-time task. A rebrand, a new product line, or a processor migration can silently change what customers see. Review the descriptor whenever the business, products or processor change, and watch for spikes in "unrecognised charge" support contacts or dispute alerts as the early warning.

Merchant descriptor checklist

Use this list before any descriptor goes live, and again after every rebrand:

1. Brand first.

   The customer-facing storefront or product name, not the legal entity name.

2. 15 characters or fewer where possible.

   22 is the cap, 15 is the target that survives strict banks.

3. DBA prefix of 2 to 10 characters.

   If you use DBA*description format, the prefix budget decides everything downstream.

4. No legal suffixes, no leading filler.

   Strip LLC, Inc., Corp. and leading "The" before counting characters.

5. No order numbers inside the descriptor.

   Long digit runs read as reference codes, not brands.

6. Stranger test passed.

   Five strangers, no hesitation.

7. Live test viewed at more than one bank.

   Display varies by issuer; one bank's rendering proves nothing.

8. Processor file confirmed.

   The descriptor on file matches the descriptor you validated.

Guide questions

Sources (checked October 30, 2026): Stripe — "Set statement descriptors for connected accounts" (only the first 22 characters sent for card payments; static prefix 2 to 10 characters; asterisk and space concatenate prefix and suffix and count toward the 22); Chargeflow — "Billing Descriptor: Examples, Rules and Chargeback Fixes" (descriptor anatomy RUNCLUB* OCT MARATHON at 21 of 22; support phone or short URL if the processor allows it; descriptor should match the storefront name); Chargebacks911 — "How to Test Your Statement Descriptors" (banks truncate differently; test transactions across banks and devices; Google-searchability test), "How to Set Up & Update Your Statement Descriptor" (DBA name, 15-character global safe zone, strip Inc./LLC/Corp. and "The", stranger test), and "Troubleshooting Statement Descriptors" (Visa 10.4 and Mastercard 4837 as the codes to watch when a descriptor is the suspect; 15-to-18-character strict-bank range); Recurly — "Payment descriptors" (Prefix*Suffix shape, 22-character total); Ecommpay — "Using dynamic merchant descriptor" (Mastercard maximum 22, Visa 25, Latin alphabet plus space and listed symbols); network reason-code references — Rapyd, Dodo Payments, Disputifier, Chargeflow's evidence matrix and Solidgate (Mastercard 4863 = Cardholder Does Not Recognize — Potential Fraud; Visa 10.4 = Other Fraud — Card-Absent Environment, with an unclear or confusing merchant descriptor explicitly listed as a cause). No vendor dispute percentage is stated in this guide: the circulating vendor percentage is a single vendor's claim, not a measured network statistic.

Built by Chargeback Clock — Meet the Founder.

← Back to the Billing Descriptor Validator · For Business — merchant tools & guides