How to Choose a Payment Platform: The Evaluation Checklist for Platform Operators

Choosing a payment platform is one of the highest-stakes infrastructure decisions a platform operator will make. Not because payments are complicated — though they are — but because the decision is effectively irreversible for three to five years. Your merchants onboard, tokenise their card data, and build workflows around whatever you deploy. Switching means re-integration work, re-tokenisation (which requires active merchant cooperation), potential downtime, and the political cost of explaining to customers why their payment setup is changing.

Get it right and payments becomes a competitive moat — a revenue line, a retention driver, a capability that larger competitors can't easily replicate. Get it wrong and you spend the next two years managing technical debt, fielding merchant complaints, and watching your engineering team fight fires instead of shipping product.

This guide is a working evaluation framework. Use it in vendor RFPs, in internal scoring sessions, and as a checklist when a vendor's sales deck is designed to obscure the things you most need to know.

Why This Decision Matters More Than Most Infrastructure Choices

Most infrastructure decisions are reversible. You can swap your database, re-platform your CMS, or change your cloud provider with effort and cost but without fundamental business disruption. Payments is different for three reasons.

Tokenisation lock-in. Card data is stored as tokens held by your payment provider. Moving tokens between providers requires a formal token migration — a process that takes months, requires cooperation from both the old and new provider, and carries real risk of declined transactions during the transition. Many platforms discover this only after they've decided to switch.

Merchant migration. If you have hundreds or thousands of merchants connected to your platform, every one of them needs to reconnect their bank account, re-verify their identity, and potentially update their integration when you switch providers. Attrition during migration is material.

Compliance re-certification. Your PCI scope, your compliance documentation, and your security audit findings are all tied to the specific provider you use. Switching means starting those processes again.

The platforms that navigate this well are the ones that spend 60 to 90 days on vendor evaluation — before writing a single line of integration code. That time investment at the front is worth 12 to 18 months of avoidable engineering work later.

The 12 Criteria That Matter

1. PSP Flexibility

What you need to know: Are you locked into a single processor, or can different merchants use different payment gateways?

This matters immediately for enterprise sales. Large customers — hotel chains, insurance carriers, established retailers — often have existing PSP relationships with negotiated rates they've spent years optimising. If your platform mandates a single processor, you lose those deals or spend months building one-off integrations. Multi-PSP architecture solves this at the infrastructure level.

Questions to ask:

• "Can a merchant bring their own PSP and still use our platform?"

• "What happens when an enterprise customer mandates Worldpay or Adyen?"

• "Can we add a new PSP without re-integrating our core platform?"

• "Is PSP routing logic something we control, or something your platform controls?"

Red flag: Any answer that starts with "we have a preferred PSP relationship" without explaining the opt-out path.

2. White-Label Depth

What you need to know: How completely does your platform brand replace the provider's brand in the merchant experience?

True white-labelling means your merchants never encounter the payment provider's brand — not in the checkout flow, not in the merchant dashboard, not in onboarding emails, not in support interactions. Partial white-labelling (branded checkout but provider-branded merchant portal, for example) creates confusion and undermines the perception that payments is your platform's capability.

Questions to ask:

• "Will my merchants ever see your brand name or logo anywhere in their experience?"

• "Is the merchant dashboard served from our domain?"

• "Are onboarding and KYC emails sent from our brand?"

• "What does a support ticket look like from a merchant's perspective?"

Red flag: "We can co-brand the portal" — this is not white-labelling.

3. Merchant Onboarding

What you need to know: How long does it take a new merchant to go from signup to processing live transactions, and how much of that is your problem to build?

KYC/KYB (Know Your Customer / Know Your Business) is the regulatory requirement that identifies and verifies merchants before they can process payments. Some platforms give you pre-built onboarding flows. Others give you an API and leave you to build the UX, the document collection, and the status management yourself. The difference is three months of engineering work.

Questions to ask:

• "What does the merchant onboarding flow look like out of the box?"

• "Who handles KYC/KYB verification — your team, a third party, or us?"

• "What's the typical time from merchant application to first live transaction?"

