Start with recognition, not an internal order code
Stripe describes statement descriptors as explanations of charges or payments on bank statements. Its requirements say the descriptor must reflect the business's Doing Business As name; an account can use a static descriptor, while card charges can combine an account prefix with a transaction-specific suffix.[3] Editorial recommendation: ask what name a customer remembers from checkout before selecting the prefix. A short operational identifier that makes sense to finance staff may be meaningless to a buyer. Keep the recognizable merchant identity stable and use the remaining space for a useful product or service distinction. This article proposes a naming workflow, not a measured claim that a particular descriptor reduces disputes.
Budget the complete string, including the separator
For the standard Latin descriptor, Stripe specifies a complete length of 5–22 characters and a static prefix of 2–10 characters. A descriptor needs at least one letter; when using prefix and suffix, both need a letter. Stripe joins the prefix, an asterisk, a space, and the suffix, and the combined string must not exceed 22 characters.[3] Editorial recommendation: validate the complete computed value, not just the suffix input. Illustrative example, not an actual merchant: NORTHSHOP is nine characters and CLASS APR is nine; NORTHSHOP* CLASS APR totals twenty with the separator. A ten-character prefix leaves ten characters for a suffix. Avoid treating the automatically inserted separator as permission to add arbitrary special characters to either component.
Use the correct field for the payment type
Dynamic suffixes apply only to card payments. Stripe documents statement_descriptor_suffix on a PaymentIntent, and payment_intent_data.statement_descriptor_suffix on a Checkout Session. For card payments, statement_descriptor cannot be specified; non-card payments can use that field to override a static descriptor.[3] Editorial recommendation: keep the mapping between payment type and parameter explicit in an integration review. Do not copy a non-card example into a card checkout simply because the field name looks more intuitive. This guide does not extend those direct-payment instructions to subscriptions, invoices, or Connect accounts, which have their own configuration paths. It also makes no claim that these fields are supported by PayIn's product API.
Make truncation an explicit review item
When a static descriptor exists but a separate prefix does not, Stripe uses the static descriptor as the prefix for card payments and truncates it if it is longer than ten characters.[3] Editorial recommendation: review that shortened identity before adding dynamic transaction labels. Otherwise the portion customers recognize may be the portion removed. Maintain a small approved vocabulary of suffixes rather than inserting free-form basket text. For a multi-item purchase, choose a truthful category label instead of implying that only one item was bought. The proposed review should include the longest prefix, the longest approved suffix, letter requirements, and the final separator-inclusive length. These are suggested checks, not evidence that a production integration has passed them.
Do not turn Latin rules into a worldwide script ban
Stripe separately supports kanji and kana descriptors for Japanese businesses. Its documented availability requires both a Visa or Mastercard issued in Japan and a charge processed by, or on behalf of, a Japanese business. The issuer ultimately decides whether to display kanji, kana, or Latin characters. The calculated_statement_descriptor returned by the API is always the Latin descriptor even when the issuer can display a Japanese one.[3] Editorial recommendation: treat this as a distinct regional path, not as a reason to put arbitrary Unicode into the standard Latin field. If this path applies to your business, review the Japanese requirements directly; do not reuse the Latin length validator and assume it covers every script.
Separate configured text from bank presentation
Stripe warns that some banks may display statement information incorrectly or not at all. For Japanese kanji and kana descriptors, it says the information is sent at capture and usually takes a few days to appear, with temporary descriptions possible in the meantime.[3] Editorial recommendation: maintain separate support fields for the configured descriptor, the computed Latin descriptor, and the customer's reported bank display. Do not promise an identical appearance in every banking app or interpret a temporary label as proof that configuration failed. If collecting a customer screenshot is necessary under your support policy, request only the relevant transaction line and avoid unnecessary account details. That privacy recommendation is editorial, not a statement of Stripe retention rules.
Publish a naming decision and an honest verification record
Editorial recommendation: finish with a small decision record stating the merchant identity, payment type, prefix, allowed suffixes, combined length, and who approved the wording. Explain the expected merchant name in the receipt or support material without guaranteeing how a bank renders it. Proposed acceptance checks: distinguish card and non-card parameter handling, inspect the full constructed string, review missing-prefix truncation, and route Japanese eligibility through the separate documented requirements.[3] Record actual observations only when authorized testing occurs. This research has not initiated a payment, inspected a customer's statement, measured recognition, or established a dispute-rate improvement. A useful descriptor is a clear identity decision backed by supported configuration, not a substitute for payment receipts or case-specific customer support.
Sources and dates
Verified on 2026-09-20. Source dates distinguish explicitly stated publication and update dates; an unspecified date does not mean the source was published today. This is public-document research, not a live payment test, security audit or accessibility certification. Vendor facts apply to the cited vendor; proposed workflows are editorial synthesis.
More new articles
Treat dispute evidence submission as a final release, not a draft →
SCA exemptions reduce authentication friction, not fraud liability →
All field guides →