Pagos Alternatives for Subscription Merchants With Many MIDs

Pagos reports approval rate per merchant ID (MID) and splits rebills from first payments, but it publishes no connector for NMI, sticky.io or Konnektive. This guide compares the alternatives on the rebill split, native reads, scheme-program ratios, alerting and price, and names where Pagos wins.

Pagos is the name most search engines return for payment data visibility. For a mixed ecommerce portfolio reading from one processor's application programming interface (API), it is a genuinely good product. The real question is narrower than the category. If your rebill traffic sits on NMI, sticky.io and Konnektive merchant IDs (MIDs), Pagos publishes no connector for any of the three. This post compares the alternatives on the five axes that decide the purchase. It also names the places where Pagos still wins.

Here is the short answer. The Pagos alternatives worth a demo read your gateway and customer relationship management (CRM) stack natively. They split merchant-initiated rebills from cardholder-initiated first payments. They track a scheme-program ratio per MID. Pagos does the second and third of those well. It does not read NMI, sticky.io or Konnektive at all.

Comparison at a glance

Coverage read from each vendor's own public documentation on 2026-10-22. "Not documented" means the capability is absent from the public docs, which is how a buyer should treat it until a demo proves otherwise.

What does Pagos actually do, and who is it built for?

Pagos is a cross-processor data layer. It pulls transactions, refunds, disputes, disbursements and fees out of the processors you already use. It harmonizes that data. It reports approval rate, cost and chargeback metrics over the top. It calls itself independent payments intelligence rather than a gateway or a CRM. Pagos builds for a payments team reading from large payment service provider (PSP) APIs.

The product splits into three layers. The foundation layer covers data harmonization, benchmarking, Pagos AI and a Model Context Protocol (MCP) data pipeline. The intelligence layer covers payments monitoring, insights and opportunities, cost optimization and decision signals. The credential layer covers bank identification number (BIN) data, account updater, network tokenization and credential management. Pagos frames Insights as self-service business intelligence (BI) over the payments stack. That is the right mental model for the buying decision. The Opportunities page is cost-side rather than risk-side. It lists Mastercard enhanced data at 55% stated confidence, network tokenization at 90% and debit routing at 65%.

Three shapes of answer exist in this category. They are not substitutes for each other. Provider-native reporting answers questions about one provider's rails. It costs nothing, and it stops at the edge of that provider. A cross-processor data platform answers questions about several providers at once. It costs a subscription, and it stops at the edge of its connector list. A BI build answers any question you can write in structured query language (SQL). It costs engineering time, and it stops when the person who built it moves on. Pagos is the middle option. Judge it on the connector list.

The direction of travel matters too. On 17 February 2026 Pagos expanded its MCP server. Payments teams can now query harmonized transaction events, approval rates, fee breakdowns and processor performance conversationally from Claude, ChatGPT or Gemini. That helps a lean team that does not want to do dashboard archaeology. The October 2026 releases were custom tables, four fintech brand and category dimensions, a BIN-level chargeback rate column and a segment-size value on alerting segments. That is BI breadth, not scheme-program enforcement tooling.

Where does Pagos fall short for subscription rebill billing?

Three gaps matter, in increasing order of cost. First, Pagos ships no connector for NMI, sticky.io or Konnektive, so you build and maintain the data yourself. Second, the alert metric list stops at chargeback count, so no alert tracks a scheme-program ratio. Third, Retry Performance sits in closed beta behind an account manager, and it is the one dashboard a rebill-heavy merchant wants most.

1. Coverage. Pagos ships 12 no-code processor connections and 5 more that need its account team. For anything else the documented path is the Data Ingestion REST API, where you POST transactions, refunds, disputes, disbursements and fees yourself. That turns a $0 or $1,000 a month subscription into an engineering project with a maintenance bill attached.
2. Risk alerting. The five alert metrics are approval rate, attempted transaction count, decline rate, refund count and chargeback count. Chargeback count is a count, not a ratio measured against a threshold, so a MID grinding steadily at 1.4% never trips an anomaly alert.
3. Rebill attribution. Retry Performance (transactions retried, transactions recovered, retry success rate, average attempts per success) is closed beta. Retry deduplication, the filter that stops dunning attempts inflating the denominator, does not apply to PayPal, dLocal or Klarna retries and may not apply to history backfilled at signup.

