Payment Provider RFP: How to Tender for a PSP, Acquirer or Gateway

Quick Summary

A payment provider tender should do more than ask several PSPs or acquirers for their best rate.

For an established business, the right provider may need to support a combination of:

• significant card-processing volume;
• ecommerce and face-to-face payments;
• multiple legal entities or brands;
• international customers and currencies;
• recurring payments;
• existing stored-card tokens;
• custom API or software integrations;
• multiple settlement requirements;
• fraud and chargeback management;
• complex reporting and reconciliation; and
• future growth into new markets or channels.

A well-structured Request for Proposal (RFP) gives providers the same information and asks them to respond against the same requirements. That makes commercial, technical and operational comparisons considerably more useful.

The difficult part is often not issuing the tender. It is deciding which providers should be invited, what they should be asked and whether their proposals are actually comparable.

Get Help With Your Payment Provider Review

What Is a Payment Provider RFP?

A Request for Proposal is a structured document sent to potential suppliers asking them to explain how they would meet a defined set of business requirements.

In payments, an RFP might be used to select or review:

• a merchant acquirer;
• a payment service provider (PSP);
• a payment gateway;
• a payment facilitator;
• a payment orchestration platform;
• a card-terminal provider;
• a recurring-payment provider;
• an international acquiring solution; or
• a combination of providers.

The process gives shortlisted suppliers a common set of information and requirements against which to respond.

For simple merchant accounts, a formal tender may be unnecessary. But as processing volume, integrations, countries, entities or payment channels increase, relying on a handful of headline quotations can make meaningful comparison difficult.

RFP, RFI or RFQ: Which Do You Need?

Businesses sometimes use these terms interchangeably, but they serve slightly different purposes.

Request for Information (RFI)

An RFI is useful earlier in the process when you are still trying to understand which providers can potentially support your requirements.

You might ask about:

• countries supported;
• acquiring coverage;
• payment methods;
• industry appetite;
• integration options;
• platform capability;
• settlement currencies; and
• high-level commercial structure.

Request for Proposal (RFP)

An RFP goes further. The business provides detailed requirements and asks each shortlisted provider to explain how it would deliver the service.

Request for Quotation (RFQ)

An RFQ focuses more heavily on pricing.

For complex payment environments, starting with pricing alone can be problematic because two providers may quote completely different technical or acquiring structures.

The cheapest response is of limited value if it cannot support the payment environment the business actually requires.

When Should a Business Run a Payment Tender?

A formal provider review may be worthwhile when:

• an existing contract is approaching renewal;
• processing volume has grown significantly;
• the existing commercial terms have not been reviewed for several years;
• the business has outgrown its current PSP;
• new countries or currencies are being introduced;
• the business is adding ecommerce, apps or new sales channels;
• multiple brands or legal entities need to be supported;
• payment authorisation performance is causing concern;
• reporting or reconciliation is becoming difficult;
• a major ERP, EPOS, booking, CRM or ecommerce migration is planned;
• the business wants to introduce more than one acquirer;
• fraud or chargeback requirements have changed;
• the existing provider cannot support new functionality;
• stored-card or recurring-payment infrastructure needs to change; or
• management wants to demonstrate that payment suppliers have been competitively reviewed.

Start With the Payment Requirements, Not the Provider List

One of the easiest mistakes is deciding which providers to approach before defining what the business needs.

A stronger process starts with the payment environment.

Document:

• what is processed today;
• how customers pay;
• which systems payments connect to;
• what is working well;
• what is not working;
• what is expected to change over the next few years; and
• which requirements are mandatory rather than simply desirable.

This is particularly important because the provider with the strongest proposition for a UK retailer may not be the right provider for an international marketplace, hotel group, SaaS platform or subscription business.

What Information Should Go Into a Payment RFP?

A payment provider cannot price or design a solution accurately without understanding the merchant.

The tender should normally include enough information to describe the existing and anticipated payment environment.

Business information

