February 3, 2015 by Leave a Comment
Last week Google announced that it will be rolling its email based money transfer system to the UK. The feature was launched about two years ago in the US and allowed those with a Gmail account to hover over a $ sign and add money to an email message like an attachment. It is expected that it would work similarly in the UK, with a $ sign naturally replaced by £. Why now? Why P2P, and not, for example, HCE-based NFC payments, ahead of the expected Apple Pay launch? We admit we don’t have insights into Google strategies (and if we did, we couldn’t blog about it), but here are some of my thoughts. P2P payments has rapidly become a competitive space in the UK. Consumers can already choose between PayPal and other “wallets” or individual bank-based initiatives, such as Barclays’ PingIt and Natwest Pay Your Contacts. Also, last year, Paym, an industry-wide solution was launched in partnership with banks. Paym recently reported having signed up 1.8 million consumers who transferred £26 million. Admittedly, it’s not much yet, but with some banks so far it’s only possible to sign up to receive payments via Paym, but not send. While all these solutions are making more consumers more comfortable with the idea of sending money based on a mobile phone or an email address, at the same time, Google will have to differentiate to stand out from the crowd. One clear differentiator is the email-based approach. While I don’t have specific numbers, my sense is that Gmail is a popular mail service in the UK, and all these customers will now be able to enjoy a new feature. Assuming they like what they see, and start sending money to each other, Google is likely to enjoy increased wallet balances, at least until the recipients are ready to cash out. I also suspect this is a customer acquisition play for Google Wallet, which has not received as much publicity in the UK as it did in the US. Every Google email user can send money, but you do need a Wallet app to accept money. Once Google Wallet establishes a customer base, it can then take on Apple Pay more directly by rolling out its full wallet services to Android users in the UK. With Android representing ~60% share of smartphone users and a growing contactless acceptance infrastructure, the UK market might prove to be an attractive opportunity for Google Wallet.
September 18, 2013 by Leave a Comment
You know the drill – you go into the store, select your goods, and take them to the cashier to check out and pay. What if we flipped the process on its head and you started with a check-in instead? You come to the store and your phone announces your arrival. The merchant knows you are here and is able to communicate with your phone as you move around the store, providing relevant information, such as product details, stock availability and special offers. When you see something you like, you just add it to your virtual shopping basket and when you are done, you simply leave (most likely, after you’ve demonstrated to someone that the contents of your shopping bag correspond to the items in your virtual basket.) What about payment? Well, the payment simply happens in the background based on your registered preferences (e.g. a card). Forget NFC, EMV and other complex buzzwords. We already highlighted this as a potential future scenario in our report on Digital Wallets last year. A number of announcements in the last 10 days or so indicate that this future might be closer than we think. Both Apple and PayPal announced new developments based on Bluetooth Low Energy (BLE) technology, iBeacon and Beacon respectively. The Beacons are essentially small devices that merchants can put around their stores. These devices then use BLE technology to communicate with other devices, such as Bluetooth compatible phones. Their energy consumption is very low and they don’t need Wi-Fi or a phone signal to work. Most excitingly, with built-in micro-location geo-fencing features, Beacons can enable new applications in indoor mapping. For example, iBeacon supports “enter” and “exit” events, so it can send different notifications while entering into the range and exiting out of the range. BLE has been touted for some time as NFC killer, and it’s easy to see how it can replace the NFC payment (NFC in card-emulation mode). Of course, NFC is also simply a communications technology (peer-to-peer mode), so BLE will also be competing with NFC tags. BLE devices are more expensive than NFC tags (~$30-50 vs $0.10), but their communication range is much bigger (up to 50 metres vs ~4cm), so the merchant would need fewer of them. It may be a coincidence, but there were further bad news to the “NFC camp” in the last few days in the US. First, Capital One, one of the three issuers that supported the Isis pilot (Chase and Amex were the other two), announced it would be withdrawing from Isis. Then, Google Wallet announced its new app with many new features, such as P2P payments. The app will be available to all Android phones, including those running on MNOs other than Sprint. While Sprint was the original and the largest MNO partner, Google Wallet has since rolled out to a number of smaller networks, including Virgin Mobile, US Cellular and Metro PCS, so technically it was available to more than one MNO, just not the 3 large giants behind Isis. The new app doesn’t change that – if you want to use NFC payments at the POS, it will still only work with selected handsets on Sprint and those other MNO partners. However, to me this is another indication that Google Wallet is re-focusing its attention on e-commerce, P2P, and other payment use cases, just not physical POS payments. I also thought the announcement on offers was interesting, as the wallet allows the customer to capture the offer irrespective of where it comes from and present it for scanning at the POS. The significant shifts here are the expansion of the universe of available offers and the fact that you don’t need NFC and tapping to get them redeemed, both of which could important catalysts for increased usage of the wallet. Mobile payments never cease to be exciting and interesting. Integration of BLE technology could be a game-changer for the industry.
May 16, 2013 by Leave a Comment
Last week saw a number of important developments at Google Wallet. Let’s recap what we’ve learned:
- Osama Bedier, the Head of Google Wallet, left the company.
- Google Wallet scrapped its plans to introduce a physical card to support purchases at the physical POS.
- Then, at Google I/O Developer conference, the company made a series of announcements about new features, such as:
- Ability to send money to friends with Gmail and Google Wallet.
- Instant Buy Android API designed for merchants and developers selling physical goods and services who are looking to simplify the checkout experience for their customers.
- Storing of payment credentials in Chrome browser to speed up check out online.
- Wallet Objects API to connect any loyalty programs, offers and more to Google Wallet.
- With email payments, Google takes on PayPal, but also many other P2P players, from Popmoney to Dwolla.
- Instant Buy Android API sounds remarkably similar to V.me and other digital wallets designed to help customers fill out their payment and shipping details at a click of a button.
- Leveraging the browser to facilitate check-out reminds me of what Dashlane is offering via its browser API.
- And Wallet Object API is almost a direct take on Apple’s Passbook down to notifications using the location services.
August 2, 2012 by 3 Comments
They say, “imitation is the sincerest form of flattery.” In my report last year I contrasted Google Wallet and PayPal as representatives of two fundamentally distinct approaches seeking to win in the battle to bring mobile payments to the high street. Not anymore – having failed to ignite the market in the first 12 months and its first incarnation, Google Wallet re-launched yesterday with a revised approach, essentially taking a leaf out of PayPal’s book. Unlike PayPal, the “Google Wallet 2.0” will continue to focus on NFC technology. However, instead of storing all the payment credentials on the secure element inside the phone, it is moving most of them into the cloud, leaving inside the phone only a prepaid account, which is based on MasterCard’s PayPass and can be used anywhere where PayPass is accepted. The prepaid account is linked direcly to any of the debit or credit payment cards (MasterCard, Visa, Amex, Discover), which the customers can register themselves, just like they would register a card as a funding source for a PayPal account. More details on the new Google Wallet here. So, what does this mean and who are going to be the winners and losers? It’s early days, of course, but here are some of my preliminary thoughts:
- Consumers, Google and payment networks, especially MasterCard, are likely to emerge as the winners here. Consumers are now in control and can register and manage their cards directly with Google, independent of their banks. They will have to learn to trust Google, which has some work to do to re-establish its image after the initial security concerns. However, as and when consumers come on board, this will be good news for Google and its card partners.
- While Google continues to stick with NFC for the “last mile” technology, MNOs will continue to have a say in this game. However, this set up now lays the ground for Google to potentially decide to bypass the secure element, and the MNOs, in the future altogether.
- The impact on banks is likely to be mixed. Most banks didn’t want to play with Google when it was offering the opportunity to digitalise their payments credentials directly and remain in control of the payments portion of the transaction. Now, while the bank cards will continue to be part of the transcation, they are clearly taking the back seat and will have to deal with Google as a “merchant of record” for their transactions. True, they won’t have to incur the extra costs of provisioning their card credentials on to secure element, but that would also rule them out from participating in other NFC ventures, such as Isis.
- The biggest unknown is the impact on merchants. And that’s because the transaction economics are no longer obvious for Google Wallet and is a question I am most keen to find out more about. In the initial set-up Google was clear that they would not take a cut on the payment transaction and the merchant would have paid a standard fee depending on the card used. Now, from the merchant point of view, they are accepting a prepaid MasterCard, while it might an Amex card that actually funds the transaction. PayPal deals with it by having direct acquiring relationships with its merchants and offering them a discount rate which represents an expected blend of funding transactions. Does it also mean that Google Wallet will have to establish relationships with the acquirers to re-coup from merchants any potential differences in transaction costs? Or will it have to charge the end user for “loading” their wallet, something that other prepaid card providers do for card-based re-load transactions?