As our apps are defeating rades of notorious hacker attacks, seeming to rise out of nowhere and out of blue to challenge our mobile app payment security, the strive for mobile application security in big and small businesses has already started to take off. Everywhere, from an e-commerce shop and up to the higher institutions’ financial systems people request an online payment security app development. The top-searched request these days is: how to build up something with a higher protection level though? We will try our best to highlight it here.
Secure is a new black.
Remember the cyber epidemic that burst into flames in Ukraine and readily invaded the whole world? Assaults like this one prove that all the online transactions security we look for is yet imperfect - that one day all the machinery could give in to the fraud, all of a sudden. There are various types of fraud, but something that most hackers are aiming at is financial data security, primarily the bank accounts’ and transactions’ security.
Unfortunately, there’s no panacea for mobile banking application development from a cyber-attacking decease, but there surely are things that increase payments and transactions’ secureness. Firstly, there are 3 types of secure online payments that your project can involve:
-
Incoming
-
Outgoing
-
In-system transactions
Let’s take a banging mobile application of Uber and study all three categories at its example. Incoming payments are those that are conducted by a client for a certain product or service your application helps them perform; once your Uber ride is over, your credit card is charged for it. Outgoing payments are those conducted by a system itself to the employees it stands for. When the happy client is delivered by an Uber driver to their destination point, the system holds on for a certain period of time and then automatically transfers money to the driver. This waiting period is designed so that the user could have an opportunity to complain about the quality of service they have received. This option requires a certain level of care from the user’s side — once this period is over, the client can no longer fill in a complaint report. Both outgoing and incoming financial transactions require a third-party payment provider to be integrated into the system.
Things work differently with the in-system transactions though — an example of which would be financial operations between the two users within the system. At this point transactions can also function without an integrated payment provider due to all interactions happening within the system mentioned. The previously described fee collection methods are widely used in financial apps of all sorts, going along with the other features.
How to secure your mobile app? Well,
...You Need THEM to Be Present.
“Every creator is always welcome to join in with his ideas - for the sake of maximizing product’s usability!”
Basically every mobile wallet with security for mobile banking apps at it’s core needs a certain amount of features to make it attractive and “user-used”. Here is a short list of features considered essential:
-
Access to your bank account anytime, come rain or shine
-
Ability to make financial transactions, in particular:
a) Transfer your funds to any account within this banking system.
b) Transfer your funds to any account, credit or debit card worldwide.
c) Pay for any communication services - recharge your mobile phone, pay to your internet provider etc.
d) Pay for any other third-party services that are included by the banking system’s business logic - bus/plane/railway tickets, food, beauty products and games, cinema and football (or any other popular sport) tickets. The number of different payments that could be conducted through your application can be different as it all depends on the business logic and requirements created at the stage of business analysis.
e) An ability to pay your bills is also quite a hint, it may maximize user’s engagement within the app, as long as users can have the whole scope of utilities (gas, electricity, water, heating and so on) present.
-
An Ability to manage your cards (block/unblock them, set an online payment limit, change the PIN or CW2 codes, add, order or close the existing card).
-
A feature of dotation making would work greatly for the banking app - suggesting that you and your clients are involved in the charity of any kind.
-
An ability to access the user’s geolocation and show him the nearby ATMs and nearest bank branches.
The scope of features doesn’t end up with the once mentioned above — those are the ones our business analysts could think of when considering how to secure online transactions, but every creator is always welcome to join in with their ideas — for the sake of maximising product’s usability!
The amount and complexity of the features mentioned would require double security for a banking mobile application. How to make your online financial transactions secure though?
1. The system doesn’t have to save users’ financial credentials
Once the incoming, outgoing or in-system operations are completed, it is necessary for all the user’s commercial info to be left out on the payment service provider while securing online transactions. A provider normally has a vault and a built-in tokenization system, that conducts and protects all the financial operations. On your website (or in your application) there has to be inserted a specific form that is not part of the whole project’s code, as shown below in the image:
Later on, the received token and the form’s data security protocols go to our server, and only after this an application could charge the system. This working method is widely used by the Stripe payment provider.
Despite this method being truly widely known, there is a certain pitfall in it. When your application sends the card’s data to the server right to the payment service, it does not mention the precise sum transferred. So there, hypothetically speaking, is a chance of the system withdrawing more money than it should - by mistake or system bug. This issue hasn’t been resolved yet, so, although Stripe is a handy solution where a user is not redirected anywhere, it still lacks a stable secure online payment process.
Another widely known system is PayPal, with its “pay via PayPal” button.
The way PayPal works is a “web app payment processing” one - as when a user hits the payment screen, it automatically transfers the user right to PayPal’s platform. When further on a client pays via the service, your mobile banking app has to create an entity sent to PayPal next, which informs whether the payment was received or not.
The key point that differentiates Stripe’s and PayPal mobile payment gateways differ is that PayPal lets you see the actual amount of funds transferred, but it redirects you to their platform; on the other hand, Stripe doesn’t make you follow any external links, but the “precise sum” mobile payment security issues might distract your future users.
2. The System Has to Keep Tokens Safe and Sound
If you are building a secure mobile app with a subscription option - then it has to be stored in safety in the service’s database. The project’s structure should allow those tokens to be kept only there - with the public profile or any other entity’s option excluded.
Another way of securing financial transactions is by encrypting HTTPS protection into the website’s structure. If there is none on the website - the user shouldn’t transfer the money to the third-party resource, in order to secure your online financial transactions.
3. Try to avoid the “Exception, Payout, Repeat” mistake
The most terrifying thing that could happen to your payout (fund transfers, when the system transfers funds to users), is an “endless loop”. A payout to users is one of the background tasks run by a system, and if an exception happens - the task is rerun. As a result every transaction could be sent over and over to one user only.
How to prevent this:
- Set background tasks’ manager in a way that financial tasks don’t get into an endless loop;
- On every stage where an element is edited or created, it would help if you note it in the log file so that no change comes unnoticed. Even if a loop occurs, at least you’ll be able to notice its reason and where the money go so that it can be returned back to the users.
Putting all the matters into a nutshell, a secure banking app requires the following rules to be followed:
-
No users’ financial credentials to store
-
No money-transferring to the platforms without HTTPS protection
-
Every server’s response or request, every action, webhook, or callback should be logged in the greatest detail
-
Secure online payment process should be simplified to the most of it, maximally relying on the payment service provider, avoiding in-house e-wallet creation where possible
-
Always take time to test how the app runs, as only during the testing process all the negative cases can be predicted
-
Usage of web hooks and callbacks is strongly recommended
-
Always check the report that payment system provides you with, as you can spot if an issue occurs just over there
The Mobilelution of Everything.
One of the most common trends every business has these days is to go mobile with mobile app security and mobile app encryption. From the huge financial corporations up to the tiniest corner shops, those smart gadgets have occupied every bit the world has. Moreover, a quick digest through Statista’s insights suggests that this trend is only going to grow within the future 7 years.
Regardless of which platform you pick - iOS or Android application security, protecting online banking is a complex yet truly rewarding process. Just imagine, you have the potential of developing a sense of security for users and their funds, for letting millions of people rest peacefully at night… isn’t it something that has a life-transforming future?
Written by Alex Averyanov, Oleg Tsarenko and Elina Bessarabova.
