Implementing mobile contactless payments: guide to overcoming pitfalls

The introduction of mobile and contactless payments has become a real technological boost in Fintech industry. Having tried this technology once, consumers and retailers will never abandon it. Obviously, the technology is mutually beneficial and convenient.

Despite the evident opportunities there are some issues that need to be taken into account.

Is there any conceptual difference between mobile and contactless payments?

I would say it is all about terminology. Mobile payment can be considered as a contactless transaction, since a consumer doesn`t “touch” a POS terminal or a card reader. On the other side, paying with a contactless card is also a contactless payment. The main point of difference is the way the payment is made, while all of the payment methods are non-cash and contactless.

But to avoid misunderstanding and misconception in the article, let`s use a blanket term for our topic – mobile contactless payment, which is a payment made via a mobile app and with no contact to a card reader or a POS terminal.

Defining the payment process

Developing the concept of a mobile payment application, first, think of the transaction types that the app will process: credit, debit or maybe stored value transactions? As a part of that analysis decide which transactions will require a signature.

Second, choose how transactions will be processed: online or offline?  Online processing is clearly the most ordinary and requires “live” authorization.

Third, define what data elements are required for every transaction: consumer`s data, card payment company, processor, or anything else?

As long as a company is ready with the payment concept and has a list of the application features, it can run the development process.

Development tips

There is a very special thing about the development of the mobile payment applications. Most of them are divided into two parts or “ends” how the developers call it – front-end and back-end. That means that your project will not stop on design and functionality development that is included into the front-end.

So, why do you need the back-end? Back-end is actually the part that is “in charge of” business and integration logics, while the front-end initiates and “displays” the things that happen in the back-end.

The division of the application into two parts raises the security questions you cannot neglect.

Security criticals

Two-part application structure leaves space for reverse engineering and data leakage. That`s the reason for the development team to take special care of the application security. The server and its correct settings should become your fool-proof security shield. Make sure that access to the server is secured as well as the messages that are sent to it. And don`t forget to check whether the payment logics, calculations and transactions are held on the server side, not within the application. But security issues do not end on the server precautions.