Soft Descriptors
A soft descriptor is a customizable label you create in collaboration with your payment processor that contains dynamic data. This field appears with a transaction on issuer statements, so customers can better identify what the transaction was for. The soft descriptor field is most commonly used for “standard” payment data segments. One common use case for soft descriptors is identifying the sub-merchants of a marketplace company. A marketplace may want to label and track their sub-merchants’ transactions individually to evaluate transaction performance and potential for fraud. While “sub-merchant” is a standard data categorization, the naming convention a company uses to ID their sub-merchants is typically of their own design. As such, the soft descriptor field is a perfect place for this dimension. Sub-merchant identification is not the only use for a soft descriptor. A company whose transaction volume is driven by events or releases, for example, may use soft descriptors to identify the transactions associated with individual events; doing so ensures they can later evaluate only those transactions when assessing the overall performance and effectiveness of the event in question. Similarly, an inventory-heavy company could use the soft descriptor field for SKUs to see which products are the most or least successful. The possibilities are endless! Here are some examples of how these soft descriptors may appear:Industry | Use Case | Example |
---|---|---|
Marketplace | Identify the individual sub-merchants on a craft goods marketplace | BIRD_SWEATERS |
Travel | Identify which area of the travel business a purchase came from (e.g. airfare, hotel, or package) | AIRFARE |
Ticketing | Identify the event associated with the purchased ticket | *EVENT NAME |
Metadata
Metadata is similar to soft descriptors in that it’s a transaction-level label often communicated via a merchant’s processor. However, while businesses typically use soft descriptors for standard payments data segmentation, they often use metadata for segmentation that’s much more company-specific. We see two generalized use cases for metadata:- Custom segmentation (e.g. transaction categorization)
- Transaction categorization based on merchant behavior (e.g. transaction routing, retries, and campaigns)
Business Type | Use Case | Example |
---|---|---|
Subscription-Based (Recurring Billing) | Identify the retry attempt | Retry: 0, Retry: 1 |
Software | Identify package type | Package: Individual, Package: Commercial |