Labeling Transactions with Soft Descriptors and Metadata
To make the most of your transaction data, you need to be able to segment that data in meaningful ways for your business. All transaction data from your payment processor(s) comes with certain identifiers—such as transaction currency, amount, or payment method used—which allow for such segmentation on a basic level. Should you have specific sale properties you want to filter by, however, you need to attach your own custom data fields to each individual transaction.
Using soft descriptors and metadata, you can do just that. In general, you’ll establish these optional fields with your processor via an API call; Pagos then ingests them through your data source connections.
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:
|Marketplace||Identify the individual sub-merchant 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 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)
For example, you may want to track transaction volume or segment sales traffic based on a product line, customer acquisition channel, or customer cohort. This custom segmentation is about areas of your business, but it’s not necessarily specific to any one MID or data connection. The metadata field is perfect for this.
Behaviorally, the best use for metadata is retries. You can categorize your transactions by a First Attempt, Retry, Second Retry, etc. Then, you can track transaction approval performance or even customer churn via the number of transaction attempts.
Here are some examples of how metadata appears on transactions:
|Business Type||Use Case||Example|
|Subscription-Based (Recurring Billing)||Identify retry attempt||Retry: 0, Retry: 1|
|Software||Identify package type||Package: Individual, Package: Commercial|
Updated 6 months ago