• "What happens when a merchant is flagged during KYC — who handles remediation?"

Red flag: "Our API makes it easy to build your own onboarding" — this is not a pre-built solution.

4. Channel Coverage

What you need to know: Does the payment integration support every channel you might need, including channels you haven't built yet?

Most platforms start with online checkout. But the most interesting growth vectors right now are voice channels (IVR, AI agents), payment links for invoice-based workflows, and chat-embedded payments. If your payment provider only supports card-present and card-not-present via web checkout, you're re-integrating when you add a voice product or a payment link feature.

Questions to ask:

• "If we add a voice channel or AI agent in 18 months, does our payment integration support that?"

• "Do you support payment links — standalone hosted checkout pages?"

• "Can payments be initiated from a chat interface or messaging platform?"

• "What channels have your existing platform customers added over time?"

Red flag: "We're focused on online payments for now" — this is a roadmap commitment you're making on behalf of your platform.

5. Compliance and Certifications

What you need to know: What is your PCI scope with this provider, and who is responsible for maintaining it?

PCI DSS Level 1 is the highest certification level — required for providers processing over six million card transactions annually. ISO 27001 and SOC 2 Type II are the information security certifications that enterprise buyers and their procurement teams will ask for. The key question for your platform is not just whether the provider is certified, but what that certification means for your own compliance obligations.

Questions to ask:

• "What PCI DSS level are you certified at, and can you provide your current AOC (Attestation of Compliance)?"

• "What is our PCI scope as a platform operator using your solution?"

• "Are you ISO 27001 certified? SOC 2 Type II?"

• "What documentation do you provide to help us pass enterprise security reviews?"

Red flag: Vague answers about "shared responsibility" without specifics on where your scope ends.

6. Revenue Model

What you need to know: How does your payment integration generate revenue for your platform, and what are the unit economics per transaction?

Embedded payments should not just be a feature — it should be a revenue line. The mechanisms are: a share of interchange or processing margin on every transaction, platform fees charged to merchants for payment access, or a combination. Understanding this upfront determines whether payments becomes a profit centre or a cost centre.

Questions to ask:

• "What is our revenue share per transaction, and how does it scale with volume?"

• "Can we set our own pricing to merchants, or are rates fixed?"

• "How is revenue share reported and settled to us?"

• "What's the realistic annual payment revenue for a platform at our scale?"

Red flag: A provider that can't give you a clear per-transaction economics model isn't ready for platform customers.

7. Enterprise Readiness

What you need to know: Does the platform scale to enterprise customers with complex requirements — their own PSPs, negotiated rates, multiple entities, multiple currencies?

Winning a mid-market platform customer is good. Winning enterprise is transformative. But enterprise customers have requirements that break most embedded payment solutions: PSP mandates, complex settlement structures, multi-currency operations, multi-entity corporate hierarchies. Your payment infrastructure needs to support these without custom engineering.

Questions to ask:

• "What's the largest or most complex customer currently using your platform product?"

• "What happens when we land a customer with 10,000 sub-merchants or multiple legal entities?"

• "Can merchants operate in multiple currencies and settlement accounts?"

• "How do you handle a customer who needs their own dedicated payment infrastructure?"

Red flag: Reference customers that are all small or mid-market only.

8. Integration Complexity

What you need to know: What does integration actually require, and what is the realistic path from zero to production?

Every payment provider will tell you their API is well-documented and easy to integrate. The real questions are: what are the pre-built components (hosted payment pages, UI kits, SDKs) that reduce engineering work, and what does production-ready look like versus a basic proof of concept?

Questions to ask:

• "What pre-built UI components do you offer?"

• "What's the realistic time from contract to first live merchant transaction?"

• "What does your implementation support look like — a dedicated solutions engineer, or documentation only?"

• "Can you share integration timelines from comparable platform customers?"

Red flag: An implementation timeline quoted in weeks when comparable platforms measure theirs in months — this suggests the salesperson hasn't been realistic with you.

9. Reporting and Reconciliation

What you need to know: Can your merchants self-serve on transaction data, and can your platform team reconcile payments at scale?

