Comparing PSP Performance

Comparing PSP Performance: How to Build a Fair Multi-Provider Scorecard A payment-performance leaderboard can be mathematically correct and operationally wrong. Suppose Provider A reports a 94% approval rate while Provider B reports 89%. The obvious conclusion is that Provider A is better. Now inspect the traffic. Provider A receives mostly domestic, low-risk, returning-customer card payments. Provider B receives more cross-border cards, unfamiliar issuers, higher transaction values, and customers requiring additional authentication. The percentages are real. The comparison is not. This is the central problem in comparing PSP performance: the provider does not choose performance in isolation. The observed result is produced by a combination of provider capability, issuer behavior, customer and transaction mix, authentication, fraud policy, routing logic, payment method, geography, and time. Provider documentation itself shows why definitions need scrutiny before benchmarking. Stripe currently distinguishes a full-funnel payment success rate from a narrower network authorization rate and separately offers raw and deduplicated views. Checkout.com explicitly cautions that PSPs can calculate authorization rates differently and recommends using a consistently defined comparison metric when benchmarking providers. The operating rule for a multi-PSP merchant should therefore be: PSP performance comparison is a cohort-normalization problem before it is a dashboard problem. Raw PSP averages lie

They do not usually lie because the data is false. They lie because averages erase the conditions under which the transactions occurred. Imagine this simplified traffic allocation: Traffic Provider A receives Provider B receives Domestic cards High share Low share Cross-border cards Low share High share Returning customers High share Lower share High-value orders Lower share High share Additional authentication Less frequent More frequent If those characteristics materially influence payment outcomes, the headline averages describe traffic plus provider, not provider alone. Stripe's current acceptance analytics illustrates how many dimensions can affect an observed rate: its breakdowns include payment method, buyer or card country, currency, card type, input method, retry status, and other payment characteristics. Stripe also explicitly separates payment attempts that reach the network from failures that happen earlier in authentication or fraud controls. A merchant comparing several providers therefore needs to ask before looking at a ranking: Were these PSPs actually processing comparable payments? If not, the ranking is descriptive—not diagnostic. Step 1: define the eligible comparison cohort The cleanest provider comparison starts with eligibility. For a transaction to belong in a head-to-head comparison of PSP A and PSP B, both providers should realistically have been valid routes for that transaction under the merchant's actual operating constraints. Those constraints may include: * market;

* acquiring arrangement; * merchant entity; * payment method; * transaction currency; * issuer geography; * card or credential type; * recurring-payment capability; * authentication requirements; * token compatibility; * transaction value; * customer type; * risk policy; and * contractual or regulatory restrictions. If Provider B cannot process a particular payment method in that market, it should not be marked down because Provider A successfully processes that traffic. That is coverage, not comparative execution performance. Likewise, if Provider A cannot use the token required for a recurring transaction, the transaction is not a fair A-versus-B authorization test. Eligibility should precede ranking A useful model is: All merchant payment opportunities ↓ Payments eligible for PSP A Payments eligible for PSP B ↓ Intersection: payments eligible for both ↓ Comparable cohorts ↓ Performance comparison This immediately separates two strategic questions: Coverage question: What useful traffic can this provider process? Performance question: How well does it process traffic that competing providers could also process? Both matter. They should not be collapsed into one number. Step 2: normalize the traffic that remains Eligibility alone is not enough. Even inside the common eligible population, providers can receive different mixes. At minimum, segment where relevant by: * market; * payment method; * issuer geography; * currency; * transaction-value band; * customer segment; * authentication state or strategy;

* risk policy; and * comparable time period. Depending on the merchant, other dimensions may matter too: * card type; * new versus returning customer; * stored credential versus new credential; * card-on-file versus customer-initiated; * subscription versus one-off; * device/channel; * merchant entity; * acquiring route; * retry status; or * specific issuer/BIN groups where sample size supports the analysis. Do not create hundreds of tiny cohorts merely because the data warehouse allows it. The purpose is to control for material differences in transaction difficulty, not maximize segmentation. A simple normalization model Suppose the shared eligible population contains three meaningful cohorts: * domestic cards; * regional cross-border cards; * interregional cross-border cards. For each provider, calculate the performance rate inside each cohort. Then apply the same reference traffic mix to every provider. Conceptually: Normalized Provider Performance = Σ common cohort weight × provider performance within that cohort If the merchant's reference portfolio is: * 50% domestic; * 30% regional cross-border; * 20% interregional cross-border, both PSPs are scored as though each processed that same mix. That removes one major source of routing bias. The weighting population should be explicitly documented. Possible choices include: * the merchant's eligible traffic mix; * a strategic future traffic mix; * an equal-weight cohort comparison; * or another defensible reference population.

