Easily connect Google Pay with your preferred payment processor

Posted by Stephen McDonald, Developer Relations Engineer, Google Pay

Easily connect Google Pay with your preferred payment processor

Adding Google Pay as a payment method to your website or Android application provides a secure and fast checkout option for your users. To enable Google Pay, you will first need a Payment Service Provider (PSP). For the integration this means understanding how your payments processing stack works with Google Pay APIs.

End-to-end PSP samples

To make integration easier, we’ve launched a new open source project containing end-to-end samples for a range of PSPs, demonstrating the entire integration process – from client-side configuration, to server-side integration with the PSPs, using their respective APIs and client libraries where applicable. The project uses Node.js and is written in JavaScript, which most developers should find familiar. Each of the samples in the project are implemented in a consistent fashion, and demonstrate best practices for integrating Google Pay and your preferred PSP with your website or Android application.

A recent study by 451 Research showed that for merchants with over 50% of sales occurring online, 69% of merchants used multiple PSPs. With these new samples, we demonstrate how you can implement an entirely consistent interface to multiple PSPs, streamlining your codebase while also providing more flexibility for the future.

Lastly, we’ve also added support to both the Web and Android Google Pay sample applications, making it easy to demonstrate the new PSP samples. Simply run the PSP samples project, and configure the Web or Android samples to send their cart information and Google Pay token to the PSP samples app, which will then send the relevant data to the PSP’s API and return the PSP’s response back.

Initial PSPs

To start with, we’ve included support for 6 popular PSPs: Adyen, Braintree, Checkout.com, Cybersource, Square, and Stripe. But that’s just the beginning. If you’re involved with a PSP that isn’t yet included, we’ve made adding new PSPs to the open source project as simple as possible. Just head on over to the GitHub repository which contains instructions on contributing your preferred PSP to the project.

Launching Google Pay for your website

When you’ve completed your testing, submit your website integration in the Google Pay Business Console. You will need to provide your website’s URL and screenshots to complete the submission.

Summing it up

Integrating Google Pay into your website is a great way to increase conversions and to improve the purchasing experience for your customers, and with these new open source samples, the process is even easier.

What do you think? Follow us on Twitter for the latest updates @GooglePayDevs

Do you have any questions? Let us know in the comments below or tweet using #AskGooglePayDevs.

Google OAuth incremental authorization improvement

Posted by Vikrant Rana, Product Manager, and Badi Azad, Group Product Manager


Google Identity strives to be the best stewards for Google Account users who entrust us to protect their data. At the same time, we want to help our developer community build apps that give users amazing experiences. Together, Google and developers can provide users three important ways to manage sharing their data:

  1. Give users control in deciding who has access to their account data
  2. Make it easier and safer for users to share their Google Account data with your app when they choose to do so
  3. Make it clear to users the specific data they are sharing with apps

What we are doing today

In service of that stewardship, today we are announcing an OAuth consent experience that simplifies how users can share data with apps. This experience also improves the consent conversion for apps that use incremental authorization, which requests only one scope. Users can now easily share this kind of request with a single tap.

Screenshot compares the previous screen and the new screen you see when Example app wants to access your account

Previous Screen                                               New Screen

A quick recap

Let’s summarize a few past improvements so you have a full picture of the work we have been doing on the OAuth consent flow.

In mid-2019, we significantly overhauled the consent screen to give users fine-grained control over the account data they chose to share with a given app. In that flow, when an app requested access to multiple Google resources, the user would see one screen for each scope.

In July 2021, we consolidated these multiple-permission requests into a single screen, while still allowing granular data sharing control for users. Our change today represents a continuation of improvements on that experience.

Screenshot that shows the option to select what Example app can access

The Identity team will continue to gather feedback and further enhance the overall user experience around Google Identity Services and sharing account data.

What do developers need to do?

There is no change you need to make to your app. However, we recommend using incremental authorization and requesting only one resource at the time your app needs it. We believe that doing this will make your account data request more relevant to the user and therefore improve the consent conversion. Read more about incremental authorization in our developer guides.

If your app requires multiple resources at once, make sure it can handle partial consent gracefully and reduce its functionality appropriately as per the OAuth 2.0 policy.

Related content

Upcoming security changes to Google’s OAuth 2.0 authorization endpoint in embedded webviews

Posted by Badi Azad, Group Product Manager (@badiazad)

The Google Identity team is continually working to improve Google Account security and create a safer and more secure experience for our users. As part of that work, we recently introduced a new secure browser policy prohibiting Google OAuth requests in embedded browser libraries commonly referred to as embedded webviews. All embedded webviews will be blocked starting on September 30, 2021.

Embedded webview libraries are problematic because they allow a nefarious developer to intercept and alter communications between Google and its users by acting as a “man in the middle.” An application embedding a webview can modify or intercept network requests, insert custom scripts that can potentially record every keystroke entered in a login form, access session cookies, or alter the content of the webpage. These libraries also allow the removal of key elements of a browser that hold user trust, such as the guarantee that the response originates from Google’s servers, display of the website domain, and the ability to inspect the security of a connection. Additionally the OAuth 2.0 for Native Apps guidelines from IETF require that native apps must not use embedded user-agents such as webviews to perform authorization requests.

Embedded webviews not only affect account security, they could affect usability of your application. The sandboxed storage environment of an embedded webview disconnects a user from the single sign-on features they expect from Google. A full-featured web browser supports multiple tools to help a logged-out user quickly sign-in to their account including password managers and Web Authentication libraries. Google’s users also expect multiple-step login processes, including two-step verification and child account authorizations, to function seamlessly when a login flow involves multiple devices, when switching to another app on the device, or when communicating with peripherals such as a security key.

