visionmobile the evolving state of mobile commerce

TITLE: The evolving state of mobile commerce SUB-TITLE: What mobile developers are looking for from an ever changing industry URL: vmob.me/MobileCommerce

http://vmob.me/MobileCommerce

The Evolving State of Mobile Commerce | © Copyright VisionMobile - Presented by Braintree | All rights reserved | http://vmob.me/MobileCommerce 1

Contents About this report

Key Messages

CHAPTER 1: The State of M-Commerce

CHAPTER 2: Friction-free payments remain the overriding objective

CHAPTER 3: The right payment platform for the right target

audience

CHAPTER 4: What matters most to developers?

CHAPTER 5: Who is collecting the money for what?

CHAPTER 6: The evolving state of m-commerce, June 2016

Methodology

Also by VisionMobile Find out more visionmobile.com/reports

Desktop Developer Segmentation 2016

IoT Developer Segmentation 2016

Cloud Develop

Segmentation 2016 Databoard

Want access to all Premium reports? Get an annual subscription!

About VisionMobile ™ VisionMobileTM are the analysts of the developer economy. We survey 30,000+ mobile, IoT, cloud, and desktop developers each year via our Developer Economics program – and bring you actionable insights and competitive intelligence.

Our mantra: We help the world understand developers – and developers understand the world

VisionMobile Ltd. 90 Long Acre, Covent Garden, London WC2E 9RZ +44 845 003 8742

www.visionmobile.com/blog Follow us on twitter: @visionmobile

Terms of re-use 1. License Grant.

Subject to the terms and conditions of this License, VisionMobile™ hereby grants you a worldwide, royalty-free, non-exclusive license to reproduce the Report or to incorporate parts of the Report (so long as this is no more than five pages) into one or more documents or publications.

2. Restrictions.

The license granted above is subject to and limited by the following restrictions. You must not distribute the Report on any website or publicly accessible Internet website (such as Dropbox or Slideshare) and you may distribute the Report only under the terms of this License. You may not sublicense the Report. You must keep intact all notices that refer to this License and to the disclaimer of warranties with every copy of the Report you distribute. If you incorporate parts of the Report (so long as this is no more than five pages) into an adaptation or collection, you must keep intact all copyright, trademark and confidentiality notices for the Report and provide attribution to VisionMobile™ in all distributions, reproductions, adaptations or incorporations which the Report is used (attribution requirement). You must not modify or alter the Report in any way, including providing translations of the Report.

3. Representations, Warranties and Disclaimer

VisionMobile™ believes the statements contained in this publication to be based upon information that we consider reliable, but we do not represent that it is accurate or complete and it should not be relied upon as such. Opinions expressed are current opinions as of the date appearing on this publication only and the information, including the opinions contained herein, are subject to change without notice. Use of this publication by any third party for whatever purpose should not and does not absolve such third party from using due diligence in verifying the publication’s contents. VisionMobile disclaims all implied warranties, including, without limitation, warranties of merchantability or fitness for a particular purpose.

4. Limitation on Liability.

VisionMobile™, its affiliates and representatives shall have no liability for any direct, incidental, special, or consequential damages or lost profits, if any, suffered by any third party as a result of decisions made, or not made, or actions taken, or not taken, based on this publication.

5. Termination This License and the rights granted hereunder will terminate automatically upon any breach by you of the terms of this License.

Copyright © VisionMobile 2016 - v.1.0

http://vmob.me/MobileCommerceRep

http://www.visionmobile.com/blog/

http://vmob.me/MobileCommerceDesktopSegments

http://vmob.me/MobileCommerceIoTSegments

http://vmob.me/MobileCommerceCloudSegments

http://vmob.me/MobileCommerceDB

http://vmob.me/MobileCommerceSubs


ABOUT THE AUTHORS

Bill Ray Senior Analyst

Stijn Schuermans Senior Business Analyst

Christina Voskoglou Director of Research and Operations

Bill wrote his first mobile app in 1988, and has been failing to make money out of them ever since. He architected set-top boxes at Swisscom and Cable & Wireless, and was Head of Enabling Technology (responsible for on-device software) at UK mobile network O2. He then spent eight years as a journalist at tech publication The Register, before joining VisionMobile as a senior analyst. You can reach Bill at: [email protected] @bill4000

Stijn has been the lead Internet of Things researcher in the VisionMobile team since 2012. He has authored over 20 reports and research notes on mobile and the Internet of Things. He focuses on understanding how technology becomes value-creating innovation, how business models affect market dynamics, and the consequences of this for corporate strategy.

Stijn has a Master's degree in engineering and an MBA. He has over 10 years’ experience as an engineer, product manager, strategist and business analyst.

You can reach Stijn at: [email protected] @stijnschuermans

Christina leads the analyst team and oversees all VisionMobile research and data projects (big or small!), from design to methodology, to analysis and insights generation. She is also behind VisionMobile’s outcome-based developer segmentation model, as well as the Developer Economics reports and DataBoard subscription services. While at VisionMobile, Christina has led data analysis, survey design and methodology for the ongoing Developer Economics research program, as well as several other primary research projects.