Do not change the weights silently when the provider ranking changes. Pairwise comparisons versus portfolio comparisons Not every PSP pair has identical eligibility. A regional PSP might overlap with a global PSP only in three markets. Another provider may specialize in one payment method. That creates two valid analytical views. Pairwise comparison Compare PSP A and PSP B only on their shared eligible traffic. Best for answering: Which performs better where both could have processed the transaction? Portfolio-normalized comparison Create a common reference population and score each provider only where its eligible coverage intersects with that population. Best for portfolio review, but its missing coverage must remain visible. Do not turn “not eligible” into a performance failure. A provider can be excellent at its strategic role while having narrow coverage. Step 3: standardize what the metrics mean Before building a PSP scorecard, establish a merchant-owned metric dictionary. This matters because provider dashboards do not necessarily use the same denominator. Stripe, for example, currently defines its payment success rate across the wider payment attempt funnel, while its network authorization rate excludes payments that fail before reaching network authorization. Stripe also distinguishes raw attempts from a deduplicated view that groups retries associated with a purchase.

Checkout.com separately distinguishes acceptance/authorization concepts from capture and warns about differences in PSP authorization-rate calculation when benchmarking. A merchant should not compare: PSP A's payment success rate with: PSP B's network authorization rate and call them approval-rate peers. Minimum common metric definitions Define internally: Payment intent The merchant/customer objective to complete a particular payment. Payment attempt One concrete processing attempt through one provider/path. Eligible attempt An attempt meeting the merchant-defined eligibility criteria for the comparison being performed. Authorization attempt An eligible attempt actually submitted into the defined authorization stage. Approved authorization An authorization attempt receiving the merchant-defined successful authorization outcome. Completed payment A payment meeting the merchant's defined completion criteria. Technical error A provider/path/integration failure classified separately from an issuer or customer payment decline. Unknown/unresolved attempt An attempt whose final state is not yet safely known. Latency Elapsed time for a clearly defined stage. Settlement exception A transaction or settlement record that fails the merchant's defined reconciliation expectation. Every dashboard should disclose its denominator. Approval rate: useful, but narrower than payment success For cards, a basic authorization metric might be: Authorization Approval Rate = Approved authorization attempts ÷ Authorization attempts

The denominator must be consistent. Stripe's current documentation makes the reason clear: payments can fail during authentication or a fraud-control stage before they reach the card network, and its network authorization rate therefore excludes those pre-network failures. Authorized payments also do not tell you whether the transaction was later captured. That means a high authorization rate can coexist with a weaker full payment funnel. For PSP comparison, use at least two views where relevant: Network/authorization performance Of payments that genuinely reached authorization, how often were they approved? Merchant payment success/completion Of the comparable payment opportunities assigned to this route, how often did the merchant ultimately achieve the intended successful payment state? Those metrics answer different questions. Do not select one merely because it makes a provider look better. Compare attempts with attempts and intents with intents Retries create another denominator trap. Suppose one customer payment is declined twice and succeeds on attempt three. At the attempt level, the success rate is 1/3. At the payment-intent level, the customer ultimately paid: 1/1. Neither number is inherently wrong. They measure different things. Stripe's current acceptance analytics illustrates exactly this distinction by providing raw and deduplicated rates; its documentation shows how repeated attempts can materially change the reported percentage.

A multi-PSP merchant should therefore carry both: Attempt-level provider performance and Intent-level merchant outcome Provider comparison normally needs the attempt-level view. Customer/revenue analysis often also needs the intent-level view. Do not combine them in one denominator. Completed-payment rate matters because authorization is not the finish line An issuer authorization can be successful while the merchant still does not reach its intended final payment state. Stripe explicitly notes that an authorized payment does not indicate whether the funds were ultimately captured. Checkout.com similarly distinguishes its acceptance concept from capture rate. The merchant should therefore define: Completed-Payment Rate = Completed payments ÷ Comparable eligible payment opportunities or attempts The precise denominator depends on the question. For a direct PSP processing comparison, an attempt-level metric is usually easier to attribute. For checkout performance, the merchant may instead track completion at the payment-intent level. Document which one is shown. Technical errors deserve their own metric Do not allow technical failures to disappear into a generic “declined” bucket. A provider can produce an issuer decline because the bank rejected the payment. It can also produce: * API errors; * gateway failures; * malformed responses; * connection failures; * service timeouts; * internal provider errors; * webhook delays; * method-specific technical failures; or * merchant integration errors.

Those causes have different owners. A useful metric is: Provider Technical Error Rate = Provider-attributed technical failures ÷ Eligible requests to the relevant provider function But the error taxonomy must be merchant-controlled. Otherwise PSP A's “technical decline” can end up compared with PSP B's “processing error” without any evidence that the categories mean the same thing. Do not classify timeouts as declines by default A timeout means the merchant did not receive a definitive answer within the expected period. It does not prove that the provider or issuer definitively failed the payment. For performance analytics, keep unresolved attempts in an unknown state until subsequent retrieval, provider events, or reconciliation establishes the final outcome. This protects both the performance data and the merchant from unsafe retry assumptions. The duplicate-payment implications belong in Preventing Duplicate Payments Across PSPs. Latency: define exactly what clock you are measuring “PSP latency” can describe several different clocks: * request-to-response API latency; * authorization round-trip time; * time awaiting customer authentication; * time for an asynchronous payment method to resolve; * webhook/event delay; * capture response time; or * complete customer payment time. These should not be averaged together. For synchronous processing, merchants can track distributions such as: * p50; * p95; * p99. The high percentiles often reveal degradation that an average conceals.