Instructions for impacted developers

Developers must register an appropriate OAuth client for each platform (Desktop, Android, iOS, etc.) on which your app will run, in compliance with Google’s OAuth 2.0 Policies. You can verify the OAuth client ID used by your installed application is the most appropriate choice for your platform by visiting the Google API Console’s Credentials page. A “Web application” client type in use by an Android application is an example of mismatched use. Reference our OAuth 2.0 for Mobile & Desktop Apps guide to properly integrate the appropriate client for your app’s platform.

Applications opening all links and URLs inside an embedded webview should follow the following instructions for Android, iOS, macOS, and captive portals:


Embedded webviews implementing or extending Android WebView do not comply with Google’s secure browser policy for its OAuth 2.0 Authorization Endpoint. Apps should allow general, third-party links to be handled by the default behaviors of the operating system, enabling a user’s preferred routing to their chosen default web browser or another developer’s preferred routing to its installed app through Android App Links. Apps may alternatively open general links to third-party sites in Android Custom Tabs.

iOS & macOS

Embedded webviews implementing or extending WKWebView, or the deprecated UIWebView, do not comply with Google’s secure browser policy for its OAuth 2.0 Authorization Endpoint. Apps should allow general, third-party links to be handled by the default behaviors of the operating system, enabling a user’s preferred routing to their chosen default web browser or another developer’s preferred routing to its installed app through Universal Links. Apps may alternatively open general links to third-party sites in SFSafariViewController.

Captive portals

If your computer network intercepts network requests, redirecting to a web portal supporting authorization with a Google Account, your web content could be displayed in an embedded webview controlled by a captive network assistant. You should provide potential viewers instructions on how to access your network using their default web browser. For more information reference the Google Account Help article Sign in to a Wi-Fi network with your Google Account.

New IETF standards adopted by Android and iOS may help users access your captive pages in a full-featured web browser. Captive networks should integrate Captive-Portal Identification in DHCP and Router Advertisements (RAs) proposed IETF standard to inform clients that they are behind a captive portal enforcement device when joining the network, rather than relying on traffic interception. Networks should also integrate the Captive Portal API proposed IETF standard to quickly direct clients to a required portal URL to access the Internet. For more information reference Captive portal API support for Android and Apple’s How to modernize your captive network developer articles.

Test for compatibility

If you’re a developer that currently uses an embedded webview for Google OAuth 2.0 authorization flows, be aware that embedded webviews will be blocked as of September 30, 2021. To verify whether the authorization flow launched by your application is affected by these changes, test your application for compatibility and compliance with the policies outlined in this post.

You can add a query parameter to your authorization request URI to test for potential impact to your application before September 30, 2021. The following steps describe how to adjust your current requests to Google’s OAuth 2.0 Authorization Endpoint to include an additional query parameter for testing purposes.

  1. Go to where you send requests to Google’s OAuth 2.0 Authorization Endpoint. Example URI: https://accounts.google.com/o/oauth2/v2/auth
  2. Add the disallow_webview parameter with a value of true to the query component of the URI. Example: disallow_webview=true

An implementation affected by the planned changes will see a disallowed_useragent error when loading Google’s OAuth 2.0 Authorization Endpoint, with the disallow_webview=true query string, in an embedded webview instead of the authorization flows currently displayed. If you do not see an error message while testing the effect of the new embedded webview policies your app’s implementation might not be impacted by this announcement.

Note: A website’s ability to request authorization from a Google Account may be impacted due to another developer’s decision to use an embedded webview in their app. For example, if a messaging or news application opens links to your site in an embedded webview, the features available on your site, including Google OAuth 2.0 authorization flows, may be impacted. If your site or app is impacted by the implementation choice of another developer please contact that developer directly.

User-facing warning message

A warning message may be displayed in non-compliant authorization requests after August 30, 2021. The warning message will include the user support email defined in your project’s OAuth consent screen in Google API Console and direct the user to visit our Sign in with a supported browser support article.

A screenshot showing an example Google OAuth authorization dialog including a warning message: To help protect your account, Google will soon block apps that don't comply with Google's embedded webview policy. You can let the app developer (moo@gmail.com) know that this app should stop using embedded webviews

Developers may acknowledge the upcoming enforcement and suppress the warning message by passing a specific query parameter to the authorization request URI. The following steps explain how to adjust your authorization requests to include the acknowledgement parameter:

  1. Go to where you send requests to Google’s OAuth 2.0 Authorization Endpoint. Example URI: https://accounts.google.com/o/oauth2/v2/auth
  2. Add an ack_webview_shutdown parameter with a value of the enforcement date: 2021-09-30. Example: ack_webview_shutdown=2021-09-30

A successful request to Google’s OAuth 2.0 Authorization Endpoint including the acknowledgement query parameter and enforcement date will suppress the warning message in non-compliant authorization requests. All non-compliant authorization requests will display a disallowed_useragent error when loading Google’s OAuth 2.0 Authorization Endpoint after the enforcement date.

Related content

A conversation with Hebe He, a developer from Guangzhou

Posted by Brian Shen, Program Manager, Google Developers

Google Developer Groups are one of the largest community networks of developers in the world. Every group has an organizer that helps curate events based on the interests of their local developer community.

