Last editedOct 20204 min read
The RFP process should give you a sense of how good each payments provider is for certain functional and non-functional requirements.
A RFP should enable you to decide whether a payments provider meets all the requirements you have. It should also help you to get a sense of how good they are along several dimensions. As a place to start, we’ve created a sample RFP which can be downloaded here.
In general, you should be assessing companies along the following dimensions:
1. Do they meet your functional requirements?
Integration with existing systems
2. Do they meet your non-functional requirements?
We give a high-level overview of what you should be looking for in each of these categories below. For a detailed breakdown of the kind of questions you should be asking, we recommend looking at the sample RFP.
These are requirements to do with the type of payment method. How you evaluate these answers will depend on how your business takes payments.
For example, whether you prefer a hosted or embedded payment page may depend on the level of control you require over the user experience. A hosted payment solution will enable you to take payments without needing to touch sensitive financial data. However, it will also mean that you will have less control over the user experience and may need to include the provider's branding in your payment pages. Embedded payment pages let you maintain control but you will need to comply with onerous legal and technical PCI/AUDDIS requirements.
Ideally a provider will offer low failure rates, the ability to take and settle payments as often as you like and regular updates on payment statuses.
For Direct Debit, the types of questions you might want to ask are:
Does the system allow you to set-up mandates electronically?
Does the system allow you to take payments on any date?
Does the system inform you when payments fail or are charged back?
Can you take variable payments using the system?
How does signing customers up work? Can this be done over the phone?
What are the typical failure rates seen for companies that they serve similar to yours?
Do you own the user experience or does the system require the provider’s brand to be featured as well?
How frequently are funds settled?
See a full list of payment-specific requirements and explanations here.
These are requirements that determine how efficient and effective the provider is from a technical point of view. Ideally, you will want to find a provider with a simple modern REST API, helpful client libraries, clear documentation and great technical support. If you love your developers, it might even be worth checking out some of the more particular features of the API; such as versioning, pagination and URL structure.
In particular, you will want to know things like:
Does the provider have a REST API that you can connect with?
How does the API work?
Does the API provide real-time information, or does it work in batch?
Does the API provide webhooks on events such as payment failures?
Is the API rate limited?
See a list of technical requirements and explanations here.
Integration with existing systems
This will vary depending on what systems you use, but generally speaking, you will want to find a solution which integrates with your current internal systems. This will save you time upfront as well as on an ongoing basis.
The types of questions you might want to ask are:
Does the provider integrate with any of our current internal systems? (e.g. Zuora, Salesforce). This includes:
If not, does the provider have a REST API that your partners can use to develop an integration?
What can the provider do to make processes more efficient where an integration is not possible? e.g. can it support agents using a dashboard to perform reconciliation? How will the process work?
Here, you will want to know the pricing of the service. Some providers may offer low transaction costs but charge additional fees for hidden extras. Ideally you'll want to find a provider with a superior service at the lowest cost. Make sure you compare fully-loaded costs not just transaction fees by asking questions like:
How does the pricing vary as your number of transactions scale?
How much will the cost be, all-in, per year?
What does the provider charge for:
Per new payer
Per failed payment
Per file submission (if applicable)
For training / installation
Are there any other charges?
Does the provider pay out all funds to you or do they retain any in case of chargebacks?
See a list of pricing and commercial questions here.
Financially, you will want to understand how funds will flow to you. This will vary depending on whether your provider offers "facilities management" or "managed administration".
With facilities management, you will have your own SUN therefore the funds will typically flow directly to you.
With managed administration, the bureau will submit and manage payments on your behalf through their SUN. Payments will therefore go via the bureau's bank account and will usually take a few days to reach your account.
Which of these options is right for you will depend on your business - managed administration will work out significantly cheaper, however, if you need to have full control over the payment process and user experience you may want to consider a provider which offers facilities management. Either way make sure you understand the flow of funds and consider how this will work with your business.
How often does the provider pay out funds to you?
What is the flow of funds, end-to-end?
Does the provider hold funds at any point, and if so, why?
How does reconciliation work? i.e. walk through the money flows for a payment failure from end to end.
See a suggested list of finance questions here.
Security is of paramount importance when picking a provider, particularly when it comes to payments. You'll want to find a provider who can offer a proven high level of security. Broadly speaking, you'll want to know:
Has the provider been penetration tested in the last 6 months?
What were the results of that report?
How often is a penetration test performed?
Does the provider use HTTPS? SSL encryption?
Has the provider had any security breaches in the past, and if so can they detail them?
How does the provider’s physical security work? i.e. guards, access control etc..
The sample RFP we provide has a full list of questions vetted by our security and technical team.
Resilience refers to the availability of the service electronically as well as the ability of the service to stay up in the event of an adverse event e.g. a failure at a data centre. Ideally a provider will have over 99.99% uptime and will have back-up systems in place to ensure this doesn't worsen.
You will want to ask about:
Uptime records in the last year.
How the provider ensures uptime in the event that one of its centres fails, e.g. having an alternate site.
What the uptime SLA is.
What the event resolution time SLA is, and who your contact will be.
Does the provider use cloud hosting or host locally? If the latter, ask them to explain how physical security works.
If cloud hosted, explain who the provider is and why that one was chosen.
See our suggested list of questions regarding the Service Level Agreement (SLA)and business continuity.