Ask a payments team which metric they'd protect above all others, and the answer is almost always authorization rate. For a good reason - a single point of authorization rate improvement is a material revenue swing, which is why teams defend the metric so closely.

An 87% authorization rate doesn't tell you much on its own. It's an average across payment processors, Visa and Mastercard networks, domestic and cross-border, mobile and desktop transactions, etc., all rolled into one figure. And averages have a way of hiding the interesting parts. So let's understand why an overall figure doesn't give you the full picture.

Why a single authorization rate number misleads more than it informs

An aggregate authorization rate tells you the outcome. It tells you nothing about the cause.

Take that 87%. It could mean your domestic Visa rate is a healthy 94%, dragged down by cross-border Mastercard sitting at 72%. One weak segment pulling the average down. Or it could mean nothing is obviously broken, but several segments are each underperforming a little: mobile checkout a few points behind desktop, first-time customers a few points behind returning ones, high-value orders a few points behind mid-range. Same 87% on the dashboard but those are two completely different problems.

The first is concentrated, so the fix is targeted: cross-border routing and 3DS configuration. The second is multi-fold, and it sends you looking in several places at once - checkout friction on mobile, authentication settings for new customers, fraud scoring on high-value orders. One number, two very different repair jobs.

The authorization rate breakdown that every payment team should run weekly:

Running this breakdown once reveals where the variance is concentrated. Running it weekly shows when it moves, and that is your early warning system for connector degradation, issuer policy shifts, or checkout regressions.

Segmenting the rate shows you where the losses cluster. The next question is why those transactions failed because some declines are recoverable and some aren't, and the segment view can't tell the two apart. That distinction lives in the decline reason code.

The four decline types, and why conflating them produces wrong interventions

Every declined transaction carries a reason code. Most payment teams track decline rate as one number. The problem is that four types of declines have different causes and need different responses. Treating them as 1 metric means you end up fixing the wrong thing.

Issuer soft declines: The issuer temporarily cannot authorize (insufficient funds timing, bank processing error, velocity check). These are retriable. A different connector with a different acquiring relationship sometimes gets a different response from the same issuer on the same card. Routing to an alternate connector can recover a portion of these.

Issuer hard declines:The issuer has a firm reason to block the transaction (card reported lost, account flagged for fraud, card expired). These can’t be retired at the connector level. The intervention is upstream: better fraud screening to cut the volume of genuinely fraudulent attempts, and better card management prompts to reduce expired card declines.

Connector/PSP soft errors: The connector had a processing error, timeout, or configuration issue that prevented the authorization attempt from reaching the issuer at all. You can tell these apart from issuer declines because the response comes from the connector layer, not the card network. They are retriable on a different connector. A merchant who treats PSP errors the same as issuer hard declines is leaving recoverable transactions behind.

Authentication declines: The 3DS challenge failed or the risk score from the authentication layer blocked the transaction before it reached authorization. The fix is at the authentication configuration level, not the connector level.

One thing worth knowing before you start measuring: when connector soft errors and issuer hard declines get lumped into one "decline rate" metric, routing optimization looks less effective than it actually is. You're measuring routing performance against a pool that includes declines routing can't touch. Separate the four types first, then measure routing only against connector errors and issuer soft declines. That gives you an accurate read on what your routing is actually recovering.

How to find the revenue hiding in your decline data

The decline reason breakdown points to three specific recovery opportunities most merchants aren't pursuing.

1. Issuer soft declines by BIN range

Not all issuer soft declines are equal. Some BIN ranges, specific issuing banks, have systematically higher soft decline rates than others, often due to conservative fraud scoring parameters that particular issuers apply to online transactions. Identifying the BIN ranges generating disproportionate soft decline volume lets you make targeted decisions: route those BINs to a connector with a better acquiring relationship for that issuer, apply 3DS authentication to shift liability and reduce friction-driven declines, or prompt customers from those banks to add their card to a digital wallet (which carries higher issuer trust scores).

2. Connector performance variance by card type

Run authorization rates for Visa transactions side by side across your active connectors. Then run the same comparison for Mastercard and Amex. If Stripe consistently outperforms Adyen on Visa by 2–3 percentage points, but Adyen outperforms Stripe on Amex by 4–5 points, your routing configuration should reflect that. Most merchants configure routing based on cost or contractual commitments, not authorization rate performance by card type. The merchants who add authorization-rate-by-card-type as a routing input recover meaningful revenue on segments that were being sub-optimally routed.

3. Time-of-day and day-of-week patterns

Authorization rates shift across time. Issuer processing capacity, fraud team staffing, and bank system maintenance windows create predictable patterns in decline rates across the week and across the day. A payment analytics layer that tracks authorization rates by hour-of-day reveals whether your authorization rate dips at 2am (low issuer staffing for manual review queues) or at end-of-month (card limit resets). Not all patterns need a response, but knowing they exist prevents operations teams from filing support tickets about "authorization rate drops" that are actually expected cyclical behavior.

What good payment analytics infrastructure looks like

The merchants running authorization rate analytics effectively share one architectural property: they have a single layer that aggregates transaction data across all PSPs before analysis.

This matters because PSP-native analytics are inherently limited to that PSP's transaction volume. A merchant processing 60% through Stripe and 40% through Adyen who analyzes each PSP's dashboard separately, sees incomplete authorization rate data for every segment because each dashboard only knows about the transactions it processed. Cross-PSP authorization rate comparison. which connector performs better for which card type, is impossible without a normalized data layer that sees both.

The data that needs to flow into a meaningful payment analytics layer:

