Overview

In this guide, we'll break down some use cases for Canary by Pagos. For each use case, we'll walk through the types of data you might want to monitor, the benefits of tracking this data in Canary, and how you can replicate the use case in your own account.

Have your own use case example you want to share with other Canary users? Contact us to share your discovery and we'll add it to this guide!

Monitoring Approval Rates by Stored Credentials

The Data

Stored credentials are primary account numbers (PANs) that customers save in your vault for use in future purchases. Your payment processors pass a Stored Credential field along with every transaction they process, identifying whether or not a customer made the transaction using a stored credential and the type of stored credential they used (e.g. recurring, installment one-time, etc.). When you analyze your payments processing, you can use this field to segment your data and identify trends or unexpected changes in specific types of transactions.

In this use case, we'll build a trigger in Canary to notify you when the approval rate (number of approved transactions divided by the total number of processed transactions) for a certain type of stored credential transaction drops below your desired threshold.

How to Replicate

To monitor approval rates by a stored credential, set up a trigger in Canary with the following parameters:

• Metric: Approval Rate
• Threshold Type: Simple
• Filter: Stored Credential
• Filter parameter selected: The Stored Credential field value you want to monitor (e.g. recurring-first)
• Direction: Below
• Threshold: The approval rate value below which you'd want to receive an alert

The Benefits

Approval rate is generally an important metric for understanding the health of your payments setup. When approval rates drop, this can indicate an increase in fraud or security attacks, technical errors in your payments processing, issues with certain payment methods, and more. That being said, looking at the approval rate for all of your processed transactions only helps so much; to really understand where problems exist, you need to segment transaction approval rates by different attributes.

In this use case, we're digging into the approval rates for transactions made with specific types of stored credentials. Depending on the stored credential you want to monitor, you can identify when certain types of customers aren't successfully making purchases for you. For example, you may want to know when the approval rates for recurring customers drops below a certain acceptable threshold, so you can ensure you're properly processing recurring transactions or keeping vaulted payment information up-to-date.

Monitoring Key Metrics by BIN

The Data

The first 6-8 digits of a payment card's primary account number are known as the bank identification number (BIN). When you know a card's BIN, you know which bank issued it and in which country, what type of card it is (e.g. credit, debit, or prepaid), whether it's a traditional or business card, and more. Breaking down your transaction data by BIN can be extremely valuable, as it allows you to spot trends, performance challenges, and behavior anomalies for particular customer segments or issuing banks.

In this use case, we'll configure a trigger in Canary to monitor key metrics—such as approval rate, transaction count, or chargeback rate—by specific BINs. Such triggers can alert you when anything happens to disrupt your ability to process transactions for cards from the issuing banks and customer segments related to those BINs.

How to Replicate

Let's consider a situation in which you've identified three BINs for which you process the highest number of transactions—perhaps using the Top 25 BINs by Transaction Count chart in your Peacock Issuing Bank dashboard. You want to ensure these transaction counts stay high and consistent over time, so you create a trigger in Canary with the following parameters:

• Metric: Transaction Count
• Threshold Type: Relative
• Filter: BIN
• Filter parameters selected: Select the three BINs you want to monitor from the drop-down menu
• Direction: Below

Canary then calculates a different threshold range for each of the three BINs, based on where 95% of your historical transaction count data sits in the time period specified in your chosen Lookback Window; you'll receive an alert whenever the transaction count for any of those BINs falls below that range.

The Benefits

In this use case example, we specifically built a Canary trigger around transaction count. You'll find out any time the number of transactions you process for cards with those BINs drops below the expected range. That being said, you can use this same logic to build a trigger for any key metric. For example, you may want to monitor approval rate, chargeback rate, or average order value for particular BINs, ensuring the associated customer segments aren't only trying to transact, but are succesfully doing so.

Regardless of which metric you choose, monitoring your data by BIN helps you detect meaningful changes in valuable segments of your business faster. If a particular BIN transacts frequently with you, then the customers who use those BINs are important to your business. Should something happen to prevent those customers from transacting with you at the same frequency, your business will disproportionately feel that impact. Triggers such as these can help you identify such issues and act before they impact your bottom line.

Creating Unique Triggers for Each Processor

The Data

The Pagos data platform sits on top of your existing payments stack and can pull in data from any number of sources. As such, Canary can monitor all of your payments data, aggregated across multiple payment processors, and alert you when unexpected changes happen. That being said, you might not always want to view your data through a processor-agnostic lens. Instead, you may have different KPIs or threshold limits for each processor you employ; for that reason, you can create Canary triggers specific to not only a single metric, but a single processor, as well.

In this use case, let's consider an instance where you use two processors. Processor A processes 80% of your transaction volume and you want the average approval rate for those transactions to stay at or above 90%; Processor B only processes 20% of your transaction volume with a desired average approval rate of at least 88%. You want to receive notifications when your transaction approval rate for either processor drops below the acceptable minimum threshold values. To do so, we'll configure two separate triggers in Canary.

How to Replicate

In order to monitor the two processors separately, configure two unique triggers with different trigger filters. Here’s what they would look like:

With both of these triggers configured, Canary will alert you when processor one’s approval rate dips below 90% and when processor two’s approval rate dips below 88%.

The Benefits

If you only configured one simple threshold trigger in Canary with a threshold value of 90%, you'd only receive alerts when the average approval rate for all of your transaction volume dipped below 90%. Such a trigger would allow a significant drop in Processor B's approval rate to go undetected given the lower percentage of your overall transaction volume going through that processor. Using filters allows you to segment your transaction volume and monitor these segments for their own distinct expected approval rates. This not only alerts you to processing issues in real time, but lets you know where exactly in your payments stack you might have a problem.

You can employ this tactic with any metric or subset of data. If, for example, you process transactions in multiple countries, you may prefer to have a different approval rate or chargeback rate threshold for each country.