There are several mobile payment libraries out there. Stripe, BrainTree, PayPal and others. The majority of them are well built and do provide mobile application developers with the straight-forward functionality of capturing payments. Developers do benefit from the inbuilt security and in many cases authentication.
But what if you had to build such library yourself and from the ground up? What would be the main components? How would they fit together?
This blog post covers exactly that – example components needed for any mobile payments library or SDK. And how do they fit together. You are most welcome to join the discussion.
How to build mobile payments engine?
When we talk about mobile payment transactions we mean that money amounts are exchanged between payment sender and payment receiver.
Sender agrees to send the funds from his account and they are delivered to receivers account. The sender is using a mobile device powered by some mobile operating system. Receivers account resides with some financial institution. Bank for example.
But all this simplicity hides multiple important activities which have to happen in the background in order to facilitate the payment transaction.
To illustrate, I’ll break these activities into separate modules which, you most likely will find in most mobile payments libraries.
Transaction details collection. Payment logic. Communication with the payment processing networks and gateways (processors like FirstData or card schemes like Visa and MasterCard). Payment verification and security. Notifications to both the sender and the receiver.
I will go through them one by one, with short explanations about what are the basic requirements for each.
Collection of payment transaction details
This activity is about collecting required transaction data from the payment sender. It manages how the sender (and your mobile application user) is interacting with the payments process.
You want this interaction to be as simple as possible, secure and quick.
Remember, mobile application user will directly link the payment process and your application quality. This activity plays a key role in keeping it simple and easy to use (don’t forget the secure bit, though).
This module should make sure that the payment sender is who he says he is (authorization) and that all required data for payments transaction is collected (there is a receiver in the payment flow!).
Filling multiple text fields will not make your application users happy, as well as asking them to create additional logins, passwords or answers to security questions (these ones always test user patience..).
Payment transaction logic
This activity is responsible for calculating payment transaction amounts, fees, taxes and anything related to the difference between amount sender sends receiver receives to his account.
Questions while designing or adopting this payments module: are multiple currencies supported? can fees be dynamically calculated based on the receivers shipping address? can sender use multiple funding sources for the transaction?
Communication with payment processing networks
In the payments World, every transaction should go through the network infrastructure called payments processing network. There are few of these out there.
Visa, MasterCard, and American Express own the processing networks for credit card transactions. Therefore, each payment made by credit card stamped with these logos will have to pass via their payments network.
Similar exists for interbank payments.
This mobile payment engine module will have to integrate into the payment processing networks in order to make funds appear in receivers account. Personally I would call it the most complex puzzle for mobile payments engine.
While adopting mobile payments library questions to ask and understand: can it process credit card payments? can it process bank to bank payments? how does it handle currency conversion?
Payment verification and security
One of most important activities in mobile commerce transactions.
As Max Levchin, technical co-founder of PayPal puts it, fraud can easily bring under an electronic commerce business.
Mobile payments engine should have an inbuilt mechanism to independently validate transactions, and verify that payments are actually in receivers account before notifying the sender.
By ‘independently verify’ I mean that such verification should happen in the backend and be independent from the actual mobile application which originates the payment. This way we are adding another independent layer of protection.
Questions to ask while evaluating this part of mobile payment library: does it support external validation of the payment transaction? How secure is payment transaction data delivery from smartphone which is running the app to payment processing networks?
This activity is responsible for notifying both sender and receiver about the payment transaction status, sent or received amounts.
Its the important module to have as we want to be proactive in notifying mobile application users. In the end of the day payment is done on the smart device. And smart bit has to be justified.
Does your mobile payments library include module for notifying sender if transaction is completed (remember the security steps we have discussed above)? Does it allow to proactively notify receivers as well?
This post is a general overview. I kept it simple, without too much information overload. As with all architecture, its possible to drill down to more and more detail if there is a need. Feel free to start a discussion in the below comments!