RFP Checklist for PSP, Acquirers, and Orchestrators

Choosing a white-label payment gateway vendor is a critical decision for PSPs, acquirers, banks, fintech platforms, payment orchestrators, and high-volume merchants. This guide explains how to evaluate gateway vendors, what capabilities to verify in real demos, and includes a practical RFP checklist covering deployment, PCI scope, 3DS readiness, tokenization, routing, reconciliation, and operational reliability.

TL;DR

A white-label payment gateway is a ready-to-deploy software you can brand and configure to enable payment acquiring for your online merchants. It helps PSPs, banks, fintechs, orchestrators, and high-volume merchants launch faster, control the checkout and payment flow, and scale operations without rebuilding a gateway from scratch.

If you’re choosing a vendor, don’t judge by a pitch deck. Judge by how the product behaves in real-life scenarios: multi-merchant and multi-MID, 3DS edge cases, token portability, reconciliation exports, webhook reliability, and what happens when an acquirer is partially down.

This guide outlines the key capabilities to look for, the most common buying mistakes, and a practical RFP checklist you can use to compare vendors more effectively.

Who this guide is for

You’ll get the most value from this checklist if you are:

1. PSPs that plan to launch a business or replace a legacy stack
2. Acquirers building or replatforming in-house merchant acceptance solutions
3. Fintech seeking more control over payment flows and revenue
4. New payment orchestrator businesses
5. High-volume merchant or marketplace that outgrew “one PSP + plugins”

What white-label payment gateway software should include

A white-label payment gateway is not just a hosted checkout page with your logo on it. Minimum features baseline should look like this:

1. API-first payment processing layer (auth/capture/refund/void, status, disputes if relevant)
2. 3DS flows supported end-to-end, or clean integration with your 3DS Server
3. Tokenization and recurring payment support, including credential-on-file flows
4. Merchant management (true multi-tenant, roles, permissions, approvals)
5. Multi-MID support with configurable merchant/MID hierarchy
6. Routing controls or tight integration with orchestration/routing engine
7. Webhooks, logs, exports, and reporting built for operations and reconciliation
8. High availability plus monitoring signals, not just vague reliability claims

If some of this is missing, you’ll pay later in operational load, reconciliation gaps, limited flexibility, and unplanned custom development.

What to evaluate when selecting a white-label payment gateway vendor

The 12 critical criteria (with questions to ask)

1. Deployment model and ownership (software vs managed service)

Start with the uncomfortable question: who actually owns and controls the system?

Ask:

1. What deployment options do you offer (software, managed service) and what’s included in each?
2. Who controls encryption keys and token vault access?
3. What can we export ourselves (configs, routing rules, merchant settings, logs)?

2. Security model, access control, auditability

Security is not a certificate on a slide. It’s RBAC, isolation, and traceability.

Ask:

1. Show your RBAC model and an audit log of config changes
2. How do you manage secrets and key rotation?
3. How do you enforce tenant isolation in a multi-merchant environment?

3. PCI scope and responsibility boundaries

This is where many projects get stuck late.

Ask:

1. Provide your PCI shared responsibility model
2. What helps keep PCI scope minimal and what makes it expand?
3. What evidence can you share (attestations, controls overview, audit approach)?

4. EMV 3DS readiness (not just “we support 3DS”)

Most vendors say yes. Few handle the messy parts well.

Ask:

1. Which EMV 3DS versions and flows do you support (browser, app, SDK)?
2. What edge cases do you handle (timeouts, retries, step-ups, soft declines)?
3. How do we see 3DS performance (frictionless percentage, challenge percentage, drop-offs)?

5. Tokenization strategy and recurring payments

Token strategy affects approvals, cost, and future portability.

Ask:

1. Where does the token vault live and who owns the keys?
2. How do you support credential-on-file flows (CIT/MIT) and lifecycle operations?
3. What does a token migration look like in practice?

6. Multi-merchant management and hierarchy

If you’re a PSP or acquirer, this is non-negotiable.

Ask:

1. Demo merchant onboarding, hierarchy, and approvals
2. Can policies be set per merchant and per channel?
3. Do you support templates for merchant configuration?

7. Multi-MID support (real control, not a workaround)

This is often the difference between “works in demo” and “works at scale”.

Ask:

