Your billing descriptor is a tool for preventing chargebacks

Visa retired reason code 75, "Transaction Not Recognized", in April 2018 when Visa Claims Resolution collapsed twenty-two reason codes into four categories.

The confusion that code described did not go anywhere. It just stopped having a label, and started arriving on merchant accounts filed as fraud.

Nineteen characters, seen days later, on a phone

Your customer buys at 11pm, gets a confirmation email from a brand name they recognise, and forgets about it. Eight days later the charge posts to their statement under a string they have never seen, sitting between a petrol station and a streaming service.

If you use Shopify Payments, that string is tightly bounded. Shopify's own documentation says the customer statement name "must be between 2 and 19 characters in length, and it must include your shop name, legal entity name, store name ('Doing Business As' name), or URL." There is a phone number field next to it so customers can call you rather than their bank. If Shopify judges what you entered insufficient, it rewrites the descriptor on your behalf and emails you about it, which it frames as protection against payout and charge holds. Getting the descriptor right belongs on the same short list as the rest of the work that goes into preventing Shopify chargebacks, precisely because it costs nothing to fix once you have found it.

Nineteen characters is not much room, and other processors are not much more generous. Stripe's guide puts dynamic descriptors "usually capped at a maximum of 20-25 characters" and draws the distinction between the soft descriptor that shows while a charge is pending and the hard descriptor that replaces it after settlement. Those two can differ, which is its own source of confusion.

The descriptor is one name in a chain of names

This is where most descriptor advice stops, and it is why most descriptor advice does not work.

The problem is almost never the string in isolation. It is the gap between that string and every other name the customer has encountered: the store they browsed, the sender of the confirmation email, the name on the shipping label, the brand on the packaging, the entity name on the receipt, and the parent company if you run several stores through one payment account.

Fix the chain, not one link in it.

Tell them what to expect at checkout. One line above the pay button saying the charge will appear as your descriptor costs nothing and removes the surprise entirely.

Repeat it in the order confirmation. The confirmation email is the artefact people search their inbox for when they are staring at a statement line. If it does not contain the descriptor string, searching for it returns nothing.

Send subscription customers a heads-up before the rebill. A renewal charge thirty days later with no email attached is the single most reliable way to generate an unrecognised-transaction dispute.

Give support the lookup. Your agents should be able to find an order from a statement amount, a date, and the last four digits, because that is all the customer has. If that search takes more than a minute, some customers will call the bank instead.

Preventing avoidable disputes is the layer of the lifecycle this belongs to, and it is unglamorous by nature. It is checkout copy, email templates, and a support macro. That is the whole job.

Test it the way a customer sees it

Do not audit your descriptor in the processor dashboard. The dashboard shows you what you configured, not what the issuer displayed.

Buy something from your own store with a real personal card. Wait for it to settle, then open your banking app and read the line. Then have somebody at a different bank do the same, because issuers truncate differently and some display a cached merchant name you do not control.

Then go the other way and read your dispute data. Pull the disputes coded as fraud in a card-absent environment, Visa 10.4 and its Mastercard equivalents, and read the cardholder statements attached to them. A dispute where the customer says they do not recognise the charge, on an order that was delivered to their own verified address, is a descriptor problem wearing a fraud reason code. Sorting those out of your fraud bucket usually changes what you think friendly fraud is costing you. It also matters for a separate reason: a dispute filed under a fraud reason code still counts against your ratio the moment it is filed, win or lose, which is why winning a chargeback does not fix your dispute ratio. Fixing the descriptor stops the dispute from being filed at all, which is the only move that actually helps the ratio.

The honest limitation

Descriptor work has a low ceiling. It addresses one specific failure, the customer who genuinely cannot identify a charge. It does nothing about late delivery, nothing about a product that disappointed, and nothing at all about a customer who recognises the charge perfectly well and disputes it anyway.

The effect is slow and hard to attribute. Disputes lag the transaction by weeks, so a descriptor change made today shows up in a ratio that is already a trailing measure, mixed in with every other thing you changed that month. Anyone who tells you they can isolate the descriptor's contribution is guessing.

You also may not get the string you want. Nineteen characters, a required connection to your legal or trading name, a processor willing to overwrite your choice, and issuers that truncate further. There is no naming formula that beats those constraints, and I would be suspicious of any article offering one.

The check to run today

Open your banking app and find a charge from your own store. Read it as though you had forgotten placing the order.

If you cannot immediately tell which of your brands it came from, neither can your customer, and their next call is to a bank rather than to you.