In this post, we will discuss the various steps we took to make our SDK one of the easiest to integrate.
Like many B2B companies, Link Money has two types of users to serve — merchants, which are our customers — and our merchants’ customers or end users. Likewise, we also offer two primary interfaces — the SDK for merchants and the open banking UI that our SDK presents to end users.
As the primary interface for our merchants, our SDK is a critical touchpoint of our customer relationships, and our goal is to make this as delightful to use as our UI. As a merchant, this may also be helpful as a checklist of technical points to look for when selecting any SDK solution.
Standard naming conventions and patterns for APIs and data models
Ensuring an experience that is intuitive and as easy to understand as possible means that you should not need to learn a new vocabulary, or be surprised by unusual patterns or conventions. Any surprises in the way an SDK works or an API is defined will increase the friction for developers to integrate.
To ensure the smoothest possible integration for our merchants, we studied a number of SDKs in the same space, and incorporated recurring patterns into our API and data model patterns to create familiarity. Further, we followed existing naming conventions for endpoints, methods and webhooks. Since our SDK contains integrations to multiple APIs, it was also important for us to ensure that all naming conventions, even across platforms, followed the same rules. The result is that our SDK is an easy, drop-in replacement for similar services in the market.
Simplicity to reduce integration time and improve security
Keeping the SDK as simple as possible not only makes the integration of the SDK easier, but also reduces any security risks that may inadvertently be exposed.
However, in some SDKs, such as our Pay by Bank product, there are both frontend UI and backend APIs, which automatically adds complexity. Furthermore, there is also some complexity in how native UI wrappers are used to present our web client where most of our logic resides.
In designing our SDK, we were obsessive about minimizing the amount of work that consumers of the SDK need to do to complete an integration, and we designed and redesigned until we convinced ourselves that it absorbs as much complexity as it can. Over multiple revisions, we were able to narrow down the integration to most essential touch points.
A focus on end user experience
Most B2B SDKs focus on the business customers consuming the SDK, leaving the end user experience in the hands of the merchant. But, as mentioned above, we also took on the task of presenting a rich UI for the end user as part of our SDK. This allows them to choose which financial institution to connect to, select an account and/or read the terms and conditions.
Since our merchants’ success depends on getting the end user experience right, we conducted end-customer usability studies to fine-tune our UI, and talked to potential customers to understand various use cases and situations in which our SDK will be used.
Based on our research, we paid particular attention to the versions of Android and iOS that the solution will be deployed on, and optimized our SDK and web-client until we achieved optimal responsiveness. We also went the extra mile implementing dark mode support to really make sure our SDK provides the best experience to end-customers.
Security from the ground-up
It is a given that security must be the highest priority when designing an SDK, especially when the solution deals with financial information. It is not just the focus on security that is important but also the process by which it is achieved.
We implemented a rigorous process around security, such as conducting third-party audits and pen-tests at key milestones. Any security issues were caught before the code made into production. Any issues identified were not only addressed immediately but also triggered an internal review to improve our process further.
Every decision made regarding the APIs or implementation must be scrutinized from a security perspective.
We believe this is the kind of security-first approach that puts merchants at ease and makes them confident that the solution as a whole meets the highest security standards.
Extensive usability testing
As mentioned above, we put a lot of thought and effort into building an SDK that’s easy to understand and integrate. However, as we are the builders and not the users, we would almost certainly have some blind spots.
To overcome this challenge, we asked an internal engineer who had never seen the SDK to develop an integration purely based on the documentation, and iterated further on friction points, using this data to add additional helper methods, improve documentation and add more sample code.
We also made it our priority to closely work with merchants who integrate our SDK and gather both explicit and implicit feedback. Implicit feedback, such as questions being asked and the number of back-and-forth communications, are also important to consider to understand the stumbling blocks for our customers. We turned this feedback into action items and improved the SDK in a way a future customer would not face the same problem.
Making usability a priority and defining a process to improve it helped us make a measurable improvement in integration times.
Choosing a frictionless SDK is a smart business move
Smooth, fast, and secure SDK integrations save your business time and money, reduce risk, and mean you can start accepting low cost payments faster.
If you’d like to try out our SDK, please check out our documentation or contact us.