Skip to content
Open site navigation sidebar
Go to GoCardless homepage
Pricing
LoginSign up
Go to GoCardless homepage
LoginSign up
Breadcrumb
Resources

Technical Requirements

GoCardless
Written by

Last editedApr 20231 min read

A list of technical criteria to include in a RFP for determining how efficient and effective a payments provider is.

A RFP should list your technical requirements from a payments provider. Ideally, you'll want to find a provider with a modern REST API, helpful client libraries, clear documentation and great technical support.

Suggested questions to ask your potential provider include:

 

Question

Explanation

1.

Do you have an API?

An API allows you to automate the payments process, and is particularly helpful if you collect payer details from a website. Without the API, you'd have to get those details into the system manually, which is labour-intensive.

2.

What protocol is the API based on? (i.e. SOAP, REST)

REST and SOAP are different ways of designing an API that follow established conventions. RESTful APIs are generally considered easier and quicker to integrate against.

3.

What data format does the API transact in? (i.e. JSON, XML)

JSON and XML are different formats for transmitting data. This information helps determine how well the provider fits with your current technology stack.

4.

Is the API rate limited? Specify the limit. Does the API return the remaining number of request tokens with each request?

A rate limit is a way of ensuring that someone doesn't overload an API - it limits the number of requests to an endpoint. Having one generally ensures that an API is robust and is unlikely to be brought down by too many requests. Specifying the number of remaining tokens allows you to know how many 'requests' you have remaining.

5.

Does the API enforce HTTPS/TLS or does it accept unsecured HTTP requests?

Enforcing HTTPS/TLS is preferred for security reasons.

6.

What authentication protocol does the API use?

Worth knowing for security reasons.

7.

How is version control / backwards compatibility enforced in the API? How does a customer communicate the version they are using to you? (e.g. using the 'Accepts' header)

Breaking changes should be minimised and handled gracefully (e.g. by using headers and versioning). This ensures your integration will function at all times.

8.

How does the API inform us of events, e.g. a payment failure? Is it webhook-based or does it use batched file transfers?

Webhooks are preferred because they are real time, whereas batched file transfers mean you will be less responsive to e.g. payment failures.

9.

Do you enable modulus check via the API?

The provider should allow you to modulus check details you collect on your site to prevent false details from being submitted.

10.

Where a mandate or payment fails, does the API provide us notification of the reason why? Describe how this is done.

The API should provide reason codes to allow you to program the appropriate response, e.g. for insufficient funds you'll want to contact the customer rather than automatically retrying the payment.

11.

Are your list/index endpoints paginated?

This feature means that for large numbers of payments or customers, you get data in a graceful way that's easy to work with.

12.

Is your API documented online? Please provide a link.

APIs should be documented, ideally online, and the quality of documentation is important to ensure a smooth and quick developer integration with your website.

13.

Can we store custom IDs against mandate objects?

This facilitates integration into other systems e.g. Salesforce by allowing you to match objects in one system to another.

14.

Does your API enable the set-up of recurring subscriptions? (i.e. where you handle the timing logic)

This feature is desirable in case you want to 'set it and forget it' for e.g. annual recurring subscriptions.

15.

Does your API support the use of dynamic descriptors on the customer's statement? Is this on a per mandate basis only, or do you also allow this on a per payment basis?

You may want to set different references per payment and/or per mandate; you should check that the API allows you to do this if you have this requirement.

16.

Do you return HTTP status codes with each response?

This allows graceful error handling.

Our sample RFP includes all of the questions above and more. You can download it here and use it as a template for creating your own.

Note: The questions suggested on this page are intended as a starting place for writing your own RFP. They're provided for general information only: they're not intended to be prescriptive or to provide legal advice. We suggest working closely with your management to develop an RFP that is tailored towards the specific requirements of your business.

Over 85,000 businesses use GoCardless to get paid on time. Learn more about how you can improve payment processing at your business today.

Get StartedLearn More
PreviousFunctional Requirements
Interested in automating the way you get paid? GoCardless can help
Interested in automating the way you get paid? GoCardless can help

Interested in automating the way you get paid? GoCardless can help

Contact sales

Try a better way to collect payments, with GoCardless. It's free to get started.

Try a better way to collect payments

Learn moreSign up