You can reach Christina at: [email protected] @ChristinaVoskog


About this report ............................................................. 4

Key Messages .................................................................. 5

The State of M-Commerce ................................................ 6

Friction-free payments remain the overriding objective ........ 8

Whatever happened to operator billing? ...................................... 9

Cryptocurrencies ahoy? ............................................................ 11

The right payment platform for the right target audience

Population .................................................................... 13

How much money is too much? ............................................... 14

A lot of small transactions can make for a big revenue ............... 16

What matters most to developers? .................................... 19

Developer segments and payment processors ............................ 20

Who is collecting the money for what? .............................. 23

The evolving state of m-commerce, June 2016 .................... 25

The demise of CurrentC .......................................................... 25

Uber as a payment platform ..................................................... 27

Mobile authentication for every payment .................................. 28

Methodology ................................................................. 30

TABLE OF CONTENTS


This report looks at how developers are embracing the fast-evolving world of m-commerce, the technologies being used by different segments within the mobile developer community, and the types of applications to which they are being applied. Recent developments, highlighted in the report, demonstrate just how quickly this market is evolving. Even the dominant players find themselves fighting to keep up, and every business model is under attack. The world of m-commerce is changing fast, and it is far from clear when it might settle down, but in the meantime developers need all the information they can get, which is what this report sets out to provide.

Stijn, Mark, Christina, Michael, Christos, Sofia, Matos, Chris and the rest of the VisionMobile team.

ABOUT THIS REPORT


• M-commerce is fast evolving, with new technologies, and applications for old technologies, arriving in rapid succession.

• App store billing is the most prevalent form of m-commerce among developers, used by 53%.

• App store payments are often great for collecting small amounts of money, but transaction costs become unsustainable when the payment amounts rise.

• The aim is always frictionless payments; ease of integration is more important to developers than cost (66% rated integration as important, 53% cost).

• Operator billing, which should be able to provide simplicity for users everywhere, is only popular in the Middle East and Africa (used by 33% of local developers), countries where credit cards aren’t ubiquitous.

• The majority of all m-commerce is aimed at collecting money from consumers rather than businesses or professionals.

• Bitcoin billing for m-commerce is real, but the largest proportion of developers using it (27%) are in North America.

KEY MESSAGES


Data gathered by Mary Meeker shows that 10% of all retail in the US is e-commerce, an increasing proportion of which is mobile. The same data reports that 55% of Pinterest users have used the mobile app to browse for purchases, and numerous other services are looking to cash in on the booming market for peer-recommended shopping.

Digi-Capital reckons that mobile commerce will grow over twice as fast as e-commerce, inflating by $100 billion annually to reach $600bn in 2018. Some of that will be driven by overall retail growth, but e-commerce (and m-commerce) will take an increasing share.

For developers, there have never been more ways to collect money from customers, and the range of options is increasing. Despite the inherent complexity of the process, collecting credit card details is still a popular option, used by 34% of developers engaged in m-commerce. App stores and platform wallets are both enhancing their offerings, in terms of available APIs and deals on offer, to attract developers to their platform.

Emerging competitors are proving that payments aren’t just about transferring money. In China, the Tencent-owned WeChat Pay has taken advantage of its dominant messaging platform to build a customer base, requiring that anyone joining a WeChat (messaging) group bigger than 100 people register a payment card with the service, preventing WeChat from carrying URLs representing payments from competitors, and providing support to developers who want to integrate the service. These initiatives have seen 200 million customers registering with WeChat Pay, resulting in $46m to Tencent from bank transfer fees alone, and the company has only just opened the platform up to foreign merchants.

Tencent used its existing portfolio to build a business around mobile payments, but not every initiative has been so successful. In the last six months we have seen the decline of CurrentC, the US project designed to take mobile payments out of the Visa/MasterCard duopoly, and it won’t be the last standard to fall in the battle for control of mobile wallets.

1 THE STATE OF M-COMMERCE

M-commerce, the process of using a mobile phone to make payments, is growing very rapidly. Most of us have noticed we’re paying for more things with a mobile phone than ever before, and gathered statistics back up that anecdotal evidence.


Central to this battle are the mobile developers, as they make the decisions on which platform they should support and how it should be integrated. Platforms that appeal to developers, like WeChat Pay, will prosper, while those that focus only on the payment mechanism, like CurrentC, will become footnotes in the evolution of the industry.

At VisionMobile, we believe that understanding what developers want is vitally important to many businesses, but perhaps none more so than mobile commerce. In that context, we asked m-commerce developers to tell us what they value, what they use, and what they use it for, and the results are presented here.


Introducing a complex process, such as typing in a credit card number, will put off a certain percentage of customers, and the more complex the process is, the more potential customers are lost.

