Technical Requirements

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.