Merchant support tickets about transactions are one of the highest-cost support categories for platforms. If your payment provider gives merchants access to clear, real-time transaction data and self-serve dispute management, those tickets don't reach your team. Equally, your finance team needs platform-level reporting and settlement data in a format they can actually use.

Questions to ask:

• "What does the merchant-facing transaction dashboard look like?"

• "Can merchants download transaction exports or access data via API?"

• "How is settlement data provided to our platform — CSV, API, or both?"

• "How are chargebacks and disputes managed in the merchant portal?"

Red flag: "Reporting is on our roadmap" — this will cost you in support overhead.

10. Geographic Coverage

What you need to know: Which countries can your merchants process in, and what does cross-border expansion look like?

Many embedded payment solutions are strong in their home market and brittle elsewhere. If your platform operates or plans to operate internationally, you need to understand local acquiring, local payment methods, currency support, and the regulatory requirements the provider manages on your behalf.

Questions to ask:

• "Which countries do you currently support for merchant processing?"

• "Do you offer local acquiring, or only cross-border processing?"

• "What local payment methods (SEPA, iDEAL, BACS, etc.) are supported in key markets?"

• "What's the process for launching in a new country — what do we need to do versus what do you handle?"

Red flag: Strong presence in one geography with vague commitments about international expansion.

11. Scalability and Reliability

What you need to know: What is the provider's actual uptime track record, and what happens to your platform during payment infrastructure incidents?

Payments downtime is not like application downtime. When payment processing fails, merchants lose revenue in real time — and they hold your platform responsible. Uptime SLAs in contracts matter less than the actual reliability track record and the incident response process.

Questions to ask:

• "What has your uptime been over the last 12 months? Can you share a status page or incident history?"

• "What is your SLA for payment processing availability, and what are the remedies for breaches?"

• "How are incidents communicated to platform operators and their merchants?"

• "What is your peak transaction throughput, and what happens to performance during high-volume events?"

Red flag: No public status page or incident history to review.

12. Vendor Stability

What you need to know: Who owns the business, what is their financial position, and what happens to your integration if the company is acquired or runs out of capital?

Payment infrastructure companies are acquisition targets. A provider that is venture-backed, growing fast, and operating in a consolidating market may look like a great partner today and a strategic asset of a direct competitor in 18 months. Understand the ownership structure, the funding runway, and the contractual protections you have if ownership changes.

Questions to ask:

• "Who are your investors, and what is your current funding position?"

• "Have there been any recent ownership changes or acquisition discussions?"

• "What change-of-control protections exist in the contract?"

• "What is your plan for long-term independent operation?"

Red flag: Evasiveness about ownership or funding — particularly from a company that has raised significant venture capital in a market with active M&A.

The Four Models Compared

There are four fundamental approaches to embedded payments for platform operators. Understanding the tradeoffs before you start vendor conversations will sharpen every question you ask.

Becoming a PayFac (registering directly with card networks and managing your own risk and compliance) gives you the most control and the best economics, but it requires substantial capital, legal infrastructure, and ongoing compliance investment. It's the right choice for platforms processing over $1bn annually with a dedicated payments team. For most platforms, it's a distraction.

PayFac-as-a-Service providers like Payrix (now Worldpay for Platforms) and Finix give you the PayFac economic model without building it yourself — but they typically lock you into their processing network. Enterprise customers with existing PSP relationships become harder to serve.

PSP Platform Products like Stripe Connect and Adyen for Platforms offer deep functionality within their ecosystem, with excellent developer experience and global reach. The tradeoff is single-PSP lock-in — all your merchants process through Stripe or Adyen, which becomes a commercial and strategic constraint as you grow into enterprise.

PSP-Neutral Payment Layers like Shuttle sit above the PSP layer, connecting to 40+ processors and routing transactions based on merchant preference, cost, or geography. This model gives platforms the white-label experience of a PayFac, the pre-built infrastructure of a platform product, and the PSP flexibility that enterprise customers require — without the compliance burden of registering as a PayFac.

The right model depends on your scale, your merchant base, and your enterprise ambitions. Most platforms that are serious about enterprise deals will eventually require PSP flexibility — the question is whether to build that flexibility in from the start.

