Your Statement Descriptor Has 22 Characters. Getting It Wrong Is Costing You Real Disputes.

Somewhere in your Stripe dashboard is a text field with a 22-character limit that nobody on your team has looked at since the day the account was created. It's probably still set to whatever the person who signed up for Stripe typed in — a shortened legal entity name, a placeholder, or whatever autofilled from your business registration. Nobody treats it as a product surface. It's the single line of text standing between a legitimate renewal charge and a customer who doesn't recognize their own subscription.

Our chargebacks and disputes guide and our pre-renewal reminder guide both mention a clear billing descriptor in passing, as one line among several. Neither goes into what the descriptor field actually does under the hood, where it breaks, or how to audit it properly — which is a gap, because it's one of the few dispute triggers you can fix once, in a dashboard setting, with zero engineering time and no ongoing maintenance.

What a statement descriptor is actually doing

A statement descriptor isn't decorative. It's the only information a card network passes through to a cardholder's statement about who charged them and for what. There's no logo, no supporting context, no link back to an invoice — just a string of up to 22 characters, and whatever a bank's own statement formatting does to it after that. Stripe caps the field at 22 characters, disallows the characters <, >, ', ", and *, and won't accept a descriptor made up entirely of numbers. Those aren't arbitrary restrictions — they're the intersection of what Visa, Mastercard, and the other networks will actually pass through unmodified. Send something outside those rules and a network will either reject the charge or silently rewrite the descriptor to something your customer has even less chance of recognizing.

The distinction between the two per-charge fields matters more than most teams realize. statement_descriptor looks like the more direct option — set it and the whole descriptor changes for that charge. But several card networks won't actually display a fully custom descriptor on a card payment; they'll silently fall back to whatever static prefix is on file for your account, which means the override you set never reaches the customer at all. statement_descriptor_suffix works differently and more reliably: it appends dynamic text to your existing account prefix, with an asterisk and a space inserted automatically to separate the two. Those two characters count against your 22-character budget, and Stripe reserves roughly 10 characters for the suffix once your prefix, the asterisk, and the space are subtracted — so a prefix any longer than about 10-12 characters leaves you with almost nothing to work with on the dynamic side.

Do the character math before you pick a prefix

This is the part almost nobody does, and it's why so many statement descriptors end up truncated into gibberish. If your account prefix is ACMESOFTWARE — 12 characters — plus the automatic * separator, you've used 14 of your 22 characters before the dynamic suffix even starts. That leaves 8 characters for a plan name, an order number, or anything else you wanted a customer to recognize. PROTIER fits. PROFESSIONAL PLAN does not, and Stripe will truncate it without warning, which is how a customer ends up staring at ACMESOFTWARE * PROFES on a bank statement and concluding it's unfamiliar enough to dispute.

The fix isn't complicated, but it does require actually sitting down and counting characters instead of typing your company name and moving on. Pick the shortest recognizable version of your brand — an abbreviation customers would still recognize, not your full legal entity name — and leave yourself enough suffix budget to fit a real plan identifier. ACME at 4 characters plus the 2-character separator leaves 16 for the suffix, enough for PRO MONTHLY or an order reference a support agent could actually look up.

Why a mismatch turns into a dispute instead of a support ticket

A confusing descriptor wouldn't matter much if customers reliably checked with the merchant before disputing. They don't. Chargebacks911's 2025 Cardholder Dispute Index, based on a survey of more than 1,200 cardholders across the US and UK, found that a large majority of cardholders — over three in four — prefer to go straight to their bank rather than contact the merchant when a charge looks unfamiliar. That's a rational choice from the cardholder's side: a bank dispute form is faster than finding a merchant's support email, and the cardholder bears none of the cost either way. It's an expensive one from yours. Once a dispute is filed instead of a support ticket, you're into the mechanics covered in our chargebacks guide — a flat $15 fee regardless of outcome, a 7-21 day evidence window, and a fraud-coded dispute that wins at roughly a third the rate of a customer-error dispute, because the network defaults to protecting the cardholder unless your evidence is airtight.

The asymmetry is what makes the descriptor worth fixing before anything downstream of it. Winning a dispute after it's filed takes evidence gathering, a submission within a strict window, and still only a partial win rate. Preventing the dispute from being filed at all costs nothing beyond getting the character count right once.

Where descriptors go wrong that isn't just "too long"

That last row matters more than it used to. As merchant-of-record and payment-facilitator setups spread — the kind our Stripe Managed Payments piece covers — more SaaS businesses are running billing through an intermediary whose name, not theirs, legally has to appear on the statement. If that's your setup, the descriptor fix described above doesn't fully apply to you; the mitigation has to happen in your own communications instead, since the network requires the entity actually moving the money to be identifiable on the statement.

How to actually audit yours

Most teams have never seen their own statement descriptor the way a customer does, because nobody on the team pays for the product with a personal card. Fixing that takes fifteen minutes:

1. Check the current setting. Dashboard → Settings → Business settings → Public details → Shortened business name (statement descriptor). Note exactly what's there today, character for character.
2. Run a real test charge. Use a card you personally control — a virtual card or your own account — for a small live charge, and check what actually posts to the statement a day or two later. The dashboard preview isn't always what the issuing bank displays; formatting varies by bank, and this is the only way to see the real output.
3. Count the suffix budget. Subtract your prefix length and 2 characters for the separator from 22. If what's left can't fit a recognizable plan name, shorten the prefix.
4. Check every product line separately if you run more than one under a single Stripe account. A generic company-wide descriptor is the single most common cause of "which subscription is this" confusion in multi-product businesses.
5. Re-test after any rebrand, legal entity change, or new product launch — this is the step almost every team skips, because updating the descriptor isn't anyone's job by default.

Where this fits with the rest of your dunning stack

A clean statement descriptor doesn't touch involuntary churn from failed payments at all — that's a completely separate mechanism covered in our Stripe dunning guide, and no amount of descriptor cleanup will recover a card that's actually expired or out of funds. It also won't stop every dispute; a customer who's angry about a price increase or who genuinely forgot to cancel will still file one regardless of what the statement says. What it removes is one specific, avoidable trigger sitting upstream of both your dispute rate and your dunning email deliverability — because a customer who doesn't recognize the charge that failed is even less likely to trust the recovery email that follows it.

If you're already tracking how much of your reported churn is coming through disputes rather than your cancellation flow, our churn calculator is a fast way to see what even a modest drop in dispute-driven involuntary churn is worth before you spend engineering time on anything bigger. And for the subscribers whose statement was never the problem — who recognized the charge just fine and simply want out — that's exactly what a real cancellation flow exists to capture, cleanly and on your terms, instead of routing them to a bank dispute form because your cancel button was harder to find than your support inbox.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.