That third gap moves money. The deduplicate toggle changes which retry attempts count. The headline approval rate therefore depends on a setting rather than on your traffic. On 5 October 2026 Pagos added an "Include Initial Attempt" toggle to Retry Performance. The toggle switches the view between retry success contribution and approval-rate contribution by attempt number. If the number you manage against moves when a toggle moves, you need to know which position it is in. Our write-up on how to recover failed rebills across multiple MIDs works the same problem from the dunning side.

• Per-MID granularity is real. The Processor filter drills from processor to data source to Merchant Account ID, MIDs can carry readable aliases, and MID is a bar list on both the Approvals and Chargebacks pages.
• The rebill split is native, not a workaround. Recurring, installment and card-on-file-repeat are classified merchant-initiated; one-time, recurring-first and card-on-file-vault are cardholder-initiated.
• BIN Benchmark is rebill-aware. It computes mean approval rates per BIN separately for merchant-initiated and cardholder-initiated traffic, and flags the 5 worst-performing BINs in each category every Wednesday.
• The VAMP view is computed per MID, which is the same unit Visa scores, and it splits the fraud and dispute contributions apart.
• The MCP server answers questions in plain language from Claude, ChatGPT or Gemini, which removes most of the dashboard work for a team of two or three.

The verdict on the product itself is positive. The problem is fit. Four of the five self-serve connections are Stripe, Adyen, Braintree and Checkout. A subscription portfolio built on NMI gateway profiles driven by sticky.io or Konnektive has none of them.

Which Pagos alternatives report approval rate per MID?

Four tools report it as a first-class dimension: Pagos, Primer Observability, IXOPAY and QuickRefund for NMI MIDs. Gr4vy stops at the connector level. Spreedly stops at the gateway level. Konnektive reports by gateway, which is the per-MID proxy inside a CRM. sticky.io's analytics dashboard cuts by bank, BIN, card type and geography rather than by MID.

The trap is that the four do not compute the same number. Pagos defines approval rate as approved transactions over attempted transactions in the period. That is a count-based rate with no volume weighting. The weighting matters when one MID carries a high-ticket initial sale and another carries low-ticket rebills. Primer defines authorization rate as successful payments over total payments. Primer counts only payments that actually reached a processor, which is a stricter denominator because it excludes pre-processor validation failures. Konnektive's headline Approval % is new-sale approvals over new-sale approvals plus declines. That formula excludes rebill attempts entirely. The same MID can show three different approval rates in three tools on the same day.

Pagos also has three per-MID limits worth knowing before a trial. First, the ordinary bar lists accept one parameter per category, so viewing several MIDs at once means using the top-of-page Processor filter. Second, the cost pages show only the MIDs with the most fees and collapse the rest into an "All Other MIDs" bucket, which hides the long tail in a portfolio of many small accounts. Third, hourly granularity is capped at 7-day date ranges. You can group MIDs into brands or business units as a 2-tier custom hierarchy. A Pagos account manager builds that hierarchy rather than you, and the mappings lock once you submit them.

If per-MID approval rate is the whole reason you are shopping, check what the gateway and the CRM already give you for free. NMI supports many MIDs under one gateway account with consolidated reporting. Konnektive's Transaction Summary groups by gateway alongside campaign, source, product, currency, date and funnel. The case for a paid layer is cross-source consolidation and alerting, not the existence of the cut. Our guides to MID risk monitoring and payment profitability tools for multiple processors cover the two adjacent jobs. Next step: ask each vendor for its approval-rate denominator in writing before the demo.

How do these tools handle rebill versus first-payment traffic?

Pagos and Gr4vy separate them natively. The subscription CRMs separate them more finely than either. A merchant-initiated transaction (MIT) is a charge the cardholder is not present for. A cardholder-initiated transaction (CIT) is a charge the cardholder is sitting in front of. Pagos reads the split from the stored credential field. Gr4vy filters on an Initiator value. Konnektive reports the two as separate columns.

Memorize Pagos' mapping, because it is specific. Pagos treats recurring, installment and card-on-file-repeat as MIT. It treats one-time, recurring-first and card-on-file-vault as CIT. The subscription-critical value is recurring-first, the first transaction in a recurring series. Pagos holds it separate from the rebills that follow it. Alerts carry a stored-credential dimension too. Pagos' own documented example triggers on authorization rate grouped by stored credential and filtered to recurring, which watches subscription traffic apart from one-time sales.

