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
• Direction: Below
• Threshold: The approval rate value below which you'd want to receive an alert
• Filter: Stored Credential
• Filter parameter selected: The Stored Credential field value you want to monitor (e.g. recurring-first)

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-10 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 Issuers 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 Percentile
• Direction: Below
• Filter: BIN
• Filter parameters selected: Select the three BINs you want to monitor

Canary then calculates a different threshold range for each of the three BINs, based on where 90% 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 successfully 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.

Monitoring Your Total Cost of Payment Acceptance

The Data

Pagos ingests your fee data through your data connections, alongside your transaction data. We then map each fee using three primary fields:

• Fee Code – The raw fee code data provided by your payment service provider (PSP).
• Fee Category – The top level classification of a fee. There are three main fee categories—Interchange (card issuer fees), Processor (PSP fees), and Network (card brand fees)—but depending on your data sources and payment methods, there may be more.
• Fee Subcategory – The next level of classification under fee categories that delineates fee groups for tracking cost trends over time. Examples include Authorization, Card_processing, Reversal, and more.

In this use case, we'll explore how to use these fee mappings to customize filters for a Canary trigger that alerts you when specific areas of your payments processing get more expensive.

How to Replicate

The cost Metric trackable in Canary is calledFee Value. A trigger configured around this metric will alert you whenever the total combined value of all your fees crosses the indicated threshold.

To monitor fees for specific data streams, however you'll need to customize the trigger filters. You can use the Card Brand, Currency, Merchant Account ID, and Processor filters to have Canary monitor segments of your business; for example, you can tell Canary to alert you when fees spike for customers in the US paying with Visa cards.

Alternatively, you can use filters that correspond to the three primary fee fields mentioned above to monitor specific types of fees:

• Fee Category – Select the exact fee category (or categories) you want to monitor fee volume for. If you want to filter down to just one category your business is particularly interested in (e.g. Processor fees), you can do so. Alternatively, you can also select “all” and monitor all the categories simultaneously and separately.
• Fee Subcategory: This will monitor the intermediate level of Pagos mappings. Depending on your processors, there may be more than a dozen subcategories to choose from. Canary allows you to monitor up to 12 data streams with each trigger, so you can select the top 12 subcategories that matter the most to you.
• Fee Code: This is the most granular level of data that you can monitor. This is for when you’re really trying to evaluate fee trends for a particular processor, card brand, or process. Like the Fee Subcategory filter, you can select up to 12 fee codes to monitor simultaneously

The Benefits

Monitoring fees means keeping on top of unexpected changes that could directly hurt your bottom line. For example, consider a situation in which you've built a Canary trigger to alert you when fees in the Processor category increase above a relative threshold. Should your fees change enough to trip this trigger, this could indicate a billing error or configuration issue that you'll want to address immediately.