1. Walk through a multi-MID scenario end-to-end
2. What’s configurable via UI versus API?
3. How do you handle fallback between MIDs and prevent bad retries?

8. Routing, cascading, failover (with guardrails)

Routing is powerful, but dangerous if it creates loops.

Ask:

1. What variables can rules use (BIN, country, currency, amount, MCC, risk flags)?
2. How do you prevent harmful retry loops?
3. What happens when an acquirer is partially down or degraded?

9. Operations: reporting, exports, reconciliation readiness

This is where money is lost quietly.

Ask:

1. Provide sample exports (CSV, API, webhooks) for settlements and transactions
2. Which identifiers are stable across systems and reports?
3. How do you map acquirer and gateway reports for reconciliation?

10. API quality, webhooks, integration experience

You want boring engineering.

Ask:

1. Do you support idempotency keys and consistent error taxonomy?
2. Do webhooks support retry and replay, and how do you dedupe events?
3. How close is sandbox to production?

11. SLA, observability, and incident response

When volume grows, “we respond fast” stops being a plan.

Ask:

1. What metrics do you expose (auth rate, declines, latency, 3DS stats) and how fast?
2. What’s your incident escalation timeline?
3. Do you have a real postmortem process?

12. Commercials, lock-in, exit plan

Teams regret lock-in only after go-live.

Ask:

1. How do we export configs, routing rules, merchant settings, and data?
2. What is the typical exit timeline and support model?
3. What breaks if we replace one component in the stack?

RFP checklist

A. Product and delivery

1. Describe your white-label payment gateway architecture and core modules
2. List deployment options and what is included in each
3. Provide implementation timelines, responsibilities, and key dependencies

B. Security and compliance

1. Explain tenant isolation and RBAC
2. Describe audit logs and access control model
3. Provide PCI shared responsibility details
4. Explain secrets management and key rotation

C. 3DS and authentication

1. List supported EMV 3DS versions and flows
2. Explain edge-case handling and fallback behavior
3. Describe available 3DS reporting and analytics
4. Outline integrations with external 3DS components if applicable

D. Tokenization and recurring

1. Describe token vault architecture, ownership, and portability
2. Explain support for recurring and credential-on-file transactions
3. Outline token lifecycle operations and migration approach

E. Merchant and MID management

1. Demonstrate merchant hierarchy and role model
2. Explain multi-MID configuration and routing support
3. Describe onboarding workflows and approval logic

F. Routing and failover

1. List supported routing variables
2. Explain cascading, failover logic, and retry guardrails
3. Describe how degraded providers are detected and handled

G. Operations and reconciliation

1. Provide reporting and export formats
2. Explain stable identifiers and reconciliation mapping
3. Describe settlement, fee, and commission support if relevant

H. API and webhooks

1. Explain idempotency and error conventions
2. Describe webhook delivery guarantees, retry, and replay
3. Clarify how close sandbox is to production

I. SLA and support

1. Provide uptime SLA and support coverage model
2. Describe incident response and escalation process
3. List operational metrics available to clients

J. Migration and exit

1. Explain export methods for configuration and data
2. Describe migration support and timelines
3. Outline transition assistance and termination terms

Common mistakes when buying White-label payment gateway software

1. Choosing a checkout product instead of a gateway layer
2. Discovering reconciliation and export gaps only after go-live
3. Not validating multi-MID scenarios in a live demo
4. Trusting “3DS supported” without verifying flows and reporting
5. Treating observability and incident response as “nice to have”
6. Signing without a clear exit plan

Where FinOn adds value

At FinOn, we see white-label payment gateway software as a core infrastructure layer for PSPs, acquirers, banks, and fintech platforms, not just a branded checkout experience.

That is why our approach focuses on the areas that tend to matter most in real operations:

1. Multi-merchant and multi-MID structures built for PSP and acquirer setups
2. Flexible deployment models, including software and managed service approaches
3. Strong integration with 3D Secure and authentication components
4. Tokenization and recurring payment support designed with control and long-term flexibility in mind
5. Exports, operational reporting, and reconciliation workflows treated as essential product capabilities rather than afterthoughts

For payment businesses evaluating gateway technology, the most effective comparison is always practical: test the product against your real operating model, not just a product presentation.
If you're currently evaluating white-label payment gateway solutions, you can contact the FinOn team to discuss your requirements and deployment options.