Understanding SDKs: Enhancing Data Privacy and User Experience Beyond APIs
Have you ever wondered, Why we use SDKs over apis? Why wouldn’t an SDK provider simply expose their API and give it directly to the app, making things easier?
In such a scenario, the SDK provider wouldn’t have to build and maintain a user interface (UI) for each type of device or framework (mobile web, native mobile for iOS or Android, web frameworks like React or Angular).
However, providing an SDK with a UI can be beneficial in some cases. Take Google Maps for example. It’s perfectly valid for Google Maps to provide an SDK that includes a UI along with the API.
But what about the SDK for payments or account aggregation? Let’s consider a situation where you pay through an app using Google Pay, PhonePe, or any other payment app. These apps typically involve scanning a QR code, entering an amount, and then being directed to a similar page across all apps where you enter your PIN and confirm the transfer amount. Notice that Google Pay (or any other payment app) doesn’t control what you do on that page, especially entering your sensitive UPI PIN.
If, instead of providing an SDK, a UPI aggregator shared just an API to transfer funds from one account to another, and the API were integrated on Google’s servers, Google would be able to see your PIN while transferring funds. They might even alter the transaction amount or have access to your account balance without your consent because they know your UPI PIN.
The same applies to account aggregators. If you’ve recently applied for a credit card, the provider might ask for your transaction history across all your bank accounts. Using an account aggregator, you start the journey in a different app or a new window in the same app, where you’re asked for your number and validate it with OTP. Then, you select your bank and choose the transactions you want to share. In this scenario, the app integrating the SDK doesn’t control your choice of bank details, ensuring your information is securely handled.
