Glossary

Dynamic Descriptor

A dynamic descriptor lets merchants customize the transaction text shown on customer bank statements per payment.

Key Takeaways

  • A dynamic descriptor is per-transaction text that appears on a customer's bank or card statement, set via API at payment time rather than fixed to the merchant account.
  • It follows a PREFIX*SUFFIX format where the prefix is the merchant or payment facilitator name and the suffix is the dynamic portion: a sub-merchant name, product, or order reference.
  • Recognizable descriptors reduce chargebacks and customer confusion, which is why card networks enforce specific formatting rules and character limits (22 characters on Mastercard, 25 on Visa).

What Is a Dynamic Descriptor?

A dynamic descriptor is a customizable text string attached to a payment transaction that appears on the cardholder's bank or credit card statement. Unlike a static descriptor, which is configured once on the merchant account and stays the same for every transaction, a dynamic descriptor can be set individually for each payment through the payment gateway API.

When a customer checks their statement after a purchase, the descriptor is the line of text next to the charge amount. A vague or unrecognizable descriptor (like "PAYCO LLC") leads to confusion and "friendly fraud" chargebacks where customers dispute legitimate charges they don't recognize. A dynamic descriptor solves this by showing context-specific text: the restaurant name on a food delivery app, the seller name on a marketplace, or the subscription plan on a SaaS platform.

Dynamic descriptors are sometimes called soft descriptors because they can be overridden at the transaction level, in contrast to hard descriptors that are permanently tied to the billing descriptor registered with the acquiring bank.

How It Works

A dynamic descriptor is composed of two parts joined by an asterisk and space separator:

  • Prefix: the merchant or platform's registered name, set at the account level and typically fixed by the acquirer
  • Suffix: the dynamic portion, passed in the API request for each transaction

The full descriptor displayed on the customer's statement is the prefix, an asterisk, a space, and the suffix concatenated together. For example, a food delivery platform named "QUICKBITE" processing a payment for a restaurant called "Taco Palace" would produce:

QUICKBITE* TACO PALACE

The asterisk and space count toward the total character limit, so the usable space for the suffix depends on how long the prefix is.

Character Limits by Card Network

Each card network enforces its own maximum descriptor length. The separator (asterisk and space) counts toward these limits:

Card NetworkMax Characters
Visa25
Mastercard22
American Express22
Discover25

In practice, many payment processors enforce a 22-character limit across all networks for consistency, since Mastercard's limit is the most restrictive. Characters beyond the limit are silently truncated, which can make a descriptor unrecognizable if the meaningful portion is cut off.

Character Restrictions

Descriptors are restricted to basic Latin letters, digits, spaces, and a small set of symbols (asterisk, comma, hyphen, period, equals sign, underscore). At least one letter is required. Special characters like angle brackets, ampersands, and quotes are not allowed. These restrictions ensure descriptors render consistently across banking systems worldwide.

API Integration

Setting a dynamic descriptor happens at the time of payment creation. The merchant's backend passes the descriptor suffix in the API call to the payment processor. A typical integration looks like this:

// Creating a payment with a dynamic descriptor suffix
const payment = await gateway.createPayment({
  amount: 2500,
  currency: "usd",
  paymentMethod: customerPaymentMethod,
  statementDescriptorSuffix: "TACO PALACE",
});

// Customer's statement shows: QUICKBITE* TACO PALACE

If no suffix is provided, the processor falls back to the static descriptor configured on the merchant account. Not all processors support dynamic descriptors by default: some require the feature to be enabled at the account level, and support varies by payment method (card payments generally support it, while bank transfers may not).

Use Cases

Marketplaces and Payment Facilitators

Marketplaces are the most common use case for dynamic descriptors. When a payment facilitator processes payments on behalf of multiple sub-merchants, card networks require the descriptor to identify the sub-merchant. Visa requires the format PayFacName*SubmerchantName so customers can identify which seller charged them. Without this, a marketplace customer who bought from three different sellers would see three identical, unrecognizable charges on their statement. For deeper context on how marketplace payment flows work, see marketplace payments and platform economics.

SaaS and Subscription Platforms

SaaS companies with multiple product tiers or add-on services use dynamic descriptors to show which plan or feature triggered the charge. A company running both "Pro" and "Enterprise" plans can differentiate them on the statement, reducing support tickets from customers who see an unexpected amount and don't remember which plan they upgraded to. This pairs well with recurring billing systems that process automatic renewals.

Delivery and On-Demand Services

Food delivery, ride-sharing, and on-demand platforms use dynamic descriptors to display the specific vendor name. When a customer orders from "Taco Palace" through a delivery app, the descriptor shows the restaurant name rather than the delivery platform's corporate entity. This is especially important because customers often remember the restaurant but not the delivery service.

Multi-Brand Businesses

Companies operating multiple brands under a single merchant account use dynamic descriptors to show the correct brand name per transaction. This avoids the cost of maintaining separate merchant accounts for each brand while keeping statements clear for customers.

Why Dynamic Descriptors Matter

The primary business case for dynamic descriptors is chargeback reduction. A significant portion of "friendly fraud" disputes come from customers who don't recognize a charge on their statement. Clear, recognizable descriptors help customers identify their purchases, which reduces the chargeback ratio and keeps the merchant in good standing with card networks and acquirers.

Card networks have increasingly penalized merchants with high dispute rates. Visa's monitoring programs impose financial penalties on merchants that exceed dispute thresholds. A well-configured dynamic descriptor is one of the simplest tools to stay below those thresholds.

Beyond chargebacks, dynamic descriptors also reduce customer support volume. When customers can identify charges on their own, they don't need to contact support to ask "what is this charge?": a question that accounts for a notable share of payment-related support tickets.

Dynamic Descriptors and Crypto Payments

Dynamic descriptors are a concept rooted in traditional card payment rails. In stablecoin and cryptocurrency payments, the equivalent concept takes a different form. On-chain transactions use memo fields or reference IDs to provide context, and the transparent nature of blockchain explorers means both parties can verify transaction details independently.

For businesses operating across both card and crypto rails, descriptors remain critical on the card side. Platforms that offer crypto-funded card payments still need clear descriptors because the customer's bank sees a standard card transaction regardless of how it was funded on the backend.

Risks and Considerations

Issuer Truncation and Display Variance

The issuing bank has final control over how a descriptor appears on the customer's statement. Some issuers truncate descriptors earlier than the network limit, reformat them, or append additional information like the processor name. A descriptor that looks correct in testing may appear differently on certain banks' mobile apps or paper statements. Testing with multiple card issuers is important before relying on descriptor clarity.

Prefix Coordination

The prefix portion of a dynamic descriptor is typically set during merchant onboarding and requires coordination with the acquirer. Changing it later may require a new application or account update. If the prefix is too long, it leaves minimal room for the dynamic suffix, defeating the purpose. Merchants should negotiate a short, recognizable prefix (3 to 7 characters) during onboarding.

Not Universally Supported

Not all payment methods and processors support dynamic descriptors. Bank transfers, some regional payment methods, and certain legacy processors may ignore the dynamic portion entirely and display only the static descriptor. Merchants should verify support with their processor and test across all payment methods they accept.

Compliance Requirements

Card networks impose rules on descriptor content. Descriptors must accurately represent the merchant or service: misleading descriptors can trigger fines or account termination. Payment facilitators face stricter requirements and must include their registered name as the prefix, with the sub-merchant name as the suffix, on every transaction they process.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.