For asynchronous payment methods, raw API response latency can be a poor proxy for customer completion. Instead measure time to meaningful state resolution for the relevant method. Adyen's current checkout analytics, for example, exposes completion, validation-error and transaction-completion timing information in its own product environment—illustrating that payment performance extends beyond a single authorization percentage. Normalize latency too Do not compare: PSP A domestic authorization latency with: PSP B's cross-border 3DS-heavy end-to-end completion time. Use the same: * operation; * payment method; * geography; * authentication context; * time period; and * preferably comparable issuer/payment characteristics. Availability: measure the path, not only the brand A multi-PSP merchant usually cares about whether an eligible payment path is usable. A provider might experience degradation only for: * one region; * one method; * one endpoint; * one acquiring route; * or one merchant account. A useful merchant operational view can therefore track: Observed Path Availability = Eligible technical requests receiving a valid processing response within the merchant-defined service objective ÷ Eligible technical requests Issuer declines should not automatically count as provider unavailability. Likewise, one payment method failing should not automatically mark the entire PSP unavailable. Useful supporting measures include: * degradation incidents; * affected minutes; * impacted traffic share; * webhook delays;

* API error spikes; * and recovery time. The deeper outage and continuity logic belongs in PSP Failover and Redundancy. Cost belongs in the scorecard—but not as “cheapest wins” A provider can authorize more payments and still have weaker economics. Another can have lower unit processing fees but create more failures, exceptions, or operational work. For this performance article, keep cost deliberately bounded. A useful metric is: Observed Processing Cost per Completed Payment = Defined provider-attributable transaction costs ÷ Completed payments The included cost components must be documented. Depending on the merchant's pricing arrangement, relevant observable components might include: * processing fees; * acquiring markup; * scheme/network fees; * interchange where passed through; * applicable authentication or service charges; * FX-related processing components where in scope; and * other directly attributable payment costs. Adyen's current Settlement Details report is one example of provider reporting that includes transaction references, merchant references, settlement values, and transaction-level cost fields that can support reconciliation and cost analysis. Do not compare two providers if one cost calculation includes interchange and scheme fees while the other contains only PSP markup. And do not let this section become a full total-cost model. True Cost & Net Revenue should own the broader economic analysis. Normalize for transaction value when comparing cost

A fixed per-transaction fee behaves differently on a $10 transaction than on a $1,000 transaction. Therefore cost should often be examined both as: absolute cost per completed transaction and, where meaningful, cost relative to processed/completed value. Transaction-value bands should also be included in cohort normalization when ticket size materially affects pricing or payment behavior. The scorecard's job is to expose that context. Pricing Optimization owns the separate question of how to route specifically for cost. Risk outcomes can make an “approval winner” look better than it is Approval should not be optimized independently of fraud. Suppose PSP A approves more traffic because its effective risk configuration is more permissive than PSP B's. A short-term authorization comparison can favor A. Later, the merchant might see a different: * fraud rate; * chargeback/dispute rate; * refund profile; or * loss outcome. Adyen's current optimization tooling explicitly treats payment conversion, risk, and cost as interconnected considerations rather than one isolated metric. For a fair PSP comparison, merchants should either: * align material risk policies where practical; * normalize by risk configuration; * or clearly state that the measured object is provider + risk setup, not the processing provider alone. Risk metrics need mature observation windows Fraud and disputes often arrive later than authorization results.

Do not compare yesterday's newly approved PSP traffic with another provider's fully matured historical chargeback cohort. For every lagging risk KPI record: * cohort transaction dates; * observation/maturity window; * numerator; * denominator; * market/method scope; and * risk configuration. Do not invent a universal maturity interval. Choose one appropriate to the payment method, merchant data, and metric. Settlement performance belongs in provider performance A payment provider can look strong in the checkout funnel and still create significant Finance friction. Relevant questions include: * Were expected transactions included in settlement? * Can Finance match provider records to merchant payments? * Are fees attributable at the required level? * Do reports arrive reliably? * Do settlement records contain usable reconciliation keys? * How many records require manual investigation? * Are payouts/settlements received according to the applicable provider arrangement? Adyen's current Settlement Details report explicitly supports transaction-level reconciliation and carries both a provider reference and merchant reference, alongside costs and settlement information. That illustrates an important scorecard principle: payment performance does not end at authorization. Settlement and reconciliation metrics Possible merchant-defined KPIs include: Reconciliation Match Rate Successfully matched provider settlement records ÷ Relevant provider settlement records Reconciliation Exception Rate

Records requiring manual or automated exception treatment ÷ Relevant settlement records Settlement Reliability Settlements meeting the merchant's defined expected conditions ÷ Relevant expected settlements Unresolved Financial Exceptions Count and value of payment/settlement records still unresolved after the merchant's defined operating window. Do not publish external benchmarks unless the underlying definitions are genuinely comparable. Operational exceptions deserve a score too Some PSP differences appear only when people have to operate the provider. Track issues such as: * unexplained payment states; * difficult-to-map error responses; * delayed provider support escalation; * missing report fields; * manual reconciliation steps; * repeated incident classes; * reporting corrections; * account/configuration errors; and * provider changes requiring merchant engineering work. These should not automatically be reduced to a subjective “support quality” number. Record the operational event. Examples: Manual reconciliation hours per 10,000 completed payments Provider-attributable operational exceptions per 10,000 attempts Incident hours affecting eligible traffic Median time to resolve provider-specific exception Use metrics the merchant can actually reproduce. The PSP Performance Scorecard A controlled scorecard should contain three layers. Layer 1 — comparison context Record before any metric: Field Required context Provider PSP/acquirer being evaluated Provider role