This is true of anyone trying to do business over the Internet, but for mobile developers the situation is particularly acute. The interface of a mobile phone does not lend itself to entering complex details, and a user with a phone in one hand will struggle to hold a credit card while typing in the identifying details. Browsers, such as Google Chrome, and retailers, such as Amazon, have gone a long way towards simplifying the credit card process (by storing details locally or remotely respectively); however, mobile app developers (and users) still prefer a more-integrated approach.

53% of mobile developers who are using mobile billing are using an App store to process payments. That may be one option amongst many, but more than half of the community has embraced it. App stores offer a familiar user experience and use stored credentials (generally a credit card number, though sometimes a connection to the network operator’s billing platform) to provide a

very seamless experience. They aren’t, however, cheap, with the store generally collecting a 30% processing fee.

Developers are often pushed into using a specific payment system, such as an app store, by the nature of the content they are selling and the rules imposed by the platform owner. Apple is most restrictive, requiring the use of the app store payment system for in-app content. Google also restricts alternative payment mechanisms, but it can only control those used by applications distributed through its Play store. Applications downloaded from other stores, or sideloaded, are generally a minority -- except in China, where the Play store does not function, so alternatives have proliferated – so, in many cases, the platform-owned app store is the only billing mechanism available.

Digital Wallets offer a similar level of simplicity, storing credit card details locally (or in the cloud, or both) so they can be presented without the user having to manually type in the details. Some Digital Wallets (such as Google’s Android Pay) can also be linked to a handset’s NFC connection to make payments in physical stores by

2 FRICTION-FREE PAYMENTS REMAIN THE OVERRIDING OBJECTIVE

Getting users to pay for things remains the biggest challenge for app developers. More than half of mobile developers are living in “app poverty” -- making less than $500 a month from their apps -- so any stumbling block for users on the way towards making a payment means lost revenue.


tapping the handset on the NFC terminal; while not important for developers, this increases the utility of the platform for the end users. For app developers, the Digital Wallets provide a simple integration API with a recognisable logo, making for a very simple user experience without involving the platform app store. It isn’t surprising to see that 43% of developers are using Digital Wallets.

Whatever happened to operator billing? Operator billing should be able to provide a competitive experience to the app store or Digital Wallet. The operator already has a billing relationship with the customer, and will have real-time credit checking as part of its billing system, so it should be able to extend that to support other transactions. For a long time, network operators assumed that they would be the eventual bankers for mobile commerce, culminating in a 2007 statement from the then-CEO of Vodafone Arun Sarin:

"The simple fact that we have the customer and billing relationship is a hugely powerful thing that nobody can take away from us… Whoever comes into the marketplace is going to have to work through us.“

But the network operators repeatedly underestimated their competitors, and despite several attempts to create cross-network payment platforms, we can see that only 16% of mobile developers doing m-commerce are using the billing systems provided by network operators.

That’s a global average, and there are regional disparities. In highly developed markets of the US and Europe, the use of operator billing drops to around 10%, while in the Middle East and Africa it hits 33%.


Credit card ownership is much lower in those regions; in the Middle East cash-on-delivery (COD) is still the preferred option for the majority of consumers. Research from PAYFORT puts the UAE at the top of credit card use in the region, at 39% of online transactions, while in Egypt COD accounted for 72% of e-commerce payments. Developers looking to do business in the region clearly need to think about alternative options. However, the acceptance of credit card payments by mobile app developers isn’t unusual, either because their customer base has credit cards, or they are targeting other national markets.

28% of m-commerce developers working in the Middle East and Africa are taking credit card payments, only a little lower than the 34% global average. The real losers in the region seem to be app stores, which are only used by 33% of local developers, compared to a global average of 53%, which rises to 66% in Europe.

Platform app stores are widely available in the Middle East, but do not operate in all African countries. In some countries, such as Nigeria, Google does operate a store but sets the default currency as US dollars. For developers, this presents an additional level of complexity and an additional cost of doing business, which pushes many of them to use billing platforms provided by local mobile operators.

However, currency does not seem to be an issue in Eastern Europe and Russia, where Google Play also defaults to US Dollars. 69% of m-commerce developers in the region are using the app store billing platform, obviously considering the cost to be worthwhile or creating applications for deployment outside their home market.

Cryptocurrencies ahoy? For developers looking to radically reduce transaction costs there is Bitcoin, accepted by 4% of developers globally. The cryptocurrency is highly unstable, varying widely in value from day to day, or even


hour-by-hour, and while it has generated enormous amounts of press coverage and field-tested some very interesting cryptographic techniques, neither of these can explain why 4% of developers choose to accept Bitcoin payments.

A proportion of Bitcoin users will be developers excited by the idea of a cryptocurrency and wanting to be part of a possible future. Adding a Bitcoin button to a payment gateway isn’t difficult, and makes the app look like it’s at the cutting edge of technology, which might be motivation enough. Bitcoin also has the advantage of being truly international, and incurring no mandatory transaction fees at all. The