Red Flags in Vendor Conversations

After seeing dozens of platform payment evaluations, these are the warning signs that a vendor isn't a fit:

"You can always add more PSPs later." The architecture either supports multi-PSP at the core or it doesn't. Adding PSP support as a later integration almost always means custom engineering work scoped to you. Ask to see a reference customer who has actually done it.

"Our checkout converts better." Compared to what baseline, over what time period, in what vertical? Conversion claims without methodology are marketing. Ask for the A/B test methodology and the confidence interval.

Vague pricing in the first three conversations. Revenue share models and processing economics vary significantly. A vendor who won't give you indicative numbers until late in the sales cycle is either building in negotiating leverage or doesn't have a standard commercial model — both are problems.

No reference customers in your vertical. A payments provider who has never worked with a platform in your industry will learn on your dime. Ask specifically for two or three reference calls with similar platform operators, and take them.

"We'll handle implementation together." This sounds collaborative; it sometimes means the implementation timeline is undefined. Ask for a project plan with milestones, timelines, and named resources — before you sign.

Change-of-control clauses that don't protect you. If the contract doesn't give you a clean exit right if the vendor is acquired, you have no protection if they're bought by a competitor or wound down. This is non-negotiable.

The RFP Template

Copy these into your vendor evaluation scorecard and rate each provider on a 1-5 scale.

PSP Flexibility

• Can merchants bring their own PSP?

• Can we add new PSPs without re-integrating?

• Is PSP routing logic configurable by us?

White-Label

• Is every merchant touchpoint under our brand?

• Is the merchant dashboard served from our domain?

Merchant Onboarding

• Is KYC/KYB fully managed by the provider?

• What is the average time from application to first live transaction?

Channel Coverage

• Does the platform support voice-initiated payments?

• Does the platform support payment links?

• Does the platform support chat and AI agent integrations?

Compliance

• What PCI DSS level is the provider certified at?

• What is our PCI scope as an operator?

• Are ISO 27001 and SOC 2 Type II in place?

Revenue Model

• What is the per-transaction revenue share?

• Can we set our own pricing to merchants?

Enterprise Readiness

• Can enterprise customers use their own negotiated PSP rates?

• Is multi-currency and multi-entity supported natively?

Integration

• What pre-built UI components and SDKs are available?

• What is the realistic time to first live merchant transaction?

Reporting

• Do merchants have real-time self-serve transaction access?

• Is settlement data available via API?

Geography

• Which countries and currencies are supported today?

• Is local acquiring available in our target markets?

Reliability

• What is the 12-month uptime track record?

• Is a public status page available?

Vendor Stability

• Who owns the business?

• What change-of-control protections exist in the contract?

Taking the Next Step

The most expensive payment infrastructure decision is the wrong one made quickly. The second most expensive is the right one made too slowly while a competitor closes enterprise deals you can't support.

If you're at the stage of shortlisting vendors, the evaluation framework above should give you enough to run a structured RFP and score responses consistently. If you're earlier — still deciding which model is right for your platform — start with the foundational questions: do you need PSP flexibility for enterprise, do you need multi-channel coverage, and how important is speed to market?

Related Reading:

• What Is Embedded Payments? — the fundamentals of the embedded payments model

• Embedded Payments Without Becoming a PayFac — the PayFac decision in detail

• PSP-Neutral vs Single-PSP Architecture — the architectural choice and its long-term implications

• How to Get Payments Off Your Product Roadmap — the build vs buy decision for platform teams

• Enterprise PSP Mandates — why PSP flexibility is a precondition for enterprise sales

• How Platforms Monetise Payments — building payments into your revenue model

Shuttle Global is a PSP-neutral payment layer connecting platforms to 40+ payment processors. White-label merchant onboarding, multi-channel support (online, voice, payment links, AI agents), and PCI DSS Level 1, ISO 27001, and SOC 2 Type II certified. Used by platforms that need PSP flexibility from day one.

Book a discovery call to walk through your specific platform requirements, or see how platforms use Shuttle.