PSP Selection Checklist: How to Evaluate Shortlisted Providers Before You Sign

The PSP evaluation process most operators run has a sequencing problem: they compare named providers before identifying the right provider class, and they compare providers on marketing claims rather than demonstrated evidence. The PSP Decision Matrix solves the first problem — it narrows the field to a shortlist of three finalists within the right class. This article solves the second: how to evaluate those finalists rigorously before you sign anything.

This stage is distinct from what came before and what comes after. The Decision Matrix handled class selection — you are no longer asking “which type of PSP do I need?” The PSP Contract Red Flags article covers the contract-clause review that follows. This article covers the evaluation in between: scoring three named finalists on evidence, not assertions, so that when you reach the contract stage you already know who your preferred provider is and why.

One more distinction worth making before diving in: the PSP Selection RFP Kit gives you the full 60+ question bank to send to each finalist and a weighted scorecard with a worked example. This article gives you the criteria and principles to score the answers you receive. The two are complementary — the Kit handles the mechanics of running an RFP; this article handles the judgment of what the answers mean.

From Shortlist to Scorecard: What This Stage Is (and Isn’t)

You arrive here with roughly three named finalists in the right provider class, selected through the Decision Matrix. The evaluation stage has one job: determine which of those three finalists is actually capable of doing what they claim to do for a business with your specific profile.

The failure mode at this stage is treating every provider claim as equivalent to a demonstration. PSPs invest heavily in sales materials that cite headline auth rates, describe migration support teams that do not exist in practice, and reference enterprise SLAs that turn out to be aspirational targets rather than contractual commitments. The evaluation process exists to separate what providers can actually deliver from what they are good at saying.

Evaluation ends when you have a preferred provider and a documented rationale — not when you have received three proposals. The preferred-provider decision should drive the contract negotiation, not follow it.

The Evaluation Dimensions: What to Actually Score

Score each finalist across eight to twelve operational dimensions. The weighting should reflect your specific business profile — subscription businesses weight token portability highest; cross-border merchants weight cost transparency and FX handling; multi-market retailers weight geographic coverage. Here are the core dimensions and what to look for in each.

Settlement timing and reserve posture. Standard settlement for a low-risk merchant is T+2. The evaluation question is not what the standard is — it is whether the PSP will commit to it contractually, and what their reserve posture looks like for a merchant at your risk profile. Ask for the settlement SLA in writing and request sample reserve terms based on your volume and vertical. A PSP that hedges on settlement timing during evaluation is unlikely to improve after signing.

True cost transparency. Ask each finalist for a full cost breakdown — interchange pass-through, acquirer margin, and every ancillary fee including 3DS authentication, chargebacks, refunds, FX conversion, and minimum monthly invoice — applied to a sample of your own transaction profile. Understanding how to read the MDR stack matters here: headline rates are misleading when ancillaries are not itemised. If a provider cannot produce this breakdown clearly, that is a red flag before you reach the contract. Blended-rate quotes that obscure the acquirer margin make meaningful cost comparison impossible — see interchange-plus vs blended pricing for the structural difference.

Auth-rate and performance evidence. This is the dimension most susceptible to marketing noise. Every PSP cites headline authorization rate figures. The operationally relevant question is: what is the auth rate for a cohort that matches your card mix, BIN countries, and transaction profile? Ask for cohort-specific data, not platform averages. Ask how their authorization optimization performs for the specific card types that dominate your volume — consumer debit in the EU, premium credit in the US, commercial cards for B2B. If they cannot produce cohort data, treat the headline figure as non-evidence.

Geographic and local acquiring coverage. Map each finalist’s direct acquiring footprint against the markets that drive your volume. Direct acquiring — where the PSP is also the acquirer — typically produces better auth rates and faster dispute resolution than indirect acquiring through a third-party acquirer. For markets outside the PSP’s direct footprint, ask which third-party acquirers they use and what the auth-rate impact has been for comparable merchants. For operators with significant APAC or EM volume, regional specialists often need to run alongside the primary PSP regardless of which finalist wins.