The limit is upstream, not in the tool. Card-on-file, moto (mail order and telephone order) and pos (point of sale) carry no MIT or CIT identification. Pagos assigns "unknown" automatically to any transaction the processor sent no stored-credential data for. If you reach Pagos through the ingestion API rather than a native connector, you map the classification yourself. The field pagos_stored_credential is a required enum whenever stored_credential has a value. An under-populated feed collapses the whole rebill view into one bucket.

Among the alternatives, Gr4vy's Authorization Insights draws the clearest separation in the orchestration group. It filters on Initiator (CIT versus MIT) and on transaction type, including card-on-file, moto, installment and recurring. It also filters on connector, error codes, BIN, issuer and scheme. Spreedly is the weakest of the group. Its success-rate denominators are transaction-type-specific, so rebill attempts made through reference purchases pool with first payments unless you segment outside the tool. sticky.io's Processing data carries no association between rebill cycles 1 to X and the initial cycle 0 transaction. You have to rebuild the initial-to-rebill link elsewhere.

Most buyers underrate the CRM baseline. Konnektive's Transaction Summary reports Approval % on new sales and RB Approval % on rebills as two distinct columns, groupable by gateway. Its key performance indicator (KPI) set adds New Sales Approval Rate, Initial Declines Rate and Recurring Declines Rate. It also adds per-cycle rates for Cycle 2 and Cycle 3. Checkout Champ runs the same engine and gives the initial-versus-rebill split by gateway and by card BIN. No payments data platform in this comparison exposes approval rate per billing cycle. An alternative has to beat that baseline, not merely match it.

One structural reason explains why rebill approval drifts on its own. Konnektive's Advanced Transaction Routing Interface (ATRI) routes first payments only. Recurring billings continue against the gateway that approved the original transaction. Its decline limits and gateway caps apply to initial transactions as well. A MID can therefore degrade on rebill traffic for weeks while the routing controls stay quiet. That is why a blended approval rate per processor is the wrong unit. Watch Cycle 2 approval rate first.

Which alternatives read NMI, sticky.io and Konnektive directly?

Three come close. Dispu names Sticky, Konnektive and NMI in its integration directory, alongside EPX, Global Payments, TSYS, Netvalve and Pay.on. QuickRefund integrates server to server with NMI, Authorize.net and Stripe at the gateway level. Spreedly supports NMI as a gateway type. Pagos, Chargeflow and the orchestration platforms list none of the three.

Pagos' coverage is acquirer-shaped rather than gateway-shaped, and its own documentation says so. The no-code connection guides cover 12 processors. The list is Adyen, Braintree, Stripe, Checkout, JP Morgan Chase, PayPal Direct, Worldpay Vantiv, dLocal, Amex, Fiserv, FirstData and Bank of America. Five more need account-team help: AuthNet, eBanx, PPro, Worldpay Core and Klarna. For anything else, the documented answer is to contact Pagos for an estimate of when a no-code connection arrives. That is a waitlist rather than a connector.

The fallback is the Data Ingestion API. You POST to a representational state transfer (REST) stream at /transactions, /refunds, /disputes, /disbursements and /fees, or you drop batches over secure file transfer protocol (SFTP). Pagos aims it at merchants whose processors lack a no-code integration or who run a proprietary switch. It requires JavaScript Object Notation (JSON) mapping against a Pagos data dictionary. For an NMI plus sticky.io plus Konnektive stack, that is engineering work before the first chart renders. It is also ongoing work every time a field changes upstream.

The native side of your own stack is thinner than it looks. sticky.io's documented provider integrations are chargeback and alert tools. The list runs Chargeback Gurus, Concept Payments, Ethoca Alerts, Midigator and sticky.io Chargeback. It also includes Verifi's Cardholder Dispute Resolution Network (CDRN) and Rapid Dispute Resolution (RDR), plus Visa Order Insights. No payment-data-visibility vendor appears among them. Konnektive's chargeback-management plugin tab lists ChargebackHelp, Fraud Deflect, Ethoca, Midigator and Optimal Alerts. Anything else goes through the API rather than a plugin. Read the vendor's published integration list before you book a demo. Look for your CRM by name rather than for a REST API you would have to build against.

Two more names come up in searches, so rule them in or out quickly. Fi911 claims over 1,000 integrations across processors, CRMs, gateways and order management systems. It reports MID health and chargeback ratios per merchant and sub-merchant. Fi911 pitches the portal at acquirers and PSPs managing sub-merchants, and it names no specific CRM or gateway. Chargebacks911's Konnektive partner page offers commercial terms (priority onboarding, special pricing, tailored support) with no documented data integration. Here is a concrete read on how thin third-party gateway coverage is. NMI's own integration directory lists exactly 1 chargeback and data-visibility partner, Midigator. NMI also disclaims development or support of every listed integration.