• legal entities;
• trading names;
• business model;
• sector;
• countries of operation;
• customer locations;
• future expansion plans; and
• relevant group structure.

Processing information

• monthly and annual processing volume;
• transaction numbers;
• average transaction value;
• maximum transaction values;
• seasonality;
• card-present volume;
• ecommerce volume;
• MOTO volume where relevant;
• recurring-payment volume;
• refund levels;
• chargeback levels;
• currencies;
• customer countries;
• card mix; and
• existing provider or providers.

Technical information

• ecommerce platforms;
• mobile apps;
• API integrations;
• EPOS;
• ERP;
• CRM;
• booking systems;
• subscription platforms;
• fraud tools;
• tokenisation;
• stored credentials;
• reporting infrastructure;
• webhooks;
• reconciliation systems; and
• data warehouse or finance-system requirements.

Separate Mandatory Requirements From Preferences

Not every requirement deserves the same importance.

A useful RFP distinguishes between:

Mandatory requirements — a provider cannot proceed without them.

Highly desirable requirements — commercially or operationally important but potentially negotiable.

Future requirements — capabilities that may become important as the business develops.

For example, support for a particular booking platform might be mandatory, whereas next-day settlement might be desirable.

This prevents an impressive presentation or attractive headline rate from disguising the fact that the provider cannot support a critical element of the payment setup.

Which Payment Providers Should Be Invited?

More providers do not necessarily create a better tender.

Inviting ten providers that have materially different propositions or little appetite for the business can create a large amount of work without improving the decision.

A useful shortlist should consider:

• sector appetite;
• merchant size;
• transaction profile;
• countries supported;
• acquiring footprint;
• payment channels;
• technical capability;
• integration requirements;
• risk appetite;
• settlement requirements;
• service model; and
• whether the provider's commercial model is appropriate for the business.

The objective is to create a credible competitive process rather than simply collect as many quotations as possible.

Check Who You Are Actually Contracting With

Payment brands, gateways, acquirers and platforms can involve several different legal entities.

Your RFP should establish:

• the legal entity providing the service;
• which entity provides acquiring;
• whether other providers sit within the payment chain;
• who holds the primary merchant relationship;
• which entity settles funds;
• which countries each entity supports; and
• the relevant regulatory status where applicable.

For UK regulated payment and electronic-money services, businesses can use the FCA Financial Services Register to verify firms and relevant permissions.

Ask Every Provider to Price the Same Transaction Profile

A payment tender becomes difficult to compare when providers receive different assumptions.

Where possible, give each shortlisted provider the same transaction profile.

This could include:

• annual card volume;
• monthly transaction count;
• average transaction value;
• consumer debit;
• consumer credit;
• commercial cards;
• international cards;
• card-present transactions;
• ecommerce transactions;
• currencies;
• regions;
• refunds; and
• chargebacks.

Ask each provider to explain the assumptions behind its quotation.

Do Not Compare Headline Rates Alone

The Payment Systems Regulator has previously highlighted the difficulty merchants can face when comparing acquiring offers because providers can use different pricing structures and approaches to headline rates.

A tender should therefore capture the whole commercial model.

Request details of:

• interchange treatment;
• scheme and processing fees;
• provider or acquirer margin;
• fixed transaction fees;
• authorisation charges;
• gateway fees;
• monthly fees;
• minimum commitments;
• terminal costs;
• refund fees;
• chargeback fees;
• fraud-service charges;
• 3D Secure charges;
• tokenisation charges;
• cross-border costs;
• FX margin;
• settlement charges;
• implementation costs;
• support charges;
• professional-services costs; and
• contractual minimums.

Where providers propose different pricing models, model each one against the same transaction data.

Read our guide to reducing payment processing costs for businesses processing £1m+ per month.

Ask Providers to Explain IC+, IC++ and Blended Pricing Clearly

If one supplier quotes a blended rate while another quotes IC++ pricing, the two percentages cannot simply be placed next to each other.

Ask providers to state:

