Metadata are custom labels added to your transactions, typically populated in collaboration with your payment processors. In other words, if you have additional information you want to tag a transaction with, you can work with your processors to ensure that information is passed along in the metadata field. Companies typically use metadata for segmentation that’s specific to their business, such as categorizing transactions based on product line, customer acquisition channel, or customer cohort. This custom segmentation accounts for the different areas of a business that aren’t specific to any one MID or data connection.
In this use case, we’ll explore the idea of using metadata for tagging and identifying transaction retries. If you have a recurring billing business model, you can use metadata to categorize your transactions by first retry, second retry, etc; then, you can use Peacock to track transaction approval performance or even customer churn via the number of transaction attempts.
For more examples of how your business might make use of soft-descriptors, see our Labeling Transactions with Soft Descriptors and Metadata guide!
Metadata allows you to label your transactions with additional information about the sale. In general, you’ll establish both your metadata field (metadata.field_name) and the associated set of metadata values (field_values) with your processor via an API call; alternatively, you can tag transactions with these fields when you send payments data to Pagos via our Data Ingestion API. In the example of this use case, you might set a metadata field called retry_attempt and use it to tag each transaction with the type of retry it is (e.g. 1st retry, 2nd retry, etc.)
After you connect your data sources to Pagos, Peacock then ingests metadata along with the rest of your payments metrics to generate dashboards of data visualizations. Each dashboard includes a Metadata filter option, which you can use to view data for only those transactions tagged with certain metadata..
If you have KPIs you want to track and compare across individual retry attempts, you can do so all in one place with a Peacock custom dashboard. For example, consider a situation in which you track retries with metadata in the method described above (e.g. 1st retry, 2nd retry, or 3rd retry); to monitor approval rates and declines for these retry types, you can create a custom dashboard containing multiple Processor Approvals and Decline Code Transactions charts filtered individually to display the data for each retry type. With this dashboard, you can immediately identify any fluctuations away from the norm for any one retry level and compare performance across retry attempts easier than ever before.
Here's how you might set up that dashboard:
- Create a new custom dashboard and add six charts to it: three each of the Processor Approvals and Decline Code Transactions charts.
- Next, create a new saved View to filter the individual charts in your custom dashboard. To do so:
- Click the funnel icon at the top-right corner of the first Processor Approvals by Processor chart, then click Add New View.
- Click the Metadata filter, then enter your metadata.field_name (e.g. retry_attempt) and to specify the first of your three field_values (e.g. 1st retry)
- Name your new View after the retry type and click Apply & Save.
- Repeat step 2 on to the second Processor Approvals chart, creating a View for the second retry type (2nd retry) and saving it for future use. Do the same to the third chart for the third retry type.
- Apply the three new saved Views to each of the three Decline Code Transactions charts individually.
- Title your new custom dashboard and click the save icon.
You can return to this custom dashboard any time to view the side-by-side comparisons of the performance of your three retry types over time.
Monitoring your transaction data by retry attempt is a great way to assess and fine tune your retry strategy for recurring billing.
You start off by reviewing the approval rates and decline code Transactions for your first retry attempts only; this will establish your baseline of how many of your recurring payments are successful and how many are failing. Ideally, approval rates will be high for this batch of transactions, meaning payments from your recurring billing customers are going through successfully, and those customers aren’t experiencing any service disruptions. Using the Decline Code Transactions chart filtered for 1st retry, you can even identify any addressable declines (e.g. expired card, insufficient_funds, lost_stolen, etc) and hone your retry strategy accordingly.
Next, you’ll review the charts in your custom dashboard filtered by 2nd retry to determine the efficacy of said retry strategy. For example, say you’ve noticed a trend of US debit card transactions failing on the first retry attempt with the decline code of insufficient_funds. To combat this, you design your system to automatically retry such transactions on the first Friday of the month (a popular payday in the United States). To determine if these second retries are successfully going through, you’d go to the Processor Approvals chart filtered for 2nd retry in your custom dashboard, and apply filters to view only US debit card transactions. If approval rates are high, you know your strategy is succeeding in recovering those customers!
If you’ve successfully designed, monitored, or fine-tuned a retry strategy using Peacock, please share your use case with us!
Updated about 1 month ago