Flexibility, speed and quality are the cornerstones of building, successful, innovative and effective mobile payments app and software development.
However with the complex mobile payments eco-system and fast pace of development, the possibilities for software quality failures are high and can impose security risks, damage brands, cause inconvenience and loss of customer trust and rack up hefty costs for fixes. With nationwide launches of Paym and Zapp in 2014 the pressure is on participating banks, as quality is paramount to ensure a good customer experience, data security and timely delivery.
To respond to these challenges, there are five key software development drivers to establishing effective, successful and quality driven m-payment applications and systems. Through agile development, open source software, automation, security embedded into the development lifecycle and efficient test management, banks can deliver mobile payments quickly and at a reduced cost:
1. Embrace Agile development to pilot and roll out innovative services quickly
With no worldwide mobile payments standard, banks need to be flexible and adopt a dynamic approach to software development, a dynamic approach to software development is key to the successful adoption of mobile payments.
Agile development methodologies offer a collaborative and flexible approach that protects banks against the consequences of adopting the “wrong” technology, by supporting small lightweight releases that are ideal for testing a business case or theory with real users.
A cultural and organisational change is necessary for the adoption of agile development. Living documentation, the ability to make changes quickly and confidently and a shifting focus to defect prevention may face some resistance. However, the benefits of faster development and error-free roll-outs is gaining interest for banks rolling out mobile payments.
2. Invest in Open Source
Many new mobile payments services will have Open Source at their core. In the competitive mobile payments market, app developers should be focusing time and effort on the new app or service’s USPs and not on commodity services and functionality that are readily available.
A wide range of Open Source projects provide building blocks for many mobile payments applications. As well as no licensing costs, using open source reduces the cost of development and testing effort.
Through Open Source software, banks benefit from the support of a community and can bring software to market more quickly as Open Source software is often at the forefront of any new technology.
Open Source software sits neatly with agile development. Open standards reduce vendor or technology lock in, providing the flexibility to change direction easily.
Using software that has already been proven in the field also reduces the likelihood of quality issues. Direct access to source code also minimises dependency on a third party and empowers users to either fix issues directly or ask the community of developers if they are unable to resolve an issue.
3. Embed security into the Software Development Lifecycle
Mobile payment security is potentially the biggest hurdle to consumer adoption. A survey of 2,000 UK consumers in 2013, found that fewer than one in four would use their smartphone for m-payments. Against this lack of consumer confidence and threat of hackers accessing sensitive data, banks are embedding security early into the software development lifecycle.
As security teams are faced with protecting customers against a myriad of vulnerabilities from different parts of the mobile payments eco-system, a threat model focused on likely vulnerabilities is the first step in the development of a ‘secure by design’ application or software.
This ‘secure by design’ approach is then verified using a security testing methodology designed specifically for the mobile technologies involved. In this case, through an industry-led and vendor-neutral initiative – OWASP – banks can verify the security of mobile applications.
Starting with the information discovery phase, banks use the application to understand the functionality and how it performs technically. Analysing network traffic and hardware reveals what network interfaces are used by the application as well as whether hardware such as Near Field Communication (NFC) and Bluetooth are used. Deep inspection of the application’s functionality will also reveal what sensitive information is collected and what transactional functionality is involved.
Static analysis (the analysis of code) reveals server addresses and Application Programming Interface (API) usage. The source code is reviewed for common weaknesses and flaws that may impact on security such as authentication, data storage and networking.
The information gained from the Information Discovery and Static Analysis phases enables a structured and informed approach to Dynamic Application Security testing of the mobile application client, server and associated services to be developed.
4. Adopt automation to ensure quality across thousands of variables
The quality of a mobile payments application is critical to successful consumer take-up. However, banks can no longer rely on manually testing mobile payments applications. The variables are simply too many. For Android alone, over 420 devices and 29 versions of the operating system have been released since 2007.
Automated functional and automated regression testing are being adopted as manual methods are unable to cope with the growing complexity and demands of mobile application testing.
Trying to mitigate mobile payments risks effectively without the use of automation is a very complex, time consuming and precarious endeavour. A well thought out test automation strategy is crucial: clear requirements, rationalisation of devices and limiting the number of combinations of operating system are imperative for the intended market.
5. Implement test management to launch mobile payments faster, smarter and cheaper
Quality Assurance and testing teams at banks are having to modify existing methods and processes to make testing more effective without huge increases in budgets.
By expanding the concept of risk-based testing to include the unique characteristics of a mobile payment system, quality assurance effort can be laser-focused to mitigate the biggest risks and so maximise the testing budget.
Considerations such as battery consumption, network hand-offs between mobile and Wi-Fi networks, required levels of security as well as user interface and App Store delivery need to be considered within the overall test strategy.
Prioritising testing tasks helps to reduce the overall volume of testing work. There are several strategies to improve testing efficiency – two of the most effective approaches for mobile payments are testing earlier in the development cycle and using both test tools and automation frameworks.
Shifting testing left introduces test activities earlier in the development lifecycle. Opportunity cost, re-test effort and correction effort are all typically much higher the closer a project or an agile iteration is to go-live. Identifying and eliminating a defect early is almost always cheaper and faster than addressing that same defect later.
Led by the sharp rise in the number of mobile subscribers globally, and the high volume of smartphone sales, mobile payments are expected to exceed $721.4 billion, which is £435.2 billion by 2017.
While gaining a share of this multi-billion pound opportunity is highly attractive, banks that are unwilling or unable to adapt their IT systems quickly are at risk of losing out to other financial services providers. Both established players and start-ups with newer infrastructure and processes in place will be the initial winners in the mobile payments. Having helped major financial service organisations in launching their m-payment apps, SQS has capabilities and experience that will ensure that the build and launch of these applications is secure, effective and within time and budget.
By Anand Vyas, VP of Banking, Financial Services & Insurance at SQS Group.