Statement Descriptor: Requirements by Processor and Chargeback Risk
A statement descriptor is the business name and reference text your payment processor prints on a customer's statement next to a charge. That text is the only clue most customers get about who charged them.
I lowered my own chargeback rate before I ever touched a dispute, by fixing the billing descriptor and turning on alerts. Descriptor confusion was the top support topic across 616 of our tickets in 12 months, and the cheapest chargeback is the one the customer never files. When you get the descriptor right, customers spot the charge on sight and never wonder what it is.
Key takeaways
- Keep your full descriptor between 5 and 22 characters on Stripe.
- Set the customer-facing name on Shopify between 2 and 19 characters.
- Expect banks to cut an over-long descriptor short with no error shown.
- Roughly 48% of US and UK cardholders have skipped the merchant entirely.
- Descriptor mismatches drove 616 support conversations in 12 months, the largest topic.
- Match your enrolled descriptor to the live one exactly, or alerts won't fire.
Recognizable charges stop some disputes, and chargeback alerts catch the ones customers still file.
What is a statement descriptor?
A statement descriptor is the text that identifies your business on a customer's card statement. Billing descriptor, statement descriptor, and account descriptor are three names for that same text. It's a business name plus a short reference code, printed next to the charge. Processors set their own character limits, and 5 to 22 characters is the standard range.
A descriptor the customer doesn't recognize is one of the most common reasons a purchase turns into a chargeback instead of a ticket.
Your processor builds the text out of what you type into your dashboard. You choose the business-name part, and some processors add a per-transaction detail like an order number or a support phone number.
The whole string has to clear three requirements:
- Character count. It has to fit your processor's fixed limit.
- Character set. Stripe accepts Latin characters only, at least one letter, and none of < > \ ' " *.
- Business name. Stripe requires your Doing Business As name, so use the name customers know you by.
One detail catches merchants who use pre-dispute alerts.
Any edit counts as a brand-new descriptor when alerts try to match it, even one that looks cosmetic to you. Add a space or spell out an abbreviation, and the text you enrolled stops matching the charge. In our dataset, descriptors were the top support topic over 12 months. A mismatch like that was the usual cause.
Why an unclear descriptor causes chargebacks
A customer who can't recognize the descriptor has nobody to email, so the bank is the only place left to ask. Their phone call is what turns the sale into a chargeback rather than a support ticket.
Going to the bank first is already normal across every dispute reason. Chargebacks911's 2025 Cardholder Dispute Index surveyed more than 1,200 US and UK cardholders and found that 48.2% had disputed a charge without contacting the merchant first.
An unrecognizable charge removes the last reason to come to you instead. The customer has no brand name to search for and no support address to write to.
On your side, it looks like a chargeback that arrived with no warning. An unrecognized charge sits alongside the other chargeback reasons you can act on before a dispute lands.
A clean descriptor fixes one kind of dispute. It works on real customers who bought from you and couldn't place the charge. Friendly fraud and stolen cards need a different control, because those customers know exactly who charged them.
For the disputes customers still file, chargeback alerts tell you before the chargeback does, so you can refund inside the window.
Statement descriptor requirements by processor
Stripe and Adyen cap the customer-facing descriptor at 22 characters, and Shopify Payments caps it at 19. Every count in the table includes spaces and the asterisk:
Shopify keeps a second name you shouldn't confuse with the first. The payout statement name runs 5 to 22 characters and shows up on your own bank statement, so customers never see it.
Merchants miscount because they forget the prefix eats into the same 22 characters.
Take Stripe's own example. A RUNCLUB prefix uses 7 of the 22 characters, so you have 13 left for the suffix. The result reads RUNCLUB* 9-22-19 10K at 20 characters, per Stripe's statement descriptor docs. The asterisk and the space both count.
Go over the limit and nothing tells you. Checkout still succeeds, and the bank cuts the descriptor short on the way to the statement. It cuts from the end of your name, usually the part you needed most. A customer hunting for your full shop name reads a clipped version and starts guessing.
Types of statement descriptors
Statement descriptors are static or dynamic depending on whether the text changes, and soft or hard depending on whether the charge has settled. That makes four types you'll meet:
- Static descriptors. Fixed text, identical on every charge.
- Dynamic descriptors. A fixed prefix plus a per-transaction suffix.
- Soft descriptors. The temporary text shown while a charge is pending.
- Hard descriptors. The permanent text shown after the charge settles.
Customers get confused by each of these for a different reason.
1. Static descriptors
A static descriptor is one fixed string that appears on every charge you process. It shows your business name and nothing that changes from order to order.
Static text works for a business that sells one thing under one brand.
A customer with three charges from you sees three identical lines and has to guess which order each one was. Your brand name is recognizable, and every charge still looks the same.
2. Dynamic descriptors
A dynamic descriptor pairs a fixed business-name prefix with a suffix that changes per transaction. The order-specific detail goes in the suffix.
Spend the characters you have left on whatever helps the customer place the charge. An order number, a subscription name, or a date all work. A string like YOURSHOP* ORDER 4471 tells a customer who charged them and which purchase it was.
Stripe and Adyen both put an asterisk between the two halves, and that asterisk uses up one of your characters. Shopify Payments gives you one customer statement name with no prefix and suffix to split.
3. Soft descriptors
A soft descriptor is the temporary text a cardholder sees while a charge is still pending. It shows up in online banking within minutes of checkout, before any money moves.
The soft descriptor can also show a different amount than the final charge, because it reflects the authorization. The standard case is a restaurant that authorizes your bill before you add a tip. So a customer can react to a charge description days before the permanent one exists.
4. Hard descriptors
A hard descriptor is the permanent text that replaces the soft descriptor once the charge settles. Settlement usually takes a few days.
This is the text on the monthly statement, so it's what a cardholder reads when they review charges weeks later.
When the soft and hard versions differ, one purchase carries two descriptions, and customers ask which of the two charges is real.
What does "SP" mean in a merchant descriptor?
"SP" in front of a business name marks a charge that ran through a payment platform. It names the platform that routed the payment, and the merchant's own name follows it.
Shopify Payments is the prefix most cardholders have seen.
For years, SP* came before the store name on every Shopify charge, until Shopify dropped the prefix in 2022. Those charges now show whatever name the merchant set in their admin.
The same two letters still show up on charges routed through Stripe, including wallet payments through Google Pay or Apple Pay.
Your cardholders are the ones who have to work it out. Someone reading SP * YOURSHOP has to know to skip the prefix and read the merchant name after it.
If they search for "SP" instead, they find nothing.
So if your platform adds a prefix, your customer reads that prefix plus your name, and you control only the second half. Run a small live charge on your own card, then read the descriptor off your banking app once it posts.
Statement descriptor vs. payment reference number
A statement descriptor tells a customer which business charged them, while a payment reference number identifies one transaction. The two exist for different readers.
Your customers read the descriptor, so it's short and it leads with a brand name they'll recognize. A payment reference number, sometimes called an acquirer reference number or ARN, is a long string of digits. Your processor and the banks use it to pull up a single charge, and it stays attached to that charge through a dispute.
Support threads are where you reach for the reference number, because a generic descriptor can't tell two of a customer's orders apart. Pull the reference number from your dashboard and you know which charge they mean. If the dispute already has a reason code attached, look up what it means before you reply.
How to find your statement descriptor
You can read and edit your current descriptor in your processor's dashboard settings. Each of the three processors keeps it somewhere different:
- Stripe: Business settings.
- Shopify Payments: Payment settings.
- Adyen: Account settings in the Customer Area.
Read the live string off a real statement before you trust the dashboard field.
Where you’ll find your descriptor will vary by processor. See our Help Center guides for finding your statement descriptors.
1. Finding it on Stripe
Open your Stripe Dashboard, go to Settings, then Business settings. You'll find the full descriptor there, plus the shortened one Stripe uses as the prefix on card payments.
Set the shortened version yourself. Keep the most recognizable word of your brand in those 10 characters rather than the first 10 letters. If you leave it blank, Stripe cuts your descriptor down to fit and picks where to cut.
2. Finding it on Shopify Payments
In your Shopify admin, go to Settings, then Payments, then Manage under Shopify Payments. The customer billing statement section holds the name your customers see.
Check the payout settings while you're there, because that's where the payout statement name lives. Merchants who edit that one by mistake leave the customer-facing name untouched.
3. Finding it on Adyen
In the live Customer Area, go to Settings, then Account, then transaction description. You can set one description across all your stores, or upload a CSV and give each store its own.
The CSV route matters if you run several brands under one Adyen account. One shared description means every customer reads the same unrecognizable line.
How we sourced our data
The descriptor pattern in this article comes from our own support conversations, not an industry survey. We read a 12-month window of tickets and ranked the topics by how often each came up.
We anonymized and aggregated those conversations, then grouped them by keyword-matched topic.
Topic totals are shares of matched conversations, not counts of individual merchants. They describe the merchants on our platform rather than merchants everywhere. Nothing published here identifies a customer.
FAQ
Can a payment processor reject my statement descriptor?
Yes. A descriptor that breaks your processor's rules gets rejected at setup, usually for length, banned characters, or a mismatched business name.
What is an example of a statement descriptor?
According to Stripe's own docs, one example reads RUNCLUB* 9-22-19 10K, a seven-character business prefix followed by an event date and distance. Yours would carry your shop name and an order reference in the same shape.
Does renaming my business change my descriptor?
No, the two are separate settings, so renaming your business leaves the descriptor as it was until you edit it. Update it yourself, and re-enroll it anywhere you've registered it for alerts.
Can two businesses have the same statement descriptor?
Yes, and short or generic descriptors collide most often. Overlapping text hides which merchant charged the cardholder, and it can point your alerts at the wrong transactions.
