Authorization Rates by PSP
Authorization Rates by PSP: How to Compare Payment Providers Fairly A merchant comparing PSP authorization rates faces a problem familiar to anyone who has tried to compare schools, hospitals, or investment managers: the headline number looks objective, but the populations undern
Authorization Rates by PSP: How to Compare Payment Providers Fairly
A merchant comparing PSP authorization rates faces a problem familiar to anyone who has tried to compare schools, hospitals, or investment managers: the headline number looks objective, but the populations underneath it may be doing most of the work.
Imagine two payment providers.
Provider A reports a 95% authorization rate. Provider B reports 89%.
The conclusion seems obvious. A is better.
But suppose Provider A processes the merchant’s domestic returning customers using current network tokens, while Provider B receives first-time cross-border buyers, higher-value orders, stale stored cards, and difficult subscription retries.
Both rates may be accurate. The comparison is not.
A PSP can influence payment performance through acquiring coverage, routing, technical reliability, data mapping, authentication support, fraud screening, tokenization, and retry handling. But it does not independently determine authorization. Card issuers make the final approval decision using the transaction information they receive, account history, cardholder controls, fraud signals, and internal policies.
The practical answer is:
A merchant can determine whether one PSP delivers better authorization performance only by comparing sufficiently similar transactions under a consistent measurement framework—or, ideally, through a controlled traffic test.
Anything less risks confusing traffic mix with provider quality.
What is a PSP authorization rate?
A PSP authorization rate is generally the percentage of submitted authorization requests that receive an approval.
The basic formula is:
PSP authorization rate = approved authorization requests ÷ total authorization requests submitted through the PSP × 100
If 92,000 of 100,000 authorization requests submitted through a provider are approved, the attempt-level authorization rate is 92%.
That formula is simple. Its implementation is not.
Before comparing providers, a merchant needs to know whether each one counts:
Every authorization attempt
Only first attempts
The final attempt for each unique payment
Duplicate attempts
Technical failures
Zero-value account checks
Partial approvals
Merchant-side fraud blocks
Authentication failures
Canceled transactions
Retries and cascades
Card-present and card-not-present traffic together
Visa, for example, has published authorization analyses using deduplicated transactions or the last attempt of a unique transaction. Those results are not directly comparable with a merchant report that counts every retry as another attempt. (Visa)
A valid PSP comparison starts with a shared data dictionary—not a dashboard screenshot.
The PSP performance-decomposition model
A provider’s reported authorization rate can be decomposed into four layers.
Traffic received
This includes the characteristics of the transactions sent to the PSP:
Issuer
Issuing country
Card network
Debit, credit, prepaid, or commercial card
New or returning customer
Domestic or cross-border
Transaction value
Currency
One-time or recurring payment
Tokenized or primary-account-number credential
Authentication status
Merchant category
Device and channel
Customer risk
Retry number
A provider receiving easier traffic should be expected to report stronger raw performance.
Decisions made before authorization
The provider or merchant may decide whether the transaction proceeds.
This layer can include:
Fraud screening
Velocity controls
Sanctions or geographic restrictions
Authentication initiation
Exemption logic
Account validation
Request validation
Merchant configuration checks
A PSP can raise its issuer authorization rate by rejecting more questionable transactions before they reach issuers. That does not necessarily improve end-to-end payment success.
Processing path
Once a transaction proceeds, the provider may influence:
Gateway availability
Processor selection
Acquirer
MID
Merchant entity
Local or cross-border processing
Card-network route
Message formatting
Transaction indicators
Authentication-data transmission
Retry or cascading logic
ISO 8583 defines a common interface and message structure for exchanging financial-transaction-card messages between acquirers and issuers. In practice, the data ultimately supported and populated can still vary by network, acquirer, provider, transaction type, and implementation. (ISO)
Measurement
Finally, the provider decides how the result is calculated and presented.
Differences may include:
Attempt-level versus payment-level rates
First-attempt versus eventual approval
Time zone
Reporting period
Deduplication
Response normalization
Technical-error treatment
Fraud-block treatment
Currency and value weighting
Inclusion of retries
Inclusion of test traffic
Exclusion of unsupported transactions
A PSP authorization rate is therefore not one pure measure of provider quality. It is the result of all four layers.
What sits inside a PSP’s payment stack?
The term PSP can obscure several underlying functions.
Depending on the provider and arrangement, the PSP may supply or coordinate:
Checkout components
Tokenization or vaulting
Gateway services
Processing
Acquiring
Fraud screening
EMV 3-D Secure
Payment orchestration
Routing
Local payment methods
Recurring-payment tools
Account updating
Reporting
Settlement and reconciliation
Two companies both described as PSPs may therefore control very different parts of the payment journey.
This matters because an approval difference may originate in a component the PSP controls directly, a third party it connects to, or the merchant’s own configuration.
Why authorization rates can differ between PSPs
Acquiring coverage
Providers may connect a merchant to different acquirers, merchant entities, MIDs, currencies, or regional processing arrangements.
An acquiring route may be stronger for a specific combination of:
Issuer
Market
Currency
Card product
Merchant category
Transaction type
Authentication status
Local acquiring may improve performance in certain markets where it provides appropriate merchant representation, currency, domestic-card support, and issuer connectivity. But the outcome depends on the merchant entity, acquirer, issuer, card-network rules, and transaction configuration. It is not enough for a provider merely to claim “local coverage.”
Merchants should ask what actually changes in the authorization message and acquiring path.
Routing
A multi-acquirer PSP may select different routes according to:
IIN or BIN range
Issuer country
Card network
Currency
Amount
Availability
Historical performance
Cost
Transaction type
Good routing can improve outcomes when eligible routes genuinely perform differently.
But routing can also make provider comparisons harder. If a merchant sends a PSP only the traffic that another provider has already declined, the second PSP will naturally report a weaker raw authorization rate.
Routing creates selection bias: the provider’s traffic reflects previous decisions.
Authentication
Authentication and authorization are distinct but related.
EMV 3-D Secure allows merchants and issuers to exchange transaction, payment-method, cardholder, and device information so the issuer can authenticate the customer. Transactions may proceed through a frictionless flow or require a customer challenge. (EMVCo)
Providers can differ in:
3DS version support
Data-field population
Challenge handling
Mobile and browser experience
Exemption implementation
Out-of-band authentication support
Transfer of authentication values into authorization
Monitoring and error recovery
EMVCo has emphasized that authentication design and out-of-band flows can affect customer experience and approval performance. (EMVCo)
A provider with better authentication completion may produce more authorization attempts and more completed payments—even if its issuer authorization rate is similar.
Transaction-data quality
Issuers cannot use information they do not receive.
Providers may differ in how well they collect, preserve, validate, map, or transmit:
Billing details
Merchant information
Stored-credential indicators
Customer-initiated or merchant-initiated status
Recurring-payment indicators
Authentication data
Device information
Cardholder details
Transaction references
Network-specific fields
Visa has reported higher ecommerce approval performance when richer transaction data is shared, although its published figures are specific to the markets, merchants, periods, definitions, and programs studied. (Visa)
The merchant lesson is not that one universal data-enrichment uplift applies. It is that PSP field support and mapping deserve the same scrutiny as acquiring coverage.
Tokenization and credential lifecycle
Stored credentials become stale when cards expire, accounts change, or cards are replaced.
A provider may support:
Network tokens
Wallet tokens
Account updating
Credential lifecycle events
Token cryptograms
Credential replacement workflows
Visa has reported a 4.3% global average authorization-rate lift for tokenized Visa card-not-present transactions compared with non-tokenized PAN transactions in its October–December 2023 analysis. Visa defined the rate using the last attempt of a unique transaction and notes that merchant results vary. (Visa)
A PSP receiving more tokenized traffic may therefore outperform another for reasons related to credential quality rather than its acquirer alone.
Fraud screening
One provider may approve more transactions for submission because its fraud controls are more permissive. Another may reject more transactions before authorization.
Neither policy can be assessed from authorization rate alone.
The first provider could produce:
Higher issuer approvals
Higher fraud
More chargebacks
More operational losses
The second could produce:
Lower end-to-end conversion
Lower fraud
More false positives
Fewer issuer attempts
The merchant needs to compare the entire risk-return outcome.
Technical reliability
A payment can fail before reaching an issuer because of:
Timeout
API error
Gateway outage
Processor unavailability
Invalid request
Configuration problem
Unsupported currency
Authentication-system failure
Technical success should therefore be measured separately:
Technical success rate = authorization requests successfully delivered for processing ÷ eligible requests sent to the PSP
A provider may have a high issuer authorization rate but poor uptime. Another may have slightly lower issuer approval but better end-to-end completion.
Retry and cascading behavior
Providers may handle unsuccessful payments differently.
They may:
Retry later
Cascade to another acquirer
Request authentication
Ask for updated credentials
Stop further attempts
Normalize a decline into a retry recommendation
Visa assigns authorization responses to categories and instructs merchants to work with acquirers and processors to determine whether a reattempt is prohibited or whether data must be corrected first. (Visa)
Mastercard gateway documentation likewise distinguishes recommendations such as resubmit later, resubmit with 3DS, use updated payment details, use alternative payment details, or abandon the order. (Mastercard Gateway)
A provider that retries aggressively may increase eventual approval but reduce attempt-level authorization rate. Another may stop earlier and report a cleaner-looking attempt rate.
Why provider-reported benchmarks are not merchant forecasts
A provider portfolio may contain thousands of merchants, but that does not make its average predictive for a particular business.
The portfolio could differ in:
Industries
Countries
Average order values
Customer tenure
Fraud risk
Card-present share
Issuer distribution
Payment methods
Subscription volume
Token adoption
Acquiring configuration
Retry methodology
A provider benchmark is evidence about its portfolio—not a promise about the merchant.
Visa’s own published performance figures routinely specify transaction population, period, geography, credential type, deduplication, and exclusions. That methodological detail is precisely what merchants should demand from any provider benchmark. (Visa)
The fair-comparison checklist
Before comparing two PSPs, confirm that the traffic is matched across the following dimensions.
Geography
Issuer country
Customer market
Merchant entity
Acquirer location
Domestic or cross-border status
Card and credential
Network
Debit, credit, prepaid, or commercial
Tokenized or PAN
Wallet or manually entered
Credential age
IIN/BIN segment
Transaction
Amount band
Currency
One-time or recurring
Customer-initiated or merchant-initiated
Card-present or card-not-present
Product or merchant category
Customer
New or returning
Customer tenure
Purchase history
Acquisition channel
Risk segment
Authentication and fraud
3DS status
Frictionless or challenge
Authentication result
Exemption category
Fraud score or decision
Manual review
Measurement
Same period
Same denominator
First attempt or all attempts
Same deduplication
Same retry policy
Same technical-error treatment
Same response-code normalization
If these conditions are not comparable, the raw PSP rates should be treated as descriptive rather than causal.
How to design a fair multi-PSP test
The strongest comparison is a randomized traffic-split test.
Step 1: Define eligible traffic
Include only transactions that both providers can process under comparable commercial and technical conditions.
Exclude transactions where:
One provider lacks an eligible acquirer.
One does not support the payment method.
Merchant entities differ materially.
Currency treatment differs.
One provider is contractually required.
Authentication support is not comparable.
Step 2: Randomize before provider selection
Randomly assign eligible payments to Provider A or Provider B before either provider evaluates or attempts the payment.
This reduces routing bias.
A simple test could use a 50/50 split, although merchants may use another allocation based on risk and volume.
Step 3: Stratify important segments
Pure randomization can still produce short-term imbalance.
Stratify or monitor by:
Issuer country
Network
Card type
Amount
New versus returning
Recurring status
Authentication
Token type
Step 4: Keep merchant-controlled rules consistent
Where possible, maintain the same:
Checkout
Fraud policy
Authentication policy
Customer messaging
Retry rules
Currency
Merchant representation
If one PSP’s bundled risk system must be tested, treat that as a separate experiment rather than calling it a pure processing comparison.
Step 5: Define primary and guardrail metrics
A strong primary metric is:
First-attempt unique-payment authorization rate
Guardrail metrics should include:
Technical success
End-to-end payment success
Fraud
Chargebacks
Processing cost
Authentication completion
Capture
Settlement
Latency
Customer support contacts
Step 6: Use a sufficient test period
The test should cover normal variations such as:
Weekdays and weekends
Payroll cycles
Issuer maintenance
Promotions
Geographic peaks
Subscription renewal dates
There is no universal minimum transaction count. Sample size depends on baseline performance, expected difference, required confidence, segment count, and business risk.
Step 7: Do not reroute the control group
If a transaction assigned to A is immediately cascaded to B after a decline, the experiment becomes difficult to interpret.
Track separately:
Initial assignment
Initial result
Subsequent provider
Final payment outcome
Hypothetical randomized PSP test
Assume a merchant randomly assigns 200,000 comparable first-attempt payments:
Metric
PSP A
PSP B
Eligible unique payments
100,000
100,000
Technical success
99.7%
99.2%
First-attempt authorization
92.8%
93.4%
Authentication completion
91.5%
93.0%
Capture rate after approval
99.4%
99.1%
Confirmed fraud rate
0.42%
0.61%
Chargeback rate
0.36%
0.49%
Average processing cost
$0.31
$0.35
Median authorization latency
720 ms
610 ms
All figures are hypothetical.
PSP B has a 0.6-percentage-point first-attempt authorization advantage. But it also has higher fraud, higher chargebacks, and higher processing cost.
The commercial winner cannot be determined from authorization alone.
Why the highest approval rate may not produce the most revenue
Consider two providers processing $50 million in comparable submitted value.
Hypothetical Provider A
Authorization rate: 93.0%
Fraud and chargeback loss: 0.4%
Processing cost: 2.5%
Capture and settlement retention: 99.5%
Hypothetical Provider B
Authorization rate: 94.0%
Fraud and chargeback loss: 1.1%
Processing cost: 2.9%
Capture and settlement retention: 99.1%
Provider B approves more value. But some of that gain may be lost through higher fees, fraud, disputes, and post-authorization attrition.
A more useful equation is:
Net retained payment value = authorized value × capture rate × settlement rate − processing costs − fraud losses − chargeback losses − incremental operational costs
The objective is not maximum approvals. It is maximum legitimate, settled, retained revenue.
The normalized multi-PSP scorecard
Category
Metric
Why it matters
Authorization
First-attempt approval
Initial provider performance
Authorization
Eventual unique-payment approval
Recovery effectiveness
Reliability
Technical success
Ability to reach authorization
Reliability
Uptime and latency
Checkout continuity and speed
Risk
Fraud rate
Loss exposure
Risk
Chargeback rate
Downstream cost and operational impact
Authentication
Completion rate
Customer friction
Authentication
Post-auth approval
Quality of authenticated traffic
Commercial
Processing cost
Direct cost
Commercial
FX and cross-border cost
Market economics
Revenue
Capture rate
Approved value captured
Revenue
Settlement rate
Captured value settled
Operations
Reconciliation quality
Finance workload
Operations
Reporting completeness
Diagnostic capability
Operations
Support responsiveness
Incident resolution
Compliance
PCI evidence and responsibilities
Security and governance
Expansion
Local acquiring coverage
Market suitability
Expansion
Local payment methods
Customer choice
Each metric should be scored for the same transaction cohort or clearly labeled where comparability is limited.
Merchant questions to ask every PSP
About the authorization rate
What is the exact formula?
Are retries included?
Is the rate attempt-level or payment-level?
Is it first-attempt or eventual approval?
Are technical errors included?
Are merchant fraud blocks excluded?
Are zero-value checks excluded?
How are duplicates handled?
Is the rate transaction-weighted or value-weighted?
About the portfolio benchmark
Which merchants are included?
Which markets?
Which card networks?
What time period?
What share is card-present?
What share is recurring?
What share is domestic?
Is the data deduplicated?
What are the median and percentile results?
About processing
Which acquirer will process each market?
Which merchant entity and MID will be used?
Is the transaction expected to be domestic or cross-border?
Which currencies are supported?
Which domestic card products are accepted?
How is routing determined?
Can the merchant view route-level performance?
About fraud and authentication
Does the rate include transactions rejected by fraud screening?
Can the merchant use its own fraud system?
How are 3DS flows implemented?
Which authentication metadata is available?
Can authentication failure be separated from issuer decline?
About retries
Are raw response and advice signals available?
How does the provider decide whether to retry?
Can the merchant configure retry behavior?
Are cascading attempts clearly linked to the original payment?
How are network retry requirements enforced?
About data and reporting
Can raw issuer or network responses be retained?
Can normalized codes be mapped back to raw codes?
Can performance be segmented by issuer, IIN/BIN, acquirer, route, country, token type, and authentication result?
How quickly is reporting available?
Can event-level data be exported?
Developer and data-team requirements
Use separate identifiers
At minimum, retain separate IDs for:
Order
Customer payment
Provider assignment
Attempt
Authentication
Authorization
Route
Retry or cascade
Capture
Settlement
One payment can generate several attempts. Without lineage, first-attempt and eventual success cannot be distinguished.
Store provider-neutral fields
Create an internal schema that does not depend on one PSP’s terminology.
Suggested normalized fields include:
payment_id
attempt_id
psp_id
acquirer_id
merchant_entity
mid
route_id
issuer_country
iin_bin_range
network
card_funding_type
token_type
transaction_type
authentication_status
fraud_decision
technical_result
authorization_result
raw_response_code
normalized_decline_category
advice_action
retry_number
capture_result
settlement_result
Preserve raw and normalized data
Provider normalization is useful because networks and processors may represent responses differently.
But normalization loses detail.
Retain:
Raw response
Provider-normalized response
Network or scheme
Advice or retry recommendation
Technical error
Failure stage
Handle ambiguous timeouts
A timeout does not prove that an authorization failed.
Before another attempt:
Query transaction status where supported.
Process asynchronous notifications.
Use idempotency keys.
Retain provider references.
Avoid duplicate holds.
Normalize time and currency
Use consistent:
UTC timestamps
Reporting windows
Currency conversion methodology
Value-weighting rules
Do not compare one provider’s transaction counts with another provider’s converted payment value.
Protect payment data
Outsourcing payment processing does not remove a merchant’s PCI DSS responsibilities. PCI SSC states that merchants remain responsible for ensuring applicable third-party services are appropriately covered, maintaining agreements, monitoring compliance status, and understanding shared responsibilities. (PCI Security Standards Council)
Merchants should request evidence that the provider’s PCI DSS assessment covers the services being used. (PCI Security Standards Council)
Common ways merchants misread PSP performance
Comparing unmatched traffic
This is the most common error.
If one PSP receives domestic returning customers and another receives difficult cross-border traffic, the rates are not provider rankings.
Trusting global averages
A provider’s portfolio average may be real and still irrelevant to a merchant’s countries, industry, transaction values, and issuer mix.
Ignoring pre-authorization blocks
A provider can report a strong issuer authorization rate while rejecting more customers through fraud or authentication before authorization.
Combining technical and issuer failures
Technical reliability and issuer approval are different problems requiring different remedies.
Ignoring retries
A PSP may appear weaker because it counts every attempt, or stronger because it reports only the final result.
Ignoring routing bias
A provider receiving “second look” transactions after another PSP declines them will inherit a harder population.
Comparing different time periods
Issuer behavior, fraud attacks, seasonality, promotions, and transaction mix change over time.
Looking only at statistical significance
A tiny approval difference can be statistically significant at very high volume but commercially irrelevant after cost and fraud.
Looking only at the headline approval rate
The provider with the highest approval rate may not produce the highest settled, retained revenue.
A practical PSP evaluation workflow
Phase 1: Define the decision
Clarify whether the merchant is evaluating:
A full PSP replacement
An additional provider
A backup route
A local-acquiring connection
A fraud service
Authentication
Recurring-payment recovery
Payment orchestration
Different decisions require different tests.
Phase 2: Audit current data
Confirm that payment, attempt, route, authentication, fraud, authorization, capture, and settlement data can be connected.
Phase 3: Normalize metrics
Agree on:
First-attempt authorization
Eventual authorization
Technical success
End-to-end payment success
Fraud
Chargebacks
Cost
Net retained revenue
Phase 4: Identify comparable traffic
Determine which transactions both providers can process under sufficiently similar conditions.
Phase 5: Run a controlled split
Randomize traffic, maintain guardrails, and avoid contaminating the test through uncontrolled cascading.
Phase 6: Analyze segments
Review overall results and differences by:
Issuer
Country
Acquirer
Card type
Token type
Authentication
New or returning customer
Transaction value
Recurring status
Phase 7: Calculate commercial value
Translate approval lift into:
Incremental captured value
Incremental settled value
Fraud-adjusted revenue
Cost-adjusted revenue
Operational impact
Phase 8: Decide where each provider belongs
The answer may not be “choose A” or “choose B.”
It may be:
A for one market
B for another
A for domestic cards
B for a specific issuer group
A as primary
B for technical failover
Both in a controlled routing strategy
Frequently asked questions
Can two PSP authorization rates be compared directly?
Only when they use the same definition and process sufficiently similar transactions. Differences in geography, issuer mix, card type, authentication, fraud screening, routing, retries, and measurement can make raw rates misleading.
What is a good PSP authorization rate?
There is no universal good rate for a PSP. The relevant benchmark is the provider’s performance for the merchant’s own comparable transaction segments, measured against fraud, cost, technical reliability, capture, and settlement.
Why does one PSP approve more transactions than another?
Possible causes include different acquirers, local-processing coverage, routing, data mapping, tokenization, authentication, fraud rules, issuer connectivity, technical reliability, or transaction mix.
Should a merchant choose the PSP with the highest approval rate?
Not automatically. The provider should be evaluated on net retained revenue, fraud, chargebacks, cost, uptime, latency, settlement, reporting, and operational burden as well as authorization.
How should merchants test two PSPs?
Use randomized assignment of traffic that both PSPs are eligible to process. Keep merchant-controlled policies consistent, measure first attempts separately, and track downstream fraud, cost, capture, and settlement.
How long should a multi-PSP test run?
There is no fixed duration. The test should contain enough transactions to detect a commercially meaningful difference and cover normal variations in days, customer behavior, issuer traffic, renewals, and promotions.
Do retries improve a PSP’s authorization rate?
Retries may improve eventual payment success but can reduce attempt-level authorization rate because they add attempts after a failure. First-attempt and eventual approval should be reported separately.
Can smart routing make PSP comparisons unfair?
Yes. If routing sends one provider stronger segments and another harder or previously declined payments, their raw authorization rates cannot be interpreted as an unbiased comparison.
Should fraud-blocked payments be included?
They should not be included in issuer authorization rate if no authorization was submitted. They should be included in broader end-to-end payment and fraud-acceptance reporting.
Is payment success rate the same as authorization rate?
No. Authorization rate covers requests submitted for issuer authorization. Payment success can include checkout, fraud screening, authentication, technical processing, capture, and settlement.
Conclusion
A PSP authorization rate is not a product specification like memory capacity or internet speed. It is an outcome produced jointly by the merchant, customer, issuer, acquirer, provider, fraud controls, authentication flow, processing route, and reporting methodology.
That is why provider comparisons should begin with skepticism.
The merchant should ask:
Did the PSPs receive comparable traffic?
Did they use the same denominator?
Were fraud, authentication, and technical failures treated consistently?
Were retries and duplicates normalized?
Did the higher approval rate produce more captured and settled revenue?
What happened to fraud, chargebacks, cost, latency, and operations?
Does the result hold within the merchant’s most important markets and issuer segments?
The best provider is not necessarily the one with the highest global approval claim. It is the one—or combination of providers—that produces the strongest risk-adjusted, cost-adjusted, operationally sustainable payment outcome for the merchant’s actual business.
Research and editorial brief
Dominant search intent
A merchant searching for authorization rates by PSP is usually trying to answer a deceptively simple procurement question:
Is one payment service provider genuinely better at getting transactions approved?
The difficulty is that a PSP authorization rate is not a laboratory result. It is the output of a system containing merchant traffic, issuers, acquirers, routing, fraud rules, authentication, transaction data, retries, technical reliability, and measurement choices.
The reader therefore needs more than a provider benchmark. They need a method for separating provider performance from everything surrounding it.
Main questions readers are trying to answer
Can PSP approval rates be compared directly?
What does a PSP-reported authorization rate include?
Why might two providers approve the same merchant’s traffic differently?
How should traffic be divided for a fair multi-PSP test?
How do routing, local acquiring, authentication, fraud screening, and retries affect the result?
Is the highest authorization rate always the best commercial outcome?
What data should merchants require from each provider?
When is a performance difference statistically and economically meaningful?
Gaps in the ranking content
Many ranking pages make provider performance sound like a leaderboard. That approach misses several realities:
Providers frequently receive different transaction populations.
One provider may block more payments before authorization.
One may have better domestic acquiring in a specific market.
Retry and deduplication methodologies can inflate or depress reported rates.
Provider uptime affects payment success but is not issuer authorization.
Higher approvals can be offset by fraud, chargebacks, fees, latency, or operational complexity.
Portfolio-wide provider benchmarks do not predict merchant-specific performance.
A provider may appear stronger because routing already sends it easier transactions.
The uploaded brief correctly calls for a provider-performance decomposition and multi-PSP evaluation framework, not a simplistic PSP ranking.
Unique editorial angle
This article treats a PSP authorization rate like a company’s profit margin: useful, but impossible to interpret without understanding what went into it.
The central framework is:
Traffic × Decisioning × Processing path × Measurement = Reported PSP performance
The article then shows merchants how to normalize those inputs, run a controlled test, calculate incremental completed revenue, and compare providers on approval, fraud, cost, reliability, settlement, and operational burden.
Recommended format
A skeptical, quantitative guide built around:
A direct answer
A PSP performance-decomposition model
A fair-comparison checklist
A normalized scorecard
A hypothetical randomized traffic test
A net-revenue model
Merchant procurement questions
Developer and data requirements
Common analytical traps
A practical implementation workflow
Important limitation
There is no credible universal table of PSP authorization rates that can predict which provider will perform best for a particular merchant. Public benchmarks generally reflect proprietary portfolios with different merchants, countries, issuers, transaction types, fraud policies, and calculation methods.
SEO deliverables
Five SEO title options
Authorization Rates by PSP: A Merchant Guide
How to Compare PSP Payment Approval Rates
PSP Authorization Rates: A Fair Comparison
Compare Payment Provider Authorization Rates
Multi-PSP Approval Rates and Performance
Five meta-description options
Learn how to compare authorization rates by PSP fairly, control for transaction mix, run a multi-provider test, and measure net payment revenue.
Compare PSP approval rates without relying on misleading averages. Evaluate acquiring, routing, fraud, authentication, costs, and settlement.
Discover what sits inside a PSP authorization rate and how merchants can design a fair, controlled payment-provider performance test.
Understand why PSP approval rates differ and how to normalize traffic, retries, issuers, fraud rules, routing, costs, and payment outcomes.
Build a provider scorecard for authorization, fraud, uptime, cost, settlement, and net retained revenue across multiple PSPs.
Recommended URL slug
/authorization-rates-by-psp
authorization rates by PSP
Secondary keywords by intent
Informational
Payment provider authorization rates
PSP approval rate
PSP payment success rate
Payment processor approval rate
Multi-PSP authorization
Comparative
PSP approval rate comparison
Compare PSP payment performance
Compare payment processors
Payment provider performance comparison
Best PSP authorization rate
Diagnostic
Why PSP authorization rates differ
Low PSP approval rate
PSP decline analysis
Acquirer performance by PSP
Payment routing bias
Procurement
PSP evaluation framework
Multi-PSP strategy
Payment provider scorecard
PSP benchmarking
PSP traffic-split test
Semantic entities and related terms
Payment service provider
Gateway
Processor
Acquirer
Issuer
MID
Merchant entity
Authorization request
Approval rate
Payment success rate
First-attempt approval
Eventual approval
Technical success
Routing
Cascading
Failover
Retry
EMV 3-D Secure
Network tokenization
Account updater
Fraud screening
False decline
IIN
BIN
Response code
Merchant advice code
Capture rate
Settlement rate
Chargeback rate
PCI DSS
Net retained revenue
Randomized traffic split
Suggested H1
Authorization Rates by PSP: How Merchants Should Compare Payment Providers
Proposed heading hierarchy
H1: Authorization Rates by PSP
H2: What Is a PSP Authorization Rate?
H2: The PSP Performance-Decomposition Model
H2: What Sits Inside a PSP Payment Stack?
H2: Why Authorization Rates Differ Between PSPs
H3: Acquiring Coverage
H3: Routing
H3: Authentication
H3: Transaction-Data Quality
H3: Tokenization
H3: Fraud Screening
H3: Technical Reliability
H3: Retry and Cascading
H2: Why PSP Benchmarks Are Not Merchant Forecasts
H2: The Fair-Comparison Checklist
H2: How to Design a Multi-PSP Test
H2: Hypothetical PSP Comparison
H2: Why Approval Does Not Equal Net Revenue
H2: Normalized PSP Scorecard
H2: Questions to Ask Providers
H2: Developer and Data Requirements
H2: Common Analytical Mistakes
H2: PSP Evaluation Workflow
H2: Frequently Asked Questions
H2: Conclusion
Three featured-snippet answers
Featured snippet 1
Authorization rates by PSP cannot be compared fairly unless each provider receives sufficiently similar transactions and uses the same formula. Geography, issuer mix, routing, fraud screening, authentication, retries, tokenization, and technical failures can all change the reported rate.
Featured snippet 2
To compare PSP approval rates, randomly split eligible traffic between providers, measure first-attempt authorization using unique payments, and track fraud, chargebacks, cost, technical success, capture, settlement, and net retained revenue.
Featured snippet 3
A PSP authorization rate is the percentage of submitted authorization requests that are approved. Merchants should confirm whether it counts all attempts, first attempts, retries, duplicates, technical failures, and transactions blocked before authorization.
Suggested FAQ schema
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Can two PSP authorization rates be compared directly?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Only when the providers use the same definition and process sufficiently similar transactions. Geography, issuer mix, card type, fraud screening, authentication, routing, retries, and measurement can make raw rates misleading."
}
},
{
"@type": "Question",
"name": "What is a good PSP authorization rate?",
"acceptedAnswer": {
"@type": "Answer",
"text": "There is no universal good PSP authorization rate. The relevant benchmark is the provider's performance for the merchant's comparable transaction segments, evaluated alongside fraud, cost, reliability, capture, and settlement."
}
},
{
"@type": "Question",
"name": "Why does one PSP approve more payments than another?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Possible causes include different acquiring coverage, routing, transaction data, authentication, fraud rules, tokenization, issuer connectivity, technical reliability, and transaction mix."
}
},
{
"@type": "Question",
"name": "Should a merchant choose the PSP with the highest approval rate?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Not automatically. The merchant should compare net retained revenue, fraud, chargebacks, processing costs, uptime, latency, settlement, reporting, and operational burden as well as authorization."
}
},
{
"@type": "Question",
"name": "How should merchants test two PSPs?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Randomly assign comparable eligible transactions to each PSP, keep merchant-controlled rules consistent, measure first-attempt approval separately, and track downstream fraud, cost, capture, and settlement."
}
},
{
"@type": "Question",
"name": "Do retries improve a PSP authorization rate?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Retries may improve eventual payment success but can reduce attempt-level authorization rate by adding attempts after an initial failure. First-attempt and eventual approval should be reported separately."
}
},
{
"@type": "Question",
"name": "Can intelligent routing distort a PSP comparison?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Yes. If routing sends one PSP stronger segments and another harder or previously declined transactions, their raw authorization rates are not an unbiased comparison."
}
},
{
"@type": "Question",
"name": "Is payment success rate the same as authorization rate?",
"acceptedAnswer": {
"@type": "Answer",
"text": "No. Authorization rate covers requests submitted for issuer authorization. Payment success can also include checkout, fraud screening, authentication, technical processing, capture, and settlement."
}
}
]
}
Suggested internal-link anchor text
What is a good authorization rate?
How to benchmark PSP approval rates
How transaction routing improves approval rates
Authorization rate versus payment conversion rate
Authorization rates by issuer
Authorization rates by country
Authorization rates by payment method
Understanding payment decline codes
Soft declines versus hard declines
How payment data quality affects authorization
Local acquiring versus cross-border acquiring
How authentication affects payment acceptance
Network tokenization for merchants
How to reduce false declines
Multi-PSP payment orchestration
Three topic-specific CTAs
CTA 1: Provider comparison
Compare providers using your own payment reality
Evaluate authorization, fraud, cost, routing, and completed revenue across the transaction segments that matter to your business.
CTA 2: Multi-PSP strategy
Turn multiple PSPs into one coherent payment strategy
CTA 3: Global expansion
Find the payment setup that fits each market
Header-image concept
“The PSP Approval Rate Illusion”
Show two PSP dashboards:
PSP A: 95%
PSP B: 89%
Pull the dashboards apart to reveal different traffic underneath:
Domestic versus cross-border
Returning versus first-time
Tokenized versus PAN
Low versus high transaction value
Authenticated versus non-authenticated
First attempt versus retry
Headline:
Authorization Rates by PSP
Supporting line:
The numbers may be accurate. The comparison may not be.
Recommended alt text:
“Two PSP authorization rates shown above different transaction mixes, illustrating why raw provider approval rates cannot be compared directly.”
Supporting infographic 1
“What Is Inside a PSP Authorization Rate?”
Show four connected layers:
Traffic received
Issuer
Country
Card type
Customer
Transaction
Pre-authorization decisions
Fraud
Authentication
Validation
Processing path
Gateway
Acquirer
Routing
Transaction data
Measurement
Denominator
Retries
Deduplication
Exclusions
Center message:
Reported PSP rate = traffic + decisioning + processing + measurement
Recommended alt text:
“Four-layer decomposition showing how traffic, decisioning, processing paths, and measurement determine a PSP authorization rate.”
Supporting infographic 2
“The Fair Multi-PSP Test”
Create a left-to-right test flow:
Define eligible traffic
Randomly assign PSP A or PSP B
Keep merchant rules consistent
Measure first attempts
Track downstream outcomes
Control for transaction mix
Calculate net retained revenue
Decide route roles
Add guardrail metrics:
Fraud
Chargebacks
Technical success
Cost
Latency
Capture
Settlement
Recommended alt text:
“Controlled multi-PSP testing framework comparing authorization, fraud, cost, reliability, capture, settlement, and retained revenue.”
Claims requiring final review
Legal and compliance
PSP and merchant PCI DSS responsibilities.
Permitted retry and cascading behavior.
Network-specific response and advice rules.
Local-acquiring and domestic-processing claims.
Authentication and SCA implementation by region.
Data-retention and privacy requirements.
Product
Routing and traffic-allocation capabilities.
Local-acquiring coverage.
Authentication features.
Tokenization and account-updating functionality.
Raw-response and advice-code access.
PSP-level reporting and exports.
Failover and cascading support.
Technical
Authorization-rate definition.
Unique-payment deduplication.
First-attempt and eventual-approval calculations.
Randomization capability.
Provider-assignment logging.
Routing and retry lineage.
Timeout reconciliation.
Data-field availability.
Authentication and fraud-event joins.
Capture and settlement reporting.
Data science
Sample-size calculation.
Statistical confidence.
Cohort matching and stratification.
Traffic-split methodology.
Seasonality controls.
Provider-interaction effects.
Calculation of incremental net revenue.
Finance and operations
Processing-cost model.
Fraud and chargeback cost.
FX and cross-border fees.
Settlement timing.
Reconciliation workload.
Reserve requirements.
Provider concentration risk.
An anonymized distribution of PSP authorization differences after traffic matching.
First-attempt versus eventual-approval benchmarks.
Routing-bias examples from multi-provider portfolios.
Domestic and cross-border PSP performance.
Issuer-level variation between acquiring routes.
Tokenized versus non-tokenized performance.
Fraud-adjusted approval comparisons.
Technical-success distributions.
Net-revenue comparison templates.
A downloadable multi-PSP scorecard.
A PSP-test sample-size calculator.
An interactive provider-evaluation worksheet.
Differentiation note
This article is specifically about provider-performance attribution and procurement.
It differs from related pieces because it does not primarily explain:
What authorization rate means
Why countries differ
Why issuers differ
How routing works
How devices affect payment performance
How payment methods compare
Its unique purpose is to help merchants determine whether one PSP is genuinely outperforming another after accounting for traffic, fraud, acquiring, authentication, routing, retries, measurement, cost, and completed revenue.
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