Integration and migration lift. Two questions matter here. First: how much integration effort is this specific PSP relative to your current stack and the others under evaluation? Get concrete answers — which SDKs and languages they support natively, what webhook and reconciliation formats look like in practice, whether their sandbox reflects production behavior accurately. Second: what does migration from your current provider actually look like? A provider that cannot describe the migration process in specific terms — including token portability, data export format, and dual-run period — is representing a support level that does not exist in practice.

Support model and escalation paths. Determine whether you will have a named technical account manager or be routed through a generic support queue. For enterprise providers, ask who your day-one named contact will be and what their escalation path looks like for production incidents. For self-serve providers, understand the threshold at which you get dedicated support and whether you are above it. Reference calls are essential here — PSP support quality as described in sales materials almost never matches reported experience from merchants who are two years into the relationship.

Redundancy and routing flexibility. Understand each finalist’s infrastructure architecture: how many processing endpoints do they operate, in which regions, and how do they handle failover? For operators considering a multi-PSP or orchestration setup, ask how each PSP’s APIs are designed for routing — specifically whether transaction routing decisions can be made at the merchant layer without requiring re-integration. For the economics of multi-acquirer routing, see multi-acquirer routing.

Compliance, data portability, and token ownership. This dimension’s importance scales with your switching cost exposure. Ask explicitly: are stored cards held as network tokens (Visa Token Service, Mastercard MDES) or as PSP-proprietary tokens? Network tokens are portable; PSP tokens are not. If the answer is proprietary tokens, the migration cost of a future switch is a re-authorization campaign with 10–25% subscriber churn — that cost should be factored into the evaluation now, not discovered at exit. The full cost structure of PSP vendor lock-in applies directly to this dimension.

Roadmap and financial stability. For providers under evaluation at enterprise scale, verify that the PSP’s strategic roadmap is consistent with your needs over a 2–3 year contract horizon. This is not about predicting the future — it is about identifying obvious misalignments: if you need deeper APAC coverage and the provider’s roadmap is focused entirely on North American SMB features, that is a visible signal. Financial stability matters for enterprise providers: a PSP that is loss-making at scale or carrying significant funding pressure is a counterparty risk for a multi-year contract.

Proof-of-Claim Tests: Make Providers Demonstrate, Not Assert

The differentiating step in a rigorous evaluation is converting each dimension from a claim into something verifiable. Here is how to do that for the dimensions that matter most.

Auth rates. Request cohort-specific auth-rate data — not the platform average — for a segment that closely matches your own: your card BIN countries, domestic vs cross-border split, consumer vs commercial card ratio, and CNP-only or mixed-channel profile. If the PSP cannot produce this, ask for anonymised data from merchants in your vertical with similar volume. A provider with a genuine auth-rate advantage relative to your profile will be able to show it; one that cannot produce cohort data is asking you to trust a headline that may not apply to you.

Migration support. Ask each finalist to walk you through the migration process for a merchant at your scale and with your current PSP. Specifically: how does token migration work if your current PSP uses proprietary tokens? What is the dual-run period, and what does the PSP’s team provide during it? Who is the named person responsible for your migration? Vague answers here are accurate answers — they are telling you what the support will actually look like.

Settlement transparency. Request sample settlement files and statements from the PSP’s reconciliation team, in the format you would receive them as a live merchant. This is a two-part test: you are verifying that the format is compatible with your reconciliation stack, and you are verifying that the cost components are itemised clearly enough to audit. A PSP that cannot or will not provide sample statements before signing is unlikely to provide adequate transparency after.

SLA penalties. Ask for the specific financial penalties that apply when the PSP breaches its published uptime or settlement SLAs. Not the SLA target — the penalty. Most PSPs publish aspirational uptime figures; few publish penalty structures with real commercial consequences. The answer to this question is more informative than the uptime figure itself.

Reference calls. Request three reference calls with merchants at comparable volume and in a similar vertical. Do not accept references selected entirely by the PSP — ask whether you can speak to merchants who have been through a migration to their platform from a different PSP, and specifically ask about migration support quality. The gap between how PSPs describe their migration support and how merchants who have used it describe it is consistently the largest disconnect in the evaluation process.

