80% of internet users own a smartphone, which means a large portion of online activity happens on a smaller screen. This doesn’t just mean ecommerce sites need to make sure they’re catering to mobile customers, banks are also focusing more on this particular part of their customers’ experience.
From 2012 to 2017, use of mobile banking apps increased by 356%. Since 2013, the number of customers managing their credit card accounts through an app rose by 46%, while the number of customers managing mortgages and investments on mobile shot up by a dramatic 86%.
This shift can benefit financial institutions just as much as it benefits their customers, as moving services online can cost significantly less in management and resources.
Mobile friendly vs mobile optimised
If it isn’t already, the layout of your main payment and transaction page needs to be designed specifically for mobile dimensions and usage. Clumsy processes, or a comparative lack of features, will discourage potential mobile customers, and they might not make the move to desktop to finish their transaction.
Mobile friendly and mobile optimised have different definitions. The former will resize itself automatically when it’s smaller - an easy way to test the mobile friendliness of a site is to drag the corner inwards and see how the layout changes. A mobile optimised page is built specifically for differently sized mobile screens, and should be the priority when building payment and transaction pages.
Simplification is key. The space may be smaller, but that means white space is still important and pop-up windows even less user-friendly. Free text fields should take less priority because the user’s keyboard is smaller, so data input should make use of dropdown menus, pre-populated fields, and tick boxes.
More room for customer error
Payments and transactions processed through mobile are still vulnerable to user mistakes. Even when usability factors are considered and the page is designed to minimise problems, users can still type the wrong details and cause problems for themselves and the business down the line.
49% use their phone one-handed most of the time. The size of a customer’s thumb could vary massively, so touch targets should always be big enough to accommodate everyone. The width of larger mobile devices can mean some users struggle to stretch from one side to the other one-handed, so this can impact their ability to use buttons and menus.
Entering number data with a conventional mobile keyboard can be an annoyance, and the keys are closer together and much smaller. To minimise error, the mobile page or app should automatically convert the keyboard to a number keypad for easier data entry.
Apps can reduce the number of sign-in steps, which makes access easier and quicker for the user. This has to be balanced with tighter security measures, so many banking institutions will make sure the initial set-up verifies the user, but future sign-ins are less time consuming. Iris-scanning technology and fingerprint recognition can make this process even more secure.
Validation for mobile payments
Despite careful user experience and design, payment validation errors are still common. Each failed payment processed through a business could cost £50 in charges, time spent fixing the error, resending costs, and exchange rate fluctuations.
So far, Validate by Apply Financial has saved over £125 million in operational costs for our clients and they’ve never lost a payment. The API validates international IBAN and BIC codes, and the 24/7 dashboard shows real-time volumes by user, currency and country, showing meaningful stats and figures.
Validate is a tool trusted by major international brands and financial institutions, such as HSBC, Barclays, Axa and Easyjet.
Apply Financial’s Validate API uses development tools and real-time analysis to reduce failed payments to zero, and save money for financial institutions and businesses whilst improving the user experience.
Try our Failed Bank Payment Cost Calculator to find out how much your business could be saving in payment errors.