Global primary, regional specialist, backup, etc. Market Comparable market Payment method Card/method cohort Issuer geography Comparable issuer location Currency Transaction currency Value band Merchant-defined transaction range Customer segment New/returning or relevant segment Authentication Comparable authentication treatment Risk configuration Comparable or explicitly different Time period Same measurement period Eligibility rule Why both providers could process the traffic Sample size Attempts/payments included Layer 2 — performance outcomes Dimension Core metric Denominator / basis Authorization Approval rate Comparable authorization attempts Completion Completed-payment rate Comparable attempts or intents—state which Technical reliability Technical error rate Eligible technical requests/attempts Latency p50/p95/p99 or relevant resolution time Same operation and cohort Availability Observed path availability Eligible requests within defined SLO Cost Cost per completed payment Same defined cost components Risk Fraud/dispute outcome Mature comparable cohort Settlement Reconciliation/settlement reliability Comparable settled records Operations Exception/incident burden Defined operational denominator Layer 3 — interpretation For every result record: * sample size; * uncertainty/confidence where used; * comparison cohort; * weighting method; * data freshness; * known routing bias; * provider configuration change; * incident contamination; * experiment status; * and whether the result is descriptive or causal.

Without Layer 3, the scorecard can become another misleading dashboard. Do not start with one weighted “PSP score” A single score such as: PSP A = 87/100 looks decisive. It also hides trade-offs. A provider can have: * stronger authorization; * slower latency; * higher cost; * better settlement reliability; * more operational exceptions. Before creating a composite score, the merchant must decide its objective. If weights are eventually used, they should be explicit and governed: Metric Result Weight Weighted result Approval

Merchant-defined

Completion

Merchant-defined

Technical reliability

Merchant-defined

Merchant-defined

Availability

Merchant-defined

Merchant-defined

Merchant-defined

Settlement

Merchant-defined

Operations

Merchant-defined

There is no universal correct weighting. A backup PSP can rationally be scored differently from a primary high-volume processor because the providers serve different portfolio roles. Provider roles change what “good” means A regional specialist does not need to win every global metric. A strategic backup may process little steady-state volume but still need to demonstrate: * technical readiness; * credential compatibility; * acceptable authorization performance; * operational supportability; * and reliable reporting. A high-volume primary provider may instead be held to demanding requirements across: * approval; * cost; * latency; * availability; * reconciliation; * operational burden; and * coverage. The scorecard should therefore contain a provider role before it contains a provider ranking. Otherwise a specialist is penalized for not being a generalist, and a backup can appear insignificant simply because routing intentionally gives it little traffic. Historical data contains routing bias This is the most important analytical caution after cohort normalization. Imagine the merchant already routes: * high-quality returning customers to PSP A; * difficult cross-border traffic to PSP B. Historical data then shows A has better performance. If the merchant uses that historical result to route still more good traffic to A, the bias becomes self-reinforcing. The merchant may eventually “prove” that A is better because the routing logic consistently gives it the traffic most likely to succeed.

That is not causal evidence. It is a feedback loop. Cohort normalization reduces bias; it does not always establish causality Suppose A still outperforms B after careful normalization. That is stronger evidence. But differences can remain: * hidden issuer mix; * provider-specific fraud controls; * network-token coverage; * transaction metadata; * credential history; * routing history; * provider optimizations; * or unobserved customer characteristics. Where the business decision is important and both providers are legitimate routes, a controlled traffic experiment may provide stronger evidence. Adyen's current optimization product explicitly supports experimentation in its own environment, underscoring the general value of testing changes rather than relying only on historical averages. A controlled PSP performance test Where operationally appropriate: 1. Define the eligible population Only include transactions both providers can safely and contractually process. 2. Hold material policy constant Where possible keep comparable: * market; * payment method; * authentication; * merchant risk treatment; * credential type; * currency; * transaction-value distribution; and * time window. 3. Allocate traffic without using the outcome you are trying to test Within the eligible cohort, use a controlled allocation method appropriate to the merchant. 4. Version the experiment Record: * experiment ID; * routing-policy version; * eligibility rule; * allocation; * start/end time; * provider configuration; and * exclusions.

5. Monitor guardrails Do not optimize authorization while ignoring: * fraud; * cost; * latency; * technical failures; * customer completion; or * provider degradation. 6. Wait for lagging outcomes where relevant Do not declare a provider winner on risk or settlement before those outcomes can be observed reliably. 7. Preserve the raw transaction-level data The merchant should be able to reconstruct why each attempt went to each provider. What if you cannot randomize? Not every merchant can—or should—randomly route every eligible transaction. Alternatives include: * strict matched-cohort comparisons; * common-weight standardization; * time-based controlled tests; * carefully designed switchback experiments; * model-based adjustment; * or restricting conclusions to descriptive evidence. The key is to label the evidence correctly. Do not write: “PSP A improves approval by X.” when the evidence only shows: “PSP A's normalized historical cohort had a higher observed approval rate during this period.” Those are different claims. Sample size matters A provider can appear dramatically better in a small cohort because a few transactions changed outcome. The scorecard should always show: * attempt count; * completed-payment count where relevant; * transaction value; * observation period; and * statistical uncertainty where the merchant uses it. Do not promote tiny cohort movements into routing policy simply because a dashboard paints them green.