value of a Bitcoin might fluctuate, but that fluctuation will often be less than the transaction fee which would have been payable on a more traditional currency.

If transaction and exchange costs were indeed the driving force behind Bitcoin adoption, then we would expect to see it used in developing markets, perhaps where the app stores didn’t operate. Instead we see a higher percentage of Bitcoin users in North America, where the high-tech image may be more of a driver.

Bitcoin is still a minority player in the m-commerce space, but the fact that it appears at all is significant.


Consumers are the largest target market by a considerable margin -- almost three quarters of developers polled, are primarily targeting consumers. 15% of developers using m-commerce are aiming at enterprise customers, while 8% are mostly looking to make money out of professional users and only 3% want to bill internal customers. Within those blocks there is some variation in the billing platforms used, though perhaps not as much as we might expect.

App store billing is most appropriate when the buyers are consumers (56%) or professionals (53%). For enterprise customers, the number drops to 46% and for those targeting internal employees to 32%. The opposite is true for bank service billing: although much less used overall, this option is more popular among developers primarily targeting enterprises and employees.

Enterprise-targeting developers are much more likely than others to use credit cards as a payment mechanism: 45% of them do so, compared to an average of 31% of developers who target other audiences. Meanwhile, direct debit is much cheaper, for the developer, than accepting credit card payments, and the platform is

heavily promoted by banks who prefer to keep their transactions in house. It is also used more in a professional context than as a way for consumers to pay, but with three times fewer developers using it, it is unlikely to replace credit card payments in companies anytime soon.

For developers primarily targeting employees inside companies, Digital Wallets (47%) are the most popular option, far outstripping app store billing and credit card processing.

Enterprises have close billing relationships with their mobile operators, making operating billing a sensible channel for additional services and a valuable option for developers supplying enterprise customers. Indeed, it is professional users and employees who are most likely to be able to pay through the operator as 19% of developers targeting those markets accept operator payments.

Interestingly Bitcoin, is used by 4% of developers across the other targeted markets, jumps to 8% for developers targeting internal employees, which suggests that the cryptocurrency is being used for cross-charging within some companies.

3 THE RIGHT PAYMENT PLATFORM FOR THE RIGHT TARGET AUDIENCE POPULATION

Some platforms lend themselves to specific applications or target audiences, and developers have to take several factors into account when considering which platform to adopt.


How much money is too much? Different platforms are clearly more suited to different transaction sizes and different markets. While payment processors may charge a standard percentage, they may also charge a repeating membership fee or a set charge on every transaction.

That means that 100 transactions of $1 would cost much more than one transaction of $100, so developers selecting a payment platform have to consider the kind of business they are in before they can work out which provider will work best for their business.

If we look at the popular payment platforms we can see a general pattern: smaller transactions are most common across the board, though there are some distinct data points worthy of further examination.

Braintree, for example, is clearly popular with developers processing

transactions between $10 and $50. 23% of developers using Braintree fall into this category, well above the average. Conversely, it seems that Braintree is less popular with those accepting payments of less than $3, as only 18% of the Braintree customer base is dealing with such small sums.

This likely reflects the charging structure used by Braintree, which favours transaction sums of this nature.

Android Pay and Apple Pay, on the other hand, are disproportionately popular with developers dealing with a large number of low-value transactions. 27% of developers using those payment platforms are processing transactions of less than $3; when we look at transactions above $10, we see a clear disparity, with developers using Android Pay, in particular, considerably less likely to be involved.


A lot of small transactions can make for a big revenue One might expect the low value of each transaction to be offset by the quantity of transactions, and to some extent that is happening, but it is more common among users of some platforms than others. If we look at the daily revenue generated by payments on different platforms we can see that while only 27% of developers using Apple Pay raise less than $50 a day, compared to 36% of those using Android Pay.

So Apple Pay and Android Pay are both used extensively, and equally, by developers to process small-value transactions, but more of the developers using Apple Pay are turning that into a decent income. This has little to do with the utility of Apple Pay, or Android Pay, and more to do with the user demographic of the related platforms (iOS and Android). We know that users of Apple devices are generally richer -- the high price of Apple hardware dictates that it appeals to a wealthy demographic -- and more willing to pay for content and services. What we see here is the result of demographic differences in the users of mobile platforms (iOS and Android) rather

than any endorsement of the payment mechanisms offered by the platform owners.

Aside from Apple Pay, it seems that transaction size is a reasonable reflection of daily revenue. 23% of developers using PayPal are processing transactions between $1 and $3, and, sure enough, 35% of them are making less than $50 a day. Conversely, Stripe and Braintree, who have the lowest proportion of developers billing for small amounts, also have the lowest proportion of developers making less than $50 a day. Braintree, in particular, seems to appeal to developers processing a great deal of revenue daily – 18% of those using Braintree report daily revenue of more than $100K.

