How to Benchmark PSP Approval Rates
The problem with benchmarking PSP approval rates is not that merchants lack numbers. It is that most of the numbers answer the wrong question. A merchant opens two provider dashboards and sees: The obvious conclusion is that PSP A performs better. It may also be completely wrong.
How to Benchmark PSP Approval Rates
The problem with benchmarking PSP approval rates is not that merchants lack numbers. It is that most of the numbers answer the wrong question.
A merchant opens two provider dashboards and sees:
PSP A: 91% approval rate
PSP B: 87% approval rate
The obvious conclusion is that PSP A performs better.
It may also be completely wrong.
PSP A may process mostly returning domestic customers using tokenized credit cards. PSP B may receive first-time cross-border customers, prepaid cards, higher-value orders, more recurring retries, or traffic that already failed elsewhere.
The reported percentages are precise. The comparison is not.
A valid benchmark must answer a narrower and more useful question:
For equivalent eligible transactions, under comparable conditions, which PSP produces the strongest risk-adjusted commercial outcome?
That formulation matters because a PSP does not operate independently of the payment architecture around it. Performance can reflect:
The acquiring connections behind the PSP
Merchant IDs and entity structure
Issuer and card-product mix
Local versus cross-border processing
Authentication configuration
Fraud-screening policy
Transaction-data quality
Token and credential support
Routing rules
Retry and cascading behavior
Technical reliability
The merchant’s own customer population
Benchmarking PSP approval rates is therefore not primarily a ranking exercise. It is a measurement and experiment-design discipline.
The metric problem: define what “approval rate” means
Before comparing providers, merchants must define the event being measured.
The basic formula is:
Approval rate = approved authorization requests ÷ eligible submitted authorization requests × 100
The phrase eligible submitted authorization requests is doing most of the work.
A provider may calculate its rate using all gateway attempts. Another may include only transactions that reached an issuer. A merchant may group several retries into one unique payment. All three can call the result an approval rate.
They are not equivalent.
Authorization rate, approval rate, and payment success rate
Authorization rate and approval rate are frequently used interchangeably to describe the proportion of authorization requests receiving approval. The exact boundary may vary by provider.
Payment success rate is usually broader. Depending on the implementation, it may include:
Merchant risk decisions
Authentication
Gateway availability
Authorization
Customer completion
Capture
Alternative payment-method completion
A PSP can therefore have a high issuer approval rate but a weak end-to-end success rate if many payments fail before authorization.
Conversely, a provider may report a lower authorization rate because it sends a broader or riskier set of transactions to issuers rather than blocking them internally.
The metric name is less important than the documented numerator and denominator.
First-attempt approval rate
First-attempt approval rate measures only the first authorization request associated with an intended payment:
First-attempt approval rate = approved first requests ÷ submitted first requests × 100
This is usually the cleanest primary metric for comparing PSPs.
It minimizes distortion from:
Retry frequency
Retry scheduling
Cascading
Decline-recovery logic
Multiple-provider attempts
Different definitions of an eventual success
First-attempt approval answers:
How often does this processing configuration secure approval on the initial authorization opportunity?
Attempt-based approval rate
Attempt-based approval counts every authorization request separately:
Attempt-based approval rate = approvals across all requests ÷ all authorization requests × 100
This metric is useful for measuring processing efficiency, but it can penalize providers or routes that receive many retries.
Consider a hypothetical portfolio:
1,000 first attempts
850 approved
150 declined
100 declined payments retried
25 retry approvals
Attempt-based approval:
875 approvals ÷ 1,100 requests = 79.5%
First-attempt approval:
850 ÷ 1,000 = 85%
Eventual unique-payment approval:
875 unique approved payments ÷ 1,000 intended payments = 87.5%
Every figure is correct. Each answers a different question.
Eventual unique-payment approval rate
Eventual approval measures the final approved outcome for each distinct intended payment after eligible recovery activity:
Eventual unique-payment approval = unique payments eventually approved ÷ unique intended payments × 100
This metric is valuable for understanding recovered revenue. It is less suitable as the sole PSP benchmark because it combines:
Initial authorization performance
Retry policies
Account updating
Token lifecycle management
Customer payment updates
Alternative routing
Dunning behavior
A provider with weaker first-attempt performance but stronger recovery could produce a higher eventual rate. That may still be commercially attractive, but executives should know what generated the result.
Technical success rate
Technical success rate measures whether the PSP successfully processed the request and returned a valid response:
Technical success rate = requests with a definitive processing outcome ÷ eligible requests submitted to the PSP × 100
Timeouts, malformed requests, provider outages, and unclassified failures should not be silently combined with issuer declines.
Technical reliability deserves its own benchmark because a transaction the issuer never evaluated is not an issuer rejection.
Capture and completed-payment rates
An authorization approval does not necessarily become captured or settled revenue.
Track:
Capture rate = captured transactions ÷ approved authorizations
and, when appropriate:
Completed-payment rate = completed eligible payments ÷ payment attempts
These metrics identify providers that obtain approvals but experience post-authorization failures, capture problems, delayed callbacks, or reconciliation issues.
A recommended benchmark metric stack
A defensible PSP comparison should include at least:
Metric
Purpose
First-attempt issuer approval rate
Primary provider comparison
Attempt-based approval rate
Request-level efficiency
Eventual unique-payment approval
Recovery effectiveness
Technical success rate
Provider reliability
Authentication completion rate
Pre-authorization friction
Capture rate
Conversion of approvals into captured payments
Fraud rate
Risk consequence of approvals
Chargeback rate
Delayed loss and dispute outcome
Cost per successful payment
Economic efficiency
Net approved revenue
Commercial outcome
No single metric is sufficient.
The baseline problem: internal versus external benchmarking
Merchants tend to ask for an external benchmark:
What approval rate should we be achieving?
That question is understandable, but frequently unhelpful.
An industry average may combine merchants with different:
Countries
Merchant categories
Average order values
Issuer populations
Customer histories
Card products
Fraud policies
Cross-border shares
Recurring-payment models
Authentication requirements
Acquiring relationships
The average can be accurate for the source population and irrelevant to the merchant.
Internal benchmarks
An internal benchmark compares current performance with:
Historical performance
A previous processing configuration
Another PSP
Another route
A matched merchant cohort
A controlled experiment
The best demonstrated internal performance for the same segment
Internal benchmarks are generally more actionable because they use the merchant’s own customers and payment profile.
Useful internal references include:
Same segment, previous period
Same segment, alternative PSP
Same issuer cohort, alternative acquirer
Same market, local versus cross-border route
Same recurring cohort, tokenized versus non-tokenized credentials
Same checkout, authentication variant A versus B
External benchmarks
External references can still be useful when they are sufficiently specific.
A credible external benchmark should disclose:
Population represented
Countries
Merchant categories
Transaction type
Card-present or card-not-present channel
Time period
First-attempt or eventual methodology
Retry treatment
Fraud treatment
Technical-error treatment
Authentication context
Whether results are weighted
Sample size or coverage
If these are unavailable, treat the benchmark as directional context—not a performance target.
Visa’s analytics materials, for example, frame authorization comparisons using portfolio characteristics such as card-not-present activity, decline responses, fraud, and peer context. The example figures in those materials are explicitly illustrative rather than universal targets. (Visa)
The mix problem: build comparable cohorts
The greatest source of PSP benchmark error is transaction mix.
A provider receiving easier traffic will generally produce a stronger blended rate even if it performs worse within every comparable segment.
The benchmark must therefore normalize the population being compared.
The minimum cohort dimensions
At minimum, PSP approval performance should be segmented by:
Customer country
Issuing country
Acquiring country
Merchant entity
Merchant ID
Card network
Issuer or account range
Debit, credit, prepaid, or commercial card
Currency
Transaction amount band
New versus returning customer
Customer-initiated versus merchant-initiated transaction
One-time versus recurring transaction
Initial attempt versus retry
Authentication status
Tokenized versus non-tokenized credential
Device or channel
Merchant risk outcome
Time period
Not every analysis must use every dimension simultaneously. The goal is to control the variables most likely to affect the comparison.
Cohort-construction checklist
Before accepting a PSP comparison, ask:
Transaction eligibility
Were both PSPs eligible to process every transaction in the cohort?
Were unsupported card products excluded consistently?
Did one provider receive only fallback traffic?
Did routing rules preselect particular issuers or countries?
Customer composition
Are new and returning customers balanced?
Are customer countries comparable?
Is one provider receiving higher-risk users?
Are subscription tenure and account history similar?
Payment method and credential
Are card networks and funding types balanced?
Are tokenized credentials distributed similarly?
Are stored credentials equally aged?
Are card-on-file and newly entered cards separated?
Transaction characteristics
Are amount and currency distributions comparable?
Are product categories similar?
Are one-time and recurring payments separated?
Are card-present and card-not-present flows separated?
Authentication and fraud
Does each provider use the same 3-D Secure policy?
Are exemption strategies comparable?
Are the same merchant fraud rules applied?
Does one PSP block transactions before issuer submission?
EMV 3-D Secure supports data exchange between merchants and issuers about the transaction, payment method, and device. Differences in authentication invocation, data completeness, challenge behavior, and customer completion can therefore change the population that eventually reaches authorization. (EMVCo)
Time and operations
Are transactions measured concurrently?
Were promotions or product launches balanced?
Did an issuer outage affect one period?
Did either provider experience a technical incident?
Did routing or fraud rules change during the test?
Standardization versus stratification
There are two common approaches to transaction-mix normalization.
Stratified comparison
Calculate each PSP’s performance within defined segments.
Example:
Segment
PSP A
PSP B
U.S. domestic credit
94%
95%
U.S. domestic debit
91%
92%
U.K. cross-border credit
82%
84%
German recurring debit
86%
87%
This reveals where each provider performs differently.
Standardized portfolio comparison
Apply the same reference mix to both PSPs.
Suppose the merchant’s target portfolio is:
40% U.S. domestic credit
25% U.S. domestic debit
20% U.K. cross-border credit
15% German recurring debit
Multiply each provider’s segment rate by the shared weight and sum the results.
This answers:
What would each PSP’s approval rate be if both processed the same portfolio composition?
Standardization is often more useful for executive comparison than the raw blended rate.
Simpson’s paradox: when the blended winner loses every segment
Simpson’s paradox occurs when the direction of an aggregate comparison reverses after the data is divided into relevant groups. The issue arises because the compared populations have different distributions across those groups. (Stanford Encyclopedia of Philosophy)
Consider this hypothetical PSP benchmark:
Domestic transactions
PSP
Approved
Attempts
Rate
PSP A
940
1,000
94%
PSP B
4,750
5,000
95%
PSP B wins.
Cross-border transactions
PSP
Approved
Attempts
Rate
PSP A
4,100
5,000
82%
PSP B
840
1,000
84%
PSP B wins again.
Blended result
PSP
Approved
Attempts
Rate
PSP A
5,040
6,000
84%
PSP B
5,590
6,000
93.2%
In this example PSP B also wins blended, so there is no reversal. Now change only the traffic allocation:
PSP A receives mostly domestic traffic.
PSP B receives mostly cross-border traffic.
Alternative traffic allocation
PSP
Domestic volume
Cross-border volume
PSP A
5,000
1,000
PSP B
1,000
5,000
Applying the same segment rates:
PSP A: 4,700 domestic approvals + 820 cross-border approvals = 5,520 / 6,000 = 92%
PSP B: 950 domestic approvals + 4,200 cross-border approvals = 5,150 / 6,000 = 85.8%
The blended result says PSP A wins, even though PSP B performs better in both segments.
The apparent advantage comes entirely from mix.
That is why a blended PSP approval rate is not merely incomplete. It can point in the wrong direction.
The experiment problem: observational comparisons versus randomized tests
Most merchant PSP comparisons begin observationally:
PSP A processed one market.
PSP B processed another.
PSP A handled primary traffic.
PSP B acted as fallback.
PSP A processed last quarter.
PSP B processed this quarter.
These comparisons can generate hypotheses. They rarely establish causation.
Observational benchmarking
Observational analysis uses historical transactions that were not randomly assigned.
It is useful for:
Identifying suspicious gaps
Finding issuer or country patterns
Prioritizing tests
Monitoring providers
Investigating incidents
Estimating opportunity size
Its weakness is selection bias. The route-selection logic may itself determine the result.
For example, a fallback PSP receives transactions only after another PSP has already failed. Its approval rate will naturally differ from a primary-route provider.
That is not a fair provider comparison.
Randomized controlled traffic split
Where technically, contractually, and operationally appropriate, the strongest PSP benchmark is a concurrent randomized test.
Eligible transactions are assigned to PSP A or PSP B according to a predefined traffic split, such as:
50/50 for a balanced test
90/10 for a lower-risk challenger test
Stratified randomization within important markets or issuer groups
The test should preserve comparable:
Fraud policy
Authentication rules
Merchant configuration
Currency
Retry policy
Customer experience
Time period
Randomization reduces the likelihood that customer and transaction differences systematically favor one provider.
It does not eliminate implementation differences. Those differences may be precisely what the merchant is testing.
What exactly should be randomized?
Randomize at the level of the unique intended payment before the first authorization attempt.
Do not independently randomize each retry. That could:
Split one payment across providers unpredictably
Complicate retry lineage
Increase duplicate risk
Distort eventual approval
Conflict with decline-resubmission guidance
The assigned treatment should normally persist for the relevant first-attempt test unless the experiment specifically studies eligible recovery routing.
Visa’s decline-response framework distinguishes transactions that should not be reattempted from those for which another attempt may be permitted, underscoring why benchmark tests must not apply blanket retry behavior. (Visa)
A sample PSP benchmark test plan
Objective
Determine whether PSP B improves first-attempt issuer approval for eligible card-not-present transactions in Market X compared with PSP A.
Hypothesis
PSP B produces a higher first-attempt issuer approval rate for matched eligible transactions without unacceptable increases in fraud, chargebacks, cost, or technical failure.
Eligible population
Customer country: Market X
Issuing country: Market X
Currency: local currency
Card networks: supported by both providers
Transaction type: customer-initiated ecommerce
Customer type: new and returning, stratified
Authentication: identical policy
Amount: within predefined range
Merchant entity: same or economically equivalent configuration
First attempts only
Transactions eligible for either PSP
Exclusions
Unsupported card products
Merchant-side fraud blocks
Account-verification requests
Known duplicate attempts
Tests and internal transactions
Transactions requiring provider-specific functionality
Previously declined payment retries
Allocation
Randomly assign eligible payment intents:
50% PSP A
50% PSP B
Stratify assignment by:
Issuer country
Card network
Funding type
Customer tenure
Amount band
Primary metric
First-attempt issuer approval rate.
Secondary metrics
Technical success rate
Authentication completion
Capture rate
Median and tail latency
Generic-decline share
Eventual unique-payment approval
Fraud rate
Chargeback rate
Cost per approved transaction
Net approved revenue
Guardrails
Pause or investigate if:
Duplicate authorization rate rises
Technical failure exceeds agreed tolerance
Fraud or chargebacks deteriorate materially
Customer-support complaints increase
Provider latency affects checkout
A compliance or network issue is detected
Duration
Determine duration using required sample size and expected transaction volume, not an arbitrary number of days.
Continue through enough normal business cycles to reduce distortion from weekday patterns, promotions, salary timing, issuer incidents, and fraud attacks.
Sample size and statistical confidence
A difference between two observed rates may reflect:
A real provider effect
Random variation
Transaction-mix imbalance
Measurement error
Operational changes
Statistical analysis addresses the first two. It does not fix poor cohort design.
Confidence intervals in plain English
A confidence interval describes the uncertainty around an estimated approval rate.
Suppose PSP A produces:
9,200 approvals
10,000 attempts
Observed rate: 92%
The true underlying probability is unlikely to be exactly 92.000%. The observed result is an estimate based on a finite sample.
A confidence interval provides a plausible range around that estimate under the method’s assumptions.
NIST notes that normal-approximation confidence intervals for binomial proportions depend on sufficiently large samples; when samples or event counts are small, exact binomial methods may be more appropriate. (NIST)
Statistical significance
A statistically significant result means that the observed difference would be relatively unlikely under a defined null hypothesis, often that the two PSPs have equal underlying approval probabilities.
It does not mean:
The difference is commercially meaningful.
The provider caused the difference.
The result will persist forever.
The provider is better for every segment.
Fraud and cost outcomes are acceptable.
Statistical significance addresses evidence against random chance—not strategic value.
Practical significance
A difference can be statistically significant and commercially trivial.
For example:
PSP A: 92.00%
PSP B: 92.08%
Millions of transactions
The difference may be statistically credible but too small to justify:
Integration costs
Higher fees
Operational complexity
Contract risk
Reconciliation work
Conversely, a commercially meaningful observed difference may not yet be statistically conclusive if the segment has low volume.
Executives need both:
Statistical confidence
Commercial materiality
Do not choose a universal minimum sample
There is no universally correct rule such as “run 10,000 transactions per PSP.”
Required sample size depends on:
Baseline approval rate
Smallest difference worth detecting
Desired confidence level
Statistical power
Traffic allocation
Segment variability
Number of comparisons
Uncertainty decreases approximately with the square root of the sample size, meaning that doubling precision requires much more than doubling volume. NIST’s technical guidance similarly connects binomial-estimate precision with sample size and the expected underlying proportion. (NIST Publications)
The merchant should define the minimum detectable effect before the test.
Example:
We need enough volume to detect an approval-rate difference of at least 0.5 percentage points with the chosen confidence and power.
A data scientist or qualified analyst should calculate the sample requirement for the planned design.
Multiple comparisons
When merchants compare:
Five PSPs
Twenty countries
Ten issuers
Four card types
Three authentication states
they may perform hundreds of comparisons.
Some will appear significant by chance.
Use:
Predefined primary hypotheses
Multiple-comparison adjustments where appropriate
Holdout data
Replication
Hierarchical or pooled models for sparse segments
Clear separation between exploratory and confirmatory analysis
A dashboard should not automatically crown a provider based on the largest observed short-term percentage.
Measuring routing and retry effects
A PSP benchmark can be corrupted by the way traffic reaches each provider.
Primary versus fallback traffic
PSP A may receive all first attempts.
PSP B may receive only:
Technical failover
Soft declines
High-risk countries
Unsupported issuers
Transactions rejected elsewhere
Comparing their raw rates is meaningless.
Label every attempt with:
Route position
Primary or fallback status
Previous attempt outcome
Previous provider
Time since previous attempt
Retry reason
Advice or eligibility signal
Payment-intent lineage
Routing selection effect
A smart router may intentionally send each PSP the transactions it historically handles best.
This can increase overall performance while making direct provider rates harder to compare.
Two distinct questions emerge:
Which provider is intrinsically stronger for a defined cohort?
Which routing policy produces the strongest portfolio outcome?
The first requires controlled provider comparison.
The second evaluates the entire routing strategy.
Do not confuse them.
Recovery-rate benchmarking
If the merchant compares retry performance, define:
Retry recovery rate = previously declined unique payments later approved ÷ eligible previously declined unique payments retried
Segment by:
Original decline category
Time since decline
Same versus updated credential
Same versus different PSP
Authentication action
Issuer
Recurring status
Attempt number
Never interpret a high recovery rate without examining how the retry population was selected.
The economics problem: approval lift is not revenue lift
A higher approval rate sounds economically positive. Usually it is. But the financial value depends on what was approved and what happened afterward.
A provider that approves more transactions may also produce:
More fraud
More chargebacks
Higher processing fees
Higher cross-border costs
Lower capture
More operational exceptions
Slower settlement
More reserves
More customer-service workload
The correct objective is not maximum approval.
It is maximum risk-adjusted net value.
From approval lift to incremental approvals
For a comparable cohort:
Incremental approvals = eligible attempts × approval-rate difference
Hypothetical example:
Eligible attempts: 1,000,000
PSP A approval: 90%
PSP B approval: 91%
Difference: 1 percentage point
Estimated incremental approvals:
1,000,000 × 0.01 = 10,000
From approvals to incremental authorized value
If average approved order value is $40:
10,000 × $40 = $400,000 incremental authorized value
This is not yet revenue.
From authorized value to captured value
Suppose 98% of incremental approvals are captured:
$400,000 × 98% = $392,000 captured value
Risk-adjusted incremental contribution
A simplified framework is:
Incremental net contribution = incremental captured margin − fraud losses − chargebacks − processing fees − authentication costs − incremental operating costs
Suppose the hypothetical incremental approved cohort produces:
Captured value: $392,000
Gross margin: 70%
Gross contribution before payment losses: $274,400
Fraud and chargebacks: $22,000
Additional processing expense: $9,000
Additional operating expense: $4,000
Estimated incremental net contribution:
$274,400 − $22,000 − $9,000 − $4,000 = $239,400
Every figure should be based on the merchant’s observed economics, not a generic assumption.
Cost per successful payment
Compare:
Cost per successful payment = total relevant processing cost ÷ successfully completed payments
Relevant cost may include:
PSP markup
Gateway fee
Acquirer fee
Interchange where applicable
Network fees
Cross-border assessments
3DS costs
Token or updater fees
Fraud-tool cost
Retry cost
Chargeback expense
FX expense
A PSP with a higher per-attempt fee can still be economically superior if it produces enough additional successful transactions.
Expected lifetime value
For subscription or repeat-purchase businesses, the value of an incremental approval can extend beyond the immediate transaction.
A successfully authorized initial payment may create:
Future renewals
Repeat purchases
Lower reacquisition cost
Higher lifetime value
Use lifetime value cautiously. Apply:
Cohort-specific retention
Contribution margin
Churn
Refunds
Fraud losses
Discounting
Confidence ranges
Do not multiply incremental approvals by an optimistic company-wide lifetime value without controlling customer quality.
The executive decision problem
A PSP decision is not simply:
Which provider has the higher approval rate?
It is:
Where should each provider sit within the merchant’s payment portfolio?
The answer may be:
Primary provider in selected markets
Secondary provider for resilience
Best route for certain issuers
Specialist for recurring payments
Local acquirer in one country
Fallback for technical failures
Limited challenger pending more evidence
Provider to be removed from a specific segment, not globally
A complete PSP benchmarking methodology
Step 1: Define the executive decision
Examples:
Should PSP B replace PSP A?
Should PSP B receive 30% of traffic in Market X?
Should issuer group Y be rerouted?
Should the merchant add a second provider?
Should a local route replace cross-border processing?
Should recurring transactions use another provider?
The benchmark design should match the decision.
Step 2: Document the metric
Define:
Numerator
Denominator
Attempt lineage
First-attempt treatment
Retry treatment
Technical failures
Authentication failures
Partial approvals
Capture
Timezone
Analysis window
Step 3: Build the eligible cohort
Include only transactions each tested configuration could legitimately process.
Step 4: Audit historical mix
Examine distribution by:
Country
Issuer
Card product
Currency
Amount
Customer type
Authentication
Recurring status
Credential type
Risk
Route
Step 5: Choose the evidence design
Use:
Randomized test where feasible
Matched observational comparison where randomization is not feasible
Historical analysis for diagnosis and hypothesis generation
External benchmark only as contextual reference
Step 6: Calculate sample requirements
Predefine:
Baseline
Minimum detectable effect
Confidence
Power
Test duration estimate
Primary outcome
Step 7: Instrument transaction lineage
Ensure that payment intent, attempt, authentication, routing, response, capture, fraud, and cost can be joined.
Step 8: Run concurrently
Avoid sequential tests where seasonality or market changes could dominate the result.
Step 9: Analyze by segment and portfolio
Report:
Raw blended results
Stratified results
Standardized results
Confidence intervals
Commercial effect
Guardrails
Step 10: Replicate important findings
Repeat high-value findings in:
Another time period
Another representative segment
A holdout cohort
A gradual traffic ramp
Step 11: Make a portfolio decision
Choose:
Traffic allocation
Routing policy
Contract action
Engineering work
Further experiment
No change
Step 12: Continue monitoring
PSP performance is not permanent. Issuer behavior, integrations, acquiring connections, fraud, and network conditions change.
Minimum viable dataset
A PSP benchmark should include the following data at the authorization-attempt level.
Identifiers
Payment-intent ID
Order ID
Attempt ID
Parent-attempt or retry ID
Idempotency key
PSP transaction ID
Authentication ID
Customer reference
Capture ID
Routing and provider context
PSP
Processor
Acquirer
Route
Route position
Merchant entity
Merchant ID
Acquiring country
Test variant
Assignment timestamp
Transaction context
Amount
Transaction currency
Settlement currency
Customer country
Issuing country
Card network
Funding type
Issuer or account-range enrichment
Merchant Category Code
New or returning customer
Device or channel
Credential and transaction type
Tokenized or non-tokenized credential
Stored credential
Customer-initiated or merchant-initiated
Recurring status
Initial or subsequent transaction
Credential age where appropriate and permitted
Authentication
Authentication invoked
3DS version
Frictionless or challenge
Challenge result
Authentication status
Exemption or exclusion indicator where applicable
Technical failure
Authorization and outcome
Submission timestamp
Technical result
Raw response
Normalized response
Retry/advice signal
Approval status
Response latency
Capture status
Refund status
Settlement status
Economics and risk
Processing fee
Network/acquirer cost where available
FX cost
Fraud outcome
Chargeback outcome
Gross margin or contribution estimate
Operational exception
Collect only data needed for legitimate analytical and operational purposes. Apply appropriate PCI DSS, privacy, access, security, contractual, and retention controls.
Sample executive PSP benchmark dashboard
Dimension
PSP A
PSP B
Difference
Confidence
Commercial interpretation
Eligible first attempts
250,000
249,800
—
—
Balanced allocation
First-attempt approval
91.2%
92.0%
+0.8 pp
Supported
PSP B leads
Standardized approval
91.3%
91.8%
+0.5 pp
Supported
Mix-adjusted gap smaller
Technical success
99.92%
99.70%
-0.22 pp
Supported
PSP B reliability weaker
Authentication completion
94.1%
94.0%
-0.1 pp
Inconclusive
No meaningful gap
Capture rate
99.1%
98.8%
-0.3 pp
Supported
Offsets part of approval gain
Eventual unique approval
92.4%
92.7%
+0.3 pp
Supported
Recovery narrows gap
Fraud rate
0.42%
0.58%
+0.16 pp
Pending maturity
PSP B guardrail concern
Chargeback rate
0.30%
0.37%
+0.07 pp
Immature
Wait for maturation
Cost per completed payment
$0.84
$0.91
+$0.07
Known
PSP B more expensive
Estimated net contribution
Baseline
+$X
—
Range
Final decision metric
All values above are hypothetical.
The dashboard should also include:
Segment-level winners
Trends over time
Confidence intervals
Sample counts
Fraud and chargeback maturity
Incident periods
Provider configuration notes
Decision recommendation
Required follow-up test
Questions to ask when a PSP presents benchmark claims
A provider may say:
Our merchants achieve a 95% approval rate.
That figure is not meaningful until the merchant asks:
What is the numerator?
What is the denominator?
Does it count first attempts or all attempts?
Are retries included?
Are technical failures excluded?
Are merchant fraud blocks excluded?
Are authentication failures excluded?
Is the result unique-payment based or request based?
Which countries are represented?
Which merchant categories are included?
What is the domestic versus cross-border mix?
Which card products are included?
What period does the figure cover?
Is it an average, median, or selected example?
Is the result weighted by volume?
Are low-performing merchants excluded?
Does it include local acquiring?
Which fraud and chargeback levels accompanied the rate?
Is the benchmark independently verifiable?
How would the provider estimate performance for our specific traffic?
Will the provider support a randomized test?
Can we access raw and normalized response data?
Can performance be segmented by issuer, route, and transaction type?
What configuration changes are required to reproduce the result?
The more a provider resists methodological detail, the less weight the headline number should receive.
When a PSP benchmark is not trustworthy
Do not rely on the benchmark when:
Denominators differ.
One PSP receives fallback traffic.
One period includes a major outage.
Transaction populations are unmatched.
Fraud policies differ.
Authentication policies differ.
One PSP uses more local acquiring.
Retries are blended into first attempts.
Technical errors are labeled as declines.
Small samples are ranked aggressively.
The test stopped immediately after a favorable result.
Only blended averages are shown.
Chargebacks have not matured.
Cost data is incomplete.
Provider configuration changed mid-test.
Routing algorithms adapted during the comparison without accounting for that adaptation.
The merchant cannot reconcile payment intents across systems.
The result cannot be reproduced.
A benchmark should reduce uncertainty. If its methodology adds hidden uncertainty, it is not serving its purpose.
How to interpret a PSP benchmark
A strong benchmark can support several different conclusions.
PSP B is broadly stronger
Evidence:
Higher standardized first-attempt approval
Stable segment performance
Comparable technical success
Acceptable fraud and chargebacks
Positive net economics
Action:
Gradually increase eligible traffic
Preserve a holdout
Monitor performance drift
PSP B is stronger only in selected segments
Evidence:
Better performance for specific issuers, countries, card products, or transaction types
No advantage elsewhere
Action:
Use targeted routing
Avoid a portfolio-wide migration
PSP B’s approval gain is offset by risk or cost
Evidence:
Higher approval
Higher fraud, chargebacks, or expense
Weak net contribution
Action:
Refine risk/configuration
Renegotiate pricing
Limit use to high-value segments
Run another test
The result is inconclusive
Evidence:
Wide confidence intervals
Small sample
inconsistent segment results
Operational incident
immature chargebacks
Action:
Continue or redesign the test
Do not declare a winner
The benchmark reveals a merchant problem
Evidence:
Both PSPs underperform in the same cohorts
Authentication, fraud rules, data, or checkout cause the divergence
Action:
Fix the merchant-side issue before changing providers
For merchants operating across several markets, PSP performance cannot be separated from acquiring, issuer coverage, local payment methods, authentication, transaction data, fraud controls, and routing.
No provider can guarantee issuer approval. A credible optimization program begins by defining the metric correctly, comparing equivalent traffic, and connecting every apparent uplift to its full commercial outcome.
Frequently asked questions
What is a PSP approval-rate benchmark?
A PSP approval-rate benchmark compares a provider’s approved authorization outcomes with an internal baseline, another provider, or a relevant external reference. A valid benchmark uses consistent denominators and comparable transaction cohorts.
What is the best metric for comparing PSP approval rates?
First-attempt issuer approval rate is usually the strongest primary comparison because it minimizes retry and recovery distortion. It should be supplemented with technical success, eventual approval, capture, fraud, chargebacks, and cost.
Can two PSP dashboard approval rates be compared directly?
Usually not without confirming that both use the same numerator, denominator, retry treatment, technical-error treatment, transaction population, and time period.
How long should a PSP A/B test run?
The test should run until it reaches the predefined sample requirement and covers enough normal operating variation. Duration depends on volume, baseline rate, desired minimum detectable effect, confidence, and statistical power.
How many transactions are needed to compare PSPs?
There is no universal number. Required sample size depends on the baseline approval rate, the smallest commercially meaningful difference, confidence level, statistical power, and test allocation.
Should retries count in a PSP approval-rate benchmark?
Retries should generally be reported separately. First-attempt approval measures initial provider performance, while eventual unique-payment approval and retry recovery measure the broader recovery strategy.
What is Simpson’s paradox in PSP benchmarking?
Simpson’s paradox occurs when one PSP appears stronger in the blended total because it receives easier traffic, even though another PSP performs better within every comparable segment. Segmenting or standardizing the traffic mix resolves the distortion.
Does a higher PSP approval rate always mean more revenue?
No. Incremental approvals may be offset by fraud, chargebacks, failed captures, higher fees, refunds, or operational costs. Merchants should evaluate risk-adjusted net contribution.
Is an external industry approval-rate benchmark useful?
It can provide context if the population and methodology resemble the merchant’s business. It should not be treated as a direct target when geography, merchant category, transaction type, fraud strategy, or denominator differs.
Should merchants always choose one winning PSP?
No. Different PSPs may perform best in different countries, issuer groups, card products, or transaction types. A portfolio and routing strategy may create more value than selecting one provider globally.
Research and editorial brief
Dominant search intent: Merchants searching for how to benchmark PSP approval rates are rarely looking for a generic industry average. They are trying to decide whether one payment service provider actually performs better than another, whether a new provider deserves more traffic, whether an existing provider is underperforming, or whether an apparent approval-rate gap is merely a product of transaction mix and measurement.
Main questions readers are trying to answer:
What belongs in a PSP approval-rate denominator?
Should retries, technical failures, fraud blocks, and authentication failures be included?
Is first-attempt approval more useful than eventual approval?
How can two PSPs be compared when they process different traffic?
Is a small observed difference statistically credible?
How should randomized traffic splitting be designed?
How much incremental revenue does an approval-rate lift actually create?
When do fraud, chargebacks, fees, and operating costs overturn the apparent winner?
What evidence should executives require before reallocating traffic or changing providers?
Weaknesses in much of the ranking content: Approval-rate benchmarking is often presented as a dashboard exercise rather than an experiment-design problem. Common shortcomings include relying on blended averages, using inconsistent denominators, ignoring routing and retry effects, comparing different time periods, treating short tests as definitive, and measuring approvals without incorporating fraud losses, chargebacks, capture, fees, or operational reliability.
Unique editorial angle: The central thesis of this article is:
A PSP benchmark is valid only when it compares equivalent opportunities to approve—not merely the transactions each provider happened to receive.
The real analytical unit is therefore not “PSP A versus PSP B.” It is a defined, eligible transaction cohort assigned to comparable processing configurations and evaluated using the same metric, time period, risk policy, and commercial framework.
Recommended format: A thesis-driven benchmarking manual organized around five problems:
The metric problem
The mix problem
The experiment problem
The economics problem
The executive decision problem
It includes a complete methodology, formulas, minimum viable dataset, cohort checklist, test plan, statistical guidance, Simpson’s paradox example, executive dashboard, and provider-claim evaluation framework.
Important limitation: There is no universally applicable public “good PSP approval rate.” Approval performance varies with issuer mix, geography, card product, merchant category, authentication, fraud controls, acquiring, routing, currency, transaction type, retry behavior, and methodology. Network benchmarking tools similarly compare performance within defined portfolios and peer contexts rather than presenting one universal merchant target. (Visa)
This article implements the methodology and executive-decision direction established in the supplied editorial brief.
SEO deliverables
Five SEO title options
How to Benchmark PSP Approval Rates Correctly
PSP Approval Rate Benchmarking: Merchant Guide
How to Compare Payment Provider Approval Rates
PSP Approval Rates: Testing and Benchmarking
Authorization Benchmarking for Payment Providers
Five meta-description options
Learn how to benchmark PSP approval rates using matched cohorts, controlled tests, confidence intervals, fraud data, costs, and net revenue.
A complete merchant methodology for comparing PSP approval rates without blended averages, transaction-mix bias, or misleading benchmarks.
Compare payment-provider performance with consistent formulas, A/B testing, statistical confidence, cohort normalization, and commercial analysis.
Discover how to calculate, test, and interpret PSP approval-rate benchmarks while accounting for retries, routing, fraud, fees, and chargebacks.
Build a trustworthy PSP benchmark with first-attempt approval, standardized traffic, sample-size planning, experiments, and executive dashboards.
Recommended URL slug
/how-to-benchmark-psp-approval-rates
how to benchmark PSP approval rates
Secondary keywords grouped by intent
Informational
PSP approval rate benchmark
Payment authorization benchmarking
Payment approval rate calculation
Payment provider approval rate
Authorization rate benchmark methodology
Comparison
Compare payment provider performance
Compare PSP approval rates
PSP performance comparison
Best PSP approval rate
PSP authorization comparison
Testing
PSP A/B test
Payment routing A/B test
Split traffic between PSPs
Payment provider experiment
PSP test sample size
Analytical
First-attempt approval rate
Eventual payment approval rate
Standardized authorization rate
PSP confidence interval
Payment cohort analysis
Simpson’s paradox payments
Commercial
Incremental revenue from approval lift
Cost per successful payment
PSP net revenue comparison
PSP fraud-adjusted performance
Payment provider ROI
Relevant semantic entities and terms
Payment service provider
PSP
Acquirer
Processor
Issuer
Card network
Merchant ID
Merchant entity
Authorization request
Authorization response
First-attempt approval
Eventual approval
Unique payment intent
Retry
Cascading
Failover
Smart routing
Local acquiring
Cross-border acquiring
EMV 3-D Secure
Authentication
Fraud acceptance
False decline
Chargeback
Capture
Settlement
Technical success rate
Confidence interval
Statistical significance
Statistical power
Minimum detectable effect
Randomization
Stratification
Standardization
Cohort analysis
Simpson’s paradox
Selection bias
Incremental revenue
Contribution margin
Cost per successful transaction
Idempotency
Payment lineage
Suggested H1
How to Benchmark PSP Approval Rates: A Merchant Framework
Proposed heading hierarchy
H1: How to Benchmark PSP Approval Rates
H2: The Metric Problem
H3: First-Attempt Approval
H3: Attempt-Based Approval
H3: Eventual Unique-Payment Approval
H3: Technical Success and Capture
H2: Internal Versus External Benchmarks
H2: The Mix Problem
H3: Cohort Construction
H3: Stratified and Standardized Comparisons
H3: Simpson’s Paradox
H2: The Experiment Problem
H3: Observational Comparisons
H3: Randomized PSP Tests
H3: Sample Size and Confidence
H2: Routing and Retry Effects
H2: The Economics Problem
H3: Incremental Approvals
H3: Risk-Adjusted Contribution
H3: Cost per Successful Payment
H2: Complete Benchmarking Methodology
H2: Minimum Viable Dataset
H2: Executive Benchmark Dashboard
H2: Questions to Ask About Provider Claims
H2: When a Benchmark Is Not Trustworthy
H2: Interpreting Results
H2: Frequently Asked Questions
Three featured-snippet answers
Definition
A valid PSP approval-rate benchmark compares equivalent eligible transactions using the same numerator, denominator, time period, fraud policy, authentication configuration, and retry treatment. First-attempt issuer approval is usually the best primary metric.
Methodology
To benchmark PSP approval rates, define the metric, construct comparable cohorts, randomize eligible first attempts where possible, calculate sample requirements, measure confidence intervals, and evaluate approval alongside fraud, chargebacks, capture, fees, and net revenue.
Warning
Do not compare blended PSP approval rates directly. A provider may appear stronger simply because it receives easier countries, issuers, card products, customers, or transaction types. Segment or standardize the traffic mix before drawing conclusions.
Suggested FAQ schema
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "What is a PSP approval-rate benchmark?",
"acceptedAnswer": {
"@type": "Answer",
"text": "A PSP approval-rate benchmark compares a provider's approved authorization outcomes with an internal baseline, another provider, or a relevant external reference. A valid benchmark uses consistent denominators and comparable transaction cohorts."
}
},
{
"@type": "Question",
"name": "What is the best metric for comparing PSP approval rates?",
"acceptedAnswer": {
"@type": "Answer",
"text": "First-attempt issuer approval rate is usually the strongest primary metric because it minimizes distortion from retries and recovery logic. Merchants should also evaluate technical success, eventual approval, capture, fraud, chargebacks, and cost."
}
},
{
"@type": "Question",
"name": "Can two PSP dashboard approval rates be compared directly?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Usually not. Merchants must first confirm that both dashboards use the same numerator, denominator, retry treatment, technical-error treatment, transaction population, and time period."
}
},
{
"@type": "Question",
"name": "How long should a PSP A/B test run?",
"acceptedAnswer": {
"@type": "Answer",
"text": "A PSP test should run until it reaches its predefined sample requirement and covers sufficient normal operating variation. Duration depends on volume, baseline approval rate, minimum detectable effect, confidence, and statistical power."
}
},
{
"@type": "Question",
"name": "How many transactions are needed to compare PSPs?",
"acceptedAnswer": {
"@type": "Answer",
"text": "There is no universal number. Required sample size depends on the baseline rate, the smallest commercially meaningful difference, desired confidence level, statistical power, and test allocation."
}
},
{
"@type": "Question",
"name": "Should retries count in a PSP approval-rate benchmark?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Retries should generally be reported separately. First-attempt approval measures initial provider performance, while eventual unique-payment approval and retry recovery measure the broader recovery strategy."
}
},
{
"@type": "Question",
"name": "What is Simpson's paradox in PSP benchmarking?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Simpson's paradox occurs when one PSP appears stronger in the blended total because it receives easier traffic, even though another PSP performs better within every comparable segment."
}
},
{
"@type": "Question",
"name": "Does a higher PSP approval rate always mean more revenue?",
"acceptedAnswer": {
"@type": "Answer",
"text": "No. Incremental approvals may be offset by fraud, chargebacks, failed captures, higher fees, refunds, and operating costs. Merchants should compare risk-adjusted net contribution."
}
},
{
"@type": "Question",
"name": "Should merchants always choose one winning PSP?",
"acceptedAnswer": {
"@type": "Answer",
"text": "No. Different PSPs may perform best in different markets, issuer groups, card products, or transaction types. A portfolio and routing strategy may produce more value than selecting one provider globally."
}
}
]
}
Suggested internal-link anchor text
What is a payment authorization rate?
Authorization rates by PSP
Authorization rates by issuer
Authorization rates by country
How to improve payment authorization rates
Payment approval rate versus conversion rate
How to reduce payment declines
Soft declines versus hard declines
Payment routing explained
Local acquiring and authorization rates
How issuer responses affect payment acceptance
How payment data quality affects authorization
How authentication affects payment conversion
How BIN data improves payment analysis
Most common card-decline reasons
How to benchmark payment performance
Cost per successful payment
Three topic-specific CTA options
CTA 1: Benchmarking focused
CTA 2: Portfolio focused
CTA 3: Executive focused
Header-image concept
“The Fair PSP Benchmark”
Each route passes through the same:
Customer cohort
Fraud policy
Authentication rules
Transaction mix
A central analytical panel compares:
First-attempt approval
Technical success
Fraud
Cost
Net revenue
Headline:
How to Benchmark PSP Approval Rates
Supporting line:
Compare equivalent traffic—not misleading averages
Recommended alt text:
“Equivalent payment transactions split between two PSP routes and compared across approval rate, reliability, fraud, cost, and net revenue.”
Supporting infographic 1
“The PSP Benchmarking Method”
Create a ten-step horizontal framework:
Define the decision → Define the denominator → Build eligible cohorts → Audit transaction mix → Choose the test design → Calculate sample size → Randomize traffic → Measure guardrails → Standardize results → Make a portfolio decision
Add a warning beneath:
A precise percentage from an unfair comparison is still an unreliable benchmark.
Recommended alt text:
“Ten-step PSP approval-rate benchmarking framework covering metric definitions, cohort construction, test design, sample size, randomization, guardrails, and provider decisions.”
Supporting infographic 2
“Why the Blended PSP Winner Can Be Wrong”
Illustrate Simpson’s paradox with two providers and two transaction segments:
Domestic
Cross-border
Show PSP B outperforming PSP A within both segments, while PSP A appears better in the blended total because it received more domestic traffic.
End with:
Segment first. Standardize second. Compare last.
Recommended alt text:
“Example showing how different domestic and cross-border traffic mixes can make the weaker PSP appear to have the higher blended approval rate.”
Claims requiring review
Verify which technical failures are included or excluded from reported authorization rates.
Confirm availability of PSP-, acquirer-, issuer-, route-, and Merchant ID–level reporting.
Review whether test assignment can persist at payment-intent level.
Confirm available authentication fields and 3DS reporting.
Validate raw response, normalized response, and retry-advice availability.
Review fraud, chargeback, capture, cost, and net-revenue reporting capabilities.
Confirm whether local and cross-border processing classifications are available.
Review support for BIN/IIN, issuer, funding-type, and product enrichment.
Validate data-retention, PCI DSS, privacy, security, and contractual requirements.
Have data science review all sample-size, confidence-interval, power, and standardization guidance.
Confirm how partial approvals and account-verification requests are handled.
Verify cost components available for cost-per-successful-payment analysis.
Ensure CTAs do not imply guaranteed authorization improvement.
Anonymized distribution of PSP performance gaps by market
Difference between blended and standardized PSP rates
First-attempt versus eventual approval by route
Share of apparent PSP gaps explained by traffic mix
PSP technical-success distributions
Local versus cross-border provider comparisons
Issuer-level PSP winners by region
Tokenized versus non-tokenized results
Fraud-adjusted approval comparisons
Cost per successful transaction by route
Examples of Simpson’s paradox in anonymized merchant data
Median sample size required to identify meaningful gaps
Results from controlled routing experiments
Approval gains that disappeared after capture or fraud adjustment
Case studies where different PSPs won different segments
Any proprietary analysis should disclose scope, denominator, period, geography, traffic selection, statistical methodology, and limitations.
Differentiation note
This article differs from the other authorization-optimization articles because the primary unit is not a country, issuer, payment method, device, or provider’s raw rate. It is the benchmarking experiment itself.
Its purpose is to teach merchants how to determine whether a PSP performance difference is valid, statistically credible, and commercially meaningful. The defining concepts are cohort equivalence, randomization, mix normalization, sample uncertainty, Simpson’s paradox, and risk-adjusted economics—not general authorization optimization.
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