Likewise, avoid combining several years of data merely to increase sample size if provider configuration, issuer behavior, merchant risk rules, or product integrations changed materially during that period. More data is useful only when it remains comparable. Use the same period—or account for time PSP performance changes. So can: * issuer behavior; * authentication; * payment method mix; * fraud; * routing; * provider optimization; * merchant integration; * customer mix; * seasonality; and * incidents. Compare providers during the same period where possible. If a provider was integrated six months later, do not treat a historical year-over-year comparison as though time were controlled. Track material configuration changes on the performance timeline. Track provider configuration versions A PSP is not a static black box. Merchant-side or provider-side configuration can change: * fraud settings; * tokenization; * authentication; * acquiring route; * payment metadata; * account structure; * retries; * or other processing configuration. A meaningful scorecard should therefore be able to answer: Which provider configuration produced this result? At minimum record major changes and dates. Otherwise an optimization can improve Provider B in June while the annual dashboard continues averaging pre-change and post-change traffic together. Separate provider performance from routing performance This article answers: How did the providers perform on comparable traffic? Routing Between PSPs should answer:

Which eligible provider should receive the next payment? The distinction matters. A normalized provider scorecard can become an input to routing. It is not a routing policy by itself. Routing additionally has to consider: * eligibility; * current provider health; * strategy; * contractual constraints; * payment-method capability; * token compatibility; * cost priorities; * risk; * and operational guardrails. Do not let a quarterly scorecard silently become production routing logic. Build the scorecard from merchant-controlled data Provider dashboards are useful for investigating provider-specific detail. The merchant still needs its own cross-provider analytical layer at sufficient scale. The minimum useful record for every attempt can include: * merchant payment-intent ID; * merchant payment-attempt ID; * PSP; * PSP transaction/reference ID; * route/assignment reason; * route or experiment version; * eligible provider set; * market; * payment method; * issuer geography where available; * currency; * value band; * customer segment; * authentication context; * risk-policy identifier; * request time; * provider response time; * canonical outcome; * raw provider outcome; * authorization outcome; * final completion outcome; * settlement reference; * fees/cost fields where available; * and later fraud/dispute outcome where appropriate.

Stripe's analytics supports filtering by multiple payment characteristics and, in relevant configurations, processor views; Adyen's settlement reporting retains both provider and merchant references for transaction-level reconciliation. Those provider capabilities are useful inputs, but the cross-PSP scorecard needs definitions that remain stable when the provider changes. Preserve raw provider data Normalization should not destroy provider-specific detail. Store both: Canonical merchant outcome: authorized and Raw provider state/code: provider-specific value Likewise preserve: * raw error code; * provider reason; * provider timestamps; * PSP reference; * settlement reference; and * original financial records. If the canonical mapping is later found to be wrong, analysts need to be able to reconstruct the original state. The scorecard review process A useful PSP performance review can run in this order. 1. Check eligibility Are the compared providers genuinely candidates for the same traffic? 2. Check the denominator Are approval, completion, and error rates using identical definitions? 3. Check traffic mix Do market, method, issuer geography, currency, value and customer mix differ materially? 4. Normalize Reweight comparable cohorts onto a common traffic distribution. 5. Check routing bias Did existing rules preferentially send easier or harder traffic to one provider? 6. Compare the full performance stack Review: * authorization; * completion; * technical errors; * latency; * availability; * cost;

* mature risk outcomes; * settlement/reconciliation; * operational exceptions. 7. Quantify uncertainty Check sample size, time period and whether the observed gap is stable. 8. Test important uncertain conclusions Use controlled comparison where practical. 9. Interpret by provider role A primary processor, regional specialist and backup do not need identical scorecards. 10. Hand evidence to the next decision Performance evidence can inform: * routing; * commercial discussions; * technical remediation; * provider role changes; * or eventually consolidation. It should not automatically trigger any of them. What a fair scorecard changes Without normalization, the merchant asks: “Which PSP has the highest approval rate?” With a controlled scorecard, the questions become: Among transactions both providers could process, how did their authorization rates differ? Did the difference survive normalization for market, issuer geography, currency, value, customer mix, authentication, and risk? Did authorization gains become completed payments? What technical-error and latency trade-offs accompanied them? Did a lower-cost provider remain cheaper per completed payment? Were higher approvals accompanied by materially different fraud outcomes? Could Finance reconcile settlement reliably? Did the observed difference persist in a controlled test? Those questions are harder. They are also much closer to the decision the merchant actually needs to make.

