DANAKit as a General SDK in iOS
There are several ways to integrate DANA as a payment method into the merchant apps. Some of them are via Internet Payment Gateway (IPG) API and native SDK. We call both of them Widget Solution.
IPG connects merchant apps through Back End APIs that provide data to create the payment. Then, it will open DANA’s web pages inside the merchant apps so users can complete their payments. DANA’s web pages provide information for the user to select their preferred payment methods, either via Balance, Debit/Credit Card or Pay Later.
On the other hand, with native SDK integration, merchant apps do not need to connect directly to the DANA Back End. The connection will be bridged by the SDK. In this article, we will explore the journey of DANA SDK from the beginning to its latest state: DANAKit as a General SDK.
So, what is DANA SDK?
DANA SDK is a native framework that wrapped the connection to DANA Back End from the merchant apps and vice versa. In iOS, the DANA SDK is written in Objective-C to provide wide compatibility with the merchant's iOS apps. So, the merchant apps written in Obj-C and Swift in all versions will have no compatibility issues to integrate with DANA SDK. We deliver DANA SDK in the form of a .framework binary file in iOS. Currently, several merchant apps use DANA SDK to integrate with DANA.
Why do Merchant Apps use DANA SDK?
The first reason is to give the merchant apps freedom to design the UI of the DANA payment process. As mentioned before, with the IPG solution, the users can choose the DANA’s payment methods and can see the payment result on the DANA’s web pages. But, with DANA SDK, the merchant can design their UI to select DANA’s payment methods since the SDK will provide the information needed to construct the page. Also, the payment result will be delivered through DANA SDK so the merchant apps do not need to open DANA`s web pages to show the payment result.
The next reason is the rich use cases provided by DANA SDK. Since the SDK is built by using native code, we can access the device resources to their full capability. For example, some of the DANA SDK use cases are Scan QR and KYC (Know Your Customer). Scan QR provides a capability for merchant apps to scan a payment QR code to do a transaction with DANA. KYC enables the user’s verification process inside the merchant apps. Both use cases need camera access that can be provided by DANA SDK smoothly.
The payment process will be more secure too since the merchant apps do not access the DANA Backend directly. DANA SDK adds an extra security layer by implementing some security components inside it. The authentication process will be handled by DANA SDK too.
DANA SDK Journey
Since the beginning, DANA SDK has had some evolutions to its architecture and functionalities. Let’s take a deeper look at each evolution here.
The Legacy of IAPBukaDANAKit
In the early days, DANA was integrated into these three apps: BBM, Tix ID, and Bukalapak. DANA SDK began its debut to provide integration with Bukalapak. We called the product BukaDANA and the framework as IAPBukaDANAKit. This framework was built with Monolith Architecture where all the codes were placed in one project and one repository.
IAPBukaDANAKit contains several use cases that aimed to integrate payment functionalities between Bukalapak and DANA. The Authentication use case makes Bukalapak users can bind their DANA account to the Bukalapak app. The Payment use case enables users to select DANA as the payment method and process the transaction. While User Info use case provides the user’s DANA account information such as balance and KYC status. Meanwhile, all the use cases are coded in one project, IAPBukaDANAKit also needs some dependencies from our partners as third-party frameworks. Some of them are to enable networking, enhance security, and provide a powerful web container. We use Cocoapods as the dependency manager to integrate the third-party frameworks.
IAPBukaDANAKit was also not yet delivered to the merchant with dependency managers such as Cocoapods or Carthage. We deliver it via email or a chat group. This becomes a problem that needs to be addressed.
The Dawn of DANA SDK 2.0
After the initiation of IAPBukaDANAKit, there were requirements to provide the SDK to other merchants. There were some new functionalities needed for the second merchant. But, most of the basic functionalities are already written in the IAPBukaDANAKit. The team came up with a solution to reduce work and reuse the code that is already available when integrating with a new merchant. The solution was to split the functionalities inside IAPBukaDANAKit into several new frameworks.
We use the Modular Architecture approach by separating the code into three major layers.
The first layer is called the Core. This layer provides basic functionalities without any business logic in it. Either for networking, common code extensions that can be used across upper layer modules or to store data in persistent storage. This layer also acts as a wrapper for our third-party frameworks. We add some custom functionalities inside the wrapper to make some adjustments so the third-party frameworks can fulfill our needs. Many-Core modules are already built by our team. One of them is FeatureToggle. This module wraps our third-party tool framework so we can do some configuration changes to DANA SDK functionalities in a real-time manner.
The second layer is Use Case. We consider this as a business layer of the architecture. Modules that falls into this category contain codes that serve business requirement. The Use Case modules use Core modules to access the infrastructure functionalities. There are seven modules that available in the Use Case layer currently. Their functionalities are:
- Auth: to process the authentication of the DANA account in the merchant apps, either to bind or to unbind the account.
- CashierPay: to connect transactions in the merchant app to DANA Back End.
- User: to provide the user’s DANA account information such as balance.
- PaymentQR: to provide the user`s QR code so the offline merchant's cashier can scan the QR to process the transaction.
- ScanQR: to enable scanning QR capabilities in the merchant app to process the transaction.
- KYC: to enable the DANA account KYC process directly inside the merchant app.
- MerchantBinding: another way to bind with DANA in the merchant app is by using DANA’s web pages.
The third layer of the DANA SDK Modular Architecture is Integration Kit. This module composes the Use Case modules into a single framework. The Integration Kit is specialized for each merchant, meaning there will be many Integration Kits. The Use Case modules that are included may differ between the Integration Kits. Merchants can select the Use Case modules that they want to use. They can select all of the modules or only some of them, depending on their needs and agreement with DANA. The implication is the framework size of every Integration Kits is varied, fewer Use Cases mean a smaller size.
DANA SDK 2.0 Products
Currently, we have been delivered DANA SDK to two merchant apps: KFCKU and Bluemart. They need different Use Case modules, so we create a specialized Integration Kit for each one of them, DANAKFCKit and DANABluemartKit. These Integration Kits are stored in a different repo and project. We need to maintain both of them. We realized there will be some problems that might come up with this approach.
SDK 2.0 Problems
From the explanation above, we created a new Integration Kit for every merchant that wants to integrate with us. Imagine if we receive requests from 10 merchants that have different Use Case needs, then we need to create 10 Integration Kit. In our experience, we need one sprint to assemble the Use Cases modules into an Integration Kit, complete with the example app, testing, and documentation. So, more merchants mean more sprints needed to be allocated.
All Integration Kit created need to be maintained also. From time to time, we will update the Core or the Use Case modules. Either to fix some bugs or to introduce new capabilities. More Integration Kit means more work to update them.
The manual delivery of the Integration Kit will need extra effort too since we need to contact every merchant to give the framework artifact.
These problems caused a high work capacity that needs to be allocated to our development team. We need to discover a more efficient way if we want to integrate with a high number of merchant apps.
Solution Attempt: Builder Automation Engine
We try to automate the processes to generate an Integration Kit. Builder Automation Engine is created for this purpose. This Ruby-based tool receives input about which Use Cases the merchant needs. Then, it will generate an Integration Kit framework artifact that contains selected Use Case modules.
We plan to integrate Builder Automation Engine into a web-based merchant portal where the merchants can input some details and Use Cases that they need. The Builder will process the request and will generate a link to download the framework. With this engine, the effort from DANA’s developer to create an Integration Kit will be reduced.
Builder Automation Engine Problems
The Builder still creates a specific Integration Kit for each merchant. It means, that one merchant cannot use the other merchant Integration Kit even though they have the same Use Case modules. It is because we placed the merchant’s identifier keys inside the Integration Kit specific for them. These keys allow DANA Back End to distinguish connected merchants.
To create such an automation tool, it needs a complex process inside. It requires secure access management so between merchants cannot download the other merchant Integration Kit. When there are so many merchants that access the Builder, we need to prepare high server resources to run it. It is because this Builder connects with Xcode build tools to create the project, assemble the Use Case modules, and archive the project to generate a framework artifact. Builder not just handles a new merchant Integration Kit creation, but also updates the existing Integration Kit to get the latest Use Case modules functionalities. More merchants that access the builder means more server resources needed to be allocated that eventually will require a high cost.
Then, We Realize…
To provide basic functionalities for DANA integration with merchant apps, three Use Case modules always need to be included: Auth, CashierPay, and User. Just by these three modules, the process from binding to completing the transaction can be handled.
Also, we realize, that if we create two Integration Kit for two merchants, but both of them use the same Use Case modules, then the only different thing in them is a file called MerchantConfig.json. This file stores identifier keys that have specific values for a merchant. So, we ask ourselves, what if we can take out the MerchantConfig.json from the Integration Kit so its framework artifact can be used by all merchants?
The Rise of DANAKit as a General SDK
We answer the previous question by creating one Integration Kit that aimed to be used by all future merchants.
We start by separating the Use Case modules into two categories: mandatory and optional. Auth, CashierPay, and User become mandatory modules that must be included in the Integration Kit. Then, we assemble them in the DANAKit. PaymentQR, ScanQR, and KYC become optional modules where the merchant can opt-in if they want to use them.
We use Cocoapods to integrate mandatory modules into DANAKit. To make the optional modules approach possible, we use Cocoapods Subspec as the way to configure them in the DANAKit’s Podspec.
The next step is to take out the MerchantConfig.json file from the Integration Kit. To make the DANAKit work, this file will be injected from the merchant apps. In this way, DANAKit becomes an SDK that can be used by all merchants.
How to Integrate DANAKit
Currently, we will require merchant apps to use Cocoapods to integrate with DANAKit. In their Podfile configuration they can add DANAKit in this way:
We create a public Podspec repo to store the DANAKit’s Podspec. By adding it to the Podfile, the Cocoapods will know where to download the DANAKit’s framework. To integrate basic functionalities, merchant apps only need to be put pod 'DANAKit' to their Podfile. If they want to use the optional modules, they can add pod 'DANAKit/<Optional Module>'.
We store the DANAKit’s framework artifacts in a Nexus Repository Manager. We will provide the access to the merchant developers so they can do pod install to download DANAKit.
The next step is, that the merchant apps need to put the MerchantConfig.json file inside their app. We will provide the file and it will be different between merchants. As explained before, this file becomes the identifier for merchant apps to access DANA’s system.
The Benefits of DANAKit
All current and future merchants can use the same Integration Kit. But, without losing the freedom to add the optional Use Case modules, or not. This makes us only need to maintain one Integration Kit. The developer effort will be reduced significantly compared to the multiple Integration Kits for multiple merchant approaches. Future updates will be easier too. We can expand the mandatory or optional modules by adding the Use Case. Once added to the DANAKit, all merchants can access it at the same time.
The previous problem where we delivered the Integration Kit’s framework manually via email was also solved since we use Cocoapods as the dependency manager. As explained before, merchants can integrate DANAKit using Cocoapods.
These mandatory and optional module approaches are also implemented in some popular third-party SDKs. Firebase from Google and FB SDK from Facebook also has a similar approach. They have one module that is mandatory to integrate, and some others that can be added optionally. So, we think merchant developers will be familiar with the process when integrating DANAKit.
But, How about the Builder Automation Engine?
Merchant developers will not need to access Builder Automation Engine from DANA’s merchant portal. We also do not need to allocate high infrastructure resources for the Builder. So, is the Builder Automation Engine discarded? Fortunately, no. The Builder still has become an important tool for DANA’s developers.
If previously Builder was intended to be accessed by merchant developers. then now the Builder will be accessed by DANA’s developers only. They will access Builder for two things:
- To create DANAKit. Only need to do this once.
- To update DANAKit with a newer version of Use Case modules, or to add new Use Cases.
So, Builder becomes an internal tool to make developer jobs to maintain the DANAKit easier. The developer's effort will be more efficient too so we can focus more on adding values to the Use Case module where the innovation lies.
That being said, the journey of SDK architecture and implementation take us from a merchant-specific framework approach to a general one. All of these are to make the merchants easier to integrate with DANA. Also, this journey brings effort efficiency to our developers. As a science-fiction author said:
“Progress isn’t made by early risers. It’s made by lazy men trying to find easier ways to do something.” — Robert Heinlein
I would like to say kudos to the Merchant Core iOS team (Yoga Widyakrisna, Cundy Sunardy, Anisa Budiarthati, Yosua Hoo, Muhammad Syahroyni, Michael Jonathan, Keenan Warouw, and Michael Gunawan) who participated in building DANA SDK iOS.