Android Pay and Apple Pay both fall off quite markedly as the total daily revenue increases, which should be a concern for those companies. Developers who process a lot of revenue will take more time in selecting their payment processor. Braintree, for example, offers significant discounts to high-volume customers, and that seems to be having an impact on the selection process.


66% of developers working in m-commerce cited ease of integration as a critical factor, as they clearly don’t want to be bogged down in the details of transaction processing and the associated security concerns. Being able to swiftly integrate the payment process into their own application is clearly an important consideration.

Integration goes beyond the APIs available; the goal is to provide a smooth experience to the end user. The payment process must be integrated into the app experience in terms of user interface and branding, while providing confidence that the process is being handled by a trusted third party. Maintaining consistency in the interface will avoid the kind of disruption that can prevent a user from making a payment.

After ease of integration comes cost. Still an important factor to more than half of m-commerce developers, cost ranks just above fraud protection and international payments. Responsibility for fraud is a key issue, especially as transaction amounts increase, and different payment mechanisms have different ways of addressing the risk.

PayPal, for example, operates as a merchant aggregator, approving individual merchants with minimal oversight and permitting them to use its account with the processing bank. That makes it easy to use as

a merchant, but it also makes PayPal quick to freeze an account if any suspicious activity is noticed.

International payments are another key driver for developers who want to be able to collect money from customers across the globe. Mobile apps are inherently international, with all the platforms encouraging near-global distribution. As mobile platforms have coalesced into no more than a handful of global standards (or two, if we only consider iOS and Android), the potential market for an application ceases to be regionally limited, so revenue has to be collected from a wide variety of countries. Even where apps are deployed within a specific geography, developers want to ensure they are future proofed against expansion.

Recurring payments are not a high priority for developers, which is perhaps surprising given the steady growth in subscription services. Both Apple and Google have recently modified their app store payment mechanisms to attract developers planning to charge regular subscriptions by cutting the processing fee from 30% to 15% (after the first year in Apple’s case). Apple and Google clearly see a value in appealing to developers searching for recurring revenue. It seems likely that support for such functionality will become more important over time.

4 WHAT MATTERS MOST TO DEVELOPERS?

Cost is clearly an important factor for developers choosing a payment platform, but it is not the most critical. When developers were asked to identify the three factors most likely to make them choose a specific payment processor, ease of integration came out on top.


Right at the bottom we have coupons and discounts, which aren’t important to most developers and don’t necessarily need to be integrated into the payment processing platform. It is possible that such functionality will matter more to the marketing side of an operation, who could be interested in the promotional opportunities it presents, but that is unlikely to be important to the developer and the figures reflect that.

Developer segments and payment processors At VisionMobile, we have found that if we are to understand why developers make specific choices, it is best to start by looking at what they are trying to achieve. Only by knowing the intended destination can we understand how they intend to get there.

By building on years of data gathered in our biannual Developer Economics surveys, we have extracted profiles covering tens of thousands of developers’ aspirations, motivations, challenges, and plans in application development. We produced a unique model of eight developer segments: the Hobbyists, the Explorers, the Hunters, the Guns for Hire, the Product Extenders, the Digital Content Publishers, the Gold Seekers and the Enterprise IT developers.

If we take the popular payment processing platforms and see which segments are using them, some distinct patterns emerge. Hobbyists, being largely unconcerned with revenue, are a minority user of all the platforms; however, it is notable that there are almost as many Hobbyists on Visa Checkout and Braintree (10%) as there are on Apple Pay and Android Pay (11%).

At 36%, Braintree has a disproportionate population of Guns for Hire, though it is worth noting that Stripe is almost as unbalanced with 29% of its customer base falling into that segment. Guns for Hire are freelance developers, working on projects for paying customers who will seek to monetise them later. The Gun for Hire is unlikely to be making revenue from the transactions processed and


will have to create such functionality for multiple customers and (quite possibly) across multiple platforms.

In that context, the preference for processors such as Braintree and Stripe is understandable. The Gun for Hire developer wants to gain experience that can be applied across their customer base, which will likely be across application categories as well as countries, so the developer will recommend the most flexible payment platform available to their customers. This makes Apple Pay and Android Pay the least attractive options; indeed, we see that those platforms have the smallest proportion of Gun for Hire developers.

Gold Seekers, who make up only a small proportion of the developer community (3%, as we observed in our Mobile Segmentation report1), are surprisingly common on WeChat Pay. WeChat Pay is the transaction system attached to the Chinese messaging platform WeChat, allowing peer-to-peer and online payments. The platform only opened to foreign (non-Chinese) merchants in January 2016, but with 697 million active WeChat users, the potential market is clearly attractive to Gold Seekers. 9% of developers using WeChat Pay are Gold Seekers, a third more than are using Alipay, a competitive platform with similar scale and reach. Alipay has been established for longer, but lacks messaging integration, which is considered particularly important for the next generation of mobile payment platforms.

