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 [email protected] www.ul-ts.com
instagram.com/ultransactionsecurity/
linkedin.com/company/ul-transaction-security
twitter.com/ULTSnews