Juspay orchestrates payment flows for enterprise merchants including Amazon, Google, and HSBC across 150+ countries, processing 300 million daily transactions as of FY2025. One of the core functions of payment orchestration is exactly this: producing a unified transaction data layer across all connected PSPs, so that authorization rate analytics are cross-PSP by default rather than siloed by connector.

Merchants who do not have a cross-PSP analytics view are making routing, PSP selection, and authentication configuration decisions based on incomplete data. A routing rule built on single-PSP authorization rate data optimizes that PSP's transaction subset.it does not optimize the total authorization rate across the full transaction stream.

The authorization rate metrics that actually connect to revenue

Not all authorization rate metrics are equally actionable. These are the four that most directly translate to recoverable revenue.

Net authorization rate (gross minus retries). Gross authorization rate counts every attempt, including retry attempts on the same transaction. Net authorization rate counts unique transactions: did this customer's payment eventually succeed, across all attempts? Net auth rate is the number that reflects actual customer experience and actual revenue capture. A high gross rate driven by heavy retry volume may mask a low net rate. This means many customers are experiencing failed payment attempts before eventually getting through, or not getting through at all.

Issuer decline rate vs. PSP error rate. Separating declines that came from the issuing bank (the issuer said no) from errors that came from the PSP layer (the PSP couldn't route the request) reveals whether the problem is upstream (issuer relationship, 3DS configuration) or at the connector layer (routing, PSP health). These require different interventions and have different recovery ceilings.

Authorization rate by first attempt vs. retry. What percentage of eventual successes required a retry? A high retry-to-success rate means your first-attempt routing is underperforming. This means the right connector is not being selected on the first attempt often enough. This is the routing optimization input: if 30% of your eventual authorizations require a retry, there is routing configuration work that could push more of those to first-attempt success.

Decline rate change over time on a stable transaction segment. Authorization rates on a fixed segment like domestic Visa, returning customers, and mid-range ticket should be relatively stable week over week. An unexplained shift in decline rate on a segment that hasn't changed in composition is an early signal of connector degradation, issuer policy change, or fraud score recalibration. Tracking segmented authorization rate over time is the monitoring layer; the aggregate rate is too noisy to catch these signals early.

Key Takeaways

• A single aggregate authorization rate number blends variance that spans 15–25 percentage points across segments.
• The four decline types (issuer soft, issuer hard, connector error, authentication) require different interventions; conflating them produces wrong remediation
• Connector performance varies by card type. Stripe may outperform Adyen on Visa while Adyen outperforms on Amex; routing should reflect this
• Cross-PSP authorization rate analytics require a normalized data layer that sees all connectors;PSP-native dashboards cannot provide this
• Net authorization rate (unique transactions eventually authorized) is more actionable than gross rate (all attempts including retries)
• Segmented authorization rate tracked over time is the early warning system for connector degradation and issuer policy changes

Frequently Asked Questions

What is authorization rate in payments?

Authorization rate is the percentage of payment attempts that are successfully authorized by the issuing bank. A 90% authorization rate means 90 out of 100 payment attempts are approved. The metric matters because every declined authorization is either a lost sale or a friction event,.The causes of declines (issuer policy, connector errors, authentication failures, fraud scoring) have different remediation strategies that a single aggregate number cannot reveal.

Why does authorization rate vary by payment method and geography?

Authorization rates vary because different card networks have different fraud scoring models, different issuers have different risk tolerance parameters, and different connectors have different acquiring relationships with different banks. A Visa card issued by one bank may authorize at a higher rate than a Mastercard issued by a different bank, for the same merchant, because of differences in how those issuers evaluate online transaction risk. Geography adds further variance: cross-border transactions are scored differently than domestic ones, and markets with high fraud prevalence have more conservative issuer approval parameters.

What should I do if my authorization rate drops?

First, break it down by the five dimensions: payment method, connector, geography, customer type, and ticket size. Identify which segment drove the change. If the drop is on one connector, check that connector's health status because it may be experiencing degradation. If the drop is on one payment method across all connectors, the issue is likely issuer-level (card network policy change or issuer fraud model update). If the drop is on cross-border transactions, review your 3DS configuration and cross-border routing setup. A drop in the aggregate rate that is equally distributed across all segments is rarer and warrants a broader infrastructure investigation.

How do I compare authorization rates across Stripe, Adyen, and Worldpay?

You need a data layer that normalizes transaction records from all three connectors into a consistent schema before analysis. PSP-native dashboards only show their own transaction data. Stripe's dashboard cannot tell you how Adyen performs on the same card types. An orchestration platform like Hyperswitch provides cross-PSP authorization rate data in a single analytics view, enabling direct connector-to-connector comparison by card type, currency, and geography. Without normalization, you're comparing different transaction mixes, not equivalent performance.

What is net authorization rate vs. gross authorization rate?

Gross authorization rate counts all payment attempts, including retry attempts on the same customer transaction. Net authorization rate counts unique transactions, for example did this customer's payment succeed across all attempts? If a transaction declines on Stripe and succeeds on the Adyen retry, gross rate counts two attempts (one failure, one success); net rate counts one eventual success. Net rate reflects customer experience and actual revenue capture more accurately. A high gross rate driven by heavy retries may still represent significant customer friction.

How does BIN-level analysis improve authorization rates?

BIN (Bank Identification Number) analysis identifies which issuing banks are generating a disproportionate decline in volume. Specific issuers apply more conservative fraud scoring to online transactions than others. This results in higher soft decline rates for cards from those issuers. Once identified, BIN-level data enables targeted interventions: routing those BINs to a connector with a better acquiring relationship for that issuer, applying 3DS authentication to shift liability, or prompting those customers toward payment methods (wallets, bank transfer) that carry higher issuer trust scores. BIN analysis converts the aggregate decline rate into a list of specific issuers and their remediation paths.