Both Alipay and WeChat Pay also compete in physical sales, providing point-of-sale terminals in shops and businesses to enable pay-by-mobile using on-screen QR Codes. In many cases those payments will not involve an on-device app – the user just selects the product they want and payment is completed using the WeChat app – so this falls outside of our analysis, which is focused on the developer community. In Asia it seems that the physical and digital

1 http://www.visionmobile.com/product/mobile-developer-segmentation-2016/


payment platforms have blurred together more successfully than in the West, perhaps propelled by the early success of FeliCa in Japan. Even in Europe and America, where handset-based NFC payments are used with a special application on the phone, payments are linked to a credit card rather than a generic wallet one could use to pay for both digital content and physical goods bought in a shop.

This will no doubt change over time, as Western users become more comfortable with digital payments. In the meantime, m-commerce payment mechanisms will largely be used to pay for digital goods as we can see when we look at what developers using each payment processor are selling.


For example: we can see that developers who are using Android Pay and Apple Pay are also those most likely to be billing for in-app transactions. We have already noted that collecting revenue for in-app transactions is generally done through the associated app store (this is mandated in the case of iOS apps), so the relationship here is indirect. Developers who choose to use Apple Pay and Android Pay are likely to have gained experience doing in-app transactions and become comfortable working with the platform owners. This is important as competing payment platforms lack this introductory process.

Virtual currencies and feature upgrades are popular amongst those developers as they are likely processing low-value transactions, which we have already noted are disproportionately popular on those platforms.

Over a quarter of developers using Android Pay (26%) are in the business of selling subscriptions, which is important given the importance subscription revenue is likely to assume over the next few years. The contrast with Apple Pay is significant. Apple Pay is ill-suited to the collection of subscription revenue, as Apple would prefer such transactions to go through its App Store process. 20% of developers using Apple Pay are selling subscriptions, which could be

part of the reasoning behind Apple’s decision to cut the transaction charge for subscriptions bought through the Apple App Store.

Stripe has the highest proportion of developers selling subscriptions, at 32%, though Braintree isn’t far behind at 29%, showing that subscriptions are a good market for these card-processing companies. Subscriptions are often relatively high value transactions, especially when repeated, so the lower rates available through these partners are clearly attractive.

Having said that, Braintree is probably the most consistent payment platform, with developers selling services of all types through the service, in fairly even proportions. The flexibility of the platform may be pertinent here, along with the international reach.

We have seen that different payment platforms are being used for all kinds of different applications, and while some platforms may prove more attractive to certain kinds of developer, and for certain kinds of applications, the fact is that almost all the payment processors are processing payments for almost all kinds of transaction. Developers looking to incorporate mobile commerce into their applications have a plethora of options available to them, and the industry is continuously evolving options, both in terms of functionality and business model, to suit every developer.

5 WHO IS COLLECTING THE MONEY FOR WHAT?

Developers were asked which of the popular payment processing companies they used, and this data can be correlated against the type of application they are creating.


Assuming the number corresponded to a Paybox account, the company would phone the payee to request authorisation, the transaction being confirmed by SMS once it had been completed. The system worked, but was cumbersome and never widely adopted, claiming 10,000 retailers Europe-wide, but only half a dozen restaurants, a cinema, and a taxi company in the UK.

One problem has always been the question of responsibility, or, more accurately, ownership. The Mobile Operators always felt that they were natural owners of any m-commerce projects, but were surprisingly reluctant to take any steps in claiming the throne. Banks didn’t really want to get involved, and third parties (such as Paybox) lacked the scale to achieve the market presence necessary for any degree of success. Phone manufacturers would have liked to be involved, but, despite a few very tentative steps from Nokia, they were too concerned about upsetting the mobile operators (who were, after all, their biggest customers).

In recent years, this has changed quite radically. The mobile operators have all but given up any claim to the payment sphere, and the owners of the big mobile platforms (notably Apple and Google) aren’t worried about offending the operators any more. Banks have noticed that faster-moving competitors, such as PayPal, are eating away at their profits, and even MasterCard & Visa feel the need to get directly involved.

In the six months since our last look at the m-commerce industry (“The Commerce Of Things”2), a number of important shifts have taken place in the industry, some of which will have a significant impact on the options available to developers in implementing m-commerce functionality.

The demise of CurrentC In 2012, a consortium of US retailers, including Walmart, 7-Eleven, and Best Buy, announced the Merchant Customer Exchange, or MCX, a new entity which would develop a mobile payment system

2 http://www.visionmobile.com/product/commerce-of-things-2015/

6 THE EVOLVING STATE OF M-COMMERCE, JUNE 2016

In 1999, the first pay-by-mobile service was launched in the UK, under the Paybox brand. This innovative service allowed restaurant customers to pay with a phone number, which the retailer would pass on to Paybox.


bypassing the duopoly of Visa and MasterCard and cutting out mobile platform owners, too. Despite the companies involved having a combined turnover of more than a trillion dollars a year, the project floundered badly, and, in 2016, MCX announced that it was postponing the (US) national deployment of CurrentC indefinitely.