Sandbox integration. Before commercial terms are finalized, run a sandbox integration for the specific payment flows you will use in production: recurring billing, 3DS2 challenge flow, dispute notification webhooks, refund processing, and multi-currency settlement. A sandbox that covers only basic card acceptance and does not reflect the edge cases in your flows is a signal about integration quality in production.

Scoring Finalists Side by Side (Lightweight)

The mechanics of scoring are less important than doing it consistently across all three finalists. Weight each dimension based on the cost of getting it wrong for your business — a subscription business should weight token portability and migration support at 20–25% of total; a one-time transaction merchant can weight those dimensions at 5% or less. Score each finalist on each dimension on a 1–5 scale based on what they demonstrated during evaluation, not what they claimed.

One illustrative weighting for a high-volume cross-border merchant:

This weighting is illustrative. A subscription business would shift the token ownership and migration lift weights to 20–25% combined, reducing the cost transparency weight only if pricing differences between finalists are small. The PSP Selection RFP Kit contains the full weighted scorecard with a worked example — use this article’s criteria to judge the answers, and use the Kit’s scorecard template to record and total them.

Disqualifiers: What Should Drop a Finalist Before Contract Stage

Disqualifiers are evaluation-stage red lines that end the evaluation for a specific provider before you reach the contract. These are capability and proof failures — not contract clauses.

A provider should be disqualified if they cannot produce cohort-specific auth-rate evidence for your card mix and geographies. A platform average is not evidence for your business — if the PSP cannot or will not produce cohort data, you are evaluating a marketing claim, not a performance record.

Disqualify any finalist who cannot produce a full, itemised cost breakdown inclusive of all ancillary fees. Opaque pricing during evaluation — “we’ll get you the full breakdown in the contract” — is a reliable predictor of opaque billing in the relationship.

No documented migration support means the migration support does not exist in any operationally meaningful sense. A provider that cannot describe, in specific terms, how they will help you migrate from your current PSP — including token portability mechanics and a named responsible contact — is describing an experience that will not match reality.

Inability to name a technical contact who will own your account is a self-report on support model. A provider that cannot tell you who your day-one technical contact will be before signing cannot give you what enterprise accounts require.

A sandbox environment that does not reflect the integration you will actually use — that omits 3DS2 challenge flows, webhook structures for disputes, or multi-currency settlement — is telling you something accurate about the depth of their production implementation.

These disqualifiers apply to evaluation stage. If a finalist passes all of them and proceeds to contract review, apply the PSP Contract Red Flags checklist to the contract clauses: rolling reserve mechanics, pricing escalation caps, token vault ownership language, data export rights, and termination notice provisions are all negotiable and all worth reviewing before signing.

Handoff to Contract and Negotiation

When evaluation produces a preferred provider, carry three outputs into the contract and negotiation stage.

First: the scorecard documenting why the preferred provider won and where the other finalists ranked. This scorecard is your negotiating leverage — a documented preferred-provider decision based on evidence, combined with two viable alternatives, is the strongest commercial position you can bring to a contract discussion.

Second: the specific claims the preferred provider made during evaluation that are not yet captured in contract language — auth-rate commitments, migration support, named account contacts, settlement SLA. Each of these needs a contractual backstop. The PSP Contract Red Flags checklist covers the clauses to review; the PSP Negotiation Playbook covers how to use your leverage to improve them.

Third: the disqualifier evidence. If any finalist was dropped because they could not evidence auth rates or produce sample statements, document that. It sharpens your position with the preferred provider (“we chose you because you could demonstrate X; we need that reflected in the contract”) and keeps the evaluation process honest if the preferred provider’s contract terms fall short.

For the full structured question bank to send to each finalist, the weighted scorecard with a worked example, and the negotiation leverage framework, the PSP Selection RFP Kit has the complete operator toolkit — 60+ RFP questions organised across eight categories, ready to send.