Do any of them monitor your scheme program ratios?

Two do. Pagos computes the VAMP ratio per MID. IXOPAY tracks the VAMP ratio and the enumeration ratio, with alerts as a chosen threshold approaches. Pagos' version depends on fraud reports (TC40), the early-fraud data that 3 processors supply. Its published threshold table still prints the retired 220 basis point (bps) line.

Start with the formula, because the whole axis turns on it. Visa's VAMP ratio is a count of TC40 fraud reports plus TC15 disputes, divided by the count of settled card-not-present (CNP) TC05 transactions. A TC40 is the fraud record a cardholder's bank files with Visa. A TC15 is the chargeback that debits you. A TC05 is the settled sale that sits in the denominator. The denominator is a settled CNP count, so a low-ticket rebill counts the same as a high-ticket first payment. Model two exclusions or the ratio overstates you. Visa excludes disputes resolved through pre-dispute solutions. Visa also excludes TC40 fraud qualified for Compelling Evidence 3.0, contingent on the timing of the data extract.

The threshold moved this year. Visa's own VAMP fact sheet footnotes the cut. Visa reduced the Excessive Merchant threshold to 150bps on 1 April 2026 in the AP (Asia Pacific), Canada, EU and US regions. The previous threshold was 220bps, which applied from 1 June 2025. The volume gate did not change. A merchant also needs at least 1,500 counted fraud and dispute events in a month to be identified. CEMEA (Central Europe, Middle East and Africa) stays at 220bps with at least 150 events and at least USD 75,000.

Pagos' implementation is genuinely good on this axis. The Chargebacks metrics page offers a Visa Formula that reflects the VAMP rate. It breaks the graph into TC40 and TC15 contributions. It renders a table of chargeback rate, chargeback count and transaction count for each MID, mirroring Visa's own per-MID calculation. It also defaults its exclusions to match VAMP logic rather than a raw count. The defaults exclude Rapid Dispute Resolution outcomes and the canceled, request-for-information, pre-arbitration, pre-dispute, notification-of-fraud and pre-compliance statuses. A toggle adds them back. The default ratio is therefore not the same number as a naive chargeback percentage, and that is deliberate.

The Mastercard side is where both Pagos and the CRMs thin out. Pagos replicates Mastercard's lagged denominator: this month's chargeback count over last month's transaction count, Mastercard volume only. It publishes no Excessive Chargeback Merchant (ECM) threshold or enrollment tier alongside that number, unlike the Visa table. The whole Risks section is 2 pages, Chargebacks and Fraud. The Fraud page does not exist at all unless you import from Adyen, Braintree or Stripe. A portfolio on other gateways therefore loses the risk-score view entirely. That matters because the two programs count different things.

Two programs, two formulas, and one MID can be comfortable on one and enrolled on the other. A tool that reports a single "chargeback rate" per MID cannot tell you which line you are near.

Among the alternatives, IXOPAY is the clearest non-acquirer example. It tracks the VAMP ratio and the enumeration ratio, and it alerts as a chosen threshold approaches. It analyzes chargebacks by reason code, PSP, issuer country, card product and MID. It aggregates fraud and dispute alerts across more than 20 PSPs. MidMetrics is scheme-ratio-first and MID-first, with a VAMP View built to surface the MIDs carrying the most risk. MidMetrics is a dispute and fraud monitor, and it documents no approval-rate reporting. QuickRefund monitors chargeback ratios against Visa and Mastercard thresholds across unlimited NMI MIDs. Here is why this matters in cash terms. Visa assesses an enrolled merchant USD 8 per fraudulent or disputed transaction. A first violation in a rolling 12 months carries a 3-month grace period.

Which tools actually alert you, or is your processor's own dashboard enough?

Your processor's dashboard reports that processor's rails, and that is exactly the problem across several gateways. Pagos makes that argument itself. Pagos alerts on 5 metrics by anomaly rather than by threshold. IXOPAY alerts on the VAMP ratio directly. NMI's webhooks are event-shaped, covering transactions, check status, recurring, settlement, chargebacks and card updater. They carry no ratio alert anywhere.

