Billing descriptors: the cheapest chargeback prevention
How the text on a customer's card statement causes or prevents chargebacks: Stripe and Braintree descriptor rules, character limits and subscription examples.
A customer looks at their card statement, sees a line they do not recognize, and taps “dispute” in their banking app. The bank files it as fraud. For a subscription business, this is one of the most common ways a perfectly valid charge becomes a chargeback, and the fix costs nothing: change the text on that line.
That text is the statement descriptor (also called billing descriptor or soft descriptor). This guide explains what it is, the rules on Stripe and Braintree, how to write a good one for subscriptions, and what else helps customers recognize a charge. Sources: Stripe’s statement descriptors, what is a statement descriptor, why customers see descriptors that don’t match and account checklist; Braintree’s descriptors and Transaction: Sale reference; and Visa’s revised enhanced descriptor policy (all accessed November 2026).
Why descriptors cause disputes
The descriptor is often the only information a customer has about a charge when they look at their statement. Three situations produce “I don’t recognize this” disputes:
- The descriptor shows the legal entity, not the brand. “ACME HOLDINGS LTD” means nothing to someone who subscribed to “Planwise”.
- One company, several products. If you run three apps under one account and all charges show the same name, customers cannot tell which subscription they are paying for.
- The charge comes long after signup. An annual renewal arrives eleven months after the customer last thought about you. A clear name is the only reminder.
These disputes usually come in as fraud (Visa 10.4, Mastercard 4863 “cardholder does not recognize”). Even if you win them, they count toward your network dispute ratios. Preventing them is much cheaper.
The rules on Stripe
Stripe’s statement descriptor docs set these limits for card payments:
| Rule | Limit |
|---|---|
| Total length | 5 to 22 characters |
| Characters | Latin characters only; at least one letter |
| Forbidden characters | Angle brackets, single and double quotes, and the asterisk |
| Content | Must reflect your business name (DBA), URL or legal name; cannot be only numbers |
Prefix and dynamic suffix
Stripe lets you combine a static prefix (called the shortened descriptor in the Dashboard) with a dynamic suffix per payment:
- The prefix is 2 to 10 characters.
- Stripe joins prefix and suffix with an asterisk and a space, and that separator counts toward the 22 characters. With a 7-character prefix, 13 characters remain for the suffix.
- Dynamic suffixes only work for card payments.
- Only the first 22 characters are sent for card payments; anything longer is cut.
For subscriptions, the suffix is where you put the product or plan: PLANWISE* PRO ANNUAL.
What the customer actually sees
Stripe’s support article on mismatched descriptors explains that some banks show a “friendly” merchant name instead of your descriptor, using several data points from the transaction, and that Stripe has no control over that mapping. Stripe’s account checklist adds that issuers may also show other account information, such as business name, address, email or phone number. Check that your public business details in your processor account (support phone, support URL) are ones you are happy for customers to see, and that they work.
The rules on Braintree
Braintree supports dynamic descriptors per transaction, but they are not enabled on every account by default. Its Transaction: Sale reference describes the name format:
| Company part | Product part | Total with asterisk |
|---|---|---|
| 3 characters | up to 18 | 22 |
| 7 characters | up to 14 | 22 |
| 12 characters | up to 9 | 22 |
Braintree also documents a phone and a URL field for descriptors, and notes that the exact length and character rules depend on your processor, and that some processors accept a URL while others accept only a phone number. Check your account settings before relying on a format.
What a good subscription descriptor looks like
Principles
- Lead with the name customers know. The brand in your app, emails and app icon, not the holding company.
- Add the product or plan when you have room. Especially if you sell more than one product or have monthly and annual plans.
- Keep it readable. Avoid abbreviations nobody would guess.
- Be consistent. Use the same descriptor in reminders, receipts and help center articles, so a customer who searches for it finds you.
Examples
| Weak | Better | Why |
|---|---|---|
ACME HOLDINGS LTD |
PLANWISE* PRO MONTHLY |
Brand and plan instead of legal entity |
AHL*SUB 88213 |
PLANWISE* TEAM ANNUAL |
No internal codes |
PLANWISE |
PLANWISE* RENEWAL |
Signals a recurring charge |
WWW.PLNWS.IO |
PLANWISE.COM |
A domain the customer can type |
Make sure each example fits your processor’s character rules; the asterisk in these examples is Stripe’s separator, not a character you type into the prefix.
Trials
When a free trial converts, the first charge is the most likely to surprise. Visa once required an enhanced descriptor for that first charge after a trial; its revised policy (December 2020) made it optional. Even if optional, a suffix such as TRIAL END or FIRST CHARGE on that payment helps, if your processor lets you set a per-payment suffix. Visa’s trial rules still require a reminder with a cancel link at least seven days before that charge.
Tell customers what they will see
The descriptor works best when the customer has seen it before. Put it in:
- The checkout page: “This will appear on your statement as PLANWISE* PRO.”
- The welcome email and every receipt.
- Renewal and trial-end reminders. See annual plan renewal reminders.
- A help center article titled with the descriptor itself, so a customer who searches “PLANWISE PRO charge” finds it.
Stripe’s fraud prevention best practices also recommend telling customers on your site what they will see on their statement.
Check what it looks like
Do not assume. Make a real purchase on your own card for each product and plan, then look at:
- the pending transaction in your banking app;
- the posted transaction a few days later;
- the monthly statement.
Banks and apps display descriptors differently, and some replace them with a friendly name. If what you see is not what you set, contact your processor.
Measure the effect
After a descriptor change, compare over the following months:
- the share of disputes with “unrecognized” or fraud reason codes on existing customers;
- support tickets asking “what is this charge?”;
- inquiries and retrievals (on networks that still use them).
Disputes arrive weeks after the charge, so give it at least two billing cycles before judging.
Descriptor checklist
- Brand name customers know, not the legal entity.
- Product or plan suffix where supported.
- Within your processor’s length and character rules.
- Public support phone and URL set and working.
- Descriptor shown at checkout, in receipts and reminders, and in the help center.
- Tested on a real card.
- Separate descriptor per product if you sell several.
For the rest of the prevention plan, see how to prevent chargebacks on subscriptions.
Doing this with NoChurn
NoChurn does not set your descriptor; that stays in Stripe or Braintree. What it does is show each dispute with its reason, so you can see whether “unrecognized” and fraud disputes drop after you change it, and gather evidence automatically when a dispute still arrives (cancel flow answers, emails sent, usage you send by API, help desk conversations read only), with an AI-drafted reply that a person reviews before it is sent. See chargebacks.