Android pAyFrequently asked questions

June 2015

Android Pay - Frequently Asked Questions

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.

Android Pay - FAQs

page 2

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.

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.

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

Android Pay - Frequently Asked Questions

page 4

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.

Android Pay - Frequently Asked Questions

page 5

Android Pay - Frequently Asked Questions

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.

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

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.

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

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

Android Pay - Frequently Asked Questions

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.

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.

Android Pay - Frequently Asked Questions

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