The best-performing PSP is not necessarily the provider with the highest number at the top of its dashboard. It is the provider that performs best for the merchant's relevant eligible traffic, under comparable conditions, against clearly defined objectives. Normalize the traffic first. Define the metric second. Compare the provider third. Only then decide what the result should change. This article provides general information and does not constitute legal, regulatory, security, compliance, accounting, statistical, or financial advice. Provider capabilities, reporting definitions, contractual terms, payment-network behavior, and technical implementations vary. Merchants should validate metric definitions and provider behavior using their own transaction data, current provider documentation, applicable contracts, and qualified specialists. 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 ARTICLE END

Comparing PSP Performance: How to Build a Fair Multi-Provider Scorecard A. Brief interpretation — editorial, not part of the article Merchant operating problem: The merchant has several PSPs but compares their headline averages even though each provider receives materially different traffic. PSP/provider role: Competing or complementary processors/acquirers whose observed performance needs to be evaluated on traffic they could realistically have processed under equivalent conditions. Merchant-owned capability: A common performance taxonomy, cohort definition, transaction/attempt identity, normalized dataset, and provider scorecard. Provider-specific capability: Authorization execution, payment processing, fraud controls where applicable, API performance, reporting, settlement behavior, and other provider-specific processing capabilities. Payment state/workflow at risk: The path from eligible payment attempt → authentication/risk checks → authorization → completion/capture → settlement/reconciliation. Operational failure mode: Routing bias and denominator inconsistency make one provider appear stronger or weaker because of the traffic it receives rather than because of what it does with equivalent traffic. Unique evidence anchor: A PSP receiving easy domestic traffic can report a higher overall approval rate than a PSP receiving difficult cross-border traffic even when the second PSP performs better in every comparable traffic cohort.

Editorial position: Compare PSPs only on transactions they were realistically eligible to process under equivalent conditions. Common assumption challenged: “The PSP with the highest overall approval rate is our best-performing provider.” Merchant decision: Which provider performs better for each genuinely comparable transaction cohort, and which evidence is strong enough to inform provider roles or future routing decisions? Selected format: Controlled provider scorecard. Structural rationale: Start by fixing the comparison population and metric definitions; only then compare approval, completion, technical reliability, latency, availability, cost, risk, settlement, and operational exceptions. Proposed measurement architecture Merchant payment/attempt data ↓ Provider eligibility model ↓ Comparable cohort builder ↓ Canonical metric definitions ↓ Provider-attributed observations ↓ Normalization / common weighting ↓ PSP Performance Scorecard ↓ Experiment or operational review where causality remains uncertain The article deliberately stops before prescribing routing policy. Routing Between PSPs owns the question of which provider should receive the next transaction.

ARTICLE C. ORIGINAL ARTICLE ASSET — not part of article PSP Performance Scorecard 1. Comparison Eligibility Gate A PSP enters a head-to-head performance comparison only when: Market eligible? ↓ Method eligible? ↓ Currency eligible? ↓ Merchant/acquiring route eligible? ↓ Credential/token compatible? ↓ Transaction type supported? ↓ Authentication/risk conditions comparable? ↓ Yes → comparison population If no, classify the difference as coverage/eligibility, not bad performance.

2. Normalization dimensions For each comparison, record: Dimension Value / rule Market

Payment method

Issuer geography

Currency

Transaction-value band

Customer segment

Authentication context

Risk-policy version

Credential type

Time period

Provider configuration version

Routing/experiment version

Eligibility rule

3. Controlled scorecard Performance dimension Merchant metric PSP A PSP B Normalized? Sample/notes Approval Authorized / comparable authorization attempts

Completion Merchant-defined completed payments / comparable denominator

Technical reliability Technical errors / eligible technical attempts

Latency p50 / p95 / p99 or appropriate resolution time

Availability Successful technical path responses / eligible requests

Cost Defined cost / completed payment

Fraud/risk Mature merchant-defined risk metric

Settlement Match/exception/reliability metric

Operations Incident/exception burden

Mandatory context beside the scorecard Provider role: Eligible traffic coverage: Actual traffic share: Reference cohort mix: Normalization method: Measurement period: Experiment or observational: Known bias: Metric dictionary version: Data completeness issues:

4. Normalized provider performance For cohort c and provider p: Metric(p,c) = provider result within comparable cohort c Then: Normalized metric(p) = Σ w(c) × Metric(p,c) where w(c) is a common reference weight applied to every provider included in that comparison. Do not use different traffic weights for PSP A and PSP B and call the result normalized.

5. Evidence strength label Give every material comparison one of these labels: Descriptive Raw observed provider data. Cohort-adjusted Observed data after defined normalization. Controlled observational Strong matching/control but no randomized assignment. Experimental Controlled traffic allocation within an eligible population. This label prevents a historical correlation from being communicated as a causal uplift.