The consortium started out as technology-neutral, but quickly settled on QR Codes as being more universal than the burgeoning NFC technology. In Europe, the ubiquity of NFC credit cards has pushed retailers to upgrade terminals, making it easy to add the functionality to a mobile device. In Asia, however, both WeChat Pay and Alipay

have proved that QR Codes can create a workable user experience. MCX felt that there was a significant advantage in avoiding the need for NFC hardware and the control it would cede.

NFC itself is a near-field radio technology, but when the standard is used for processing payments, it relies on a secure element (SE) for cryptographic authentication. While some network operators have put the SE in a SIM, and phone manufacturers have embedded an SE into their hardware, neither is under the control of the retailers as CurrentC was intended to be.

QR Codes can be used to provide a smooth mobile payment experience, but it requires careful design of the user experience, and trials of CurrentC have not provided the positive feedback that member companies were hoping for. MCX also put pressure on member companies to drop support for alternative payment platforms such as Apple Pay and Android Pay, hoping that stalling the competitors would give CurrentC time to get established.

The purpose of MCX, and CurrentC, was to wrest control of the payment system from the duopoly of Visa and MasterCard, who take a percentage of app transactions processed through their systems. These percentages are typically less than it would cost to handle the equivalent amount of cash, but still represent a cost centre that the retailers would like to reduce. Card processing companies also gather a great deal of customer data on spending habits and disposable income, and as the value of this data is increasingly realised, retailers are further motivated to try and launch alternatives.

Despite extensive trials, and several years of development, CurrentC has stalled as a payment system. In May 2016 MCX announced that the national rollout (originally scheduled for 2015) would be delayed and that the organisation was refocusing on building relationships with existing banks.


MCX CEO Brian Mooney explained at the time:

“Utilizing unique feedback from the marketplace and our Columbus pilot, MCX has made a decision to concentrate more heavily in the immediate term on other aspects of our business including working with financial institutions, like our partnership with Chase, to enable and scale mobile payment solutions. As part of this transition, MCX will postpone a nationwide rollout of its CurrentC application."

It is possible that CurrentC will re-emerge, in some form or another, but what the failure of the initial plan tells us is that even a trillion dollars of annual revenue wasn't enough to shift users away from their existing payment relationships. While users do want to pay with their mobile devices, they want to do so with their existing credit and/or banking cards. Anyone hoping to transition users away from those services will have to provide a very gentle migration path, rather than the "big bang" approach tried by MCX.

Uber as a payment platform One of the most interesting trends in m-commerce is when, by integrating payment into the transaction process, mobile devices become mechanisms for payment without the end users being particularly aware of the change. There are an increasing number of mobile applications whose primary function is to facilitate a service provided by a third party, and many of them collect the revenue as part of that facilitation. For example, Uber is known as a car service, competing with private taxis, but has become a more generic service with the 2014 launch of Uber Eats.

Uber has become the poster child for mobile disruption. As a taxi service, Uber puts drivers willing to carry passengers in touch with passengers looking for a lift, while also setting the price that the passenger will pay and collecting the revenue using stored credit card details. Users are more comfortable dealing with a fixed price set by a third party (Uber), even if tips have become a feature in some markets, and the automated collection of payment makes for a seamless experience where drivers and passengers aren't required to manually handle the transaction.

The lack of contact between driver and passenger is the primary reason for Uber's success in Saudi Arabia, which has (in part) prompted the $3.5bn investment in Uber from the Saudi


government. Women aren't permitted to drive in Saudi Arabia, nor are they allowed to communicate with unmarried men, so booking (and paying for) a taxi has been all but impossible. Using the Uber app a Saudi woman can book, and pay for, a taxi ride without interacting with anyone. Only pre-existing limousine services are allowed to use Uber in Saudi Arabia, so rather than creating a new wave of owner-drivers (as Uber has in other markets) the advantage is the lack of physical interaction between service provider and service user.

That is obviously a very extreme market, but there is a significant demand for similar services covering all kinds of transactions.

With the launch of Uber Eats, the company became more than a car service, offering to arrange the delivery of food and, critically, collecting the revenue from the delivery. By doing so, Uber competes with JustEat and Deliveroo; both specialist services fill a similar role, but Uber brings a very strong brand and the ability to offer an alternative source of revenue for Uber drivers when work is slack. Uber Eats operates in the same way as Uber, setting (and collecting) the delivery price while matching people wanting food with drivers willing to deliver it.

In this way, Uber becomes a facilitation platform that just happens to handle payments.

Mobile authentication for every payment By removing potential blocks to payment, mobile commerce has created a simplified process flow that has increased e-commerce in general. Users of mobile apps are used to being able to make payments seamlessly with only a couple of clicks, which makes web commerce look decidedly dated. Most web commerce is still completed by typing credit card details into a web form, a process that abounds with security risks and puts off potential customers. In June 2016 Apple announced that its mobile payment platform – Apple Pay – would be extended to authorise web-based transactions.