As we continue to explore how different Google Developer Groups build their communities, we interviewed Hebe He, an organizer of Google Developer Group Guangzhou in China. Learn more about how she is building the developer scene in China, thinking up new events for her community, and more below.

Hebe He, an organizer of Google Developer Group Guangzhou in China.

Hebe He, an organizer of Google Developer Group Guangzhou in China.

Tell us about yourself.

I am Hebe from China and I’m a native of Guangzhou. I’m the organizer of GDG Guangzhou, as well as an ambassador for Women Techmakers (WTM). I work at one of China’s new electric-vehicle brands, where I’m responsible for the intelligent business operation of the Internet of Vehicles. I’m relatively outgoing and active, so I really like to deal with different people, whether it’s at work or in other activities.

How did you learn about Google Developer Groups?

In 2014, I participated in GDG Guangzhou DevFest for the first time by coincidence and met the founder of GDG Guangzhou. Afterward, I joined the founder’s company and volunteered at many GDG programs. In 2017, I officially became an organizer after the existing organizers recognized my ability and desire to contribute more to the GDG Guangzhou community.

Tell us more about Guangzhou and the developer community there.

Our community members are talented, passionate, and amazing. I see all kinds of possibilities in them. They’re always excited for every event we hold, keep a fanatical attitude toward Google’s technological innovation, and are particularly interested in Android, Kotlin, and Flutter.

What are events like in your community?

We highly value feedback from event participants, who are interested in a wide range of topics. For this reason, we generally use 15% of every event to cover non-technical topics, such as entrepreneurship, business management, and careers. For more comprehensive activities, such as DevFest, we increase the amount of non-technical content to roughly 30%.

What is your Google Developer Group focused on right now?

We devote most of our energy to improving the quality of activities. We try to add more elements to the event to strengthen the interaction of participants in hopes of improving the feedback mechanism and gaining more valuable suggestions for future event optimization. We also try to improve the quality of guests and themes, and pay more attention to event details, such as event announcements, registration, and check-in.

What’s your favorite community memory from a Google Developer Group event?

The memory that touches me the most is the construction of WTM Guangzhou. From the first event with only 80 developers to the audience of more than 500 people in recent years, it represents the recognition of, and support for, our events. There are many people who come to participate every year; some are actively encouraging their friends to participate and others are even urging us to hold events. They feel honored to be invited to our events and their enthusiasm endured during the pandemic.

What’s next for you and your Google Developer Group?

There’s still lots of room to grow in our community. We hope that we can continue to develop a Google Developer Group that reflects the best of Guangzhou. We also hope to find better ways to accumulate the experience shared by speakers and the value of community users.

If you want to grow your career and coding knowledge with people like Hebe He, join a Google Developer Group near you.

Updated Google Pay app offers more consumer touchpoints

Posted by Soc Sieng, Developer Advocate, Payments & Ola Ben Har, Payments DevRel Lead

What's new in Google Pay header

We redesigned the Google Pay app to boost user engagement with your business.

The redesigned app makes it easy for users to find your business and provides you with a branded surface that lets you build relationships with your customers at scale.

The app is available in the App Store and Google Play Store in the US, India, and Singapore with availability in more markets on the way. In this blog post, we focus on features available in the US version of the app.

New in Google Pay

The Google Pay app focuses on users’ relationships with people, businesses, and other everyday essentials.

Centers around your relationships

The app lets users send money, save money, and see spending insights.

Understand and organize money

It makes it easy for users to save money at their favorite businesses and discover new ones.

Save money and discover businesses

It also provides your brand with another surface to initiate meaningful reengagement with your customers. The branded experience is automatically created when customers check out with Google Pay or a Google Pay-enrolled card in the app, in stores, or online. This dedicated space for your business is also where customers can redeem offers, sign up for loyalty rewards, and view their transaction histories.

Branded experience

How it works

Google Pay’s new features are only part of the story.

Behind the scenes, we worked on the Google Pay APIs and developer tools to enable those experiences, help you acquire new customers, and better serve existing ones.

Google Pay APIs for Web and Android

Google Pay APIs for Web and Android enable your transaction history within your branded experience on Google Pay in addition to contactless payments in store. After a user makes a purchase with Google Pay or a Google Pay-enrolled card, they can search for your brand and view their transaction history in Google Pay.

Two phones showing inside your app and inside google pay

When you integrate with the Google Pay APIs, you’re not only providing a convenient and secure checkout option in your app or on your website, but you also let your users track their transactions, independent of the channel, in one central place. Your brand becomes searchable for millions of active Google Pay users, which provides you with more reengagement opportunities.

Loyalty Enrollment and Sign-in API

The Loyalty Enrollment and Sign-in API lets users discover, and sign up or sign in to your loyalty program from your branded experience with a few taps in Google Pay.

Loyalty enrollment and sign-in API

When users sign up, they provide their consent and Google Pay securely shares sign-up details with your loyalty program’s sign-up process. They can use information that they already saved to their Google Accounts, which makes the sign-up process a snap. Afterward, users can easily access their loyalty passes at checkout.

4 phones

That does it for now, but these updates are only the beginning, so stay tuned for more news in this space!

Learn more

Want to learn more about Google Pay? Here’s what you can do:

Google Pay introduces a Flutter plugin for payments

Posted by Jose Ugia, Developer Programs Engineer, Google Pay and Anthony Panissidi, Technical Writer, Google Developer Studio

Flutter and Firebase logos

We made it easier than ever to integrate Google Pay in Flutter apps!

