field notes 2026-04-11 7 min read the multiflow desk

Billing descriptor strategy — the lever most operators don't pull

3-minute scan
  • Half of all chargebacks across e-commerce have a reason code that traces back to the same root cause: the customer didn't recognize the charge on their statement.
  • Visa reason code 13.2 ("merchandise/services not received") and 10.4 (fraud CNP) both frequently hide a simpler truth — the customer saw a weird name on their bank statement and assumed fraud.
  • Most operators don't bother because it's buried in an acquirer admin panel that nobody thinks about after onboarding.
On this page

    Half of all chargebacks across e-commerce have a reason code that traces back to the same root cause: the customer didn't recognize the charge on their statement. Visa reason code 13.2 ("merchandise/services not received") and 10.4 (fraud CNP) both frequently hide a simpler truth — the customer saw a weird name on their bank statement and assumed fraud.

    Fixing the descriptor is free. Most operators don't bother because it's buried in an acquirer admin panel that nobody thinks about after onboarding. But tuning a descriptor properly cuts dispute volume 30-50% in the worst-affected merchants. Here's how to do it.

    The descriptor anatomy

    A billing descriptor is up to 25 characters that appear on a cardholder's bank/credit card statement next to each charge. Two parts:

    • Hard descriptor (3, 7, or 12 chars depending on network): your parent merchant's DBA. Fixed per MID.
    • Soft descriptor (12-22 chars): variable portion. Per sub-brand, per product, or per order.

    Separated by an asterisk. Example: GENESISLABS*PEAKBIO.

    Network rules: uppercase only, alphanumeric + space + asterisk + hyphen + period. No special characters beyond those. Must be truthful (describes the actual merchant or product, not bait).

    The three descriptor patterns (pick one per sub-brand)

    Pattern A: Brand-only static

    BRANDNAME*shop

    Simple, static per brand. Customer sees "BRANDNAME" on statement — matches what they bought from. Minimal dispute from unrecognized-charge.

    Use when: single-product brands, subscription-only businesses, brands with high brand recognition.

    Pattern B: Brand + product

    BRANDNAME*BPC157 10MG

    Variable portion is the product SKU or category. Customer sees their brand AND what they bought.

    Use when: product-driven recall matters (peptides, supplements), multiple distinct product lines.

    Pattern C: Brand + order/subscription

    BRANDNAME*MO SUBSCR MAY

    Variable portion is the subscription period or order reference. Customer who cancelled and sees a refund or final billing cycle sees exactly which period the charge is for.

    Use when: subscription businesses, membership sites, recurring billing with cancellation complexity.

    The multi-brand operator challenge

    On a single-brand Stripe account, the descriptor is whatever Stripe set based on your Stripe account name. Boring but works.

    On a multi-brand portfolio, the question becomes: if I have 4 brands all running through one parent merchant account, what does each customer see?

    The wrong answer: all 4 brands share one descriptor like "ACME HOLDINGS LLC." Every customer across all 4 brands sees the parent company name — nobody recognizes it. Disputes surge.

    The right answer: per-brand soft descriptors. Customer from Brand A sees BRANDA*... Customer from Brand B sees BRANDB*... The parent LLC is invisible to customers; they see only the brand they bought from. This requires configuring per-brand descriptors at the acquirer (each acquirer handles this differently; on multiflow it's a single config per sub-brand).

    Dynamic descriptors (the per-transaction variant)

    A dynamic descriptor changes per transaction based on merchant rules. Pass the descriptor value in the authorization request; it overrides the default.

    Use cases:

    • Subscription clarity: BRAND*SUBSCR MAY26 tells the customer exactly which billing cycle. Huge reduction in "I already cancelled" disputes.
    • Product specification: BRAND*BPC157 10MG — customer recognizes the product, not just the brand.
    • Multi-region operations: BRAND*FL 800-555-1234 with state + customer support phone. Works well for licensed professional services.

    Tradeoff: requires transaction-time generation logic. If your dynamic logic fails, the auth should fall back to the static default (not the bare parent name).

    Phone number in the descriptor

    Visa and Mastercard both allow appending a customer service phone or URL to the descriptor. Card issuer statements display this; customer sees "BRAND*HELP 800-555-1234" and knows where to call.

    Research consistently shows: merchants with support phone in the descriptor see 15-25% fewer disputes. Customer who would have disputed calls your line first; often you refund, case closed, no ratio damage.

    Tradeoff: the phone number eats characters from the 25-char budget. You can't have a long brand name + long phone + descriptive text.

    What NOT to put in the descriptor

    • Anything deceptive or misleading. Acquirer termination is automatic.
    • Your personal/legal name if different from the public brand. Creates confusion.
    • "WWW.YOURSITE.COM" as the entire descriptor. Customers don't recognize domains on statements as readily as brand names.
    • Initials or acronyms the customer has never seen ("ACME" when customers know the brand as "Acme Wellness Co").
    • Anything suggestive for adult/novelty brands. Discreet but recognizable works.

    The testing methodology

    You can't really "test" a descriptor in a non-production environment — statements render issuer-side, not processor-side. So do this:

    1. Pick your 3 most common card issuers (usually Chase, Bank of America, Capital One, Wells Fargo, Amex).
    2. Make a $1 purchase from yourself using each issuer's card.
    3. Wait 1-2 days, check the statement for each card.
    4. Confirm the descriptor renders as expected on each. Some issuers truncate or reformat.

    Iterate from there. Different issuers truncate differently — some show 22 chars, some show 15. Put the critical context (brand + product/period) right after the asterisk, not at the end.

    When to change an existing descriptor

    Descriptor changes require acquirer approval (not instant). Typical turnaround: 3-5 business days.

    If you change mid-subscription-cycle, existing subscribers see a new name on their next bill. Notify them proactively ("Our billing descriptor is updating from X to Y — same charge, new label on your statement") to prevent the brief chargeback spike that otherwise happens.

    The multi-brand operator checklist

    1. Each sub-brand has its own soft descriptor that matches the brand name.
    2. No sub-brand falls back to the parent LLC name on customer statements.
    3. Customer support phone is in the descriptor if you have 25-char budget.
    4. Subscription businesses use dynamic descriptors with period specification.
    5. You've tested the actual rendering on 3+ real issuer cards.
    6. You have a process to update descriptors without cycle-spike chargebacks.

    The multiflow version

    Configure per-brand soft descriptors once at sub-brand setup. multiflow handles the dynamic injection per transaction. Per-transaction descriptor that was actually transmitted is surfaced in the operator portal on every order so you can audit and tune.

    For operators who haven't thought about descriptors before, implementing this alone typically pays for the orchestration fee several times over in the first 60 days through chargeback reduction.

    Found this useful? Share it X LinkedIn Reddit HN Email

    Running multiple brands?
    multiflow was built for this.

    The Operator Briefing

    Twice-monthly. No fluff.

    Processor shutdowns, reserve-hold playbooks, reconciliation lessons, and the merchant-account decisions that save operators six-figure years. Delivered to your inbox — never spam.

    No spam. Unsubscribe in one click.

    We use essential cookies · Privacy