[MUSIC PLAYING]
RAJIV APPANA: Hi.
My name is Rajiv Appana, and I'm a product lead
on the Google Pay team.
Today, I'm here to share all of the new features we've
been working on since the last time you heard from us.
This year, we're working on tools
to improve transaction security across the payments ecosystem.
We're doing that while also making
things simpler and more rewarding
for our users shopping online with Google Pay.
Later on, I'll share the exciting work
we've been doing to help merchants and developers,
like the introduction of a new model for card ownership
verification and a simpler integration process
for our Google Pay APIs.
Finally, I'll share how we're staying up
to date with the strong customer authentication
standards in the EU and provide a sneak peek
into what users and developers can
expect from Google's new comprehensive digital wallet.
Now, all of the work ties back to our mission
at Google Pay, which is to provide
simple, safe, seamless payment experiences for everyone
everywhere.
But before we start, let's talk about how Google Pay works.
Our product works on a facilitated model.
That means we securely transfers a user's payment credentials
to the merchant.
Merchants, in turn, pass them to the payment service providers
for processing.
Google does not process the payment
and is not involved in moving the money from the customer
to the merchant.
As you already know, the COVID-19 pandemic
has accelerated the shift towards online commerce,
and with it came a large acceleration of online fraud.
Statista estimated e-commerce losses from online payment
fraud reached $20 billion globally in 2021.
That's up over 14% compared to 2020.
It's also one of the reasons we have
made security our top priority and why
I'm most excited to talk to you about our newest
product, virtual cards.
Today we announced virtual cards.
This is a multi-year project that
has us working closely with the online payments ecosystem
to make critical changes to the network infrastructure
tokenization model.
So what are virtual cards?
You might be familiar with autofill on Chrome and Android.
Autofill lets users quickly fill in forms on merchant websites
using data they've already saved securely with Google.
What's unique about virtual cards
is that when they are enabled, we're
able to replace the user's 16 digit card
number with a distinct virtual number during form fill.
This helps reduce fraud in the overall payments ecosystem
while also increasing safety for our users
when they shop online.
With virtual cards, users no longer
have to manually enter any of their card details
at checkout, eliminating a big pain point.
We do that by dynamically generating
the three digit CVV to fill the checkout form without any user
input.
This is possible because whenever a virtual card is
selected at checkout, the network or the issuer
can perform their own risk based authentication.
For example, they can send a code to the user's phone
if they deem the transaction might have a higher
risk of fraudulent activity.
Fortunately, we only expect this kind of step
up to happen in a small minority of cases
so users won't have to reach for their wallet
every time they shop online.
For merchants, this means fewer abandoned carts,
better conversion rates, and higher revenue.
I'm delighted to announce that for users in the US,
Visa issued cards will be eligible for enrollment
starting this summer.
Capital One and American Express cards
will also be eligible at the same time.
Before the start of the holiday shopping
season, Mastercard cardholders should also
be able to take advantage of this feature.
Virtual cards are launching on Chrome for Android and desktop
as well as across all of your Android apps,
but they will soon expand to other services as well.
Getting started is easy.
Users are prompted to enroll right after checking out
with an eligible card.
Finally, we're also making it easier
for users to manage their virtual cards
at pay.google.com.
Here users can enable the virtual card features
for eligible cards, retrieve card details
for their enrolled cards, like the virtual number or CVC,
or even see their most recent virtual card transaction.
Now you're probably wondering, what does all of this
mean for developers?
As long as your website is set up for autofill,
virtual cards will work seamlessly
without any additional change on your end.
However, we do recommend optimizing your checkout form
so that it works well with autofill on Chrome and Android.
To improve the effectiveness of autofill
and ensure a smooth user experience with virtual cards,
make sure your form fields are tagged
with the respective attributes for credit card fields
as well as address fields.
Next, let's talk about some of the other work we're
doing to create more rewarding payment
experiences for our users.
Today, it's difficult to understand the unique benefits
that each of your cards have when you check out,
yet users often have a strong preference
towards a specific form of payment.
For example, many users want to choose
a card that optimizes their travel rewards when
they purchase a plane ticket.
However, in most checkout forms where cards are saved,
users can only identify their card
by the last four digits and the name of the network.
We're making it easier for users to recognize
their preferred payment method at checkout.
We're starting with showing users the card issuer logo
and the name in the autofill experience on Chrome
or Android.
In the future, we will look to provide even more
helpful information about the card benefits such as points,
cash back, and purchase predictions
so our users can make the best choice when
they are checking out.
Moving on, I'm excited to dive deep into how we're improving
security on the Google Pay API with our new model for card
ownership verification.
Today, customers can choose between using
a tokenized or an untokenized card for their transactions.
Non-tokenized cards, also known as FPANs,
are the actual 16 digit account number on the physical card.
When a card is tokenized, an alternate card number
is created.
This token represents the same account number
but simply has a different number than the physical card.
Tokenized cards also have an additional layer of security
in the form of a cryptogram that is generated and then passed
to the merchant.
Google stores both the tokenized and non-tokenized cards
securely in our data bunker where
all data is encrypted before being shared with developers
or their processors.
Now, it's not a secret that there
are millions of card details currently circulating
on the dark web.
So we wondered how could we make transactions even more
secure for our users, especially as an increasing number
of users transact online?
To lower the fraud risk for merchants who use Google Pay,
we're moving to a model where we enforce stricter card ownership
verification up front.
The verification process breaks down the transaction
into a few separate phases.
Once a risk engine identifies the need
to verify a form of payment, the verification decision service
will determine the option that offers the least amount
of friction for the user.
Today, those options are inline tokenization and card OTP.
Starting with inline tokenization,
here's the UX flow of the current card verification
process.
When a customer tries to use a card,
our risk engine first identifies if it needs verification
before the card is used at a merchant.
When prompted, the user will then confirm their card details
and accept the terms and conditions.
Finally, the user chooses one of their available ID&V methods
to confirm their ownership.
Here's the flow for the second option, card OTP.
For reference, the card OTP method
is often used as an alternate or a backup option.
To verify card ownership, a small temporary authorization
is made by Google that carries the OTP code.
The user then logs into their bank account,
retrieves their code, and shares it
with Google to finalize the verification.
The charge is reversed soon after.
Once a card is successfully verified,
the verification status is saved so users
can have a safer, more seamless experience
across the wide variety of merchants
that offer Google Pay.
Next, I'm going to talk about how we're
helping our partners in the EU adjust
to the introduction of the Strong Customer Authentication
requirement, also called SCA.
We have been talking to merchants and developers
to understand how we can help them.
The top questions we hear from developers collecting payments
in Europe are how do I implement a SCA across multiple payment
processors?
How can I tweak the authentication parameters
to minimize user friction?
And well, most importantly, how do I ensure my conversion
rates do not fall?
To address these concerns, Google
Pay leveraged device binding for Android devices.
This allows users to bind their payment information
to their device and verify their credentials with biometrics
or a device PIN.
This extra layer of identity confirmation
helps meet the SCA two-factor authentication rules
while leveraging Android OS features to optimize the user
experience, allowing users to check out
in as little as one click.
This, in turn, helps improve conversion rates for merchants.
Partners who rely on the Google Pay SCA solution
report a positive impact on their checkout success.
You can learn more about the Google Pay SCA
solution at the following link.
Now let's talk about how we are evolving our APIs, tools,
and documentation to support developers
throughout the integration process.
We often hear that our partners rely on multiple payment
processors to comply with local regulations
and provide familiar solutions to customers across the world.
To make the integration with Google Pay APIs quicker
and easier, we created a repository
of open source samples for some of the most popular PSPs.
These samples demonstrate the end-to-end integrations
with each of the PSPs, significantly reducing
integration efforts.
They also demonstrate how you can easily
integrate multiple PSPs with a single surface.
Leveraging the same samples, we also
made the integration easier for Firebase users.
With the Google Pay Firebase extension,
users can configure each of their PSPs
all within the Firebase console.
You can find out more on the link shown on the screen.
In addition to the vanilla SDKs for Android and web,
we have made other libraries available to help
you integrate Google Pay using the stack of your choice.
The Google Pay button component is the easiest way
to integrate Google Pay into your website,
whether your site is built with React, Angular, Vue,
or many other popular networks.
To find out more, visit the link shown here.
If you're developing applications
on multiple platforms with Flutter,
take a look at the pay package in pop.dev
to add payment functionality using pre-built widgets.
You can check out the following link for more information.
And finally, if you work with Android Studio,
you can use the Google Pay template
to access pre-built integration with Google Pay.
Using the Google Pay Wallet Console,
you can take a look at the integration,
update the payment configuration,
get approved as a business, and finally,
switch your integration status to go live on production.
Google Pay has been on a multi-year journey which
started off as a convenient and safe way to pay in store
and online.
Later on, our products grew to hold digital items that
are stored in your physical wallet,
including things like event tickets, boarding passes,
and transit passes.
Earlier today, we were thrilled to announce the Google Wallet.
The Google Wallet allows any user with an Android device
to replace their physical wallet while enabling developers
to securely store and provide easy access to wallet objects
across the Android and Chrome ecosystem.
The Google Wallet will serve as a secure container
alongside Google Pay.
Users can save their payment cards to the Google Wallet
and use them to pay easily and securely anywhere
Google Pay and contactless payments are accepted.
Google Wallet will be rolling out to millions of users
across over 40 countries, and it will be supported
on both Android and Wear OS.
For more details, please check out
the session "Introducing Google Wallet and Developer API
Features."
Well, that is what's new across payments at Google.
We're incredibly excited about the ecosystem
we're building for our users and developers,
and we look forward to bringing you
more of our exciting innovation soon.
Thank you.
[MUSIC PLAYING]