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 Direct Debit provider include:
|1.||Do you have an API?||An API allows you to automate the Direct Debit process, and is particularly helpful if you collect DD details from a website. Without the API, you'd have to get those details into the direct debit 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.
(A modulus check is a numerical check against the bank account number & sort code to make sure the combination is possible. It reduces the error rate on checkout pages)
|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?||For various reasons 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.‹ View table of contents Next page ›