The volume floor decides fit for a many-MID portfolio. Pagos' alert logic documentation says automatic segment selection requires 45 days of history. It also requires at least 100 transactions per day on at least 75% of those days, and at least 5% of total transaction volume. A 5% floor admits at most 20 segments by construction. Separately, Pagos evaluates a MID only if it cleared more than 1,000 transactions in the last 30 days. The MID also needs more than 100 transactions on the alert date. If you deliberately spread rebill traffic across many small descriptors, Pagos does not monitor most of those MIDs as segments at all.

Segment shape is the second constraint. Automatic anomaly alerts monitor segments defined by a single parameter from a fixed list. That list is processor, payment method, stored credential, card brand, card type, BIN (count spikes only), issuing country and MID. So Pagos does not monitor "rebills on this one MID" out of the box. You can build it as a custom segment, which requires a processor and allows at most 2 further filters (1 for decline rate). Low-volume segments get static-threshold alerts only, because Pagos will not run anomaly detection on them. A 3-way cut such as MID plus recurring plus card brand is not expressible at all.

The firing bar is high by design. An approval-rate alert needs today's rate to sit 2 standard deviations below the 45-day minimum and under 75% of the lowest rate in 90 days. A chargeback-count alert needs today's count to sit at least 2 standard deviations above the 31-day mean. It also needs more than 3 times the highest count in the last 31 days, and at least 20 chargebacks on the day. Those are spike detectors. A MID drifting from 1.1% to 1.4% over six weeks produces no alert. Pagos is explicit that green bars after a red one do not mean resolved, because the system does not track whether anomalies persist. Scheme-program exposure is a cumulative month-to-date problem, and this model does not hold that shape.

Latency and plumbing round it out. Pagos reviews direct no-code connections and the Data Ingestion API from about 2AM UTC the next day. File-based connections such as JP Morgan Chase and Worldpay Vantiv can take up to 3 days before an alert appears. Pagos also monitors approval rate and attempted transaction count hourly, which is the fastest signal in the product. Delivery runs through the Pagos Service Panel, email or Slack. Static thresholds are opt-in per segment. You build one by clicking Custom Segment when you have a specific target, such as a 90% approval rate. Pagos has also widened the metric set over time. A Decline Code Rate metric landed on 31 March 2025. Cost Health fee alerts landed on 17 April 2026.

The alternatives split cleanly here. IXOPAY's alerting is configurable by area, metric, aggregation field, merchant account, filter and timeframe. It covers authorizations, chargebacks, declines, VAMP, sales, refunds, fees and 3D Secure, which is a broader surface than a processor-plus-two-filters model. Gr4vy shipped custom authorization-rate monitors with configurable thresholds and webhook notifications in Q2 2026. sticky.io markets MID stability scoring, chargeback risk detection, real-time approval shifts and gateway health monitoring alongside its cascading. OpenPath alerts on MID caps, decline percentages and availability rather than on a scheme ratio. Next step: ask each vendor for its alert latency per connection type. Next-day at 2AM UTC and up to 3 days are very different operating postures.

What do the alternatives cost, and which should you pick for your MID count?

Pagos prices on connections and transactions, not on MID count. Its published tiers are Free and Growth. Free costs $0 a month and includes 1 no-code connection and 25,000 transactions. Growth costs $1,000 a month and includes 2 connections and 100,000 transactions. File-based connections are Enterprise-only. A portfolio spread across several gateways reaches a custom quote on connector count before volume is even discussed.

The usage-based lines are easy to miss in a budget. Overage costs $0.03 per transaction on Free and $0.02 on Growth. Pagos charges transaction-level data exports separately at the same $0.03 and $0.02 per record. Benchmarking is a $500 a month add-on, and it is still closed beta behind an account manager. The credential add-ons price independently. A Batch BIN File costs $2,500 a month. BIN Lookup costs $10 a month with 500 calls included, then $0.02 per lookup. Account Updater costs $0.09 per card update with a $250 monthly minimum. Network Tokenization costs $0.09 per token with the same $250 minimum.

Prices read from each vendor's public pricing page on 2026-10-22. Note the pattern: the outcome-priced tools cost nothing until something happens, while the platform-priced tools cost the same whether you look at the dashboard or not.

