How to Benchmark PSP Approval Rates

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: 1. Statistical confidence 2. 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: 1. Which provider is intrinsically stronger for a defined cohort? 2. 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: 1. What is the numerator? 2. What is the denominator? 3. Does it count first attempts or all attempts? 4. Are retries included? 5. Are technical failures excluded? 6. Are merchant fraud blocks excluded? 7. Are authentication failures excluded? 8. Is the result unique-payment based or request based? 9. Which countries are represented? 10. Which merchant categories are included? 11. What is the domestic versus cross-border mix? 12. Which card products are included? 13. What period does the figure cover? 14. Is it an average, median, or selected example? 15. Is the result weighted by volume? 16. Are low-performing merchants excluded? 17. Does it include local acquiring? 18. Which fraud and chargeback levels accompanied the rate? 19. Is the benchmark independently verifiable? 20. How would the provider estimate performance for our specific traffic? 21. Will the provider support a randomized test? 22. Can we access raw and normalized response data? 23. Can performance be segmented by issuer, route, and transaction type?

24. 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: 1. The metric problem 2. The mix problem 3. The experiment problem 4. The economics problem 5. 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 1. How to Benchmark PSP Approval Rates Correctly 2. PSP Approval Rate Benchmarking: Merchant Guide 3. How to Compare Payment Provider Approval Rates 4. PSP Approval Rates: Testing and Benchmarking 5. Authorization Benchmarking for Payment Providers Five meta-description options 1. Learn how to benchmark PSP approval rates using matched cohorts, controlled tests, confidence intervals, fraud data, costs, and net revenue. 2. A complete merchant methodology for comparing PSP approval rates without blended averages, transaction-mix bias, or misleading benchmarks. 3. Compare payment-provider performance with consistent formulas, A/B testing, statistical confidence, cohort normalization, and commercial analysis. 4. Discover how to calculate, test, and interpret PSP approval-rate benchmarks while accounting for retries, routing, fraud, fees, and chargebacks. 5. 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 Primary keyword 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

4. Verify which technical failures are included or excluded from reported authorization rates. 5. Confirm availability of PSP-, acquirer-, issuer-, route-, and Merchant ID–level reporting.

7. Review whether test assignment can persist at payment-intent level. 8. Confirm available authentication fields and 3DS reporting. 9. Validate raw response, normalized response, and retry-advice availability. 10. Review fraud, chargeback, capture, cost, and net-revenue reporting capabilities. 11. Confirm whether local and cross-border processing classifications are available. 12. Review support for BIN/IIN, issuer, funding-type, and product enrichment. 13. Validate data-retention, PCI DSS, privacy, security, and contractual requirements. 14. Have data science review all sample-size, confidence-interval, power, and standardization guidance. 15. Confirm how partial approvals and account-verification requests are handled. 16. Verify cost components available for cost-per-successful-payment analysis.

18. 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.