The short answer
A dynamic descriptor is a billing descriptor that varies per transaction — unlike a static soft descriptor that's set per sub-brand and never changes. Dynamic descriptors let you encode context into what the customer sees on their statement: the product they bought, the subscription tier, the geographic origin, or the specific sub-brand they purchased from within a larger brand family. Supported by Visa, Mastercard, and most modern acquirers.
Format (same 25-character envelope)
Visa and Mastercard enforce the same 25-character total limit. A dynamic descriptor still has a hard (parent) segment and a variable segment, but the variable part is generated per-transaction by the merchant's system:
PEAKBIO*ORDER 8881726(with order number)PEAKBIO*BPC157 10MG VIAL(with product SKU)PEAKBIO*MO SUBSCR MAY26(monthly subscription May 2026)PEAKBIO*800-555-1212(brand + support phone for easy customer contact)
When dynamic descriptors are worth the complexity
- High chargeback categories. If your chargeback ratio trends up and "unrecognized charge" is the leading reason code, dynamic descriptors that show the specific product or order number cut disputes by 15-30% in most cases.
- Subscription businesses. Showing the subscription month/period on the statement prevents the "I already cancelled this" dispute. Customers cancel and then see one more charge — the dynamic descriptor tells them exactly which billing period.
- Multiple product lines under one brand. A credit repair operation offering monthly monitoring, one-time bureau challenges, and dispute services can use dynamic descriptors to tell the customer which product generated the charge.
- Geographic variants. A brand operating in multiple states can indicate state on the descriptor for consumer protection compliance (some states require this).
When static soft descriptors are enough
- Single-product brands.
- Low chargeback ratios already (< 0.5%).
- Simple subscription with clear confirmation emails.
- Tight operational resources. Dynamic descriptors need transaction-time generation logic that can fail if your upstream breaks.
Rules and restrictions
- Must be truthful. The variable portion must represent actual transaction context. Can't be used to sneak unrelated text onto a statement.
- Must be pre-approved by acquirer. You submit the template ("PEAKBIO*" + variable) and the rules that generate the variable. Acquirer reviews before enabling.
- Character restrictions. Uppercase, space, asterisk, hyphen, period, slash — no other special characters.
- Must be passed in the auth request. Your gateway needs to support per-transaction descriptor overrides (most modern gateways do; some legacy ones don't).
Common pitfalls
- Truncation. Issuers truncate descriptors to fit their statement layout. Don't put the critical context at the end — put it right after the asterisk.
- Generating descriptors from user input. Never — sanitize and pre-approve templates only.
- Inconsistency with confirmation emails. If the statement says "SUBSCR MAY26" and the email says "May 2026 membership," the customer may still not recognize. Align them.
- Breaking on fallback. If your dynamic logic fails, the charge shouldn't fail — the descriptor should fall back to the static soft descriptor for the brand.
How multiflow handles dynamic descriptors
Our transaction routing layer supports dynamic descriptor generation via pre-approved templates and rules per sub-brand. You configure the template once in your operator portal (e.g., "BRAND*ORDER {order_id}"), test with a handful of live transactions, then enable. The descriptor that was actually transmitted is displayed alongside every transaction in your portal so you can audit and tune.