Let's look at the advantages of using a native SDK for integration instead of a Webview-based integration.
- Optimizations for speed
- Auto-OTP reading
- Optimizations on bank page for mobile
- Low SDK size
Our native SDKs are specially designed to handle low-bandwidth of the mobile network. Mobile platform's networking components allow for parallelization of requests and retry of failed requests. However, in a JS based integration, you are restricted to single thread and it's difficult to handle errors. Hence, JS based integration directly leads to subpar performance.
One of the most prominent reasons for failure of a payment is due to an error related to OTP. Various possible errors:
- User entered wrong OTP
- By the time user switched app to messenger, read OTP, memorized it, switched back to your app, the bank page had already expired
- User's device is a low-end android device, and your activity got garbage collected when the user switched to messenger app
While these may seem like edge cases, the frequency of occurrence is very high. The Auto-OTP reading feature helps massively in reducing these. This feature is present in our Android SDK. It automatically reads the OTP and shows it to the user inside your app itself, hence eliminating the need to switch apps. It also takes care of reducing human errors. This feature is technologically impossible to implement in JS based integration
Most of the bank pages are not optimized for mobile screens. The page elements are too small for interaction on a touchscreen. This can be fixed by adding some custom CSS across bank pages. However, for adding custom CSS on a bank page, there need to be two threads at least, one thread that controls the thread in which bank pages are running. With JS based integration, this is not possible. However, with an SDK based approach, we are already doing this.
Again, while this may seem like an edge case, data proves that the occurrence is high enough to impact the overall success rates.
Normally, one of the major reasons for not including a third party SDK in an app is the size of the SDK. However, our SDK at < 200KB is one of the smallest payment SDKs out there, even with the bunch of features discussed above. This is due to a conscious effort on our part to strip out anything that is not necessary in the SDK.