Payment Data, Decoded: A Practical Guide to Merchant Payment Operations Monitoring
Most merchants monitor payment metrics at the top line. They watch total approval rate, total chargeback ratio, and total processing volume. Those numbers are real. They are also the last place a problem becomes visible.
By the time an aggregate metric moves, the cause has typically been building for weeks in segmented data underneath it. That gap between signal and response is where merchant payments friction lives, and it is the operational problem this guide is built to address.
This guide is the closing piece of the StreamPayments Payment Monitoring and Business Intelligence series.
What is your Approval Rate hiding?
Customer Profiling & Behavioral Analytics
The Problem with Code 05 - Do Not Honor
It brings the full series together into a single operational reference: the framework, the metrics, and the monitoring methodology a merchant can use as a standing guide.
Two things make this guide different from general payments monitoring content.
The first is the peer-group baseline methodology. Most monitoring guidance assumes a merchant already knows what normal looks like for their business. Many do not. The peer-group baseline gives merchants an external reference point before they have accumulated enough transaction history to define their own. It is a starting point, not a substitute for building internal benchmarks over time.
The second is practitioner observations from Milena Milusheva, StreamPayments' Risk Systems and BI Manager. Milena works directly with merchant payment data across verticals and markets. Her observations appear throughout this guide as a practitioner lens from inside the data, not industry commentary.
This guide covers monitoring baseline methodology, approval rate as a diagnostic signal, decline code interpretation, chargeback ratio leading indicators, customer behavioral intelligence, and card scheme compliance thresholds.
These metrics do not operate independently. They form a system. A movement in one metric is almost always preceded by a signal in another. This guide shows where to look and in what order.
Milena Milusheva is StreamPayments' Risk Systems and BI Manager. She builds and runs payment monitoring systems for merchants across verticals and markets. Her observations appear throughout the sections that follow.
The guide works end to end as a framework, or by section depending on which metric you are currently investigating. The glossary at the close defines all terms used throughout. The FAQ addresses the questions we hear most consistently from merchants encountering these concepts for the first time.
The Problem With Aggregate Monitoring
Aggregate monitoring is the default view for most merchants. It covers total approval rate, total chargeback ratio, total volume, and portfolio-level averages. These are the most visible numbers in any payment dashboard. They are also the least diagnostic.
The fundamental limitation is straightforward. Aggregates tell you what happened. They do not tell you where it happened, which customers drove it, or what is likely to happen next.
The compression problem makes this worse. By the time an aggregate metric moves, the cause has been visible in segmented data for weeks, sometimes months. The aggregate is always the last signal to move. Merchants who monitor only at this level are working with the oldest available information in the dataset.
The most dangerous condition is what we call silent degradation. This is a metric that holds steady at the portfolio level while the distribution underneath it shifts significantly. A stable aggregate approval rate can mask a growing problem in a specific customer segment, issuer, or acquisition channel. The top-line number produces false confidence. The problem only becomes visible when it is large enough to move the aggregate, at which point root causes are harder to isolate and more costly to address.
The segmentation principle is the counter to silent degradation. The same metric, segmented by issuer, market, customer type, transaction type, and acquisition channel, reveals what the aggregate hides.
Each of the four standard aggregate metrics should generate a segmented follow-on question:
Total approval rate: which customer segments authorize at lower rates than the portfolio average?
Total chargeback ratio: which acquisition channels drive disproportionate disputes compared to their share of total volume?
Total volume: which segments are growing, and do they carry different risk profiles than the existing base?
Portfolio-level averages: where does performance sit relative to peer-group norms for the vertical and merchant category code?
None of those questions is answerable at the aggregate level.
One further layer sits above all of this. The 3DS upstream gap refers to authentication failures that occur before authorization is even attempted. In many payment systems and dashboards, authentication outcomes sit outside the approval rate calculation entirely. A merchant can have a stable aggregate approval rate while an authentication problem builds invisibly above it. The rate they are monitoring does not include the transactions that never reached authorization. Section 3 covers how to account for this in practice.
The sections that follow take each metric in operational sequence, starting with the foundation that makes any monitoring meaningful: the baseline.
Building the Monitoring Baseline: The Foundation Everything Else Requires
Most merchants know their own numbers. What they typically lack is any external reference point for those numbers.
The peer-group baseline fills that gap. It is a reference built from data across merchants with similar business models, merchant category codes, industry verticals, and market footprints. It establishes what normal looks like for a comparable peer group before the merchant has accumulated enough transaction history to define their own internal normal.
The reason this matters is simple. A metric without context is ambiguous. A 0.8% chargeback ratio in isolation tells you nothing meaningful. Against a peer-group range for the same merchant category code, it tells you exactly where you stand and whether investigation is warranted. Monitoring without a baseline is pattern recognition without a reference point. It can detect movement, but it cannot tell you whether that movement is significant.
The process starts at onboarding. The first question asked of any new merchant is a direct one: can you describe your business model in your own words? The answer shapes what a meaningful peer-group comparison looks like. A subscription merchant in iGaming and a one-time purchase merchant in ecommerce share a card-not-present transaction structure and very little else that is relevant to payment monitoring.
From that first conversation, we work through expected transaction volumes, average ticket sizes, and target markets. These form the initial profile that peer-group data is mapped against. It is a working approximation at this stage, not a fixed benchmark. Its purpose is to give context to early-stage data that would otherwise be interpreted in isolation.
Monitoring intensity is higher in the early phase for this reason. Until a merchant has built sufficient transaction history, actual activity is measured against both the declared processing profile and peer-group behavior simultaneously. Two reference points are more reliable than one.
What the first review typically finds is that merchants rarely have a strong understanding of their own transaction data or its operational value. Most have seen top-line numbers. Few have worked through what those numbers reveal at a segmented level.
The first concrete step is establishing clear key performance indicators and tracking fluctuations against historical data from day one. This creates the baseline and makes early anomaly detection possible. An anomaly is only visible against a reference point. Without it, an unusual number is just a number.
Once KPIs are in place, actual performance is measured against anticipated processing levels. Significant over or underperformance relative to the declared profile is where the peer-group baseline earns its value. It gives context to figures that would otherwise require guesswork to interpret.
What surprises most merchants is how significantly actual transaction behavior can deviate from their initial expectations, and how consequential that deviation is in the early processing phase. Expectations and reality diverge more often than merchants anticipate. The baseline makes the divergence visible and interpretable.
The first sustained review period produces something practically valuable: a reliable transaction track record and enough data for a more accurate risk assessment. That assessment can translate directly into improved processing terms. Merchants who engage with monitoring seriously from the start are better positioned to benefit from this.
This is particularly relevant for iGaming operators and subscription merchants, where compliance risk accumulates quickly and the cost of delayed risk assessment is higher than in lower-complexity verticals.
The baseline is not a one-time deliverable. It is the foundation everything else in this guide is built on. Sections 3 through 7 all assume it is in place.
As Milena puts it: "Creating a baseline improves the reliability of ongoing monitoring and the detection of deviations, as well as potential technical anomalies and operational issues."
With a peer-group baseline established, the next step is understanding what to monitor against it, starting with the metric most merchants already watch but rarely read correctly.
The Approval Rate: A Diagnostic Signal, Not a Performance Score
The approval rate is not a performance score. It is a diagnostic signal. A strong number does not mean payment operations are healthy. A dropping number does not necessarily mean something is broken. The number, on its own, tells you almost nothing actionable.
What the approval rate usually measures is the proportion of authorization attempts that succeed. What it may not capture is more variable: authentication failures that sit upstream of authorization, the composition of attempt types within the denominator, and whether retry activity is inflating the attempt count. Some gateways and dashboards include failed authentication attempts within the approval rate calculation. Others exclude them entirely. Knowing which is true for your reporting environment is a prerequisite for interpreting the number correctly.
The mapped response code problem adds another layer. Acquirers normalize issuer decline codes into a standardized set for operational consistency across the network. This is a practical necessity. The side effect is that diagnostic detail is removed before decline data reaches the merchant. What a merchant analyzes is already an interpretation of the original signal, not the signal itself. This matters more in Section 4, which covers decline codes directly.
When the approval rate drops, there are three distinct causes, each requiring a different response.
A technical issue involving data quality or how authorization requests are being configured. This is fixable, but only if it is correctly identified. It requires a conversation with the technical or integration team, not the risk team.
A country distribution shift. If the market mix has changed, a new territory with lower issuer approval norms will mechanically suppress the portfolio rate. Payment operations have not degraded. The transaction mix has shifted.
An average ticket size change. A higher average transaction value suppresses authorization rates, particularly on cards with lower credit limits. This is not a payment problem. It is a transaction mix change that is visible in the approval rate.
The critical insight across all three: treating the number as the problem rather than the symptom means directing time and resources at the wrong place. Each cause requires a different conversation with a different team. None of them is visible in the aggregate approval rate without segmentation first.
The baseline and trend principle follows directly from this. A single approval rate figure carries very limited diagnostic value without historical context. What matters is the direction and pace of movement against the baseline established in Section 2, and whether that movement is concentrated in a specific segment or distributed across the portfolio.
Retry inflation is the distortion that most consistently undermines approval rate analysis. Multiple authorization attempts on the same card each count as separate attempts in the denominator. A period of elevated retries inflates the attempt count without reflecting genuine demand, which suppresses the calculated rate arithmetically. Segment retry attempts out before interpreting any period with higher-than-normal attempt volume.
Healthy approval rate monitoring has a defined structure. It segments by issuer, market, customer type, and transaction type. It tracks variance against predictable events, including product launches, seasonal volume shifts, and market expansions. It separates retry volume from first-attempt volume before drawing any conclusions.
When the rate moves, the first step is to cross-reference the decline code distribution. Before escalating or making changes, identify whether movement is concentrated in a specific BIN range, issuer, or transaction type. That segmentation almost always narrows the cause faster than any other approach.
As Milena puts it: "The retry inflation point is one we flag consistently when reviewing approval rate data with merchants. It is one of the quieter distortions, but it compounds quickly and makes the baseline unreliable until you separate it out."
When the approval rate moves, the first place to look is the decline codes underneath it. Understanding what those codes are, and what they are not, telling you is where the diagnostic work actually begins.
Decline Codes: The Most Underused Diagnostic Tool in Payments
Code 05, Do Not Honor, is the most common decline code returned by issuers across both Visa and Mastercard, and the most operationally frustrating. It is a generic response. It gives no specific reason for the decline and no guidance on how to respond.
Based on Adyen's analysis of issuer response patterns, approximately half of Do Not Honor declines represent insufficient funds that issuers present generically rather than through a more specific code.
The RC59 picture has been shifting. Historically, Visa remapped suspected fraud responses under Code 59 to RC05 before the decline reached the merchant. That practice is changing. RC59, Suspected Fraud, is now appearing more directly in decline data, with RC05 being used less frequently for this purpose. The shift is not yet consistent across the full network. For merchants reviewing historical decline data against current data, this evolution in how codes are applied is worth accounting for.
What this means operationally: the RC05 volume a merchant sees today carries a different mix of underlying causes than it did two or three years ago, and it will continue to evolve as both schemes push for greater specificity in issuer responses.
The mapping layer adds a further dimension. In most cases RC05 is not the original issuer response. The acquirer or gateway has already normalized the bank's original response into a generic Do Not Honor before it reaches the merchant. Diagnostic detail was removed at that stage. What merchants analyze is a translation, not the source signal.
What RC05 does not tell you: the reason for the decline, whether to retry, when to retry, which team should investigate, or whether the pattern is structural or isolated. It collapses all of those options into a single unhelpful output.
The way to extract diagnostic value from RC05 is to segment before drawing any conclusions.
RC05 volume concentrated in a specific BIN range points to a card product or issuing bank with a particular risk posture toward the transaction type. This is a bank-level signal, not a portfolio-level one.
RC05 volume concentrated on a specific issuer across multiple BIN ranges suggests that issuer is tightening its posture toward the merchant category more broadly. That is a different investigation than a BIN-level issue.
RC05 spiking on recurring transactions only, while leaving first-time authorizations unaffected, points to an authentication or mandate reference issue. The fix is technical, not commercial.
RC05 appearing broadly with no concentration pattern suggests something in how transactions are being submitted, which brings the investigation back to the integration and configuration level.
Retry inflation compounds the RC05 reading in the same way it distorts approval rate analysis. Multiple attempts on the same card generate separate RC05 responses that accumulate in the data. Remove retry activity from the dataset before analyzing the underlying RC05 distribution.
There is an important counterpoint worth holding. Some declines stay generic by design. Issuers withhold detail on certain fraud-related declines deliberately, so the reasoning cannot be reverse-engineered by bad actors. A generic response in these cases is not a transparency failure. It is a security design choice. Merchants should not expect specificity on all fraud-adjacent declines, and pushing for it will not produce it.
The broader direction of travel across both Visa and Mastercard is nonetheless toward more specific issuer responses. Both schemes monitor issuers that rely disproportionately on generic codes and are actively pushing for greater specificity across the network. More specific codes give merchants, acquirers, and schemes better data to act on.
What more specific codes enable is practically significant. A specific decline tells a merchant to retry later, prompt the customer to update their payment details, stop retrying entirely, or refine a fraud rule. A generic decline collapses all of those options into a guess.
Mastercard Merchant Advice Codes formalize this structure. MAC 01 indicates that new account information is available. MAC 02 indicates the transaction can be retried later. MAC 03 indicates the merchant should not retry, typically because the account is closed or suspected fraud is involved. MAC 21 indicates the payment has been cancelled by the cardholder.
The fee consequences of ignoring these codes are direct and measurable. Retrying after a MAC 03 or MAC 21 response triggers fees under Mastercard's Transaction Processing Excellence program. Visa applies equivalent excessive retry fees above applicable threshold limits. Fee rates vary by region, and neither scheme publishes regional schedules publicly. Merchants operating in Europe should confirm the applicable rate directly with their acquirer. The principle is consistent across regions: blind retrying has a direct and measurable cost.
Good decline code monitoring combines native issuer codes wherever available, treats mapped codes as a starting point rather than a final answer, applies BIN range and issuer segmentation consistently to RC05 volume, and integrates MAC responses into retry logic so that fee-triggering retries are eliminated systematically rather than managed reactively.
As Milena puts it: "The BIN range concentration point is one we look for first when reviewing RC05 patterns with merchants. It narrows the investigation down fast and usually points to something actionable pretty quickly."
Decline codes reveal pressure at the transaction level. The chargeback ratio reveals what happens when that pressure goes unaddressed. The signals connecting the two are already in the data.
The Chargeback Ratio: A Lagging Indicator With Early Warning Signals
The chargeback ratio is the last metric to move and the first one most merchants respond to with urgency. That sequence is the operational problem.
By the time the ratio moves, earlier signals have been visible and readable in segmented data for some time. The ratio is not the problem. It is the result of problems that have been building upstream. Sections 3 and 4 have already covered where those upstream signals live.
The signals that typically precede a rising chargeback ratio follow a recognizable pattern. Approval rate drifts without a clear operational explanation. RC05 patterns begin concentrating on specific issuers. Manual review rates at the gateway or PSP level creep upward. These are the signals this guide has covered in the preceding sections.
There are additional upstream signals that merchants often miss, or respond to too slowly when they do see them. A rising customer complaints rate in support data. An increasing volume of refund requests. Elevated fraud detection alerts from PSP or gateway risk tools. Each of these can move independently. When multiple signals increase in intensity at the same time and are considered only as individual factors, the compounding effect accelerates the timeline to chargeback ratio movement in ways that are harder to reverse than if each signal had been acted on when it first appeared.
Timing windows matter for how urgently those signals should be read. Fraud-related disputes can surface within days of the original transaction. Non-fraud chargebacks typically lag 30 to 60 days. The upstream leading signals appear well before either window closes. That is the window for intervention. Once the ratio has moved, the options narrow and the cost of correction rises.
One point on how disputes count under VAMP specifically. Under Visa's Acquirer Monitoring Program, disputes count toward the ratio whether the representment is won or not. The ratio is based on disputes filed, not disputes lost. Winning a chargeback does not remove it from the VAMP calculation. This distinction is operationally significant for merchants managing their ratio against scheme thresholds. For a fuller treatment of VAMP mechanics and what they mean for iGaming operators specifically, see our post on the subject.
https://www.streampayments.com/blog/subscription-compliance-2026
The chargeback ratio feeds directly into the conditions that activate certain card scheme monitoring programs. Those programs are covered in Section 7.
The acquirer relationship is the most underutilized early warning resource available to most merchants. Acquirers monitor portfolio performance against internal thresholds that are typically stricter than the official scheme limits. They work with merchants and payment service providers before those limits are breached, not after. By the time a formal scheme notice arrives, the risk team conversation at the acquirer has usually been running for some time. Merchants who maintain open, data-backed communication with their acquirers benefit from that relationship as a protective early warning system rather than a reactive compliance mechanism.
What active monitoring of leading indicators makes possible is intervention at a point when root causes are still addressable. Once the ratio has moved, the options available are narrower and the cost of correction is higher.
As Milena puts it: "The reason code distribution shift is a pattern we often see when analyzing payment data for merchants. It is visible in the segmented data well in advance, but only if you are already looking at it at that level."
Aggregate metrics and decline codes tell you what is happening across the portfolio. Customer and behavioral data tells you who is driving it, and which patterns are predictive before they appear in any top-line metric.
Customer and Behavioral Data: What the Aggregate Cannot Tell You
Transaction-level data contains a detailed picture of customer behavior. Most merchants never look at it. Their reporting stops at the aggregate, and everything that is only visible at the segment level goes unread.
Four things aggregate metrics cannot tell you: which customer segments generate disproportionate decline rates relative to their share of total volume, which acquisition channels correlate with higher chargeback frequency, which onboarding patterns predict future payment challenges, and how customer tenure relates to authorization outcomes over time. None of those questions can be answered from a portfolio total.
The customer tenure finding is one of the most consistently observed patterns in merchant payment data. Long-standing customers with established transaction history authorize at higher rates than first-time users. This is not surprising in isolation. What is significant is how invisible it is in the aggregate, and how clearly it appears when authorization rate is segmented by customer cohort. A merchant who treats all customers identically in routing and verification is leaving recoverable approval rate on the table.
Three behavioral signals predict future payment outcomes before they appear in any top-line metric.
Customer tenure predicts authorization rate. As a segment, newer customers authorize at lower rates. This is a portfolio composition signal, not a payment infrastructure problem.
Acquisition channel correlates with chargeback frequency. Some channels consistently produce customers with higher dispute rates. This pattern is invisible in the total chargeback ratio. It is visible at the segment level. A channel that generates volume but drives disproportionate disputes is not a growth driver. It is a risk concentration that will eventually surface in the aggregate.
Rapid growth in a new customer cohort without a corresponding authorization rate improvement is the third signal. It typically means the new cohort carries a different risk profile than the existing base, and that difference has not yet moved into the chargeback ratio. It will.
What this is not: fraud scoring. Fraud scoring assesses individual transaction risk. What behavioral intelligence describes is something different: understanding which behaviors at the segment level correlate with payment outcomes across the portfolio. The two are complementary, not interchangeable.
What merchants can do with this intelligence is concrete. Onboarding flows can be adjusted by customer profile. Additional verification can be applied where segment-level risk is higher, and smoother flows where it is lower. Routing decisions can be informed by segment behavior rather than applied uniformly across all transaction types. Risk concentrations can be identified before they reach top-line metrics.
Accessing this data requires connecting transaction-level data to customer profile data across payment reporting tools, CRM systems, PSP analytics, or BI platforms. For merchants without this integration in place, the most accessible starting point is acquisition channel segmentation against chargeback data. That single cut typically surfaces the most actionable signal fastest.
The early warning function of behavioral monitoring is its most practically significant characteristic. By the time a behavioral shift at the customer or segment level appears in the aggregate, it has been building in the underlying data for some time. Behavioral monitoring is where that shift first becomes visible and still addressable.
As Milena puts it: "Apart from fees reduction and improvement of authorization performance, merchants fine-tune their fraud rule management and gain a better understanding of issuer behavior."
Understanding what the data contains is the operational foundation. Understanding what it feeds into at the scheme level is what gives that monitoring its urgency.
Card Scheme Monitoring Programs: What Your Metrics Are Feeding Into
The metrics covered in Sections 3 through 6 are the same metrics that card scheme monitoring programs use as triggers. Approval rate, chargeback ratio, refund rates, fraud alerts, and customer behavioral signals do not exist only as operational data. They feed directly into scheme-level enforcement. Understanding the programs clarifies exactly why the monitoring discipline this guide describes matters and why it cannot be treated as optional.
Mastercard's Scam Merchant Monitoring Program is effective July 24, 2026. When a trigger is breached, the acquirer is required to open an investigation within 72 hours. If scam activity is confirmed, Mastercard and Maestro processing stops immediately. This is a required network action, not an advisory. The merchant does not receive a warning period once a trigger activates.
Three categories of signals trigger a mandatory investigation.
The first: an authorization rate that drops more than 50 percentage points in a 72-hour period compared to the merchant's baseline average in the preceding seven-calendar-day period, or an authorization rate that falls below 30%.
The second: an alert from a Mastercard-approved Merchant Monitoring Service Provider identifying the business as a potential scam merchant or as suspected of illegal activity.
The third applies to merchants under six months of Mastercard acceptance history: two fraud reports from different issuers citing reason code 56, Manipulation of Cardholder, or a combined refund and chargeback rate exceeding 5% in a rolling 30-day window with 500 or more transactions.
None of these triggers require bad intent to activate. They require metrics outside acceptable thresholds. A legitimate merchant with operational monitoring failures can breach the same triggers as a fraudulent one. The program does not distinguish between them at the trigger stage. That determination is the acquirer's investigation to make.
The VAMP connection operates differently. Under Visa's Acquirer Monitoring Program, Visa monitors at the acquirer portfolio level. A merchant's dispute and fraud ratio affects the acquirer's aggregate standing before any scheme-level enforcement touches the merchant account directly. Acquirers act on individual merchant ratios to protect their own portfolio position. A merchant does not necessarily receive formal notification before acquirer-level action begins.
The shared principle across all monitoring programs is this: by the time a metric crosses a formal threshold, the underlying cause has typically been building for weeks. Reviewing your current position is not the same as addressing a metric that has been drifting for months. The monitoring discipline in Sections 3 through 6 is what creates the window to intervene before formal thresholds become relevant.
Acquirers apply internal thresholds stricter than the official scheme limits and begin working with merchants before formal notices arrive. Merchants who maintain open, data-backed communication with their acquirers benefit from this as a protective relationship rather than a reactive one. The data that enables that conversation is the same data this guide has covered throughout.
Good compliance monitoring is not a separate function from operational monitoring. It uses the same data. A merchant reviewing their segmented approval rate, decline code distribution, chargeback leading indicators, and behavioral signals on a regular basis is not running two separate disciplines. They are running one, and it covers both.
Each of the preceding sections covers one element of the monitoring picture. The section that follows shows how they connect as a single operational system.
The Payment Operations Monitoring Cycle: Putting It Together
The Payment Operations Monitoring Cycle is the framework this guide has been building toward. Each preceding section covered one element. This section shows how they connect as an operational system a merchant can run consistently and use as a standing reference.
The cycle has six stages.
Stage 1: Establish the peer-group baseline. Define what normal looks like for the vertical, merchant category code, and market footprint before attempting to detect deviation. A metric cannot be read as anomalous without a reference point. This is the foundation everything else in the cycle requires.
Stage 2: Monitor approval rate as a diagnostic signal. Segment by issuer, market, customer type, and transaction type. Remove retry activity from the dataset before interpreting any period of elevated volume. React to the composition and direction of movement, not the aggregate number.
Stage 3: Read decline codes before escalating. Distinguish between mapped codes and native issuer codes. Segment RC05 by BIN range and issuer before drawing conclusions. Apply Mastercard Merchant Advice Codes to retry logic so that fee-triggering retries are eliminated systematically. Know which codes indicate a recoverable transaction and which indicate a hard stop.
Stage 4: Watch the leading indicators of chargeback problems. Monitor refund rates, customer complaint volumes, fraud detection alerts from PSP or gateway risk tools, and reason code distribution shifts. The chargeback ratio is the last thing to move. Leading indicators are the only point at which root causes are still addressable before the ratio moves and options narrow.
Stage 5: Apply customer and behavioral intelligence. Use customer and segment-level data to understand which acquisition channels, onboarding patterns, and customer profiles are driving authorization and dispute outcomes. Identify risk concentrations before they reach top-line metrics.
Stage 6: Know what your metrics are feeding into at the scheme level. Understand the SMMP triggers, VAMP thresholds, and MAC penalty structure. These are the downstream consequences of operational monitoring done or not done. They are not a separate compliance function. They are the same data read from a scheme enforcement angle.
The cycle is not a one-time project. Establish baseline, detect signals, diagnose root cause, communicate with the acquirer, adjust operations, re-baseline. That is the discipline, and it runs continuously.
What to Bring to an Acquirer Conversation
Merchants who arrive at acquirer conversations with segmented data have productive discussions. Merchants who arrive with only the top-line number have reactive ones. The data to bring is specific.
Segmented approval rate trend for the period in question, broken down by issuer and market. Decline code distribution with BIN range concentration breakdowns. Chargeback ratio trend tracked against the peer-group baseline. Any known operational changes in the period that would explain metric movement. These four data points reframe an acquirer conversation from escalation management to collaborative problem-solving.
A Note on AI in Payment Monitoring
AI tools are entering payment monitoring workflows and worth addressing directly.
The current state is this: AI can assist and recommend. It should not execute without prior human verification. The false positive rate in AI-only payment risk systems is currently too high to rely on without oversight.
The consequence of AI-only monitoring is not neutral. False positives generate unfair scrutiny and consequential action against merchants who may not have the infrastructure to identify and challenge incorrect flags. The damage is real and often difficult to reverse quickly.
Institutional expertise is precisely what addresses this gap. The knowledge built over years of working directly with merchant payment data is what catches and corrects errors in AI-generated signals. The monitoring discipline this guide describes is what makes AI tools useful rather than harmful. AI tools in payment monitoring should be treated as assistants to experienced teams, not replacements for them.
The framework above describes what good payment operations monitoring looks like in practice. The observations that follow come from someone who builds and runs it daily.
From Inside the Data: Observations From Our Risk Systems and BI Team
The six observations below come directly from Milena Milusheva, StreamPayments' Risk Systems and BI Manager. They are drawn from working directly with merchant payment data across verticals and markets, not from industry research or secondary sources. Each one reflects a pattern that repeats.
On approval rate and retry inflation:
"The retry inflation point is one we flag consistently when reviewing approval rate data with merchants. It is one of the quieter distortions, but it compounds quickly and makes the baseline unreliable until you separate it out."
On RC05 and BIN range concentration:
"The BIN range concentration point is one we look for first when reviewing RC05 patterns with merchants. It narrows the investigation down fast and usually points to something actionable pretty quickly."
On what happens when merchants treat decline codes as operational data:
"When a merchant starts treating decline codes as operational data, it leads to one outcome: a higher approval rate. The change that always stands out first is in routing logic and retry strategy."
On baseline methodology and new merchants:
"Creating a baseline improves the reliability of ongoing monitoring and the detection of deviations, as well as potential technical anomalies and operational issues."
On what behavioral data unlocks beyond the obvious:
"Apart from fees reduction and improvement of authorization performance, merchants fine-tune their fraud rule management and gain a better understanding of issuer behavior."
On what early monitoring makes possible that late monitoring does not:
"Merchants underestimate how much flexibility early monitoring provides. Detecting adverse trends early allows them to make gradual operational adjustments instead of implementing disruptive corrective actions under tight deadlines."
The observations above come from working directly with merchant payment data across verticals and markets. The patterns repeat. The guide captures what those patterns look like and what to do about them.
The terms used throughout this guide are defined in the glossary below. The FAQ addresses the questions we hear most often from merchants encountering these concepts for the first time.
Glossary
Authorization rate: the proportion of authorization attempts that result in approval.
BIN (Bank Identification Number): the first six to eight digits of a card number identifying the issuing bank and card type.
Chargeback ratio: the proportion of transactions that result in a formal dispute filed by the cardholder.
MAC (Merchant Advice Code): instructions returned by the issuer alongside a decline, indicating whether to retry, when to retry, or whether to stop attempting.
Mapped response codes: normalized translations of issuer decline codes applied by acquirers or gateways. Operationally consistent but compress the diagnostic detail of the original issuer response.
MCC (Merchant Category Code): a four-digit code classifying a merchant by the type of goods or services provided.
Native issuer response codes: the original decline codes returned directly by the issuing bank before any mapping by the acquirer or gateway.
Peer-group baseline: a reference benchmark built from data across merchants with similar business models, MCCs, verticals, and market footprints. Used to establish what normal looks like before a merchant has sufficient transaction history to define their own.
RC05: the Do Not Honor decline code. The highest-volume decline code in most merchant datasets, returned when an issuer declines a transaction without specifying the reason.
Representment: the process by which a merchant disputes a chargeback and submits evidence to the card scheme for review.
SMMP (Mastercard Scam Merchant Monitoring Program): a Mastercard program effective July 24, 2026, requiring acquirers to investigate flagged merchants within 72 hours and immediately stop Mastercard and Maestro processing if scam activity is confirmed.
3DS (3D Secure): an authentication protocol used in card-not-present transactions. Authentication failures at this stage do not appear in the authorization approval rate in many reporting systems.
VAMP (Visa Acquirer Monitoring Program): a Visa program that monitors chargeback and fraud ratios at the acquirer portfolio level, with thresholds applied at both the acquirer and merchant level.
-
A payment operations baseline is a defined reference point for key payment metrics, established so that any movement in those metrics can be read against a known normal rather than in isolation. Without a baseline, it is impossible to distinguish meaningful deviation from expected fluctuation. A baseline makes anomaly detection possible and turns monitoring from a reactive exercise into a proactive one.
-
A peer-group payment baseline uses data from merchants with similar business models, merchant category codes, industry verticals, and market footprints to establish external context for a merchant's own metrics. Unlike a standard baseline, which relies on a merchant's own historical data, a peer-group baseline provides a reference point before sufficient transaction history exists. It is used in merchant payment operations to determine whether approval rate, chargeback ratio, and refund rate are within the expected range for the vertical, or whether performance indicates a structural issue requiring investigation.
-
The approval rate measures the proportion of authorization attempts that result in approval. What it captures depends on the reporting environment. Some gateways and dashboards include failed authentication attempts within the calculation. Others exclude them, meaning authentication failures upstream of authorization may not appear in the rate at all. A dropping approval rate is a diagnostic signal, not a performance score. The appropriate response depends entirely on identifying the cause. A technical submission issue, a shift in transaction mix, and issuer-level pressure on a specific BIN range each require a different response from a different team.
-
RC05, also known as Do Not Honor, is among the most common decline codes returned by issuers across both Visa and Mastercard. It is a generic response that provides no specific reason for the decline and no guidance on whether to retry. In most cases RC05 is not the original issuer response but a mapped code applied by the acquirer or gateway, which removes diagnostic detail before the merchant sees it. Merchants should segment RC05 volume by BIN range, issuer, and transaction type before acting, rather than treating the aggregate as a single undifferentiated problem.
-
The chargeback ratio is a lagging indicator. The signals that typically precede a rising ratio include an increasing refund request rate, rising customer complaints in support data, elevated fraud detection alerts from PSP or gateway risk tools, and reason code distribution shifts within specific issuers. Fraud-related disputes can surface within days of a transaction, while non-fraud chargebacks typically lag 30 to 60 days. Monitoring these upstream signals is where root causes are most effectively addressed, before the ratio moves and the window for proactive intervention narrows.
-
Mastercard's Scam Merchant Monitoring Program, effective July 24, 2026, is triggered by three categories of signals. The first is an authorization rate that drops more than 50 percentage points in a 72-hour period compared to the merchant's baseline average in the preceding seven-calendar-day period, or an authorization rate that falls below 30%. The second is an alert from a Mastercard-approved Merchant Monitoring Service Provider identifying the business as a potential scam merchant or as suspected of illegal activity. The third applies to merchants under six months of Mastercard acceptance history: two fraud reports from different issuers citing reason code 56, Manipulation of Cardholder, or a combined refund and chargeback rate exceeding 5% in a rolling 30-day window with 500 or more transactions. When a trigger is breached, acquirers are required to open an investigation within 72 hours. If scam activity is confirmed, Mastercard and Maestro processing stops immediately.
-
Mastercard Merchant Advice Codes are instructions returned by the issuer alongside a decline, providing explicit guidance on how the merchant should respond. MAC 01 indicates that new account information is available. MAC 02 indicates the transaction can be retried later. MAC 03 indicates the merchant should not retry, typically because the account is closed or fraud is suspected. MAC 21 indicates the payment has been cancelled by the cardholder. Retrying after MAC 03 or MAC 21 triggers fees under Mastercard's Transaction Processing Excellence program, with rates varying by region. Merchants should confirm the applicable rate with their acquirer directly.
-
Customer behavioral analytics in payment operations is the practice of using transaction-level data to identify patterns in customer behavior that correlate with payment outcomes across the merchant's portfolio. This is distinct from fraud scoring, which assesses individual transaction risk. Operating at the segment level, it identifies which customer cohorts, acquisition channels, and onboarding patterns generate disproportionate decline rates or chargeback frequency. This intelligence supports more targeted decisions in merchant payment infrastructure, including adjustments to routing logic, onboarding flows, and verification requirements by segment.
-
Native issuer response codes are the original decline signals returned directly by the issuing bank. Mapped response codes are normalized translations applied by the acquirer or payment gateway, converting the original codes into a standardized format for processing. The mapping process compresses diagnostic detail, meaning the decline code a merchant receives often does not reflect the specific reason the issuer declined the transaction. Merchants relying solely on mapped codes are working with a filtered interpretation of the original signal rather than the signal itself.
-
The most effective approach follows the Payment Operations Monitoring Cycle: establish a peer-group baseline, monitor approval rate as a segmented diagnostic signal, read decline codes before escalating, watch the leading indicators of chargeback problems, apply customer and behavioral intelligence, and understand what the metrics feed into at the scheme level. The process is ongoing rather than a one-time project. The full framework is covered in Section 8 of this guide. Merchants who want to establish a monitoring baseline can reach the StreamPayments team at streampayments.com/contact.
How StreamPayments Approaches This Work
The work described in this guide is what StreamPayments does with every merchant from the first conversation. Not everyone is built for this kind of work. We are. Working from the analytical and the objective, we produce clarity, and in complex payment environments, that clarity is not easy to come by.
In practice, that means establishing a peer-group baseline at onboarding, monitoring approval rate and decline code distribution on a continuous basis, maintaining active compliance awareness across Visa and Mastercard monitoring programs, and supporting the acquirer relationships that sit underneath all of it. This is not an added service layer. It is how we operate with every merchant we work with.
If you want to talk through what your current payment data is showing, reach us at streampayments.com/contact.
