By using this site, You consent to the use of Cookies. For more information read our Privacy & Cookie Policy. OK

ARE BANKS GEARED UP FOR THE M-PAYMENT RACE?

The mobile payments race is on: Visa, VocaLink, MasterCard all have mobile payment products in development while banks and other financial sector organisations are looking to launch their own products. Led by the sharp rise in the number of mobile subscribers globally, and the high volume of smartphone sales, according to Gartner, mobile payments are expected to exceed $721.4 billion (£435.2 billion) by 2017. Widespread adoption is however still some way off and all players will need to establish their services in the minds of consumers as reliable, fast and safe.

The simplicity of a mobile payment app’s user interface can be deceptive and ensuring that a payments service is reliable, safe and secure is not trivial. The complexity of m-payment apps stems from the mobile ecosystem behind the bright colours and big buttons. This includes the device, network connection to corporate systems, data transferred over the connection and the need for security and auditing. Further, particularly for apps used in multiple countries, variations in mobile networks can affect how well the app will work. With greater complexity comes the increased risk of an error or breakdown in some part of the mobile ecosystem supporting the payment app.

Consumer concern at the perceived risks can be seen in the results of a survey of 2,000 UK consumers in 2013 from Firstsource, which found that fewer than one in four would use their smartphone for m-payments. For a consumer, if Angry Birds crashes on a smartphone it can be annoying, but if a banking or mobile payment app crashes it isn’t just annoying, personal data may be exposed and customer funds put at risk, damaging not only bank’s reputation but also lowering customer trust as well as loss in revenue. So, to survive and flourish in this fiercely competitive market, m-payment apps have to be high quality and work first time, every time.

Ensuring high quality and getting to market faster

Unfortunately, ensuring the quality of m-payment apps can be hugely labour intensive and testing can consume a large part of that effort. As one financial services company discovered, an m-payment app aimed at popular consumer devices could easily need over 2,000 test cases to ensure that it works as expected. These tests would need to be executed on ten or more versions of iOS, Android and Windows Phone – potentially over 200,000 tests. Moreover, these tests should, ideally, be conducted every time the software is updated to ensure that new updates do not break existing functionality (this is known as regression testing).

The sheer volume to testing needed to ensure a high quality app can be daunting. Techniques such as open source (OS) optimisation can help to reduce the load. For example, by only conducting lower risk tests once on one version of each device (e.g. only on iOS 6.1 on an iPhone 5, rather than on iOS6, iOS7, iOS7.1 etc. on multiple iPhone types). Even so, many tests are still required. With automation, the repetitive and time-consuming aspects of testing can be handled without manual intervention, increasing speed and reducing the likelihood of mistakes and ultimately saving money.

Automation is not without its challenges: smartphone manufacturers (particularly Apple) impose restrictions upon their devices that can limit the effectiveness of test automation. Further, for international projects, devices should ideally be tested in-country on mobile networks that end customers are likely to use. However, these issues can be overcome though the solution often varies on a case-by-case basis. Successfully implementing automation can reduce testing effort dramatically – as in the case of the financial services company mentioned earlier, the  saving can be as much as 80% compared to manual testing. In the m-payment race this improvement can be a huge advantage.

A good, clean race – safe and secure development

Security is another major challenge for m-payment systems and the common use of third-party software by mobile developers adds an extra – and possibly unexpected – dimension of risk.

Are Banks Geared Up For The M-Payment Race?
Are Banks Geared Up For The M-Payment Race?

To deliver an m-payment system developers need to write software that uses many different technologies and that works on very different hardware devices. To simplify this task developers often make use of open source or third-party software libraries to carry out common functions. While these libraries can make development faster, their use raises questions about licencing and intellectual property rights (IPR). Have licencing requirements been met or even understood? How do the licence terms affect the IPR of the system if it uses open source libraries? Has the library used been written with secure coding in mind?

It is all too easy for developers to ignore or gloss over these considerations in the rush to get a working product out. However, it is important not to simply pay lip-service to licensing and IPR – even high profile names such as Cisco and Samsung have fallen foul of these issues and been forced to withdraw non-compliant products.

Irrespective of whether third party libraries are used, thorough security testing is essential. The common practice of only conducting security tests at the end of a project can be risky. When weaknesses are discovered, the bank is likely to be left facing a choice between delaying a release to solve the issues or going live with software that has known vulnerabilities. A better approach is to build secure coding or security testing at the development stage. As a result potential defects are detected and fixed earlier rather than at the end of a project, saving both time and accelerating speed to market.

Winning the race

Traditional testing and Quality Assurance methods are of limited value when developing mobile payments apps. The race to get to ahead of the competition effectively mandates the use of dynamic, agile software development methods. But developing the software rapidly is not enough, the quality assurance must keep pace with development and this can only be achieved through more efficient software quality methods.

Leave A Reply