A key challenge that fintech, SaaS, and B2B platforms face as they scale is adding new functionality that provides the business with opportunities for upsell and customer acquisition.
In this case, rather than build in-house, the best approach is to leverage a third-party API which can bring value-add functionality for your SME customers to your platform quickly and easily.
However, what are the key considerations when selecting an API? For example, some APIs have a great deal of functionality, but are technically difficult to work with. This can cause integration problems for your developers, which leads to slower time to market and can potentially cause issues for your customer in the future if something breaks. On the other hand, sometimes an API can be designed well technically, but not really provide the value added functionality you need for your customers. An effective API needs to have a good balance between these two objectives.
This article helps you understand some of the key considerations in selecting an API from technical and regulatory perspectives, as well as a business one, so you can ask the right questions and collaborate with your developers more effectively.
Usability for your developers
There is a lot of discussion around the advantages and disadvantages of API standards, such as REST, GraphQL, SOAP, and so on. But usability – how easy it is for your developers to accomplish your desired tasks with the API – is a much deeper topic than which standard your API partner is following.
A good way to test usability is in a sandbox environment where your developer can test things out quickly, without too much information, and see how fast and easy it is to accomplish the desired task. As a product manager, you can find out early if a sandbox or test environment exists, or how your developers can quickly assess the usability of the API.
Functionality for your customers
As mentioned, an API can have a good level of usability, but not provide your SME customers with the functionality that will move the needle in terms of customer acquisition and upsell. So it’s important to make sure that the API has been designed with the input of someone who understands your business and your customers’ needs.
This means the team building the API should not only be made up of technical people. Rather, it should also include someone who understands how both you and your end customers interact with it. This person should be able to talk you through why an API is designed in such a way, the value it brings to your customers, and take your feedback on board for future iterations and product development.
An appropriate level of security for handling other people’s money and data
Financial automations are, of course, extra sensitive, and it is critical to be sure that any third-party APIs in your platform are secure. To be sure that this is the case, some relevant areas for discussion include the provider’s practices around GDPR, PSD2, PCI/PII and any other regulations, whether they have any relevant certifications, their security practices, and where data is stored. When choosing an API provider, it is wise to get in touch with their compliance and security team early on, to learn more about their practices and assess whether they meet your standards.
Ease of integration with your existing systems
At this point in your company’s growth, your platform or app will already be live and serving customers, so it is important that if you are going to partner with a third-party API, it can easily integrate with your existing platform. An API created with only simplicity in mind runs the risk of becoming overly tailored, serving only very specific use cases, and may not be flexible enough for other use cases. For this, a third-party API needs to be simple enough to work with easily, but agnostic and flexible enough to fit with your existing stack.
Here you can ask your developers and tech leads to assess the complexity of integration, including a call for your team to discuss the integration with the tech team from the API provider. In addition, you look at feedback in key developer communities such as GitHub.
Good support and documentation
Many developer questions can be covered by good documentation, FAQs, or forums. But self-service has limits. For more in-depth questions or other complications, there should be some type of technical support available.
In addition, it may be worth asking if your potential API partner offers software development kits (SDKs). These can help your developers by offering building blocks for the creation of an application, instead of them having to start from scratch.
One other thing to look out for is if a potential API partner publishes their integration artifacts, such as Postman Collections, integration demos, the source code of their products, and perhaps have educational videos on YouTube. Resources such as these can save you technical team time and energy.
Stability and scalability
Stability is critical to ensure your internal resources are not needed to constantly maintain your API connection, but also to avoid the business impact of having a connection break. Key questions to ask your API provider include geographical coverage, their SLAs in these regions, error rates, rate limiting practices, how quickly they can address latency issues, and how well their platform architecture can be adjusted to the peaks on your side.
About the Monite API for embedded finance
At Monite, we build our API with the above principles in mind, including good documentation, an API Explorer, and SDKs. In addition, our multirail approach to payments hides a lot of complexity from our fintech, SaaS, and B2B platform customers. Rather than needing to deal with multiple APIs and all the complexity that comes with that, the fact that you only need the single Monite API to connect with multiple payment service providers saves a lot of time and provides more predictability and stability.
To find out more about what embedded finance API can do for your fintech, SaaS, or B2B platform, contact us.