D. SEO PACKAGE — not part of article SEO title: Comparing PSP Performance: Build a Fair Provider Scorecard H1: Comparing PSP Performance: How to Build a Fair Multi-Provider Scorecard Meta description: Learn how to compare PSP performance fairly using eligible cohorts, normalized approval and completion rates, latency, cost, risk, and settlement metrics. URL slug: /comparing-psp-performance Primary keyword: comparing PSP performance Secondary keywords: * compare PSP performance * payment provider performance comparison * PSP approval rate comparison * payment processor performance * PSP scorecard * payment provider KPI comparison * PSP latency comparison Related entities/concepts: * Payment service provider * Acquirer * Issuer * Authorization * Payment completion * Payment attempt * Approval rate * Acceptance rate * Technical error rate * Latency * Availability * Settlement * Reconciliation * Chargeback * Routing * Cohort normalization * Selection bias * Controlled experiment Article excerpt: The PSP with the highest overall approval rate is not necessarily the merchant's best-performing provider. Fair comparison requires merchants to first identify traffic each PSP could genuinely have processed, normalize differences in transaction mix, and standardize metric definitions before comparing authorization, completion, reliability, latency, cost, risk, and settlement outcomes. Suggested structured data: Article

Use Person only for a genuine named author/reviewer. No FAQ schema is recommended because the scorecard is the article's stronger original asset. Supporting visual: PSP Performance Scorecard Image alt text: “PSP performance scorecard showing eligible cohort normalization across market, payment method, issuer geography, currency, transaction value, authentication and risk before comparing approval, completion, errors, latency, cost and settlement.”

E. INTERNAL-LINK PLAN — not part of article Priority internal links 1. Routing Between PSPs Recommended anchor: routing between PSPs Purpose: Move from evidence about historical/provider performance into the separate decision of selecting the next eligible route. 2. Pricing Optimization Recommended anchor: payment routing and pricing optimization Purpose: Own detailed cost-based route economics and least-cost routing rather than expanding this article into a pricing strategy. 3. True Cost & Net Revenue Recommended anchor: true PSP cost and net revenue Purpose: Own complete provider economics beyond the bounded cost-per-completed-payment measure used here. Useful adjacent cluster links Multi-PSP Reporting Anchor: standardized multi-PSP reporting Use where the article explains building merchant-controlled cross-provider analytics. Standardizing PSP Integrations Anchor: standardizing PSP states and error categories Use where provider-native metric/state definitions must be normalized. How to Manage Multiple Payment Providers Anchor: multi-provider performance review process Use where scorecard ownership and governance are discussed. Do not turn the article into a broad link directory.

F. CURRENT AUTHORITATIVE SOURCE PLAN — not part of article Stripe — Acceptance analytics Current Stripe documentation is particularly useful because it: * separates payment success from network authorization; * defines different denominators; * distinguishes raw from deduplicated rates; * supports breakdowns by payment characteristics such as country, currency and method; * and demonstrates how retries materially alter rate interpretation. Use: Metric-definition and denominator discipline. Do not generalize: Stripe's definitions into a universal industry definition. Checkout.com — Authorization analytics Checkout.com's current authorization analytics defines its authorization-success metric and explicitly warns that differences in PSP calculation methodology complicate direct benchmarking. Use: Strong primary-source support for the article's argument that cross-provider KPI definitions must be normalized before comparison. Checkout.com — Acceptance versus capture Current Checkout.com support documentation separately explains acceptance and capture concepts. Use: Support the distinction between authorization/acceptance and downstream payment completion. Adyen — Uplift / performance analytics Adyen's current Uplift tooling treats payment conversion, risk, cost, experiments, completion, validation errors, and transaction-completion timing as distinct analytical concerns. Use: Support the argument that provider performance is multi-dimensional and that controlled experimentation can be useful.

Scope: Product-specific example, not an industry-standard metric system. Adyen — Settlement Details report Adyen's current settlement reporting supports transaction-level reconciliation and contains both PSP and merchant references, settlement information, and transaction-cost fields. Use: Support settlement/reconciliation and cost-measurement sections.

G. MEASUREMENT PLAN — not part of article Core required metrics Authorization approval rate Numerator: successful authorizations under the merchant definition Denominator: comparable authorization attempts Completed-payment rate Numerator: merchant-defined completed payments Denominator: explicitly identified attempt- or intent-level population Technical-error rate Numerator: provider-attributable technical failures Denominator: eligible provider attempts/requests Latency Track by operation and cohort: * p50 * p95 * p99 where statistically useful Cost per completed payment Numerator: consistently defined provider-attributable cost Denominator: completed payments Availability/degradation Track: * affected eligible requests; * degraded minutes; * traffic impact; * incident count. Reconciliation exceptions Numerator: records requiring exception treatment Denominator: relevant provider settlement records Mature risk outcome Define: * metric; * cohort; * maturity window; * denominator. No industry benchmark is proposed.

H. FACT-CHECK AND TECHNICAL REVIEW PLAN — not part of article Integration fact checks Confirm for each provider included in a real merchant comparison: * exact transaction/attempt identifier available; * authorization outcome semantics; * technical-error taxonomy; * timeout semantics; * request/response timestamps; * whether retries share or create distinct provider objects; * whether processor/acquirer route is observable; * whether merchant-defined metadata can link provider data to internal attempts. Provider-state fact checks Verify current: * authorization state; * pending/unknown state; * capture/completion semantics; * cancellation/void behavior; * refund state; * asynchronous event behavior. Do not infer semantic equivalence from similar status names. Routing fact checks Because routing bias is central to this article, verify that merchant data records: * set of eligible providers; * selected provider; * routing reason; * policy/version; * experiment assignment where applicable; * fallback/retry attribution. Without this, historical cohort normalization has an important blind spot. Idempotency / duplicate fact checks This article does not own duplicate prevention, but performance measurement should confirm: * whether repeated attempts are counted separately; * whether deduplication occurs; * how payment intent differs from payment attempt; * whether late success changes historical outcomes. Do not silently deduplicate provider traffic using inconsistent rules. Token / portability fact checks

