Tracking Individual Retries on Recurring Billing Using Metadata

The Data

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.

👍

Note:

For more examples of how your business might make use of soft-descriptors, see our Labeling Transactions with Soft Descriptors and Metadata guide!

Exploring the Data in Peacock

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 connections 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.

📘

Metadata Tip:

To use the metadata filter, you must know the exact metadata field names and field values tagged to your transactions, including exact formatting. You can confirm these fields and values in the Metadata page under the Know Your Data section of your Pagos account.

Creating Custom Dashboards

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 Approval Rate 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:

  1. Create a new custom dashboard and add six charts to it: three each of the Processor Approval Rate and Decline Code Transactions charts.
  2. Next, create a new saved View to filter the individual charts in your custom dashboard. To do so:
    1. Click ... at the top-right corner of the first Processor Approval Rate chart, then click Add View.
    2. Click Create New View, then give your View a name.
    3. Click the Metadata filter.
    4. Enter your Metadata Name (e.g. retry_attempt) and specify the first of your three metadata field values in the Value textbox (e.g. 1st retry), then click Add.
    5. Click Apply Filters, then click Create View
  3. Click ... on the same chart, click Add View, then select your new View from the menu.
  4. Repeat step 2 on to the second Processor Approval Rate 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.
  5. Apply the three new saved Views to each of the three Decline Code Transactions charts individually.
  6. 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.

Drawing Conclusions

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 Approval Rate 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!