Android pay Frequently asked questions June 2015
Android Pay - FAQs In May 2015, Android Pay was announced by Google. Android Pay is Google s payments solution that allows consumers to do in-store and in-app purchases. Some of the buzz words that are used these days within the payment industry can be found in Android Pay: tokenization, HCE (host card emulation) and fingerprint authentication. The announcement is not a surprise to the industry, given the fact that both Apple and Samsung have announced their respective payment services, Apple Pay and Samsung Pay. The announcements of the different tech giants have injected some very innovative energy into the payment industry. One can say that it has become more or less a show down between Silicon Valley and the traditional payment industry. Apple Pay can be seen as an innovative payment solution, and Samsung Pay is introduced to compete from an OEM point of view. With the arrival of Android Pay it has clearly also become a competition from an OS point of view. With Apple being both the OEM as well as the OS provider, will they have the advantage over Samsung Pay and/or Android Pay? As usual, there were quite some discussions around the announcement of Android Pay, but what do we actually know about it? In the following sections, we try to answer some of the most relevant questions about Android Pay. What is Android Pay? There are different definitions of Android Pay, given the information available today. First of all Android Pay means the Android Pay app (the exact name to be confirmed), which will be available to download via Google play app store. This can be to some extent comparable with Apple s wallet, which was formerly known as passbook. However what is more important is the second definition. When Android Pay was announced by Google, they explicitly mention that Android Pay is not a newer version of the Google Wallet, with new and improved features, but instead it is an open platform. This open platform will be deeply integrated with the next version of the Android OS Android M, including fingerprint authentication as a card-holder verification method. In other words, Android Pay allows existing apps to be NFC-enabled and perform user authentication with your fingerprint. This means that Android Pay, is not only an application, but it is also a platform that is integrated within the operating system. page 2
For payments in brick and mortar shops Android Pay uses industry-standard EMV contactless protocols over NFC. For in-app and remote payments, given the available information today, it is not yet certain that Android Pay will leverage technologies such as DSRP (digital secure remote payment) or if they will simply leverage the credit card registered in the Google Play app store. From a user point of view, Android Pay can be seen as a way to link the funding of one s choices to the Android device, and Android Pay subsequently creates several channels into those funding sources (one called NFC, other one called in-app purchase). All these can be done without dependencies towards external parties such as MNOs/Carriers. One thing to note is that Android Pay will not be the new Google Wallet, as Google Wallet will focus on peer to peer payment functionality. What are the security features provided by Android Pay? When performing NFC payments, Android Pay leverages HCE technology which enables software (apps) to be able to conduct APDU command exchange with POS terminals without the need for a smart card or secure element. However, HCE technology does not dictate where the payment credentials are stored and where payment logic is processed. The cloud based payment technologies of the payment networks are there to fill this gap. In this line of thinking, it is expected that Android Pay will be compatible with the cloud based payment technologies from the payment networks, where limited use payment credentials are generated in the cloud and stored in the app. It is important to point out that although cloud based technologies can work well with Android Pay, it is technically not the only way to enable Android Pay. TEE (trusted execution environment) technology may be another technology to be leveraged by Android Pay. TEE can either be used as a stand-alone storage of the payment credentials, meaning the entire card is stored in TEE or it can be used together with the cloud server to store the limited use credentials. The Android Pay framework is flexible and could allow for future extensions such as TEE. HCE merely enables an app to communicate APDUs, and TEE can be a perfect mean to achieve the remaining goal to have a place where payment credentials can be securely stored. Previously, TEE technologies were not widely used with HCE implementations mainly because of the needs for an agreement between the issuer and the OEM, in order to use TEE. Thanks to the requirements and developments in the DRM (digital rights management)/media domain, a lot of devices in the field are equipped with TEE and more importantly the keys are already provisioned by Google. As a result, the obstacle will not exist for Android Pay. Regardless of the storage location, Android Pay also makes use of tokenization - to be more precise, PAN tokenization. To realize this, Android Pay is connected to the payment networks such as American Express, Discover, Visa and MasterCard and uses their tokenization services. Due to the fact that Android Pay is meant to be an open platform, it is expected that third party token service providers can also enter the market.. Furthermore, Android Pay will use another security measure, which is called 100+ signals. Android has created their own risk engine, which assesses the risks during the process of adding a virtual payment card to Android Pay, or when a transaction will take place. Lastly, Android Pay allows the use of fingerprint authentication when Android M is released. It is expected that all of the above mentioned security mechanisms will apply to both in-store and in-app purchases with Android Pay. page 3
What do we know about Android Pay today regarding user experience? From a user experience point of view, the in-store and remote payment functionality of Android Pay, can be seen as simplicity for consumers. Thanks to the deep integration within the OS, opening the Android Pay app upon payment is no longer required; the user only needs to swipe up in the screen to select a payment card. Thanks to the fact that Android Pay is designed as an open platform, there are no pre-defined enrollment procedures from Android Pay s point of view. It is up to the issuers and third-party payment service providers to decide on how enrollment will take place. For example it is possible for users to enroll with Android Pay from their mobile banking application, which is different from Apple Pay. More importantly, Android Pay allows integrating loyalty transactions into the payment process. When an NFC payment is done loyalty points are automatically redeemed or accumulated in one single tap. How does Android Pay compare to the other Pays, in terms of technology used? When we compare Android Pay, Apple Pay and Samsung Pay, the three mobile payment solutions differ, but also have similarities in terms of technology used. A few key observations are listed below as the most important findings: Starting with the location where the payment credentials are stored. Apple Pay makes use of an embedded secure element. Android Pay uses HCE for APDU and for the command exchange with the POS, and it is part of the operating system. However, Android Pay is flexible such that TEE technology could be used for the storage of the keys, which results in a hybrid implementation which also integrates to the hardware. When comparing the three with respect to POS communications, all three implementations support NFC contactless payments. However unlike Android Pay and Apple Pay, Samsung Pay also supports the legacy magstripe terminal, due to MST technology that Samsung acquired through LoopPay, which can work with the majority of the magstripe terminals, if not all. Therefore, Samsung Pay will have a larger reach in terms of acceptance (especially in the US) for users to pay with their mobile phone, given the fact that there are now (only) 700,000 terminals in the US that support NFC. However, the number of terminals accepting NFC payments is expected to grow rapidly. This growth in NFC acceptance in the US market is based on the on-going migration efforts in this region towards EMV, as well as new suppliers such as Square who are partnering with Apple to provide NFC acceptance to smaller merchants. This increased acceptance of NFC will benefit all of the Pay players, as each can interface to an EMV enabled NFC terminal. page 4
Apple Pay and Android Pay have been designed and marketed as providing both in-store as well as in-app purchases, whilst SamsungPay appears to be primarily focused on the in-store environment where it can make the most use of its magnetic strip emulation to provide differentiation to its competitors. According to Google, Android Pay can already support in-app purchases for Uber, Groupon and other apps. However, it is stated on Android s website that, Android Pay cannot be used for the purchase of digital goods. For digital goods, they require Google Play in-app features. Regarding in-app purchases, it is not yet clear if technology such as DSRP (digital secure remote payment) is used, where an EMV cryptogram is generated and validated by the issuer also for in-app purchases. If this is not used, then this would be a strong and fundamental difference with respect to Apple Pay, since technology such as DSRP allows user to also perform EMV transaction over the internet, which enhances the security level. platform, issuers can also leverage the Android Pay APIs to enable payments from their own mobile application. Moreover, taking into account user authentication, all three implementations are leveraging fingerprint authentication technology. Apple and Samsung are both in control of the payment platform and the hardware, and therefore are better placed to ensure any biometric integration has full coverage. However in the case of Android Pay, this feature will only be available in Android M, meaning that this will not be available in earlier version of Android (4.4 and 5). For these earlier versions a PIN entry is required for authentication. From an enrollment stand point, both Apple Pay and Samsung Pay require users to take a picture of the card or enter their card details in order to enroll. For Android Pay there are more possibilities such as enrollment from a mobile banking application. How does Android Pay compare to the other Pays in terms of user experience? From a wallet point of view both Apple Pay and Samsung Pay require cards to be put in their wallets. This means that for issuers it is no more than putting a card into the wallets. For Android Pay issuers can similarly choose to put their card in the Android Pay app, which provides deeper integration with the OS to enable features such as selecting cards directly by swiping up from the bottom of the screen. Additionally, as Android Pay is an open Looking from a transaction perspective, all three implementations provide quite similar user experiences. The users unlock the screen, tap and pay, and can select the card which they would like to pay with. But Android Pay provides one additional feature, where it is possible to have a transaction completed while a consumer s loyalty points are automatically redeemed or accumulated. In case of Apple Pay, the wallet of Apple will most likely be able to provide the right loyalty card based page 5
on location or other relevant data. A similar experience can only be achieved on the back end (for example when Apple Pay is used to do a credit card payment, one can get the cashback or loyalty deal connected automatically) How does Android Pay compare to the other Pays, in terms of constraints and dependencies? Apple Pay has established relationships with the big payment networks. This means that issuers need to connect to the tokenization services, for example, MasterCard (MDES) or Visa (VDEP/VTS), in order to onboard their cards within Apple Pay. For Samsung Pay and Android Pay this is also an option, but there could be other options to onboard, for example with the issuer s own in-house solution/tokenization service. Moreover, what is known nowadays is that Apple Pay will charge the issuer 0.15 percent of the transaction value, whereas Android Pay will not impose any fee charge towards issuers. These fees are separate from the fees that come together with the tokenization service provided by the payment networks. Regarding Android Pay, because of the open platform, the issuer and user are free to choose the way they would like to implement and use mobile payments. Issuers can choose to leverage the tokenization service from the payment networks in order to connect to Android Pay, or implement their own cloud based payment service in combination with HCE technology. From a device stand point, Apple Pay is only available on the latest Apple products. Samsung Pay is only available on Samsung Galaxy S6 and S6 Edge currently, assuming that the coverage will increase when more devices are released. For Android Pay, the constraints in terms of coverage comes from a different perspective the fragmentation of Android OS. Android Pay will be available for all Android OS version 4.4 and up (with fingerprint authentication only available from Android M and up). As of the 10th of June 2015, the market share of Android 4.4 or up is 51.6% of all the Android devices, which makes the coverage relatively big compared to Samsung Pay. Another potential dependency within this ecosystem is that Samsung depends on Android for the OS and Android will depend on OEM s including Samsung. It is not yet clear if they will be compatible and for example, if Android Pay will be interoperable with handsets from different OEMs remain to be seen and tested. What is the impact from an issuer perspective? For issuers that would like to implement open loop mobile contactless payments using Apple devices, Apple Pay is the only way so far. Up to this point, there is no other option of being a card located in the Apple s wallet. For Android OS, issuers can choose between Samsung Pay for Samsung devices, Android Pay, or their own issuer branded implementation using a cloud based approach together with HCE. Next to this, the issuer can also use hardware based secure element/tee implementations. In order for issuers to make a well informed decision, various factors will need to be taken into consideration: Objective of the mobile payment implementation simply enable payment or a further roadmap Current implementation Market share of device and/or Android OS versions Local payment landscape majority transaction processed by the networks, volume of on-us transactions and local processor Capability of the token service provider Business arrangements between different stakeholders page 6
Obviously, these are only a part of the factors that issuers will need to consider when implementing a mobile payment solution. It is a much more in-depth strategic decision making process, which every issuer should thoroughly go through before implementing a solution. The decisions that are made in this phase are crucial for the roll-out of the solution and to achieve the issuer s technical and business objectives. Given the extended knowledge linked to the technologies, as well as the experience to support within various mobile payment initiatives, UL is able to assist issuers in conducting a situational and scenario analysis, in order to help issuers to make the best informed strategic decisions in such an innovative environment of mobile payments. ABOUT US For more than a century, UL has been one of the most recognized and trusted resources for advancing safety. Its Transaction Security division guides companies within the mobile, payments and transit domains through the complex world of electronic transactions. UL is the global leader in safeguarding security, compliance and global interoperability. Offering advice, test and certification services, security evaluations and test tools, during the full life cycle of your product development process or the implementation of new technologies. UL s people pro-actively collaborate with industry players to define robust standards and policies. Bringing global expertise to your local needs. UL has accreditations from industry bodies including Visa, MasterCard, Discover, JCB, American Express, EMVCo, PCI, GCF, ETSI, GSMA, GlobalPlatform, NFC Forum and many others. page 7 UL and the UL logo are trademarks of UL LLC 2015 All Rights Reserved
Contact details UL Transaction Security Division info@ul-ts.com www.ul-ts.com instagram.com/ultransactionsecurity/ linkedin.com/company/ul-transaction-security twitter.com/ultsnews