Take Harbor Lane Supplements, a subscription merchant you can picture. Assume 14 MIDs spread across NMI gateway profiles driven by sticky.io and Konnektive, and assume 4 of them carry enough volume to clear 1,000 transactions in a rolling 30-day window. On Pagos Growth at $1,000 a month you pay for 2 no-code connections you cannot use, you build the ingestion feed yourself, and you map the stored-credential enum by hand. You still get MID-level alerts on only those 4 accounts, and the other 10, the ones you opened precisely to spread exposure, stay unmonitored. That arithmetic decides this purchase, not feature parity.

1. One or two MIDs behind Stripe, Adyen, Braintree or Checkout: Pagos Free or Growth, and stop shopping. $0 or $1,000 a month buys the per-MID and rebill-versus-first-payment cuts you need.
2. Three or more supported processors: Pagos Enterprise on a custom quote, because the published tiers cap at 2 no-code connections regardless of volume.
3. NMI, sticky.io or Konnektive carrying the rebills: start with the CRM's own RB Approval % per gateway, which costs nothing, then add a layer that reads those sources by name.
4. Many small MIDs rotated deliberately: the alert volume floors decide this, not the dashboard. A MID under 1,000 transactions in 30 days produces no Pagos alerts at all.
5. Scheme-program exposure is the live problem: choose per-MID VAMP and ECM ratio tracking over a BI layer, because a spike detector does not fire on a MID grinding steadily at 1.4%, and that is the job a gateway compliance monitoring layer does.
6. Your question is really dispute volume rather than reporting: price the outcome tools instead, at $29 per deflected chargeback or $12 per refund, and keep the reporting free.

• Get the approval-rate denominator in writing: approved over attempted, or successful over payments that reached a processor.
• Confirm the tool reads your actual sources by name, NMI, sticky.io or Konnektive, rather than offering a REST API you would build against.
• Check that rebills and first payments separate without a custom build, and ask what share of your traffic would land as "unknown".
• Require a per-MID ratio on both formulas: TC40 plus TC15 over settled card-not-present count for Visa, and chargebacks over the prior month's sales for Mastercard.
• Verify the threshold the product prints is 150bps, not the retired 220bps line.
• Read the alert volume floors against your smallest MID rather than your largest, and ask whether a slow drift triggers anything.
• Price the subscription against your connector count and transaction volume, then compare it to the USD 8 per counted event a VAMP enrollment costs.
• Ask when alerts arrive: next day from about 2AM UTC on a direct connection, or up to 3 days on a file feed.

Frequently Asked Questions

Is a payment provider's own dashboard enough?

Not for a portfolio spread across several gateways, because a provider dashboard reports that provider's rails only. Pagos makes this argument itself. If your MIDs sit behind one supported processor, the native dashboard plus an export answers most questions. Past two processors you are reconciling spreadsheets by hand, which is where a paid layer earns its price.

Do I need payment analytics if I already use Stripe or PayPal?

If Stripe or PayPal carries all of your volume, their own reporting answers most questions, and Pagos' free tier adds a cross-processor view for $0 a month on 1 connection and 25,000 transactions. The case for a separate tool starts when a second processor appears, because neither provider's dashboard can see the other's approval rate.

What is the difference between payment analytics and payment reporting?

Reporting tells you what happened on one set of rails. Analytics joins several sets of rails and tells you which one is degrading. The practical test is the cut: reporting shows a blended approval rate, while analytics shows approval rate per MID and per stored-credential type, so you can see which account actually moved and when.

How much does payment analytics software cost?

Published prices run from $0 to $1,000 a month, and most vendors quote instead. Pagos lists Free at $0 with 1 connection and 25,000 transactions, Growth at $1,000 a month with 2 connections and 100,000 transactions, and Benchmarking as a $500 monthly add-on. Chargeflow Insights is $0, while IXOPAY and Dispu publish no price.

Which payment metrics should you track first?

Track three per MID, in this order. First, approval rate split into merchant-initiated rebills and cardholder-initiated first payments. Second, the Visa VAMP ratio, which is TC40 fraud reports plus TC15 disputes over settled card-not-present transactions. Third, the Mastercard chargeback ratio against the prior month's sales. The first protects revenue, the other two protect the MID.

Which payment analytics tools fit a portfolio with many MIDs?

Pick on connector coverage first, then on granularity. Pagos, Primer Observability and IXOPAY all report approval rate per MID, and IXOPAY adds per-MID VAMP alerting, but none of the three lists NMI, sticky.io or Konnektive. Dispu names all three, QuickRefund covers unlimited NMI MIDs, and Konnektive's own RB Approval % per gateway costs nothing.