How to ask the right questions in an integration project
  • Screen Shot 2019 08 13 at 16 12 52 Jessica Allen
  • 21/08/2019

How to ask the right questions in an integration project

We’re joined by Simon Tabor, Software Engineer at DAZN, to hear his recommendations on the right questions to ask in an integration - and Bhavin, Integrations Engineer at Ravelin, to hear his answers.

We caught up with Simon from DAZN to hear his recommendations for what questions your engineering team needs to ask when integrating with a new service. DAZN is the first global pure-sport live and on-demand streaming service. It gives millions of sports fans around the world affordable access to sport anytime, anywhere.

Simon says: “When you’re looking at integrating with a new API, it might seem like the obvious question should be ‘How long will the integration take?’ But it’s usually not that simple. The basic implementation could take just a few hours, but depending on the size and setup of your business it could take months to be fully complete. Your new service provider is unlikely to fully understand your setup, so they can’t give you a definitive answer. I’d recommend asking these five questions to get an idea of how much time and work the integration could take."

Our Integrations Expert Bhavin will be answering the questions to give insight into how we manage integrations at Ravelin. To find out more about development at Ravelin see our tech blog here.

How do I make an API call?

This seems like a basic question, but what you’re really asking is to see what their public developer documentation looks like.

If the service provider is vague about this or is urging you to sign a contract without seeing these docs, it should be a warning sign. The quality of the docs and how well-maintained they are will give you insight into how easy the integration will be. If it’s a PDF or in a format which makes it hard to read, or if docs are missing or outdated, the integration process is likely to have some road bumps.

Ravelin response

Our developer docs are here. They cover most topics that a developer would need in order to successfully integrate with Ravelin. In addition to an API reference, we have separate guides for frequently asked questions -- how to handle errors, how customer service reps can use Ravelin, etc.

Our documentation is based solely on our API, and if anything in our API changes it will automatically update immediately. Whilst our documentation is very informative, it doesn’t take into account things that are specific to your payment flow and business. This is where you’ll benefit from working with an Integrations Engineer who has experience in dealing with many of the common pitfalls that might come up during the integration.

Ravelin Developer docs

How do I authenticate myself against the API?

In this case, the authentication relates to using the API, not making a payment. In other words, which credentials do I need to use to access the API? This tells you about the security of the API.

Ravelin response

When we create a new account for you we will create some API keys for you to authenticate against our API. You get one key for the sandbox environment where all the testing happens, as well as a key for the live environment.

If raw card details (such as the PAN, expiry dates, and cardholder name) need to be sent to Ravelin, we’ll provide an RSA key that you can use with our Javascript library and mobile SDKs. This ensures that card data remains confidential.

Do you have an API library?

An API library can help extract away the complexity of the API and makes it easier to integrate without having to build a lot of unnecessary code. This means you can just focus on your business logic. If a company doesn’t have a library, it means you need to have a simple API that is easy to communicate with.

Ravelin response

API library SDK

Integrating a product like Ravelin will take time. Because of this, we used a language-agnostic REST API, so we don’t need to maintain lots of different language libraries and risk security issues. We have a mobile SDK to be used in mobile apps, and a JavaScript library for use on desktop and mobile sites. The main way you’ll communicate with Ravelin is through our REST API - this enables you to send all the data to us, and receive the recommendations that we make. Thankfully it’s very easy to use and your Integrations Engineer will be on hand to answer all your questions.

Are there any limits on the API?

At DAZN, we need to be able to handle hundreds of thousands of users at once. It’s important to know if there are any limits on API usage. A limit doesn’t necessarily mean the API will break at that point, many providers have them for reasons like fair usage. There’s no concrete proof for the answer to this question, so it’s important to trust what the service provider says - and the docs and responses to other questions will help you with this.

Ravelin response

We have rate limits to protect all our customers from a huge influx of requests from one customer affecting others. Our default rate limits are fairly permissive, but they can be tuned in accordance with your business traffic.

Do you have any developers to talk to during the integration?

In previous roles, I’ve helped customers integrate with our API, so I know from both sides how much it helps to have someone available to answer questions. The quicker the feedback loop, the quicker you get the integration complete, so having dedicated support is a massive bonus.

Ravelin response

We have a team of integration engineers to answer all your questions, and you’ll be allocated a specific engineer to work with. You can call or email us, and we also set up a Slack channel for faster response. We have weekly check-in calls to guide the integration, make sure everything is going smoothly and give updates to your fraud teams.

Thanks to Simon for his insight, and to Bhavin for sharing how integrations work at Ravelin. To find out more about development at Ravelin see our tech blog here.


You might also like

San Francisco Roundtable Gerry Carr Read more
Blog image ATO shared device Jessica Allen Read more
PSD2 blog Martin Sweeney Read more