Not central to the scorecard. Where token availability determines provider eligibility, verify: * which provider can use the credential; * whether the credential type differs; * whether recurring versus customer-present traffic differs. Treat token compatibility as an eligibility dimension, not provider performance. Failover fact checks Not central to the article. If failover traffic is included, tag it separately because: * it can represent degraded conditions; * the provider receiving fallback traffic may receive disproportionately difficult transactions; * the first provider's unresolved attempt can affect intent-level completion attribution. Do not mix routine first-route traffic and emergency failover traffic without marking them. Reporting/reconciliation fact checks Verify: * merchant reference persistence; * PSP reference; * settlement reference; * fee fields; * report timing; * refunds; * disputes; * adjustments; * payout linkage; * currency normalization. The merchant should be able to trace a scorecard payment back to provider and settlement records. Provider-performance fact checks Before publication or operational use, confirm: * metric definitions; * denominators; * filters; * raw versus deduplicated handling; * attribution rules; * observation window; * cohort eligibility; * provider/account configuration; * current provider documentation. Provider dashboards and analytics products change.

I. AMBER-FLAG CLAIMS — not part of article Treat the following claims with special caution if added later: “PSP A has better authorization.” Requires common cohort, denominator and observation period. “PSP A is X% better than PSP B.” Requires precise metric, comparable population and methodology; causal wording requires stronger evidence. “This route improves conversion.” Requires controlled evidence or appropriately qualified observational analysis. “Provider A is faster.” Requires the same operation, method, geography, authentication context and latency definition. “Provider B has better uptime.” Requires merchant-observed path-level availability using a consistent SLO/measurement model. “Provider C is cheaper.” Requires consistent fee components, ticket/value mix and completion denominator. “Provider A produces less fraud.” Requires mature, comparable cohorts and aligned/controlled risk settings. “Provider B settles more reliably.” Requires an explicit settlement/reconciliation metric. Avoid externally published provider rankings unless the evidence, period, traffic mix and methodology can be disclosed and defended.

J. SECURITY / COMPLIANCE FLAGS — not part of article Provider-performance analytics may contain: * payment identifiers; * customer information; * issuer/BIN information; * fraud outcomes; * transaction metadata; * commercial pricing; * provider performance data; * contractual SLA information. Apply appropriate: * access control; * privacy/data-minimization review; * retention rules; * contractual restrictions on provider data; * security classification; * and aggregation rules for external publication.

* compares multiple PSPs automatically; * normalizes PSP performance; * routes based on authorization performance; * exposes processor-level scorecards; * conducts controlled traffic experiments; * provides multi-PSP reporting; * calculates cost per completed payment; * monitors third-party PSP latency or availability; * consolidates settlement records; * supports specified external PSP integrations; * provides particular routing or orchestration functions; * improves approval rates by a stated amount.

L. HUMAN REVIEW RECOMMENDATION — not part of article Recommended author profile: Advanced payments/data writer with experience in multi-provider analytics, authorization funnels and payment operations. Primary methodological reviewer: Payments data scientist or senior payments analyst. Payments reviewer: Head of Payments responsible for provider strategy and routing. Finance/operations reviewer: Finance, reconciliation or payment-operations lead to validate settlement and operational metrics. Optional statistical reviewer: Useful if the final publication introduces confidence intervals, causal-uplift claims, regression adjustment or experimental results. First-hand contribution worth adding: A real, attributable example in which raw PSP rankings changed materially after transaction mix was normalized. Do not invent the example, result, reviewer, or quotation.

M. CLUSTER SAMENESS-AUDIT RECORD — not part of article Title: Comparing PSP Performance: How to Build a Fair Multi-Provider Scorecard Opening device: A mathematically valid leaderboard that produces an invalid operational conclusion. Provider role: Multiple eligible PSPs being compared as processing routes. Operational problem: Selection/routing bias and inconsistent denominators. Merchant-owned capability: Cohort-normalized performance measurement. Provider-specific capability: Provider execution across authorization, completion, technical performance, risk, and settlement. Payment-state issue: Authorization versus full payment completion. Primary format: Controlled provider scorecard. Unique evidence anchor: Easy domestic traffic versus difficult cross-border traffic. Editorial position: Compare only equivalent eligible transactions under comparable conditions. Merchant decision: Determine where provider-performance differences remain after normalization and whether evidence is strong enough to change the provider's role. Original framework: PSP Performance Scorecard + Comparison Eligibility Gate + Evidence Strength label. Primary metrics: Normalized approval/completion plus technical reliability, latency, cost, risk, settlement and operational exceptions. Conclusion: Normalize traffic first, define metrics second, compare PSPs third, then decide what the evidence should change.

CTA style: Route to the dedicated routing and provider-economics articles rather than making an orchestration sales pitch. FAQ: None. The practical scorecard replaces a generic FAQ.