• the pricing methodology;
• which underlying costs are passed through;
• the provider's own commercial margin;
• which costs can vary;
• how scheme-fee changes are treated;
• how international cards are priced; and
• where additional fixed fees apply.

For larger merchants, pricing transparency can be as important as the initial headline rate because it affects the business's ability to understand future cost changes.

See our guide to blended pricing, IC+ and IC++.

Include Authorisation Performance in the Tender

A payment provider review should not treat cost and payment performance as separate issues.

Ask providers how they would support:

• authorisation optimisation;
• soft-decline handling;
• 3D Secure;
• stored credentials;
• network tokenisation where applicable;
• account updater services;
• fraud configuration;
• local acquiring;
• issuer response analysis; and
• performance reporting.

Do not ask only for an overall expected approval rate.

Understand how performance will be measured by geography, card type, transaction type and customer journey.

Our guide to payment authorisation rates for enterprise merchants explains the subject in more detail.

International Businesses Need a Separate Acquiring Strategy

If the business operates internationally, ask providers to map their proposed acquiring structure rather than simply list the countries in which they operate.

Questions can include:

• Where will transactions actually be acquired?
• Which legal entity will contract with each merchant entity?
• Which settlement currencies are supported?
• Which presentment currencies are supported?
• Where will FX occur?
• Are local acquiring arrangements available?
• Are additional merchant accounts required?
• Can the provider support future expansion?
• How are cross-border transactions treated?
• Can reporting be consolidated across countries?

Local acquiring can be useful for some businesses, but a global PSP model can be more appropriate for others.

See Local Acquiring vs One Global PSP.

Do Not Leave Integration Until After the Provider Is Chosen

A commercially attractive provider may become a poor choice if substantial development work is required to make it fit the existing payment environment.

The tender should establish whether providers can support:

• the existing ecommerce platform;
• custom API requirements;
• mobile applications;
• payment terminals;
• EPOS;
• ERP;
• CRM;
• booking systems;
• subscription systems;
• payment links;
• virtual terminals;
• webhooks;
• refund workflows;
• reconciliation systems; and
• internal data requirements.

Ask what functionality is native, what requires a third-party integration and what requires custom development.

For more complex environments, see our guide to payment API integration.

Stored Cards and Tokens Can Change the Economics of Switching

Businesses with subscriptions, memberships, repeat customers or stored payment credentials should investigate migration before awarding the contract.

Do not assume that existing PSP tokens can simply be copied into a new platform.

Ask:

• who currently holds the stored payment credentials;
• whether data can be exported;
• what the receiving provider can import;
• which parties need to coordinate the migration;
• whether customers need to re-enter card details;
• how new customers will be handled during migration;
• how recurring transactions will continue during transition;
• what testing is required; and
• what happens if the migration is unsuccessful.

Token and stored-card migration can involve technical and compliance dependencies between the old and new providers, so it should be investigated before the commercial decision is finalised.

Read Changing Payment Gateway: Can You Move Stored Cards, Tokens and Recurring Payments?

Include PCI DSS and Payment Security Requirements

PCI DSS applies to organisations that store, process or transmit cardholder data, as well as entities that can affect the security of the cardholder-data environment.

The current PCI DSS version should therefore form part of technical due diligence where relevant to the proposed payment architecture.

Ask potential providers:

• which parts of the payment flow they host;
• where card data is entered;
• whether cardholder data reaches merchant systems;
• how tokenisation is handled;
• which PCI responsibilities remain with the merchant;
• what documentation is provided;
• how third-party integrations affect scope; and
• how security changes are communicated.

The objective is not to ask a provider whether it is simply “PCI compliant”. It is to understand how the proposed design affects the merchant's own responsibilities.

Settlement Can Matter as Much as Price

A lower transaction rate can be less attractive if settlement creates a working-capital problem.

Ask each provider to specify:

• standard settlement timing;
• whether faster settlement is available;
• settlement currencies;
• bank-account requirements;
• weekend and bank-holiday treatment;
• deduction of fees;
• gross versus net settlement;
• reserve arrangements if applicable;
• settlement reporting; and
• how adjustments are shown.

