I’m certain all of us have seen a statement descriptor before, but very few might have given it as deep a thought as I did. Today's article is going to delve into the importance of statement descriptors and their purpose; also, how it can be leveraged as a powerful marketing tool by the merchant to add context to the purchase and reduce risks/chargebacks.
Tl;Dr
Because a statement descriptor is so familiar, there is often a tendency to forget about it or leave it as an afterthought.
Risk teams are not the only ones who need to know & have an informed opinion on statement descriptors. GTM, payment acceptance, branding, Payment Ops & customer service (to name a few) need to be familiar & super involved as well.
if you are a PayFac or white-labeled product, this is your opportunity to insert your brand & start building that relationship
Do make this part of your checklist when thinking about - splitting business entities (conglomerates), re-branding, pivoting, becoming a PayFac etc.
Statement descriptors, as the name suggests are the descriptions of purchases on your credit/debit/bank monthly statements detailing the transaction. This helps provide context, define, and make the transaction instantly recognizable. When you see a $2.99 charge for coffee or $4.54 charge from CVS, you immediately recall- “ah! I had coffee Wed morning before work” or “ya, I stopped by CVS to pick up Ricola for my sore throat” etc. This builds trust between merchants, & a consumer. The trust makes consumers less inclined to file for a chargeback. On the flip side, if you see your CC statement & something looks totally unrecognizable, unknown merchant, no context for charge then you will be highly likely to file for a chargeback suspecting fraud via stolen CC details or force-post by merchant etc.
These are some sample statement descriptors:
This is from my recent AmEx statement. It tells me more about each of the charges - Uber BV is a subsidiary of Uber in Amsterdam for the EMEA region. So, that tells me I took an Uber in Europe. It checks out as I was in Greece at that time & an annual charge for Clear from clearme.com (the travel digital identity platform).
PayFac & statement descriptors
Square was probably the first to start the PayFac trend of adding a SQ * in front of the statement descriptor before adding the end merchant name. That’s one way to make a subtle marketing/branding statement & also identify the merchants with a square terminal. I thought that was very clever! I used to think this is universal, later when I was working at SQ, I realized that this does not apply to AmEx; AmEx is its own universe & we will talk about it in a sec.
Try this fun experiment- next time try tapping your AmEx card at any SQ POS & see how your statement descriptor looks. I bet it won’t be SQ * <<coffee shop name>>.
Toast & other PayFacs have followed suit. PayFacs are a topic in itself, so I am not going to get into the details of how PayFac works. However, adding a subtle hint is only fair because the PayFac (parent) are the MoR (merchants of record), hence they underwrite the child businesses, bear chargeback risk etc. But in the same vein, the reason to keep it subtle & give more real estate to the name of the coffee shop, cookie shop or follower shop etc makes it easily recognizable.
A PayFac with BNPL/Wallet, Shopify as a platform supports pay in 4 powered by Affirm, & this is how they have decided to configure their statement descriptor: SP+AFF* - SP for Shopify & AFF for Affirm then the * and then the name of the merchant. Pretty smart for internal analytics but if you are not as deep into it, it might get confusing. I am not sure if SP+AFF is needed, but it must be working well for them. Plus keep in mind, the more character you add the less you have for the actual end store that the consumer recognizes. So keep that constraint in mind.
Shopify when paid with card & not Affirm shows up as:
Characteristics of a statement descriptor:
Since it’s a set limit of 22 chars, it needs to be used wisely.
Make sure if you support foreign languages or countries, then umlaut, apostrophe, accents etc are not supported & are likely to break your code
Rebranding & company name changes
Rebranding as the name suggests is a branding/PR & marketing heavy exercise; however, as a payments product, you do need to make sure your Statement Descriptor aligns with the new name/brand/strategy etc.
Consider the following example from HBO rebranding to MAX. Instantaneously, the descriptor aligned & changed to MAX in June. Also, make sure you send email comms explaining what to expect & why the change. If you have an installment product, BNPL, subscription etc, it becomes even more important to explain & add context because the time when the user subscribed/paid for the first installment might be a while ago.
Make sure you don’t appear as so:
Conglomerates & subsidiaries
When I was working at Uber, we used the same MoR for all of Uber businesses, Rides and Eats etc. Eats got to appear in your CC statement as Uber not UberEats. Circa 2019, we started our effort to split transactions based on which subsidiary of Uber it came from- Rides, Eats , Freight etc. This was not an easy change as we had to create separate sub-merchants inside Adyen & ChaseNet etc across our global processing partners. However, this yielded massive benefits.
Where to configure Statement Descriptors:
If you are using an external payment processor, your processor will have a section to configure a statement descriptor. It could be static with just a company name (default setting) or you can configure it in code to send a dynamic one every time a purchase is made with timestamp or specifying the SKU; for PayFacs it could be with a static prefix like SQ * (Square) or TST* (Toast) and then adding dynamic text after in code.
American Express Statement Descriptors
American Express has its own system for statement descriptors. It takes 48 - 72 hrs or sometimes even more to reflect changes made to reflect on AmEx cards’ statements. They also seek self reporting from customers, but they are slow to respond to merchant changes. So just have patience.
Ramp also has a way to report merchant categorization and merchant name etc. But I am guessing these are for Ramp’s own internal categorization & data sanity. I am not sure if they share this data back to MC or Visa.
If you want to check what your configuration looks like or want to make changes to it based on what you learned from this article but don’t know where to start, here are some quick tips:
For Stripe:
For Adyen:
*Your specific merchant configuration may vary & look slightly different.
In conclusion, most risk teams are very familiar what effect statement descriptors can have on chargebacks. But beyond that, I have seen the knowledge being very sparse. I’d urge payment product & growth teams to not ignore this lever they have at their disposal in order to have a direct relationship with their end customer (the payee). Especially if you are a PayFac or white-labeled product, this is your opportunity to insert your brand & start building that relationship. Finally, if you are rebranding, pivoting, or changing the ethos of the company etc., don’t forget to update this important rather forgotten asset or down the line it can come back & haunt you in the form of customer service tickets or chargebacks → VDMP program.