Our open source Flutter plugin simplifies the addition of payments to Flutter apps on iOS and Android.

The plugin gives you the ability to add functionality to your apps across platforms with a single and familiar codebase written in Dart.

It adapts common steps required to facilitate payments that adhere to how Flutter constructs components, works with the user interface of the app, and exchanges information between the native and Dart ends.

Now, as a Flutter developer, you can easily reap the benefits of Google Pay, which lets you provide users with a secure and fast checkout experience that increases conversions, and frees you from the need to manage credit cards and payments.

How it works

To use the plugin, add pay as a dependency in your pubspec.yaml file. For more information, see Adding a package dependency to an app.

To configure a payment, load a payment profile with the desired configuration, either with a local file or one retrieved from a remote server. For a complete list of all configuration options, see the PaymentDataRequest object.

Here’s an example of a JSON file that defines payment options:


"provider": "google_pay",
"data": {
"environment": "TEST",
"apiVersion": 2,
"apiVersionMinor": 0,
"allowedPaymentMethods": [{
"type": "CARD",
"tokenizationSpecification": {
"parameters": {
"gateway": "example",
"gatewayMerchantId": "gatewayMerchantId"
"parameters": {
"allowedCardNetworks": ["VISA", "MASTERCARD"],
"allowedAuthMethods": ["PAN_ONLY", "CRYPTOGRAM_3DS"],
"billingAddressRequired": true,
"billingAddressParameters": {
"format": "FULL",
"phoneNumberRequired": true
"merchantInfo": {
"merchantId": "01234567890123456789",
"merchantName": "Example Merchant Name"
"transactionInfo": {
"countryCode": "US",
"currencyCode": "USD"

For more examples of JSON files that define payment options, take a look at the example/assets/ folder.

Now you can use this configuration to add the Google Pay button to your app and forward the payment method selected by your users.

Here’s an example of a Dart file:

import 'package:pay/pay.dart';

const _paymentItems = [
label: 'Total',
amount: '99.99',
status: PaymentItemStatus.final_price,

// In your Widget build() method
paymentConfigurationAsset: 'sample_payment_configuration.json',
paymentItems: _paymentItems,
style: GooglePayButtonStyle.black,
type: GooglePayButtonType.pay,
onPaymentResult: onGooglePayResult,

// In your Stateless Widget class or State
void onGooglePayResult(paymentResult) {
// Send the resulting Google Pay token to your server or PSP

How to use it

The best part of this news is that you can use the plugin today. To get started with it, check out the pay package on pub.dev.

[Insert screenshot of package when live]

We also want to hear your thoughts and feature requests, and look forward to your contributions on GitHub.

[Insert screenshot of GitHub page when live]

Learn more

Want to learn more about Google Pay? Here’s what you can do:

Updated Google Pay button increases click-through rates

Posted by Soc Sieng, Developer Advocate, Google Pay

Google Pay header

An improved Google Pay button works wonders for click-through rates and the checkout experience.

The updated Google Pay button displays a user’s card information, which makes the user 30% more likely to use it and increases conversions by 3.6%.

The display of the card’s type and last four digits reminds the user that they already saved a payment card to their Google Account, which makes them more likely to opt for the quick and easy checkout process that Google Pay provides.

How it works

If a user configured an eligible payment method in their Google Account at the time of purchase, the Google Pay button displays the type and last four digits of their most-recently used card.

Dynamic Google Pay button

Figure 1. An example of the Google Pay button with the additional information.

Buy with Google Pay button

Figure 2. An example of the Google Pay button without the additional information.

How to enable card information

If you use the createButton API with default button options, your Google Pay button is automatically updated to include the user’s card network and last four digits.

If you customized the createButton API and set buttonType to plain or short, set it to buy to make your Google Pay button display the user’s card information.

If you haven’t integrated with the createButton API yet, consider doing so now so that the user knows that their payment details are a click away.

See it in action

To test the Google Pay button with other button options, check out this button-customization tool:

Next steps

To get started with Google Pay, visit Google Pay’s Business Console. Make sure to use the createButton API to benefit from the new features. If you have any questions, tweet @GooglePayDevs on Twitter and use #AskGooglePayDevs.

Everything Assistant at I/O

Posted by Mike Bifulco

Google I/O banner

We’re excited to host the first ever virtual Google I/O Conference this year, from May 18-20, 2021 – and everyone’s invited! Developers around the world will join us for keynotes, technical sessions, codelabs, demos, meetups, workshops, and Ask Me Anything (AMA) sessions hosted by Googlers whose teams have been hard at work preparing new features, APIs, and tools for you to try out. We can’t wait for you to explore everything Google has to share. Given the sheer amount of content that will be shared during those 3 days, this guide is meant to help you find sessions that might interest you if you’re interested in building and integrating with Google Assistant.

With that in mind, here’s a rundown of everything Assistant at Google I/O 2021:

Keynote: What’s New in Google Assistant (register)

We’ll kick off news from Assistant with our keynote session, which will be livestreamed on May 19th at 9:45am PST. Expect to hear about what’s happened in Assistant over the past year, new product announcements, feature updates, and tooling changes.

Keynote: What’s New in Smart Home (register)

In celebration of Google Assistant’s 5th birthday, we’ll share our Smart Home journey and the things we’ve learned along the way. We’ll also dive into product vision, new product announcements, and showcase great Assistant experiences built by our developer community. Catch the Smart Home keynote on May 19th at 4:15pm PST.

Technical Sessions

Technical sessions are 15 minute deep dives into new features, tools, and other announcements from product teams. These 4 sessions will be available on demand, so you can watch them any time after they officially launch during the event.

Driving a Successful Launch for Conversational Actions (register)

In this session, we’ll discuss marketing activities that will help users discover and engage with what you’ve built on Google Assistant. Learn some of the basics of putting together a marketing team, a go-to-market plan, and some recommended activities for promoting engagement with your Conversational Actions.

How to Voicify Your Android App (register)

In this session, you’ll learn how to implement voice capabilities in your Android App. Get users into your app with a voice command using App Actions.

Android Shortcuts for Assistant (register)

Now that you’ve added a layer of voice interaction to your Android app, learn what’s new with Android Shortcuts and how they can be extended to the Google Assistant.

Refreshing Widgets (register)

Widgets in Android 12 are coming with a fresh new look and feel. Come to this session to learn how you can make the most of what’s coming to Widgets, while also making them more useful and discoverable through integrations with Assistant and Assistant Auto.

Ask Me Anything (AMA)

AMAs are a great opportunity for you to have your questions fielded by Googlers. If you register for I/O, you’ll be able to pre-submit questions to any of these AMAs. Teams of Googlers will be answering audience questions live during I/O. All AMA sessions will be livestreamed at specific dates and times, so be sure to add them to your calendar.

App Actions: Ask Me Anything

May 19th, 10:15am PST (register)

This is the place to bring all of your burning questions about App Actions for Android. Our App Actions team will include Program Managers, Developer Advocates, and Engineers who are looking forward to answering your questions. Maybe you’re building an app which uses Custom Intents, or you’ve got questions about some of the new feature announcements from our Technical Sessions (see above!) – the team is looking forward to helping.

Games on Google Assistant: Ask Me Anything

May 19th, 11:00pm PST (register)

Join a panel of Googlers to ask your questions about building Games with Google Assistant. Our team of Product Managers and Game developers are here to help you – from designing and building games, to toolchain questions, to figuring out what types of games people are playing on their smart devices.


This year, our workshops will be conducted online via livestream. Each workshop will be led by a Googler providing instruction alongside a team of Googler TAs, who will be there to answer your questions via live chat. Workshops will show you how to apply the things you learn at I/O by giving you hands-on experience with new tools and APIs. Each workshop has limited space for registrations, so be sure to sign up early if you’re interested.

Extend an Android app to Google Assistant with App Actions

May 19th, 11:00am PST (register)

Learn to develop App Actions using common built-in intents in this intermediate codelab, enabling users to open app features and search for in-app content, with Google Assistant.

Debugging the Smart Home

May 19th, 11:30pm PST (register)

Improve your products’ reliability and user experience with Google’s new smart home quality tools in this intermediate codelab. Learn how to view, analyze, debug and fix issues with your smart home integrations.


Women in Voice Meetup

May 20th, 4:00pm PST (register)

This meetup will be a chance for developers to share influential work by women in Voice AI and to discuss ways allies can help women in Voice to be more successful while building a more inclusive ecosystem.

Smart Home Developer Meetup

[Americas] May 18, 3:00pm PST (register)
[APAC] May 19th, 9:00pm PST (register)
[EMEA] May 20th, 6:00am PST (register)

This meetup will be a chance for developers interested in Smart Home to chat with the Smart Home partner engineering team about developing and debugging smart home integrations, share projects, or ask questions.

Register now

Registration for Google I/O 2021 is now open – and attending I/O 2021 is entirely free and open to all. We hope to see you there, and can’t wait to share what we’ve been working on with you. To register for the event, head over to the Google I/O registration page.

How online payments work with Steve Klebe

Posted by Jose Ugia and Steve Klebe

intro to online payments

Steve Klebe forms partnerships that drive adoption of Google Pay. He’s spent the last 9 years working for the Google Payments Business Development team, and possesses more than 40 years of experience with products and services related to payment processing, data security, and authentication.

Recently, Steve sat down for an interview with Jose Ugia, a Developer Relations Engineer on the Google Pay team.

Read the interview transcript for a deep overview of online payments.

Jose Ugia: Let’s get started with the basics. What is the typical sequence of events in processing an online credit-card payment?

Steve Klebe: This can happen in a few different ways, but let’s talk about the typical series of events:

  1. A consumer visits the merchant’s website or application, and they need to pay for the items that they want to purchase.
  2. The merchant then presents an order form to the consumer with a variety of payment options, including Google Pay. The consumer presses the Google Pay button, and the information that’s associated with the card that the consumer chooses to pay with is securely sent to the merchant.
  3. The merchant calls the payment processor. The processor receives the request from the merchant and uses a shared key to decrypt the information in it in the payment service provider’s secure environment.
  4. The payment processor interacts with the network that’s associated with that particular card, such as Visa, Mastercard, American Express, or Discover. Although, there are variations of networks around the world.
  5. The network consults the issuing bank, and the issuing bank checks the account to verify that it’s active and valid. If there are funds available to cover the transaction, then the transaction is approved.

The approval triggers a response chain. The network responds to the payment processor, the payment processor responds to the merchant, and the merchant responds to the consumer with something like, “Your payment has been accepted!”

This sequence of events happens in approximately 2 seconds, during which the transaction passes through multiple different systems in order to deliver a response to the consumer.

Jose Ugia: Most developers and businesses don’t think about these steps. When you think about chargebacks and fraud, this information is especially useful.

The next question is related to a concept that goes by many names in the industry. It’s what we call a PSP or payment service provider, but others refer to it as a payment processor, payment provider, or payment gateway. What is this concept and why are there so many different terms for it?

Steve Klebe: Things evolve and sometimes different entities in the ecosystem create their own terms to differentiate themselves. It’s a big challenge in the payments industry; there are many terms for the same concepts.

The term PSP has an official meaning in the ecosystem, and it can represent companies that take on different roles in the payment sequence, which I outlined in the first question. However, we kept things simple for our merchant and developer partners. PSP defines the initial link between the merchant and the network, regardless of their roles. The role of the PSP is to make sure the merchant is legitimate and categorize the merchant as a retail store, restaurant, or something else.

The PSP is the entity through which the money flows, from the card issuer through the networks to the PSP. They provide consolidated reporting to the merchant and—most people don’t realize this—they also often hold the financial responsibility. If the merchant is fraudulent or goes out of business and there are lingering transactions, the PSP assumes financial responsibility for the merchants.

Jose: So, if I’m planning to accept payments online, do I need a PSP?

Steve Klebe: Yes, you absolutely need to have a PSP, but it doesn’t matter to you as a merchant if the PSP is an official processor or a licensed agent of a processor.

Jose: Are there specific considerations that I have to account for as a merchant or developer when I choose a PSP to process credit-card payments?

Steve Klebe: Sometimes it’s tied to the shopping cart of your e-commerce platform, most of which embed one or more PSPs into their systems. Sometimes, the decision has been made for you. Other times, you have flexibility to choose whatever you want. Different PSPs have different expertise in different types of payments. For example, if you’re a merchant who focuses on a subscription model, there are certain PSPs who handle these types of payments better than others. If you’re going to sell globally, you need to pick a PSP with the maximum ability to support alternative payment methods from other countries. If you’re a restaurant and you need to do in-store and online payment processing, not all PSPs are equal in their ability to support different types of channels.

So, do some research, talk to peers in your industry to find out who they use and whether they’re satisfied, and make an intelligent choice. It can have fairly significant consequences if you need to do online ordering, but you picked a PSP who is competent at in-store purchases and doesn’t take e-commerce seriously.

Jose: Are you suggesting that I might need to integrate multiple PSPs to cover different scenarios?

Steve: Yes. Using multiple PSPs is not unusual. If you need to cover different scenarios, such as subscription payments, in-person payments, or online payments then this can be very common. If you need to change your PSP, it can affect you later. Your PSP choice becomes intertwined with your back-office operations and fulfillment. It’s not just an API; it becomes integrated into all aspects of the business supply chain, including customer servicing, revenue recognition, etc. and switching isn’t easy.

Jose: I’ve seen some PSPs offering something called “hosted checkout”. How does that differ from a regular integration in my website or application?

Steve Klebe: There are typically two approaches: you integrate your PSP’s API and you as the merchant typically control the checkout process directly with the consumer. In the case of Google Pay, you can add the Google Pay button to your checkout pages. That’s typically used by medium-to-large merchants, while smaller merchants tend to gravitate towards this concept called a hosted order page, which has some limitations because the checkout occurs on a page that the PSP hosts and different PSPs have different hosted-order-page capabilities.

If you’re an API merchant, for your non-Google Pay transactions you have a responsibility to protect the card information of your customers. With a hosted order page, all the sensitive information is being hosted on a page from the PSP. The penalties for having card information stolen from your servers are very severe, so hosted order pages are popular, flexible, and customizable.

In Europe, hosted checkouts are popular because commerce is complicated with more than 20 countries, different currencies, and payment methods. A US merchant could survive with a much simpler array of payment options if the merchant plans to only sell within US borders.

We work with most major PSPs globally and have them implement Google Pay as a default option for hosted checkouts. Usually, this is enabled by default but the PSP gives the merchant a choice to opt out.

Jose: What are e-wallets, digital wallets, and other payment facilitators, and how do they differ from a PSP.

Steve Klebe: There are a lot of acronyms, and they can start blending together and sounding the same to someone new to the space. The metaphor for a digital wallet was originally developed to represent that whatever is in your physical wallet would ultimately be in your digital wallet. While PSPs facilitate online transactions, digital wallets are a form of payment. There are many benefits to offering a digital wallet like Google Pay. One of the most obvious being the ability for customers to checkout quickly, without needing to re-enter credit card and billing information for every single transaction .

In the case of Google Pay, you can store loyalty cards, boarding passes, payment cards, and receipts in your digital wallet and use it to transact in physical stores, online websites and applications alike. The metaphor has played out, but there are a lot of differences within the broad category of alternative payment methods and digital wallets.

Those differences are evolving. Today, we have Google Pay, Apple Pay, PayPal, Samsung Pay, WeChatPay, Alipay and others. In some cases, the app or the account is only a container for credentials. In other cases, it’s the account of record for your money. For example, in Asia, you see the popularity of Alipay and WeChat Pay, which are actually like bank accounts. In India, the Google Pay for India app connects directly to the consumer’s bank account, and initiates the movement of money to the merchant’s bank account.

Jose: What is a tokenized card and how does it affect online transactions?

Steve Klebe: The word tokenization is a loaded word in our industry and it creates a bunch of confusion. Tokenization and encryption (which are sometimes confused) came about because of the growing popularity of cards, and the growing use and misuse of cards by people with good and bad intentions.

The concept of exchanging a card number with a token is applied by various parties at different stages of an online transaction:

Tokenization, at the network level, came about after the industry established a standard for protecting card data that’s now referred to as PCI, which is an industry consortium funded by the major card brands that established a single standard for security.

Similarly, to assist merchants with complying with PCI, most PSPs came up with a proprietary scheme to take the card number from the merchant and give the merchant a token or reference number. The PSP, within its secure environment, would hold the card and the merchant wouldn’t need to handle it anymore. This became a dominant approach after PCI took effect.

In addition, there are two types of tokens that are used at the network level:

Device-based tokens or DPAN

When you want to use an existing card on your phone as a payment method, the call gets made to the associated network, which then calls the bank that issued the card. A call then comes back to authenticate the consumer and the most common step is the consumer is asked to enter a one time passcode they received through text. After the bank confirms your identity, it sends a signal to the network and approves your card for digital payments. The network then takes the account number, converts it to a token, and returns it to your wallet provider who securely stores it on the phone.

E-commerce tokens

This is a brand new concept where a product like Google Pay, which helps to securely store millions of cards in its cloud, delivers them to the network for conversion to a token. The network validates the status of the card with the issuing bank, turns them into e-commerce tokens, and returns the tokens to Google. Now, when you shop on any device, Google can use one of these e-commerce tokens because the network and issuer authenticated them. Even if the underlying card changes completely or the expiration date gets updated, this all happens behind the scenes. This is not only convenient for customers, but it also helps protect their card and transaction information by keeping the actual credit card number unexposed and including a dynamic element that is different for every transaction.

Jose: What is the future of payments going to bring? What are you most excited about?

Steve Klebe: I would say, due to the changes our world is going through, we are rethinking how payments are changing. It’s hard to know what the ultimate impact will be, but it’s been about mobile optimization during the last couple years. Every merchant and PSP realizes that they have to enhance their digital offerings, but it’s not going to be any one individual thing. I think it’s the entire holistic experience, whether it’s web, mobile, or in-store. All of a sudden, every merchant realizes that they need to be prepared to do payments contactlessly. Even if the consumer is standing in front of you, you have to be prepared to handle the payment without contact.

There is a clear divide between card present and card not present, and those areas are now blending together. The card industry doesn’t care whether the person is in front of you. If a payment is made digitally, there are alternative rules that apply to the merchant. Merchants need to be extremely cognizant of these rules and they need to do everything they can to optimize how they accept payments.

An exception would be where you can start shopping with a merchant on your desktop and complete transactions elsewhere while your goods remain in your shopping cart. Their systems have to be capable of multiplatform payments and that requires a fresh look at who your PSPs are because not all PSPs provide such capabilities.

Device-bound tokens are very 1990ish. The whole world is moving to the cloud. A device bound token needs to be reprovisioned every time I get a new phone, which is typically every 1-2 years, and that has to change. We live in a cloud-based world and people expect to authenticate themselves and start doing business, and payments have to work this way, too.

Jose: Thank you for the chat, Steve. It sounds like payments are changing a lot, adapting to the evolution of technology and we’re excited to see where these changes take us.

Interested in learning more about Google Pay APIs or have questions? Follow us @GooglePayDevs and let us know in the comments or tweet using #AskGooglePayDev! For any other Google Pay-related requests and questions, or to start your Google Pay integration, visit Google Pay Business Console.

The digital wallet is here to stay. It’s time for your business to cash in.

Posted by Cole Stuart, Google Pay Product Marketing

Digital wallets are rapidly growing in popularity, as adoption from users and acceptance from businesses has expanded significantly over recent years. As we have seen in recent months, this trend towards digital payments over traditional card or cash transactions has only accelerated during the COVID-19 pandemic. Over 40% of global ecommerce spending in 2019 came from a digital wallet like Google Pay, Apple Pay, or Alipay according to the FIS Global Payments Report1. This year, over one billion shoppers are expected to make a digital wallet transaction.

We believe this is just the beginning. In the next five years, digital wallet adoption is expected to increase dramatically. Worldpay’s white paper explores how adopting digital wallets can benefit businesses like yours. Some of the key takeaways are highlighted below.

What digital wallets have to offer

Digital wallets, such as Google Pay, have the ability to not only improve your business outcomes, but also provide unique value to everyday consumers. Benefits include:

  • Higher conversion rates
  • Seamless checkout experience
  • Reduced cart abandonment
  • Advanced security and protection
Google Pay checkout screen

Digital wallets vs. ordinary card transactions

Real tangible benefits are found when businesses adopt a digital wallet. Findings include:

  • Digital wallet transactions showed significantly higher acceptance rates and significantly lower chargeback rates for businesses compared with ordinary card transactions2.
  • Even though transaction volumes for digital wallets were lower than cards in most markets, the value of US digital wallet transactions were on average 25% greater than ordinary card transactions in 20192.

How to bring Google Pay into your business

Ready to adopt a digital wallet and give your customers a seamless transaction experience in just 4 easy steps? Sign up with the Business Console here and visit our developer’s site for more information. You can also find the full whitepaper here, alongside previous case studies that prove how Google Pay has helped drive lasting impact for other businesses.

Chart of Business Console process

Liked our whitepaper? Reach out directly to the contacts below.


Steve Klebe

Head of PSP Partnerships, Google Pay

[email protected]


Rami Josef

Senior Product Manager, Worldpay

[email protected]

[1] – Worldpay by FIS Global Payments Report
[2] – Sourced from Worldpay’s Worldwide Payments Gateway (WPG) using data from Q4 2018 through Q1 2020

What do you think?

Do you have any questions? Let us know in the comments below or tweet using #AskGooglePayDev.

Announcing DevFest 2020

Posted by Jennifer Kohl, Program Manager, Developer Community Programs

DevFest Image

On October 16-18, thousands of developers from all over the world are coming together for DevFest 2020, the largest virtual weekend of community-led learning on Google technologies.

As people around the world continue to adapt to spending more time at home, developers yearn for community now more than ever. In years past, DevFest was a series of in-person events over a season. For 2020, the community is coming together in a whole new way – virtually – over one weekend to keep developers connected when they may want it the most.

The speakers

The magic of DevFest comes from the people who organize and speak at the events – developers with various backgrounds and skill levels, all with their own unique perspectives. In different parts of the world, you can find a DevFest session in many local languages. DevFest speakers are made up of various types of technologists, including kid developers , self-taught programmers from rural areas , and CEOs and CTOs of startups. DevFest also features a wide range of speakers from Google, Women Techmakers, Google Developer Experts, and more. Together, these friendly faces, with many different perspectives, create a unique and rich developer conference.

The sessions and their mission

Hosted by Google Developer Groups, this year’s sessions include technical talks and workshops from the community, and a keynote from Google Developers. Through these events, developers will learn how Google technologies help them develop, learn, and build together.

Sessions will cover multiple technologies, such as Android, Google Cloud Platform, Machine Learning with TensorFlow, Web.dev, Firebase, Google Assistant, and Flutter.

At our core, Google Developers believes community-led developer events like these are an integral part of the advancement of technology in the world.

For this reason, Google Developers supports the community-led efforts of Google Developer Groups and their annual tentpole event, DevFest. Google provides esteemed speakers from the company and custom technical content produced by developers at Google. The impact of DevFest is really driven by the grassroots, passionate GDG community organizers who volunteer their time. Google Developers is proud to support them.

The attendees

During DevFest 2019, 138,000+ developers participated across 500+ DevFests in 100 countries. While 2020 is a very different year for events around the world, GDG chapters are galvanizing their communities to come together virtually for this global moment. The excitement for DevFest continues as more people seek new opportunities to meet and collaborate with like-minded, community-oriented developers in our local towns and regions.

Join the conversation on social media with #DevFest.

Sign up for DevFest at goo.gle/devfest.

Still curious? Check out these popular talks from DevFest 2019 events around the world…

Guidance to developers affected by our effort to block less secure browsers and applications

Posted by Lillan Marie Agerup, Product Manager

We are always working to improve security protections of Google accounts. Our security systems automatically detect, alert and help protect our users against a range of security threats. One form of phishing, known as “man-in-the-middle”, is hard to detect when an embedded browser framework (e.g., Chromium Embedded Framework – CEF) or another automation platform is being used for authentication. MITM presents an authentication flow on these platforms and intercepts the communications between a user and Google to gather the user’s credentials (including the second factor in some cases) and sign in. To protect our users from these types of attacks Google Account sign-ins from all embedded frameworks will be blocked starting on January 4, 2021. This block affects CEF-based apps and other non-supported browsers.

To minimize the disruption of service to our partners, we are providing this information to help developers set up OAuth 2.0 flows in supported user-agents. The information in this document outlines the following:

  • How to enable sign-in on your embedded framework-based apps using browser-based OAuth 2.0 flows.
  • How to test for compatibility.

Apps that use embedded frameworks

If you’re an app developer and use CEF or other clients for authorization on devices, use browser-based OAuth 2.0 flows. Alternatively, you can use a compatible full native browser for sign-in.

For limited-input device applications, such as applications that do not have access to a browser or have limited input capabilities, use limited-input device OAuth 2.0 flows.


Modern browsers with security updates will continue to be supported.

Browser standards

The browser must have JavaScript enabled. For more details, see our previous blog post.

The browser must not proxy or alter the network communication. Your browser must not do any of the following:

  • Server-side rendering
  • HTTPS proxy
  • Replay requests
  • Rewrite HTTP headers

The browser must have a reasonably complete implementation of web standards and browser features. You must confirm that your browser does not contain any of the following:

  • Headless browsers
  • Node.js
  • Text-based browsers

The browser must identify itself clearly in the User-Agent. The browser must not try to impersonate another browser like Chrome or Firefox.

The browser must not provide automation features. This includes scripts that automate keystrokes or clicks, especially to perform automatic sign-ins. We do not allow sign-in from browsers based on frameworks like CEF or Embedded Internet Explorer.

Test for compatibility

If you’re a developer that currently uses CEF for sign-in, be aware that support for this type of authentication ends on January 4, 2021. To verify whether you’ll be affected by the change, test your application for compatibility. To test your application, add a specific HTTP header and value to disable the allowlist. The following steps explain how to disable the allowlist:

  1. Go to where you send requests to accounts.google.com.
  2. Add Google-Accounts-Check-OAuth-Login:true to your HTTP request headers.

The following example details how to disable the allowlist in CEF.

Note: You can add your custom headers in CefRequestHandler#OnBeforeResourceLoad.

    CefRequest::HeaderMap hdrMap;
hdrMap.insert(std::make_pair("Google-Accounts-Check-OAuth-Login", "true"));

To test manually in Chrome, use ModHeader to set the header. The header enables the changes for that particular request.

Setting the header using ModHeader

Related content

See our previous blog post about protection against man-in-the-middle phishing attacks.