Understand Reserves and Risk Terms Before Signing

For some sectors or transaction profiles, a provider may require additional risk controls.

These can include:

• rolling reserves;
• fixed reserves;
• delayed settlement;
• processing caps;
• transaction-value limits;
• country restrictions;
• monitoring conditions; or
• additional underwriting requirements.

If these could apply, they should be discussed during the tender rather than discovered after the provider has been selected.

Make Reporting and Reconciliation a Core Requirement

For larger businesses, payment operations continue after the transaction has been approved.

The finance team may need to reconcile:

• transactions;
• settlements;
• refunds;
• chargebacks;
• fees;
• currencies;
• stores;
• legal entities;
• brands;
• payment methods; and
• multiple providers.

Ask providers to demonstrate the actual reports and data feeds rather than simply confirm that “reporting is available”.

Questions should include:

• What transaction-level data is available?
• How are fees identified?
• Can settlement be reconciled automatically?
• Are APIs or data exports available?
• Can multiple MIDs and entities be consolidated?
• How are chargebacks represented?
• How are refunds matched?
• What historical data is retained?

Ask About Support Before You Need It

Support is often difficult to evaluate during procurement because every supplier can describe its service positively.

Make the questions measurable.

Ask:

• Is there a named account manager?
• What support hours apply?
• Is technical support separate from commercial support?
• What incident-severity levels are used?
• What response targets apply?
• What happens during a major payment outage?
• How are incidents communicated?
• Is support delivered directly or through another organisation?
• What implementation support is included?
• What happens after go-live?

Ask Providers to Explain Their Resilience Model

Businesses for which payments are operationally critical should understand what happens when something fails.

The RFP can ask about:

• platform availability;
• planned maintenance;
• incident communication;
• gateway resilience;
• acquirer dependencies;
• terminal connectivity;
• regional infrastructure;
• failover options;
• business-continuity arrangements; and
• historic service reporting.

Where the business is considering multiple acquirers, our guide to acquirer-agnostic payment gateways explains one potential architecture.

Get Help Comparing Payment Providers

Create a Consistent Provider Response Template

Do not allow every provider to structure the commercial response completely differently.

Give suppliers a response template containing the same sections.

Build the Evaluation Method Before Responses Arrive

Decide how proposals will be assessed before the team knows which provider performs best in each area.

Possible evaluation categories include:

• commercials;
• technical fit;
• acceptance and geographical coverage;
• authorisation and performance;
• risk and underwriting;
• settlement;
• reporting and reconciliation;
• service and support;
• implementation;
• contract terms; and
• future scalability.

The weighting should reflect the business.

For one merchant, payment cost may be dominant. For another, an existing booking-system integration or ability to support ten countries may be non-negotiable.

Require Evidence, Not Just Yes or No Answers

Questions such as “Do you support multiple currencies?” tend to produce a yes.

Better questions ask providers to explain:

• which currencies;
• for which merchant entities;
• in which countries;
• through which acquiring relationship;
• how funds settle;
• what FX is involved; and
• what additional charges apply.

The same principle applies to APIs, reporting, fraud tools, tokenisation and account management.

Where a requirement is important, ask the provider to demonstrate how it works.

Should the Incumbent Provider Be Included?

Often, yes.

A tender does not necessarily mean the existing provider has to be replaced.

Giving the incumbent the same requirements and commercial template can establish whether:

• pricing can be improved;
• new functionality is available;
• the existing architecture can evolve;
• service commitments can be strengthened; or
• switching genuinely creates enough benefit to justify migration.

The final outcome may be a move, a renegotiation or confirmation that the current arrangement remains appropriate.

Do Not Ignore the Contract

The commercial proposal is only one part of the eventual agreement.

Review:

