Authorization Rates by Issuer
Authorization Rates by Issuer: How Merchants Should Diagnose Issuing-Bank Performance Authorization rates can differ materially between card issuers, but a lower rate for one issuer does not automatically mean that the issuer is making worse decisions. An apparent issuer gap may
Authorization Rates by Issuer: How Merchants Should Diagnose Issuing-Bank Performance
Authorization rates can differ materially between card issuers, but a lower rate for one issuer does not automatically mean that the issuer is making worse decisions.
An apparent issuer gap may instead reflect:
Different customer or card-product populations
Cross-border versus domestic transaction exposure
Debit, credit, prepaid, or commercial-card mix
Authentication configuration
Recurring-payment behavior
Acquirer and routing differences
Merchant fraud controls
Transaction-data quality
Retry behavior
Incorrect or outdated issuer identification
Small or unstable samples
The merchant’s job is therefore not to create a league table of “good” and “bad” banks. It is to determine whether transactions associated with a specific issuer or account range are underperforming after relevant differences have been controlled, identify where in the payment funnel the divergence begins, and quantify whether a fix would create meaningful net value.
A useful issuer investigation follows six questions:
Identity: Which issuer and account ranges are actually being analyzed?
Comparability: Are the transactions being compared genuinely similar?
Location: At what stage does performance begin to diverge?
Pattern: Which response, authentication, routing, or risk signals explain the gap?
Value: Is the opportunity economically important?
Action: Which merchant or provider change can be tested safely?
What does “authorization rate by issuer” mean?
An issuer authorization rate is the percentage of submitted authorization requests associated with a defined issuing institution or account-range population that receive an approval response.
The simplest formula is:
Issuer authorization rate = approved issuer-submitted requests ÷ total issuer-submitted requests × 100
Suppose a merchant submits 20,000 first-attempt authorization requests associated with Issuer A and receives 17,600 approvals:
17,600 ÷ 20,000 × 100 = 88%
That rate is useful only if the merchant defines the population precisely.
A defensible calculation should specify:
Whether only first attempts are counted
Whether retries are included
Whether the rate is request-based or deduplicated by payment intent
Which merchant entities and Merchant IDs are included
Which acquirers and routes are included
Whether technical failures are excluded
Whether authentication failures are excluded
Whether partial approvals count as approvals
Which time period is covered
Which issuing account ranges map to the issuer
Which card products and transaction types are included
Without those details, the issuer rate may be directionally interesting but analytically weak.
Why issuer approval rates differ
Issuers make authorization decisions using their own account information, controls, risk models, cardholder history, transaction context, and applicable network and regulatory requirements.
Issuer performance may differ for legitimate structural reasons.
Cardholder and account composition
Two issuers can serve very different customer populations.
One issuer’s merchant traffic might contain more:
Low-balance debit accounts
Prepaid products
First-time online shoppers
International travelers
Commercial cards
Youth or student products
Cards with international-use restrictions
High-risk or high-velocity customers
Another issuer’s traffic may consist mainly of established credit-card customers making familiar domestic purchases.
Comparing their blended rates without accounting for product and customer mix can produce a misleading conclusion.
Issuer risk strategy
Issuers differ in how they balance fraud prevention, customer friction, and approval.
An issuer may respond more conservatively to:
New merchants
Cross-border ecommerce
High-value digital goods
Unfamiliar devices
Rapid repeat attempts
Merchant-initiated transactions
Unauthenticated card-not-present activity
Transactions with weak or inconsistent data
Issuer policies also change over time. A pattern identified during one quarter should not be treated as a permanent institutional characteristic.
Card-product support and controls
Cards issued by one banking group may not behave uniformly.
A group may issue:
Debit cards
Credit cards
Prepaid cards
Premium products
Commercial cards
Virtual cards
Domestic-only products
Co-branded portfolios
These products may use different processors, account ranges, risk strategies, authentication systems, and customer controls.
An issuer-level average can therefore hide meaningful account-range differences.
Authentication behavior
EMV 3-D Secure allows merchants and issuers to exchange transaction, payment-method, and device data for cardholder authentication. Issuers can approve a frictionless flow or require a customer challenge depending on the transaction and issuer’s assessment. (EMVCo)
Issuer-level differences may appear in:
Frictionless authentication rate
Challenge rate
Challenge-completion rate
Authentication failure rate
Issuer access-control-server availability
Authorization after successful authentication
Authorization after attempted authentication
A low issuer authorization rate may therefore begin as an authentication problem rather than an authorization-decision problem.
Cross-border, currency, and acquiring context
The same issuer can perform differently depending on:
Acquiring country
Merchant entity
Merchant ID
Transaction currency
Settlement structure
Domestic versus cross-border classification
Network route
Acquirer
Processor
Authentication configuration
A merchant should not describe an issuer as underperforming until these route-level differences have been examined.
Data quality and transaction classification
Issuer behavior can also vary because requests differ in quality or classification.
Relevant fields may include:
Merchant name and location
Merchant Category Code
Amount and currency
Stored-credential indicators
Customer-initiated or merchant-initiated classification
Recurring-payment indicators
Authentication values
Previous transaction references
Token information
Billing information
Device and transaction context
A malformed or incomplete request can create an issuer-specific pattern if that issuer reacts more strongly to the missing information.
How to identify an issuer accurately
Issuer analysis begins with identity resolution. If the issuer mapping is wrong, every later conclusion is unreliable.
BIN, IIN, and account-range data
The first digits of a card’s Primary Account Number identify the issuing program under the applicable numbering structure.
ISO/IEC 7812 defines the issuer-identification numbering system. The current standard revised the IIN length from six to eight digits. (ISO)
Visa notes that both six- and eight-digit BINs continue to exist and that product characteristics may be defined at the eight-digit level. Systems that rely only on the first six digits can therefore misidentify card product or issuer attributes. (Visa)
Mastercard similarly publishes account-range resources intended to provide accurate and current assignment information and reduce erroneous declines caused by inaccurate BIN or account-range data. (Mastercard)
For merchant analytics, this means:
Do not assume every six-digit prefix maps cleanly to one current product or issuer.
Support both six- and eight-digit IIN/BIN structures.
Use current, licensed, or authoritative account-range data.
Preserve the source and effective date of enrichment.
Re-enrich historical data when mappings materially change.
Do not use card-number digits beyond what is necessary and permitted.
Issuer-name normalization
The same institution may appear under several names:
Full legal name
Consumer brand
Parent company
Subsidiary
Acquired institution
Processing sponsor
Co-brand partner
Regional affiliate
Abbreviated processor-provided name
Legacy name retained in an account-range file
A normalized issuer model should preserve at least three levels:
Field
Purpose
Raw issuer label
Original value supplied by provider or enrichment source
Normalized issuing entity
Current issuing legal entity or best available issuer identity
Banking-group parent
Parent group used for consolidated analysis, where appropriate
Do not replace the raw value. Preserve it for traceability.
Mergers and acquisitions
When banks merge, account ranges may not move immediately to the new entity’s systems or risk strategy.
Possible states include:
Legacy ranges still processed by the former platform
Newly issued ranges using the acquiring bank’s systems
Different subsidiaries retaining separate licenses
Co-branded portfolios continuing under separate processing
Gradual migration over months or years
A merchant should therefore avoid assuming that all cards owned by one parent company share the same decisioning.
During normalization, store:
Effective date of corporate change
Original issuer identity
Current legal ownership
Processor or platform where known
Account-range-specific mapping
Confidence level of the mapping
Subsidiaries and regional entities
A banking group may operate separate issuers in different countries. Treating the group as one global issuer can obscure:
Local regulation
Domestic card products
Authentication systems
Currency behavior
Risk models
Processing platforms
Issuer analysis should usually start at the most specific reliable account-range and country level, then roll up to the legal entity and parent group.
A practical issuer hierarchy
A useful hierarchy is:
Account range → card product → issuing entity → issuing country → banking group
This allows the merchant to answer both narrow and broad questions:
Is one account range failing?
Is the issue limited to debit cards?
Does the whole legal entity underperform?
Is the pattern country-specific?
Does the parent group show a consistent pattern?
Why issuer comparisons are often misleading
A table of issuer rates is easy to produce. A fair comparison is much harder.
Different transaction populations
Suppose Issuer A has an 84% approval rate and Issuer B has a 91% rate.
That seven-point gap may disappear after discovering that:
Issuer A traffic is 70% cross-border.
Issuer B traffic is 90% domestic.
Issuer A has more prepaid and debit cards.
Issuer A customers have a higher average order value.
Issuer A traffic contains more first-time buyers.
Issuer B receives more authenticated returning-customer traffic.
The correct comparison is not necessarily Issuer A versus Issuer B. It may be:
Issuer A domestic authenticated debit first attempts versus equivalent Issuer B transactions.
Inconsistent denominators
One provider may report:
Approvals ÷ all gateway attempts
Another may report:
Issuer approvals ÷ issuer responses
A merchant dashboard may report:
Unique payments eventually approved ÷ unique payment intents
These are different metrics.
Issuer comparisons should preferably use:
First authorization attempts
Confirmed requests submitted to an issuer decision
Consistent technical-error treatment
Consistent authentication treatment
Consistent partial-approval treatment
Consistent deduplication
Retry distortion
Retries can disproportionately affect issuers with more initial declines.
If every retry is counted as another attempt, an issuer with repeated unsuccessful submissions can appear worse because the denominator expands.
Track separately:
First-attempt authorization rate
Eventual unique-payment approval rate
Average attempts per approved payment
Retry recovery rate
Do-not-retry compliance
Revenue recovered by retry
Visa organizes certain decline responses into categories that guide whether and how merchants may reattempt transactions, and advises merchants to obtain the relevant handling guidance through their acquirers or processors. (Visa)
Retry practices must follow current network, issuer, processor, regional, and transaction-specific rules. A merchant should never infer retry eligibility solely from an internally assigned “soft decline” label.
Small sample sizes
Issuer rates can move sharply when transaction volume is low.
For example:
9 approvals from 10 requests = 90%
900 approvals from 1,000 requests = 90%
The point estimate is identical, but the second result is much more stable.
Confidence intervals quantify the uncertainty around a sampled proportion. NIST notes that normal approximations require sufficiently large samples and that exact binomial methods are more appropriate for small samples. (NIST)
Merchants should:
Display transaction counts beside percentages.
Suppress or flag very small samples.
Use confidence intervals.
Compare changes over sufficient periods.
Avoid ranking issuers based on a handful of transactions.
Issuer concentration and merchant exposure
Issuer concentration determines how economically important an issuer-specific issue is.
A merchant may have:
A large rate gap affecting a tiny issuer
A small rate gap affecting a dominant issuer
Several moderate gaps across a concentrated banking market
The second or third situation may represent more recoverable revenue.
Measuring issuer concentration
Track each issuer’s share of:
Submitted authorization attempts
Unique customers
Transaction value
Approved revenue
Declined revenue
Recurring-payment portfolio
Target market
A simple concentration view might show:
Issuer
Share of attempts
Approval rate
Portfolio baseline
Rate gap
Declined value
Issuer A
28%
86%
90%
-4 pp
$420,000
Issuer B
14%
82%
89%
-7 pp
$310,000
Issuer C
4%
74%
88%
-14 pp
$75,000
Issuer C has the largest percentage gap, but Issuer A may represent the largest commercial opportunity.
Estimating addressable value
A preliminary opportunity estimate is:
Potential additional approvals = eligible attempts × credible approval-rate gap
For a monetary estimate:
Potential approved value = eligible declined value × estimated recoverable share
This is not a forecast of settled revenue.
Adjust for:
Fraud losses
Chargebacks
Capture failure
Refunds
processing cost
authentication cost
engineering effort
provider fees
uncertainty in the estimated uplift
Do not assume every difference from the portfolio average is recoverable. Some gaps reflect legitimate cardholder, product, or account differences.
The issuer-performance investigation waterfall
Use the following waterfall before concluding that an issuer is responsible.
Step 1: Confirm issuer identity
Check:
Account-range data source
Six- versus eight-digit handling
Issuing country
Product type
Legal entity
Parent group
Mapping date
Merger or portfolio changes
Stop condition: If mapping is outdated or uncertain, correct the mapping before further analysis.
Step 2: Confirm the metric
Define:
Numerator
Denominator
First attempt or all attempts
Unique-payment grouping
Technical-error treatment
Authentication treatment
Time period
Stop condition: If issuer populations use different definitions, rebuild the comparison.
Step 3: Match comparable cohorts
Control for:
Country
Currency
Merchant entity
Acquirer
Route
Card network
Funding type
Transaction type
Order value
Customer tenure
Authentication result
Recurring status
Token status
Device and channel
Fraud treatment
Stop condition: If the issuer has a materially different transaction mix, compare within matched segments.
Step 4: Locate the divergence
Compare issuer performance across:
Merchant fraud screening
Authentication initiation
Authentication completion
Authorization submission
Issuer response
Retry recovery
Capture
Interpretation: If the divergence occurs before issuer submission, it is not primarily an issuer-authorization problem.
Step 5: Analyze response patterns
Evaluate:
Raw response codes
Normalized categories
Advice indicators
Generic declines
Insufficient-funds responses
Authentication-related responses
Invalid-data responses
Issuer-unavailable responses
Account or card restrictions
Mastercard notes that response descriptions can differ and advises developers not to code directly against plain-language descriptions. (Mastercard Developers)
Stop condition: Do not infer one precise root cause from a generic decline description.
Step 6: Compare routes and providers
For the same issuer and matched cohort, compare:
Acquirer
Processor or PSP
Merchant ID
Domestic versus cross-border route
Authentication provider
Tokenized versus non-tokenized credential
Currency
Data completeness
Interpretation: If one route underperforms while another does not, the issue may involve routing, acquirer configuration, or message handling—not the issuer alone.
Step 7: Quantify confidence and value
Assess:
Sample size
Confidence interval
Consistency over time
Declined transaction value
Customer count
Expected net benefit
Implementation effort
Step 8: Form and test a hypothesis
Examples:
Authentication challenge completion is lower for one issuer.
An acquirer is formatting recurring indicators incorrectly.
One account range is misclassified as prepaid.
Cross-border currency presentation is causing restrictions.
A merchant fraud rule disproportionately blocks cards from one issuer.
Network-token coverage differs across issuer populations.
Test one principal change at a time where operationally possible.
Decline-code and response-pattern analysis
Issuer-rate investigation should examine the distribution of responses, not only the overall decline rate.
Build a response distribution
For each issuer, calculate the percentage of issuer responses that fall into categories such as:
Approved
Insufficient funds or credit
Generic issuer decline
Authentication required or failed
Invalid or outdated credential
Restricted card or transaction
Suspected fraud
Issuer unavailable
Data or format issue
Do not retry
Other or unknown
The exact taxonomy should reflect the data available through the merchant’s providers.
Preserve both:
Raw provider or network response
Merchant-normalized analytical category
Compare response mix, not just volume
Suppose two issuers both approve 85%.
Issuer A’s declines are mostly insufficient funds.
Issuer B’s declines are dominated by authentication-required and generic issuer responses.
The headline rate is identical, but the remediation opportunity differs:
Issuer A may offer limited merchant-controlled recovery.
Issuer B may justify investigating authentication, data, or routing.
Watch for response-code translation loss
A PSP or processor may translate network responses into a smaller set of merchant-facing categories.
For example, several distinct responses may become:
Generic decline
This normalization helps reporting but reduces diagnostic detail.
Ask providers:
Which raw response fields are retained?
Are network and issuer responses distinguishable?
Are retry or advice indicators available?
Has the mapping changed over time?
Are authentication and authorization errors separated?
Are technical timeouts grouped with declines?
Do not interpret “do not honor” as a diagnosis
A generic response indicates that the issuer did not approve the request. It does not prove:
Fraud
Insufficient funds
Incorrect MCC
Cross-border aversion
Poor routing
Authentication failure
Customer behavior
Treat generic declines as an investigation category, not a root-cause conclusion.
Authentication performance by issuer
Authentication should be analyzed as a separate issuer-level funnel.
For each issuer, measure:
Eligible transactions
Authentication initiated
Authentication completed
Frictionless outcome
Challenge requested
Challenge completed
Authentication failed
Authentication unavailable
Authorization submitted after authentication
Authorization approved after authentication
An authentication waterfall
A useful issuer view is:
Eligible transactions
→ 3DS initiated
→ issuer available
→ frictionless or challenged
→ challenge completed
→ authentication successful
→ authorization submitted
→ authorization approved
This identifies whether an issuer’s weakness begins with:
High challenge frequency
Low challenge completion
Technical unavailability
Authentication failure
Low authorization after successful authentication
Questions to ask
Does the issuer challenge more often than peers for comparable traffic?
Is challenge completion lower on mobile?
Are one-time passcodes delayed or abandoned?
Does the issuer’s authentication system show elevated unavailability?
Are all recommended 3DS data fields reaching the issuer?
Is the authentication result passed correctly into authorization?
Does performance differ by 3DS version, device, or browser?
Are exemptions or exclusions represented correctly where applicable?
Do not assume that a successful authentication guarantees authorization. The issuer still makes a separate authorization decision.
Recurring and credential-on-file performance by issuer
Issuer analysis should separate:
Initial customer-initiated payment
Subsequent merchant-initiated payment
Fixed recurring payment
Unscheduled credential-on-file payment
Retry after decline
Credential update
Tokenized credential
Primary account number
Recurring portfolios can vary by issuer because of:
Credential age
Card reissuance
Expiration
Account closure
Stored-credential classification
Missing original-transaction references
Recurring transaction limits
Merchant-initiated transaction treatment
Network-token lifecycle behavior
Account updater coverage
Useful recurring metrics
By issuer, track:
Initial-payment authorization rate
Renewal first-attempt authorization rate
Eventual renewal recovery rate
Expired-credential decline rate
Account-updater match rate
Token coverage
Approval rate by credential type
Approval rate by days since initial payment
Retry recovery by response category
Customer payment-update completion
A low recurring rate for one issuer may reflect an older customer cohort or lower updater coverage rather than issuer hostility toward the merchant.
Cross-border, currency, and acquiring context
Every issuer scorecard should include acquiring context.
Segment by:
Issuer country
Customer country
Acquirer country
Merchant entity
Merchant ID
Transaction currency
Local versus cross-border classification
Processor
Route
Card network
A bank may appear to underperform only because most of its traffic is routed cross-border while peer issuers are primarily domestic.
Route-level comparison
For a sufficiently large issuer population, compare:
Route
First-attempt rate
Technical success
Authentication completion
Generic decline rate
Volume
Acquirer A, local
91%
99.8%
94%
3%
30,000
Acquirer B, cross-border
85%
99.6%
91%
7%
25,000
Acquirer C, cross-border
86%
98.9%
92%
6%
6,000
This does not prove that local acquiring caused the difference. The cohorts must still be matched for transaction and customer characteristics.
Fraud controls and merchant-side effects
An issuer-level rate can be influenced before the request reaches the issuer.
Suppose cards associated with Issuer A are disproportionately used by customers in a market that the merchant’s fraud system treats as high risk.
The merchant may see:
More pre-authorization blocks
More forced authentication
More manual review
Fewer issuer submissions
An artificially high issuer authorization rate because only the safest traffic reaches the issuer
Or the opposite may occur:
The merchant sends more risky Issuer A traffic to authorization.
The issuer declines it.
Issuer A appears weak even though the merchant’s submission policy differs.
Measure the full issuer funnel
For every issuer, track:
Checkout payment attempts
Merchant risk blocks
Authentication attempts
Authentication completions
Authorization submissions
Issuer approvals
Captures
Confirmed fraud
Chargebacks
This allows teams to distinguish:
Merchant fraud acceptance rate
Authentication success rate
Issuer authorization rate
End-to-end payment success
Building an issuer scorecard
An issuer scorecard should combine performance, diagnostic evidence, concentration, and actionability.
Issuer scorecard template
Category
Metric
Current period
Prior period
Comparable baseline
Notes
Identity
Normalized issuer/entity
—
—
—
Include mapping source/date
Exposure
First attempts
Show volume
Exposure
Attempt value
Local currency and normalized value
Approval
First-attempt authorization rate
Primary issuer KPI
Approval
Eventual unique-payment approval
After eligible recovery
Reliability
Technical success rate
Before issuer response
Authentication
Authentication completion
Separate challenge and frictionless
Authentication
Challenge rate
By device and market
Responses
Generic-decline rate
Share of issuer responses
Responses
Insufficient-funds rate
Interpret cautiously
Responses
Authentication-related rate
Verify taxonomy
Credentials
Token coverage
Eligible transactions
Recurring
Renewal first-attempt rate
Separate from initial
Routing
Best/worst route gap
Matched cohorts
Risk
Merchant pre-auth block rate
Not issuer decline
Outcome
Capture rate
Approved requests
Economics
Declined value
Gross opportunity
Economics
Estimated addressable value
Risk-adjusted estimate
Confidence
Confidence interval
Flag small samples
Action
Current hypothesis
—
—
—
Evidence-based
Action
Owner and next test
—
—
—
Named team
Use distributions and medians
A simple issuer average can hide volatility.
Consider adding:
Daily or weekly median rate
Interquartile range
10th and 90th percentiles
Confidence interval
Volume-weighted rate
Unweighted segment median
Rate by account range
Rate by route
A weighted average shows portfolio impact. An unweighted segment view can reveal whether one large account range dominates the result.
Issuer symptoms, possible causes, evidence, and ownership
Symptom
Possible causes
Evidence needed
Primary owner
One issuer falls suddenly
Issuer policy change, route change, outage, mapping change, fraud attack
Time series, deployment log, route data, raw responses
Payments operations
One account range underperforms
Product restriction, outdated range mapping, specific processor, portfolio difference
Current account-range data, product type, issuer entity
Data and payments
High authentication challenge rate
Issuer risk policy, incomplete data, customer mix
3DS fields, challenge rate, matched cohort
Payments product
Low challenge completion
OTP issue, mobile UX, issuer ACS problem, customer behavior
Device data, challenge abandonment, issuer availability
Product and engineering
Low approval after successful authentication
Issuer risk, route, amount, currency, merchant configuration
Auth result, authorization request, route and response codes
Payments operations
High generic-decline share
Issuer conservatism, thin data, cross-border context, normalization loss
Raw responses, data completeness, route comparison
PSP/acquirer liaison
High insufficient-funds share
Account/customer mix, billing timing, order value
Funding-type mix, amount distribution, recurring cohort
Finance and subscriptions
Poor recurring approval
Stale credentials, incorrect MIT indicators, weak token/updater coverage
Credential age, updater results, stored-credential fields
Billing engineering
One acquirer performs worse for the issuer
Route configuration, formatting, merchant ID, connectivity
Matched route test, raw request fields
Routing team/provider
High merchant risk blocks
Overly broad fraud rule, geographic or BIN rule
Rule-level blocks, confirmed fraud, customer outcomes
Fraud team
Technical failures concentrated by issuer
Incorrect routing or stale BIN/account-range data
Routing table version, technical codes, provider traces
Engineering/provider
Higher fraud after approvals
Risk-selection difference, issuer authentication behavior
Fraud and chargeback outcomes by issuer and route
Fraud and finance
Distinguishing an issuer issue from another payment problem
Before labeling a pattern as an issuer problem, test alternative explanations.
It is more likely an issuer-specific issue when:
The same issuer underperforms across several acquirers and routes.
The pattern persists within matched domestic, currency, product, and transaction cohorts.
The divergence begins at issuer response rather than before submission.
Response distributions differ materially from comparable issuers.
Authentication and technical performance are normal.
The issuer pattern is consistent across merchant IDs.
The gap is sustained over time and supported by adequate volume.
It is more likely an acquirer or routing issue when:
The issuer underperforms through one route but not another.
Technical errors or timeouts are concentrated on one provider.
Response-code detail differs by provider.
The issue appears after a routing change.
Merchant IDs or transaction classifications differ.
It is more likely an authentication issue when:
Challenge rates or failures are elevated.
Authorization performance is normal after successful authentication.
The problem is device-, browser-, or market-specific.
Issuer authentication-system availability is weak.
It is more likely a merchant fraud issue when:
The performance gap begins before authorization.
One issuer population receives more blocks or step-up verification.
A BIN-, country-, device-, or value-based rule disproportionately affects the issuer.
The issuer rate appears strong only because risky requests are filtered out.
It is more likely a data-quality issue when:
Invalid-data or format responses are elevated.
Stored-credential indicators differ by integration.
One account range is incorrectly classified.
Currency, amount, or merchant data is inconsistent.
The pattern began after a deployment.
It is more likely a transaction-mix issue when:
The issuer has more prepaid, debit, cross-border, recurring, or high-value traffic.
The gap narrows or disappears after cohort matching.
The issuer’s customer population differs materially from peers.
Escalating an issuer-specific issue
Merchants usually do not have a direct operational channel to an issuer’s authorization team.
The practical escalation path is commonly:
Merchant → PSP/processor/acquirer → card network or issuer relationship channel
The exact route depends on contracts, market, volume, and provider structure.
A strong escalation should be evidence-driven and narrowly scoped.
Sample provider escalation packet
Executive summary
Affected issuer or account ranges
Affected country, currency, and card network
Start date
Current impact
Reason for suspected issuer-specific behavior
Requested provider action
Identity details
Raw issuer name
Normalized issuer entity
Parent group
Issuing country
BIN/IIN or masked account-range identifiers
Account-range source and update date
Product or funding type
Do not include unnecessary full card data.
Metric definition
State:
Numerator
Denominator
First-attempt or eventual rate
Retry treatment
Technical-error treatment
Timezone
Reporting period
Transaction cohort
Describe:
Merchant entity and MID
Acquirer and processor
Transaction type
Customer- or merchant-initiated status
Recurring status
Currency
Average order value
Authentication flow
Credential type
Customer country
Device or channel
Performance evidence
Provide:
Daily or weekly rate trend
Transaction counts
Confidence interval
Comparable issuer or historical baseline
Raw and normalized response distribution
Authentication waterfall
Route comparison
Technical success rate
Capture rate
Sample transactions
Provide a small set of traceable examples containing:
Provider transaction ID
Merchant reference
Masked credential reference
Timestamp
Amount and currency
Route
Authentication result
Raw response
Normalized response
Final status
Changes ruled out
Document:
No relevant merchant deployment
No fraud-rule change
No major customer-mix change
No routing change
No currency change
No account-range mapping issue
No known provider outage
Specific questions
Examples:
Are the affected requests reaching the issuer?
Has the provider observed similar behavior across other merchants?
Has message formatting changed?
Are stored-credential or authentication values being transmitted correctly?
Is a network or issuer incident known?
Can the issue be escalated through the acquirer or network?
Is another eligible route available for a controlled test?
“Please improve our approval rate” is too broad. A precise evidence packet is more likely to produce a useful investigation.
Designing controlled remediation tests
A remediation test should isolate a plausible cause without increasing fraud or violating retry restrictions.
Form a specific hypothesis
Weak hypothesis:
Issuer A is bad.
Testable hypothesis:
Authenticated first-attempt ecommerce transactions from Issuer A are approved less often through Acquirer X than through Acquirer Y because the two routes transmit different transaction or authentication context.
Define the eligible population
Specify:
Issuer/account ranges
Country
Network
Card product
Transaction type
Currency
Merchant entity
Authentication result
Customer type
Order-value range
Device or channel
First attempts only
Change one primary variable
Potential test variables include:
Acquirer or route
Local versus cross-border acquiring
Transaction-data completeness
Network token versus eligible PAN credential
Authentication configuration
Merchant ID configuration
Stored-credential indicators
Customer messaging after authentication request
Avoid simultaneously changing route, fraud rules, checkout, currency, and authentication unless the configuration cannot be separated. If several changes are bundled, describe the result as a configuration test rather than attributing it to one factor.
Predefine success metrics
Primary:
First-attempt issuer authorization rate
Guardrails:
Fraud rate
Chargeback rate
Authentication completion
Technical failure
Checkout conversion
Capture rate
Processing cost
Customer-support contacts
Duplicate attempts
Use concurrent controls when possible
A before-and-after comparison can be distorted by:
Seasonality
Pay cycles
promotions
issuer outages
fraud attacks
customer-mix changes
A concurrent control group is generally stronger when the merchant can split comparable eligible traffic safely and compliantly.
Do not cascade prohibited declines
A route test should focus on selecting the first route for eligible new authorization attempts. It should not automatically resubmit an issuer decline through another path when applicable network or provider guidance prohibits another attempt.
Developer and data-team guidance
Issuer analysis depends on clean lineage across payments, authentication, fraud, and routing systems.
Recommended identifiers
Capture:
Payment-intent ID
Order ID
Authorization-attempt ID
Provider transaction ID
Acquirer reference
Idempotency key
Retry-parent ID
Authentication transaction ID
Capture ID
Customer ID or privacy-preserving stable reference
Recommended issuer and card fields
Where necessary and permitted:
Raw issuer label
Normalized issuer entity
Parent banking group
Issuing country
BIN/IIN or account-range token/reference
Mapping source
Mapping effective date
Mapping confidence
Card network
Funding type
Product type
Tokenized versus PAN credential
Avoid retaining unnecessary cardholder data. Scope storage and access according to applicable PCI DSS, privacy, security, contractual, and retention requirements.
Authorization fields
Attempt timestamp
Amount
Currency
Merchant entity
Merchant ID
Acquirer
Processor/PSP
Route
Acquiring country
Customer-initiated or merchant-initiated indicator
Recurring indicator
Stored-credential fields
Raw response
Normalized category
Advice or retry indicator
Technical status
Response latency
Final authorization state
Authentication fields
3DS version
Authentication initiated
Frictionless or challenge
Challenge result
Authentication status
Issuer/ACS availability
Authentication value presence
Device channel
Browser or app channel
Exemption or exclusion indicator where applicable
Authorization linkage
Fraud fields
Pre-authorization block
Risk score
Rule identifiers
Review result
Step-up action
Confirmed fraud
Chargeback outcome
Do not expose confidential fraud logic broadly.
Normalization controls
Keep raw and normalized values.
Version the response-code mapping.
Version issuer mappings.
Normalize timestamps to a common analytical timezone while retaining originals.
Document partial approval treatment.
Separate unknown, timeout, decline, and technical failure.
Deduplicate using payment lineage rather than amount and timestamp alone.
Reconcile synchronous responses with asynchronous webhooks.
Common analytical mistakes
Ranking issuers without controlling transaction mix
A low blended rate may reflect more difficult transactions rather than weaker issuer performance.
Treating the issuer name as perfectly accurate
Issuer identity can be affected by outdated account-range data, eight-digit BIN changes, mergers, sponsorship, and provider normalization.
Combining first attempts and retries
Retry-heavy issuers can be penalized by an expanded denominator.
Confusing pre-authorization blocks with issuer declines
Merchant fraud decisions and authentication abandonment are not issuer authorization decisions.
Treating generic declines as proof of fraud or insufficient funds
A broad response does not reveal one definitive cause.
Ignoring account-range and card-product differences
One banking group can contain multiple issuing entities and portfolios with different behavior.
Comparing different providers without route controls
Provider performance can differ because of acquirer, merchant ID, geography, customer mix, and authentication—not only provider quality.
Ignoring sample uncertainty
A large percentage difference in a small sample may not be reliable.
Looking only at percentage-point gaps
Commercial importance depends on volume, value, recoverability, cost, fraud, and effort.
Assuming historical issuer behavior will persist
Issuer policies, portfolios, systems, and customer populations change.
Prioritizing issuer investigations
A practical prioritization score can combine:
Declined transaction value
Issuer traffic share
Credible approval gap
Generic or potentially addressable decline share
Statistical confidence
Route alternatives
Implementation effort
Fraud risk
Strategic market importance
One possible framework is:
Priority = economic exposure × evidence strength × actionability
Use qualitative or normalized scores rather than presenting the result as a guaranteed revenue forecast.
High-priority investigations usually have:
Substantial volume
A sustained matched-cohort gap
Clear response or funnel divergence
A plausible merchant- or provider-controlled remedy
Acceptable fraud and compliance risk
Issuer-level analysis becomes most useful when it is connected to the broader payment setup: acquiring, routing, authentication, local payment methods, recurring-payment operations, fraud controls, and market expansion.
No provider can control issuer decisioning or guarantee an approval-rate increase. The objective is to give legitimate transactions the most appropriate payment path and the strongest accurate context available.
Frequently asked questions
What is an authorization rate by issuer?
It is the percentage of submitted authorization requests associated with a defined card issuer or account-range population that receive approval. Merchants should specify the denominator, retry treatment, time period, route, and transaction cohort.
Why do some issuing banks approve fewer transactions?
Possible reasons include cardholder and product mix, issuer risk strategy, authentication behavior, cross-border exposure, transaction limits, available funds, account controls, data quality, acquiring route, and merchant configuration. A lower rate does not by itself prove one cause.
How can a merchant identify the card issuer?
Merchants typically use current BIN/IIN or account-range data supplied by a network, provider, or authorized data source. Systems should support current six- and eight-digit structures and account for mergers, subsidiaries, and portfolio changes.
Should merchants compare issuer rates directly?
Only after matching relevant variables such as country, currency, card product, acquirer, route, transaction type, authentication, customer type, order value, fraud treatment, and time period.
How much volume is needed before an issuer rate is reliable?
There is no universal transaction threshold. Reliability depends on the observed rate, desired precision, confidence level, and expected effect size. Display confidence intervals and avoid ranking issuers from small samples.
Can a merchant contact an issuer directly about low approvals?
Sometimes, but direct operational access is not generally available to every merchant. The usual escalation path is through the merchant’s PSP, processor, or acquirer, which may then engage the network or issuer.
Does a high generic-decline rate prove that an issuer is blocking the merchant?
No. A generic decline confirms that the request was not approved but does not reveal a single root cause. Merchants should examine authentication, routing, data, transaction mix, and raw responses before drawing a conclusion.
Can changing acquirers improve one issuer’s authorization rate?
It can in some cases because routes may differ in merchant configuration, message quality, authentication support, domesticity, connectivity, and issuer performance. The effect should be tested with comparable first-attempt cohorts.
Should recurring authorization rates be compared with one-time payments?
No. Recurring and merchant-initiated transactions have different credential age, customer presence, classification, authentication, and recovery characteristics. Analyze them separately.
What should an issuer scorecard include?
At minimum: issuer identity, account ranges, issuing country, product type, first-attempt authorization rate, volume, response distribution, authentication performance, route, recurring performance, merchant fraud blocks, capture rate, confidence interval, economic exposure, and next action.
Research and editorial brief
Dominant search intent: Readers searching for “authorization rates by issuer” are usually trying to diagnose why cards issued by one bank or banking group appear to approve less often than comparable cards. Their real objective is not merely to rank issuers. They need to determine whether the apparent performance gap is statistically credible, commercially important, correctly attributed, and actionable.
Main questions readers are trying to answer:
Is a particular issuer genuinely underperforming?
Are the issuer names and BIN/IIN ranges mapped correctly?
Is the gap caused by the issuer, or by routing, authentication, fraud controls, transaction mix, or data quality?
Which decline patterns support a specific diagnosis?
How much approved revenue could realistically be recovered?
What evidence should a merchant give its PSP, processor, or acquirer?
How should a remediation test be designed?
Gaps in current ranking content: Much of the available material explains authorization rates broadly or recommends segmenting by issuer, but provides little practical guidance on issuer normalization, account-range changes, banking-group structures, confidence intervals, authentication waterfalls, escalation packets, or controlled remediation. Ranking pages also commonly treat a low issuer rate as proof of issuer behavior, even when transaction populations are not comparable.
Unique editorial angle: This article is an issuer-performance investigation manual. It treats issuer analysis as a forensic exercise: establish identity, define a comparable cohort, locate where performance diverges, assess economic importance, form competing hypotheses, collect evidence, and test a targeted remedy.
Recommended format: A diagnostic manual containing an investigation waterfall, issuer scorecard template, responsibility matrix, developer data checklist, sample escalation packet, and controlled-test framework.
Public-data limitation: There is no comprehensive, independently verified public database that provides current merchant authorization rates for every issuer. Issuer performance is highly dependent on the merchant, transaction population, acquirer, routing path, authentication flow, fraud controls, geography, and time period. Consequently, issuer analysis should be based primarily on the merchant’s own controlled data—not generalized public rankings.
This article follows the differentiated analytical direction and required utility established in the supplied editorial brief.
SEO deliverables
Five SEO title options
Authorization Rates by Issuer: Merchant Guide
How to Analyze Authorization Rates by Issuer
Issuer Approval Rates: A Diagnostic Framework
Card Issuer Authorization Analysis for Merchants
Why Payment Approval Rates Differ by Issuer
Five meta-description options
Learn how to analyze authorization rates by issuer, normalize bank data, diagnose decline patterns, compare routes, and prioritize payment fixes.
A merchant guide to issuer approval rates, including BIN mapping, matched cohorts, authentication analysis, scorecards, and provider escalation.
Discover why card issuers perform differently and how to separate issuer behavior from routing, fraud, authentication, and transaction-mix effects.
Investigate issuer-specific declines with a practical waterfall, scorecard, data checklist, escalation packet, and controlled testing framework.
Learn how to measure payment approval by issuing bank without misleading comparisons, weak samples, blended averages, or incorrect issuer data.
Recommended URL slug
/authorization-rates-by-issuer
authorization rates by issuer
Secondary keywords grouped by intent
Informational
Issuer approval rate
Card issuer authorization rate
Payment approval by issuing bank
Issuer authorization analysis
Card issuer payment performance
Diagnostic
Issuer-specific declines
Why one bank declines more payments
Bank decline rate analysis
Low approval rate by issuer
Generic declines by issuer
Issuer authentication failure
Analytical
Compare issuer approval rates
Authorization rate by BIN
Approval rate by issuing bank
Issuer performance dashboard
Issuer scorecard
Payment decline analysis by BIN
Technical
BIN issuer normalization
Eight-digit BIN analysis
Account-range payment analytics
Raw issuer response codes
3DS performance by issuer
Retry lineage
Issuer routing analysis
Commercial investigation
Improve issuer approval rates
Acquirer performance by issuer
Local acquiring by issuer
Payment routing by issuing bank
Recover issuer declines
Relevant semantic entities and related terms
Issuer
Issuing bank
Issuing entity
Banking group
Acquirer
Processor
PSP
Card network
BIN
IIN
Account range
Primary Account Number
Eight-digit BIN
Issuing country
Funding type
Debit card
Credit card
Prepaid card
Commercial card
Merchant ID
Merchant Category Code
Authorization request
Authorization response
First-attempt approval
Eventual approval
Decline code
Response code
Merchant Advice Code
Generic decline
Do not honor
EMV 3-D Secure
Access Control Server
Frictionless authentication
Challenge flow
Stored credential
Customer-initiated transaction
Merchant-initiated transaction
Network token
Account updater
Local acquiring
Cross-border acquiring
Smart routing
Cascading
Fraud acceptance
False decline
Confidence interval
Cohort analysis
Payment lineage
Suggested H1
Authorization Rates by Issuer: A Merchant Investigation Guide
Proposed heading hierarchy
H1: Authorization Rates by Issuer
H2: What Authorization Rate by Issuer Means
H2: Why Issuer Approval Rates Differ
H2: How to Identify an Issuer Accurately
H3: BIN, IIN, and Account Ranges
H3: Issuer-Name Normalization
H3: Mergers, Subsidiaries, and Portfolios
H2: Why Issuer Comparisons Can Be Misleading
H2: Issuer Concentration and Merchant Exposure
H2: The Issuer-Performance Investigation Waterfall
H2: Decline-Code and Response-Pattern Analysis
H2: Authentication Performance by Issuer
H2: Recurring and Credential-on-File Performance
H2: Cross-Border, Currency, and Acquiring Context
H2: Fraud Controls and Merchant-Side Effects
H2: Building an Issuer Scorecard
H2: Distinguishing an Issuer Problem from Other Problems
H2: Escalating Issuer-Specific Issues
H2: Designing Controlled Remediation Tests
H2: Developer and Data-Team Guidance
H2: Common Analytical Mistakes
H2: Frequently Asked Questions
Three featured-snippet answers
Definition snippet
Authorization rate by issuer is the percentage of authorization requests associated with a defined issuing bank or account-range population that receive approval. Merchants should calculate it using a consistent denominator and separate first attempts from retries.
Diagnostic snippet
To investigate a low issuer approval rate, first verify issuer mapping, then match comparable transaction cohorts, locate where the payment funnel diverges, analyze response and authentication patterns, compare routes, quantify sample confidence, and test a specific remedy.
Comparison snippet
Issuer rates should not be compared until differences in country, currency, card product, acquirer, authentication, transaction type, customer mix, order value, fraud controls, retries, and time period have been controlled or clearly disclosed.
Suggested FAQ schema in valid JSON-LD
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "What is an authorization rate by issuer?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Authorization rate by issuer is the percentage of submitted authorization requests associated with a defined card issuer or account-range population that receive approval. The calculation should specify the denominator, retry treatment, route, time period, and transaction cohort."
}
},
{
"@type": "Question",
"name": "Why do some issuing banks approve fewer transactions?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Issuer approval rates may differ because of cardholder and product mix, issuer risk strategy, authentication behavior, cross-border exposure, available funds, card controls, transaction data, acquiring route, and merchant configuration. A lower rate does not prove one specific cause."
}
},
{
"@type": "Question",
"name": "How can a merchant identify the card issuer?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Merchants generally use current BIN, IIN, or account-range data supplied by a card network, provider, or authorized data source. Systems should support both six- and eight-digit structures and account for mergers, subsidiaries, and portfolio changes."
}
},
{
"@type": "Question",
"name": "Should merchants compare issuer approval rates directly?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Issuer rates should be compared only after matching relevant variables such as country, currency, card product, acquirer, route, transaction type, authentication result, customer type, order value, fraud treatment, retry behavior, and time period."
}
},
{
"@type": "Question",
"name": "How much volume is needed for an issuer rate to be reliable?",
"acceptedAnswer": {
"@type": "Answer",
"text": "There is no universal minimum volume. Reliability depends on the observed approval rate, desired precision, confidence level, and effect size. Merchants should show transaction counts, use confidence intervals, and avoid ranking issuers from small samples."
}
},
{
"@type": "Question",
"name": "Can a merchant contact an issuer directly about low approval rates?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Direct operational issuer access is not available to every merchant. The usual escalation path is through the merchant's PSP, processor, or acquirer, which may engage the card network or issuer through its own channels."
}
},
{
"@type": "Question",
"name": "Does a high generic-decline rate prove an issuer is blocking the merchant?",
"acceptedAnswer": {
"@type": "Answer",
"text": "No. A generic decline indicates that the issuer did not approve the request but does not identify one root cause. Merchants should examine authentication, routing, transaction data, customer mix, and raw responses before drawing a conclusion."
}
},
{
"@type": "Question",
"name": "Can changing acquirers improve one issuer's authorization rate?",
"acceptedAnswer": {
"@type": "Answer",
"text": "It can in some cases because acquiring routes may differ in merchant configuration, message quality, authentication support, domesticity, and connectivity. Any effect should be tested with comparable first-attempt transaction cohorts."
}
},
{
"@type": "Question",
"name": "What should an issuer scorecard include?",
"acceptedAnswer": {
"@type": "Answer",
"text": "An issuer scorecard should include issuer identity, account ranges, issuing country, card product, first-attempt authorization rate, volume, response distribution, authentication performance, route, recurring performance, merchant fraud blocks, capture rate, confidence interval, economic exposure, and next action."
}
}
]
}
Suggested internal-link anchor text
What is a payment authorization rate?
How to improve payment authorization rates
Most common card-decline reasons
How issuer responses affect payment acceptance
Why issuers decline legitimate customers
Soft declines versus hard declines
How BIN data can improve payment performance
Authorization rates by country
Authorization rates by payment method
Authorization rates by PSP
How to benchmark PSP approval rates
Local acquiring and authorization rates
How authentication affects conversion
Payment approval rate versus conversion rate
How payment data quality affects authorization
Merchant Category Codes and approval rates
Domestic versus cross-border payment performance
Three topic-specific CTA options
CTA 1: Issuer investigation
CTA 2: Global performance
CTA 3: Evidence to action
Header-image concept
“The Issuer Performance Investigation”
Show transaction traffic entering from the left and separating into several anonymous issuer or bank nodes. Most paths continue in gold toward approval, while one issuer path branches into decline, authentication, routing, and data signals.
Headline:
Authorization Rates by Issuer
Supporting line:
Find where issuing-bank performance really diverges
Recommended alt text:
“Payment authorization traffic segmented by card issuer, with approval, decline, authentication, routing, and data signals used to investigate issuer performance.”
Supporting-infographic concept 1
“Issuer-Performance Investigation Waterfall”
Create an eight-step vertical or horizontal investigation flow:
Verify issuer identity → Define the metric → Match cohorts → Locate the divergence → Analyze responses → Compare routes → Quantify value → Test a remedy
Include a stop-or-continue checkpoint at each stage.
Recommended alt text:
“Eight-step waterfall for verifying issuer identity, matching payment cohorts, locating performance divergence, analyzing declines, comparing routes, and testing remedies.”
Supporting-infographic concept 2
“Issuer Problem or Payment-Stack Problem?”
Create a decision tree beginning with:
Where does performance first diverge?
Branches:
Before authorization → merchant risk or checkout
During authentication → 3-D Secure or customer friction
Before issuer response → gateway, PSP, acquirer, or routing
At issuer response across all routes → possible issuer-specific issue
Only on one route → acquirer or configuration issue
Only for recurring payments → credential or transaction-indicator issue
Recommended alt text:
“Decision tree helping merchants distinguish issuer-specific declines from fraud, authentication, routing, acquirer, technical, and recurring-payment problems.”
Claims requiring final review
Validate current support for raw network responses, normalized decline categories, and retry-advice indicators.
Confirm which issuer, BIN/IIN, account-range, funding-type, and product attributes are available.
Confirm support for six- and eight-digit BIN/IIN analysis.
Review the retention and display of account-range data for PCI DSS, contractual, privacy, and security compliance.
Validate current EMV 3DS reporting, including challenge, frictionless, failure, and issuer-availability metrics.
Confirm available network-token and account-updater coverage.
Review all recurring, MIT, CIT, and stored-credential guidance against current network rules.
Validate any issuer escalation process described in final product or sales copy.
Ensure no CTA implies direct control over issuer decisioning.
Confirm whether local versus cross-border classification is available in reporting.
Validate the availability and accuracy of Merchant ID, route, processor, and acquirer metadata.
Have data science review the confidence-interval and cohort-comparison methodology.
Have legal review any use of issuer or banking-group names in merchant-facing reporting.
Confirm that account-range enrichment sources are current and appropriately licensed.
Distribution of authorization rates across anonymized issuer cohorts
Share of declines concentrated among a merchant’s top five issuers
Issuer-level local versus cross-border route comparisons
Authentication challenge and completion rates by issuer market
Tokenized versus non-tokenized approval rates by issuer cohort
Recurring versus initial authorization performance by issuer
Generic-decline concentration by issuer and country
Recovery rates after eligible retries by issuer response category
Before-and-after results from issuer-specific routing tests
Examples of issuer gaps caused by account-range misclassification
Median time to detect and resolve issuer-specific incidents
Revenue-impact estimates from real issuer investigations
Aggregated account-updater success by issuer or market
Issuer-level payment-method substitution after card decline
Any proprietary data should be anonymized, methodologically documented, legally approved, and accompanied by population, geography, period, denominator, and limitation disclosures.
Differentiation note
This article differs from the other authorization-optimization pieces by using the issuer or issuer account range as the primary analytical unit.
It is not a general explanation of authorization rates, a country benchmark, a PSP comparison, a decline-code guide, or a broad article about issuer decisioning. Its specific purpose is to help a merchant investigate whether an issuer-level performance pattern is real, where the divergence begins, how identity and transaction mix can distort the result, what evidence is required, and how to escalate and test a targeted remedy.
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