Analytics & Reporting.

Standard payment reporting from a single processor provides transaction-level data for that processor's MID. High-risk merchants using multi-acquirer architecture have multiple MIDs across multiple acquiring banks — each with separate reporting. The metrics that matter most — chargeback ratio per MID against card-network thresholds, approval rate by acquirer and card geography, cascade retry success rates — require consolidated data from all acquiring relationships in a single view. Standard reporting doesn't consolidate across acquirers, doesn't segment approval rates by the variables that matter for routing decisions, and doesn't provide real-time chargeback-ratio tracking against threshold levels.

Card-network monitoring programs are calculated monthly — but chargeback accumulation is continuous. A merchant ending one month at a 0.5% chargeback ratio can cross the 0.9% Visa VDMP threshold mid-way through the next if a fraud event generates a cluster of chargebacks. Without real-time ratio tracking, the merchant doesn't know the ratio has crossed threshold until the acquiring bank notifies them of placement. With real-time monitoring per MID, a threshold alert at 0.7% provides time to implement interventions — pre-dispute alert response, routing rebalancing, volume reduction on the affected MID — before the month closes and the program triggers.

Routing optimization depends on knowing which acquiring bank produces the best approval rates for specific transaction characteristics. Performance data shows approval rate by acquiring bank for each card BIN country (EU-issued Visa through bank A versus bank B), approval rate by transaction amount range, decline reason-code distribution by acquirer, and cascade retry success rates from one bank declined to another. This reveals where routing changes would improve aggregate approval rates — routing EU Visa above a given amount to the acquirer with better EU issuer relationships, for example. Without segmented performance data, routing configuration is based on assumptions rather than observed outcomes.

Yes. Export options include CSV export from the reporting interface for ad-hoc analysis, scheduled report delivery by email, a REST API for real-time programmatic access, webhook events for automated downstream processing, and structured data export compatible with Snowflake, BigQuery and Redshift warehouse ingestion. For BI integration, the platform connects to Tableau, Looker and Microsoft Power BI — so merchants can build payment-analytics dashboards within their existing BI environment rather than working exclusively in the analytics interface.

The platform consolidates data from all MIDs across all acquiring banks in a single interface. Merchants can view aggregate metrics — total volume, combined approval rate, portfolio-level chargeback ratio — alongside per-MID metrics like each account's individual ratio against threshold and each acquirer's approval-rate performance. The multi-MID view is essential for ratio management: merchants need to see which MID's ratio is approaching threshold so they can rebalance volume routing away from that account. Acquiring-bank reporting, by contrast, provides visibility only within each bank's own accounts.

Decline reason codes indicate why a card authorization was declined — the code is returned by the issuing bank and communicated via the acquiring bank. Different codes indicate different underlying causes: insufficient funds (cardholder account issue), do-not-honor (issuer discretionary decline), refer-to-card-issuer (issuer wants call-in authorization), reported stolen (stop payment), invalid card number (data error or expired card). For high-risk merchants, reason-code analysis matters because soft declines like do-not-honor and refer-to-issuer are candidates for cascade retry — and knowing which acquirer returns which codes informs whether routing to an alternative acquirer is likely to help. Hard declines don't benefit from retry.