• initial term;
• renewal;
• notice periods;
• minimum volumes;
• minimum charges;
• pricing-change provisions;
• service levels;
• termination rights;
• migration support;
• data-export provisions;
• reserve provisions;
• suspension and termination rights;
• liability provisions; and
• dependencies on third-party contracts.

Commercial and legal review should take place before the business becomes committed to implementation.

Plan Migration Before Awarding the Tender

The winning provider still needs to become the live provider.

Ask for an implementation plan covering:

• merchant onboarding;
• underwriting;
• contracts;
• API development;
• gateway configuration;
• terminal deployment;
• token migration;
• fraud configuration;
• reporting;
• reconciliation;
• testing;
• pilot transactions;
• rollout;
• staff training;
• customer communication where required;
• fallback arrangements; and
• decommissioning of the previous provider.

For custom integrations, see our Enterprise PSP Migration Guide.

Common Payment Tender Mistakes

Some of the most common problems are avoidable.

Starting with a long provider list

Shortlist providers against the requirements first.

Making price the first question

Confirm that the provider can actually support the business before spending significant time modelling price.

Comparing different pricing structures as if they were identical

Normalise proposals using the same transaction data.

Ignoring migration

Integration, token transfer, terminals and operational change can alter the economics of switching.

Using vague technical questions

Ask providers to demonstrate how specific requirements will work.

Leaving finance out of the process

Settlement, reporting and reconciliation should be assessed alongside checkout technology.

Leaving risk until the end

A provider's willingness to underwrite the business and the conditions attached to approval can be fundamental to the proposal.

Choosing solely on the initial rate

Total payment cost, performance, contract terms and operational impact need to be considered together.

Questions Worth Asking Every Shortlisted Provider

• Which legal entity will contract with us?
• Who will provide acquiring?
• Which requirements cannot you currently support?
• What assumptions have you made in your pricing?
• Which fees are not included in the headline quotation?
• How is your own margin shown?
• How are scheme-fee changes passed through?
• How will international transactions be acquired?
• What settlement options are available?
• What reserves or risk controls might apply?
• How does the proposed integration work?
• How would existing tokens or recurring customers be migrated?
• What reporting data is available?
• How would our finance team reconcile settlements?
• How will you support authorisation optimisation?
• What support do we receive during implementation?
• What support do we receive after go-live?
• What service commitments apply?
• What is the contract term?
• What happens if we later decide to move provider?

How Merchant Advice Service Can Support a Payment Provider Review

A business does not necessarily need someone else to run its entire procurement process.

But independent payment input can be useful at several points.

Merchant Advice Service can help businesses:

• understand their payment requirements;
• identify the type of payment provider required;
• consider which providers may be suitable for the business;
• avoid approaching providers whose proposition or risk appetite is unlikely to fit;
• understand differences between provider models;
• structure the information needed for meaningful comparison;
• understand pricing structures;
• identify questions that should be answered before switching; and
• make introductions to providers that may be appropriate.

That can be useful whether you are at the beginning of a tender or already have several proposals on the table.

Discuss Your Payment Provider Review

Sources & References

• Payment Systems Regulator – Market Review into the Supply of Card-Acquiring Services
• Payment Systems Regulator – Market Review into Card Scheme and Processing Fees
• Financial Conduct Authority – Financial Services Register
• PCI Security Standards Council – PCI Data Security Standard
• Adyen – Migrating Payment Data Between Payment Providers
• Merchant Advice Service – Reducing Payment Processing Fees at £1m+ Monthly Volume
• Merchant Advice Service – Payment API Integration
• Merchant Advice Service – Enterprise PSP Migration
• Merchant Advice Service – Enterprise Payment Authorisation Rates

About Merchant Advice Service

Merchant Advice Service (MAS) provides independent information, comparison and provider-matching support for UK businesses looking for payment services.

We help businesses understand their payment requirements before introducing them to providers that may be suitable. MAS does not provide payment processing services directly.

Disclosure: Merchant Advice Service may receive commission from payment providers following a successful introduction. This does not increase the price paid by the merchant and does not determine which providers are included in our editorial guidance.