There is an urgent need to improve the web shopping experience; the Baynard Institute estimates that 69% of web-based shopping carts are abandoned before payment, while the adoption of Chip & PIN has made stolen credit card details all but unusable in many regions, forcing criminals to look to online transactions.

The concept of using a mobile handset to authenticate web payments is far from new. Mobile handsets are less vulnerable to attack, and their ubiquity makes them an obvious choice as an authentication token.

Around the turn of the century it was routine for web sites selling valuable information, such as sporting tips or region-unlocking codes for DVD players, to use premium-rate text messaging (SMS) to collect payment. The user visiting the web site would be required to send an SMS to a specific number and receive an unlocking password which could be entered (providing proof of purchase) before the valuable data was released. The passwords were single use, or frequently changed, providing an effective micro-transaction platform in markets where SMS had already become ubiquitous.

The use of smartphone-based two-factor authentication, for which a password and a physical device are both needed before access is granted, is predicated on the idea that mobile devices are as or more secure than their desktop compatriots. Using a mobile device as an authentication system benefits from having two channels of communication, providing additional protection against man-in-the-middle attacks (as two men-in-the-middle are required) and making it harder for an attacker to intercept communications (as two interception points would be needed).

That's not to say that such attacks are unknown. Attacks on banking customers have managed to intercept both the web client and the SMS-based authentication, but such sophisticated attacks are rare; a mobile-based payment system can be extremely secure when combined with traditional security techniques.


In June 2016 Apple announced that it would extend Apple Pay to support any website (though initially limited to customers using Apple's Safari browser). A Safari user, on desktop or mobile, can click on a "Pay with Apple Pay" logo to have their iPhone display an authorisation request. This can be confirmed with a fingerprint or PIN, providing two-factor authentication and integrating with the familiar Apple Pay experience.

Apple Pay is already used as an NFC wallet, capable of hosting credit card details and using them to complete contactless payments in physical stores, as well as transactions within mobile apps, though apps can also take payments through the iTunes App Store. Extending the service into websites will facilitate larger transactions and increase use, though as the service will only be available to users of the Safari browser, adoption will be limited. This limitation is a deliberate decision by Apple, and Apple retains the option to broaden the user base later.

Google's equivalent to Apple Pay, Android Pay, offers the same contactless and in-app functionality as Apple Pay; however, at the time of writing Google has not announced anything comparable to Apple's web transaction service. That being said, there is no technical or legislative reason why Google could not quickly launch a competitive service, and it would be a surprise if it did not.

Having both dominant mobile platforms promoting themselves as the answer to web-based transactions will increase confidence in the idea, and we expect to see rapid adoption once any initial wrinkles have been ironed out. Websites that currently require customers to type in their credit card details will prefer a mobile-authenticated service for simplicity; the enhanced security of two factor authentication should lead to lower levels of fraud and, thus, lower rates of commission.


For the purpose of this report, VisionMobile has done market research around e-commerce, m-commerce and retail banking systems, as well as analysed data from Developer Economics 11th edition, which reached more than 16,500 developers. We have also scanned the market for the most relevant use cases, talked to key players active in the field of m-commerce, and analysed secondary macroeconomic data on the researched markets.

Respondents to the online survey came from over 150 countries, including major app and IoT development hotspots such as the US, China, India, Israel, UK and Russia and stretching all the way to Kenya, Brazil and Jordan. The geographic reach of this survey is truly reflective of the global scale of the developer economy. The online survey was translated into 11 languages (Russian, Vietnamese, Spanish, Chinese (simplified and traditional), Korean, Portuguese, Japanese, French, Indonesian, Italian) and promoted by leading community and media partners within the app development and IoT industry.

Respondents were asked to self-identify as mobile, desktop, IoT or cloud developers, or a combination of those. 84% of the developers polled in the survey are involved in creating mobile applications, 1,986 of whom are using m-commerce platforms. This group is the basis of our analysis throughout this report. We consider everyone

who is involved in the production cycle of a mobile project to be a mobile developer, whether or not they are writing code. This includes team leaders and other decision makers.

To eliminate the effect of regional sampling biases, we weighted the regional distribution across 8 regions by a factor that was determined by the regional distribution and growth trends identified in our App Economy research. Each of the separate branches: mobile, desktop, IoT, and cloud, were weighted independently and then combined.

To minimise the sampling bias for platform distribution across our outreach channels, we weighted the responses to derive a representative platform distribution. We compared the distribution across a number of different developer outreach channels and identified statistically significant channels that exhibited the lowest variability from the platform medians across our whole sample base. From these channels we excluded the channels of our research partners to eliminate sampling bias due to respondents recruited via these channels. We derived a representative platform distribution based on independent, statistically significant channels to derive a weighted platform distribution. Again, this was performed separately for each of mobile, IoT, desktop, and cloud, using targeted vertical markets rather than platforms for IoT or cloud hosting providers.

METHODOLOGY


distilling market noise into market sense