How to run an RFP for a payment provider

This guide is general information for a product prototype. It is not legal or procurement advice. Adapt it to your organisation's own process.

Executive summary

Choosing a payment provider is a long decision. Contracts often run for several years, and switching later means re-integrating, migrating stored cards and retraining teams. A well-run request for proposal (RFP) reduces the chance of an expensive mistake.

This guide is for payments, finance and procurement teams at mid-market and enterprise businesses that sell across borders. It covers how to scope the RFP, what to ask, how to compare pricing fairly and how to test claims before you sign.

The main lesson is that the most useful RFP questions ask for evidence on your own data, not general claims. A provider that cannot show you how it would perform on your traffic mix has not yet answered the question.

Key findings

These points come from conversations with payments teams who have run recent selection processes. Any figures are illustrative.

1. Most RFPs ask too many questions. A 300-question document produces 300 answers that all say yes. Teams that cut to 40–60 questions focused on their own priorities got answers they could compare.

2. Pricing comparisons fail on mix. Headline rates are not comparable unless every provider prices the same sample of transactions. Give each bidder an anonymised file of your recent volume and ask for a priced result.

3. Approval rate claims need a test. Approval rates depend on your markets, card mix and fraud settings. Ask for a paid or unpaid pilot on a share of real traffic before you commit.

4. Migration is underestimated. Moving stored card credentials, recurring payments and dispute history takes planning. Ask each provider how they would do it, and who does the work.

5. Support terms matter as much as features. Response times, named contacts and escalation paths are often decided late and regretted later.

How to structure the process

1. Define what you need. List your markets, payment methods, volumes, settlement currencies and must-have capabilities. Separate needs from preferences.
2. Shortlist. Three to five providers is usually enough to compare without losing focus.
3. Issue the RFP. Include a pricing file, a short question set and a clear timeline.
4. Score. Use a weighted scorecard agreed before responses arrive.
5. Pilot. Run the top one or two candidates on live traffic where possible.
6. Negotiate and sign. Use what the pilot showed you.

Questions to include

A short selection from the question bank in the full guide:

• In which of our markets do you acquire locally, and through what entity or partner?
• Which payment methods do you support in each market, and which are live today?
• How do you price cards, local methods, FX conversion, refunds and disputes?
• Can you return a per-transaction fee breakdown through the API?
• How do you handle network tokens and card updates?
• What is your approach to 3-D Secure exemptions?
• How would you migrate our stored card credentials, and how long would it take?
• What are your support response times by severity, and who is our named contact?
• What uptime have you reported over the last 12 months, and where is it published?

What's in the full guide

The full 20-page guide is free to read and includes:

• A scoping worksheet for markets, methods and volumes.
• A question bank of 60 questions grouped by payments, risk, FX, payouts, compliance, engineering and support.
• A weighted scorecard template with suggested weights for different business types.
• A pricing comparison method, including how to build the sample transaction file.
• A pilot plan with success criteria and a timeline.
• A migration checklist for stored credentials and recurring payments.

Related reading

• Solutions by industry and business size
• Pricing, including Interchange++ and blended models
• Reading an Interchange++ statement
• Talk to our team about an evaluation