Posted by Jose Ugia and Steve Klebe
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:
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.
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:
Digital wallets vs. ordinary card transactions
Real tangible benefits are found when businesses adopt a digital wallet. Findings include:
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.
Liked our whitepaper? Reach out directly to the contacts below.
Google:
Steve Klebe
Head of PSP Partnerships, Google Pay
sklebe@google.com
Worldpay:
Rami Josef
Senior Product Manager, Worldpay
rami.josef@fisglobal.com
[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.
Posted by David Ko, Engineering Director; Jeff Lim, Software Engineer; Pankaj Gupta, Director of Engineering; Will Horn, Software Engineer
Three years ago, when we launched Google Pay India (then called Tez), our vision was to create a simple and secure payment app for everyone in India. We started with the premise of making payments simple and built a user interface that made making payments as easy as starting a conversation. The simplicity of the design resonated with users instantly and over time, we have added functionality to help users do more than just make payments. Today users can pay their bills, recharge their phones, get loans instantly through banks, buy train tickets and much more all within the app. Last year, we also launched the Spot Platform in India, which allows merchants to create branded experiences within the Google Pay app so they can connect with their customers in a more engaging way.
As we looked at scaling our learnings from India to other parts of the world, we wanted to focus on a fast and efficient development environment, which was modern and engaging with the flexibility needed to keep the UI clean. And more importantly one that enabled us to write once and be able to deploy to both iOS and Android reaching the wide variety of users.
It was clear that we would need to build it, and ensure that it worked across a wide variety of payment rails, infrastructure, and operating systems. But with the momentum we had for Google Pay in India, and the fast evolving product features - we had limited engineering resources to put behind this effort.
After evaluating various options, it was easy to pick Flutter as the obvious choice. The three things that made it click for us were:
Now the task was to get it done. We started with a small team of three software engineers from both Android and iOS. Those days were focused and intense. To start with we created a vertical slice of the app — home page, chat, and payments (with the critical native plugins for payments in India). The team first tried a hybrid approach, and then decided to do a clean rewrite as it was not scalable.
We ran a few small sprints for other engineers on the team to give them an opportunity to rewrite something in Flutter and provide feedback. Everyone loved Flutter — you could see the thrill on people’s faces as they talked about how fast it was to build a user interface. One of the most exciting things was that the team could get instant feedback while developing. We could also leverage the high quality widgets that Flutter provided to make development easier.
After carefully weighing the risks and our case for migration, we decided to go all in with Flutter. It was a monumental rewrite of a moving target, and the existing app continues to evolve while we were rewriting features. After many months of hard work, Google Pay Flutter implementation is now available in open beta in India and Singapore. Our users in India and Singapore can visit the Google Play Store page for Google Pay to opt into the beta program and experience the latest app built on Flutter. Next, we are looking forward to launching Google Pay on Flutter to everyone across the world on iOS and Android.
We hope this gives you a fair idea of how to approach and launch a complete rewrite of an active app that is used by millions of users and businesses of all sizes. It would not have been possible for us to deliver this without Flutter’s continued advances on the platform. Huge thanks to the Flutter team, as today, we are standing on their shoulders!
When fully migrated, Google Pay will be one of the largest production deployments on the Flutter platform. We look forward to sharing more learnings from our transition to Flutter in the future.
Posted by Soc Sieng, Developer Advocate
We are pleased to announce the launch of the official Google Pay plugin for Magento 2. The Google Pay plugin can help increase conversions by enabling a simpler and more secure checkout experience in your Magento website. When you integrate with Google Pay, your customers can complete their purchases quickly using the payment methods they’ve securely saved to their Google Accounts.
Google Pay in action.
The Google Pay plugin is built in collaboration with Unbound Commerce, is free to use, and integrates with popular payment service providers including Adyen, BlueSnap, Braintree, FirstData - Payeezy & Ucom, Moneris, Stripe, and Vantiv.
The Google Pay plugin can be installed from the Magento Marketplace using this link or by searching the Magento Marketplace for “Google Pay”.
Refer to the Magento Marketplace User Guide for more installation instructions.
To get started with the Google Pay plugin, you will need your Google Pay merchant identifier which can be found in the Google Pay Business Console.
Your Merchant ID can be found in the Google Pay Business Console.
Once installed, you can configure the plugin in your site’s Magento administration console by navigating to Stores > Configuration > Sales > Payment Methods and selecting the Configure button next to Google Pay.
Click on the Configure button to start the setup process.
Testing out Google Pay can be achieved in three easy steps:
You can optionally try out some of the advanced settings that provide the ability to customize the color and type of Google Pay button as well as enabling Minicart integration, which is recommended.
Checkout the Advanced Settings to further customize how and where the Google Pay button is presented in your store.
If your payment provider isn’t listed as an option in the payment gateway list, check to see if your payment provider’s plugin has built-in support for Google Pay.
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.
Integrating Google Pay into your website is a great way to increase conversions and to improve the purchasing experience for your customers.
Find out more about Google Pay and the Google Pay plugin for Magento.
Posted by Jose Ugia and Checkout.com
We sat down with Riaz Bordie, the CTO of Checkout.com, a leading international provider of online payment solutions, to get his advice to merchants and the developer community on how to think about future-proofing payments in the uncertain world we live in today.
Jose Ugia: What advice do you have for merchants and developers as it relates to payments in these difficult times?
Riaz: Merchants are seeing a polarizing impact of COVID-19 on their businesses. For those who have an online presence, you’re either seeing a lull in traffic or a spike.
If you’re a merchant who’s seeing traffic dwindle, it’s more important than ever to make sure every transaction counts. If you used to see 50 transactions a day and now you see 10, you want to make sure all 10 deliver. Work with your Payment Service Provider (PSP) to make sure your approval ratios are as optimal as possible -- a legitimate customer who gets declined incorrectly may not return to purchase as they have in the past. If your PSP supports alternative payment methods like Google Pay that decrease friction at checkout and local payment methods if you’re selling internationally, that’s ideal. Keep an eye on your PSP’s stacks and uptimes to make sure you’re not missing out on sales due to outages or technical issues.
If you’re a merchant seeing a spike in traffic, that’s great news! But it’s important to note that a sudden traffic increase without proper operational and infrastructure planning can lead to fraud spikes, decreases in approval ratios, and downtime. With higher sales velocity, risk related issues will multiply. You’ll see more attempted fraud as fraudsters take advantage of unsuspecting consumers, higher payment declines resulting from outdated issuer risk modeling and excessive chargeback levels, subscription cancellations, buyer’s remorse, among others. How are your payments infrastructure and operations equipped to handle all of this?
Make sure your infrastructure is capable of scaling up. If you don’t have autoscaling, you’ll need a team and processes in place to scale infrastructure for traffic spikes, and keep in mind this may get harder with people working remotely. Work your PSP and other providers to optimize your payments, risk models and chargeback handling during this challenging time.
For both types of merchants, it’s important to pay closer attention to performance of your payments system. This includes both ensuring that processes are working in an optimal way - especially given remote working situations and also ensuring that you are seeing efficiencies at scale.
Jose Ugia: How did you think about building a payments infrastructure that was scalable and future-proof at Checkout.com?
We knew in the beginning we wanted a unified API, which through a single integration gives a merchant access to any market via a range of payment methods and other facilities. We’ve worked hard to get acquiring licenses in as many markets as possible so we can bring acquiring in-house, which in turn gives us greater visibility on the entire payment flow. We have also invested in a gateway that can be consistently deployed in local geographies so that whether the merchant is in Dubai or Singapore, they are getting the most optimal traffic flow.
Any engineer knows that tech breaks. Those who win have a better plan for dealing with breakage efficiently, to consistently maintain high levels of service. We spend a lot of time and resources on making sure our stack is resilient and we have the right operational processes in place to both proactively monitor for potential issues and respond correctly when they come up.
Jose Ugia: Speaking of where things are headed, where do you see the future of payments going from a payment service provider perspective?
A few key trends I see:
Risk & Fraud Detection. AI/ML is improving every aspect of tech. Fraudsters will get smarter but so will fraud prevention - it’s a cat and mouse game. In payments, sophisticated risk engines offering ML-based transaction scoring and highly customizable rules builders, among other features, will get better at detecting fraud without compromising sales.
Global acceptance will continue to be complex but paramount. Offering a variety of payment methods is table stakes these days. More and more, we’ll see that local payment methods aren’t the alternative but instead the primary way consumers pay. For example, you need to have Giropay if you’re selling in Germany and Alipay if you’re selling in China if you want a high conversion rate. Ensure that you and your local entities have an optimized setup with your acquirer (ideally domestic where possible) focused on achieving the lowest costs and highest approval rates.
Embedded infrastructure. Merchants - especially enterprise players - will want increased visibility and more control on optimizing their payment systems. We offer this level of insight and flexibility to our merchants today via our APIs around risk, reconciliation, disputes, etc. But we’re headed toward a world where dedicated infrastructure will become part of the package and allow for complete data separation and zero contention.
Jose Ugia: How do you think these changes of payments infrastructure will impact consumers downstream?
Convenience is king among consumers. I believe that COVID-19 will accelerate the move toward a contactless payments society, with consumers relying more on digital wallets and opportunities to pay through their devices. I personally no longer take my wallet out with me when I leave the house. A couple of years ago that felt like a conscious decision - now it’s just part of everyday life to rely solely on my smartphone to pay.
In some regions like MENA, which has typically been a cash-on-delivery society, we’re seeing more merchants close off cash and impose digital payments, opening up more adoption of upfront e-commerce payments. As mandated payment methods begin to change consumer behavior (studies say it takes 2 months to change a habit), new ways of paying will be here to stay, even beyond COVID-19.
The Google Pay API enables fast, simple checkout for your website.
The Google Pay JavaScript library does not depend on external libraries or frameworks and will work regardless of which framework your website uses (if it uses any at all). While this ensures wide compatibility, we know that it doesn’t necessarily make it easier to integrate when your website uses a framework. We’re doing something about it.
React is one of the most widely-used tools for building web UI's, so we are launching the Google Pay Button for React to provide a streamlined integration experience. This component will make it easier to incorporate Google Pay into your React website whether you are new to React or a seasoned pro, and similarly, if this is your first Google Pay integration or if you’ve done this before.
We’re making this component available as an open source project on GitHub and publishing it to npm. We’ve authored the React component with TypeScript to bring code completion to supported editors, and if your website is built with TypeScript you can also take advantage of type validation to identify common issues as you type.
Get real time code completion and validation as you integrate with supported editors.
The first step is to install the Google Pay button module from npm:
npm install @google-pay/button-react
The Google Pay button can be added to your React component by first importing it:
import GooglePayButton from '@google-pay/button-react';
And then rendering it with the necessary configuration values:
<GooglePayButton environment="TEST" paymentRequest={{ ... }} onLoadPaymentData={() => {}} />
Try it out on StackBlitz.
Refer to component documentation for a full list of supported configuration properties.
Note that you will need to provide a Merchant ID in paymentRequest.merchantInfo to complete the integration. Your Merchant ID can be obtained from the Google Pay Business Console.
paymentRequest.merchantInfo
For our Angular developers, we’ve also got you covered with the Google Pay Button for Angular. It shares the same features and functionality as the React component, but uses the conventions and idioms that you expect as an Angular developer.
npm install @google-pay/button-angular
Import and install the GooglePayButtonModule into your Angular module:
GooglePayButtonModule
import { GooglePayButtonModule } from '@google-pay/button-angular'; @NgModule({ // ... imports: [ // ... GooglePayButtonModule ], // ... })
And add the <google-pay-button /> into your Angular component:
<google-pay-button />
<google-pay-button environment="TEST" [paymentRequest]="paymentRequest" (loadpaymentdata)="onLoadPaymentData($event)" ></google-pay-button>
We also want to provide an improved developer experience for our developers using other frameworks, or no framework at all. That’s why we are also releasing the Google Pay button Custom Element.
Custom elements are great because:
Like the React and Angular components, the Google Pay button custom element is hosted on GitHub and published to npm. In fact, all three components share the same repository and large portion of code. This ensures that both versions maintain feature parity and receive the same level of care and attention.
Like the React component, the Google Pay button custom element is hosted on GitHub and published to npm. In fact, the React component and the custom element share the same repository and large portion of code. This ensures that both versions maintain feature parity and receive the same level of care and attention.
Try out the HTML version or the Vue version on StackBlitz.
There's no change to the existing Google Pay JavaScript library, and if you prefer, you can continue to use this directly instead of the React component or custom element. Both of these components provide a convenience layer over the Google Pay JavaScript library and make use of it internally.
This is the first time that we (the Google Pay team) have released a framework specific library. We would love to hear your feedback.
Aside from React, most frameworks can use the Web Component version of the Google Pay Button. We may consider adding support for other frameworks based on interest and demand.
If you encounter any problems with the React component or custom element, please raise a GitHub issue. Alternatively, if you know what the problem is and have a solution in mind, feel free to raise a pull request. For other Google Pay related requests and questions, use the Contact Support option in the Google Pay Business Console.
At Google Pay, we’re always looking for ways to make things simple, helpful, and accessible for everyone, whether that’s consumers or developers. Today, we’re introducing a new resource for developers that does just that — the Business Console for Google Pay. The Business Console is a new tool that streamlines the way you integrate Google Pay into your apps and websites.
Many of you have already added support for Google Pay. In the process, you asked questions like:
We created the Business Console for Google Pay in response to your feedback. With the new console, you’ll be able to integrate Google Pay into your apps and websites more seamlessly, discover resources, get support at different stages throughout your integration, and keep track of your progress along the way.
And this is only the beginning. As we add new features, the Business Console will be your go-to place to manage all your new and existing integrations with Google Pay, see how your integrations perform over time, and add support for other business- and developer-focused products.
The new Business Console lets you simplify your Google Pay integrations by guiding you during the submission for approval and helping you keep track of progress.
Getting started is easy. Just head to pay.google.com/business/console. If you’ve already integrated with Google Pay, log in with your account to see your existing integrations or create new ones. And if you haven’t integrated with Google Pay yet, simply create your business profile, build an integration, and submit it for approval directly from the console.
Some businesses, system integrators, and developers have already started using the Business Console as part of our early-access program. “The new Google Pay Business Console helped us understand the integration requirements, and the examples made it easy to implement the Google Pay API into our website,” Gymondo GmbH CTO Christopher Weiss said. The Business Console also helped Weiss get their integration approved quickly. “Shortly after,” Weiss said, “we started seeing purchases coming from our customers paying with Google Pay."
We hope the new console makes your integration process go just as smoothly, and we’d love to hear about your experience. You can share any feedback from the menu within the console. We’re looking forward to learning how we can make Google Pay even more helpful in the future.
Google Pay is now available on Stripe Checkout. Businesses with Stripe Checkout on their websites can now provide an optimized checkout experience to Google Pay users.
Google Pay is available directly from Stripe Checkout
Refer to Stripe’s Checkout documentation for more information.
Stripe merchants that aren’t using Stripe Checkout can integrate directly with Google Pay using the Google Pay Setup Guide.
Google Pay is the fast, simple and secure way to pay on sites, in apps, and in stores using the payment options saved to your Google Account.
See Google Pay Developer documentation for information on additional integration options.
We’re thrilled to announce we’ve expanded our collaboration with PayPal to make payments easy and seamless no matter how or where your customers like to shop. Now, you’ll be able to accept PayPal with Google Pay on your app or website in all 24 countries where your customers can link their PayPal account to Google Pay.
Here are 5 ways this integration can add value to your business:
Hundreds of millions of users already have their payment methods saved to their Google Account. And as of 2018, customers who use their PayPal account to make a purchase on a Google app or service like Google Play and YouTube can automatically choose that PayPal account when they pay with Google Pay—no new setup required. When you enable PayPal as a payment method on your Google Pay integration, all of these customers will be able to seamlessly check out on your website or app.
Users will be able to choose PayPal—or any other payment method—right from the Google Pay payment sheet.
Once users link their PayPal account, they won’t need to sign in to PayPal when they use it with Google Pay. This means they’ll enjoy fewer steps at checkout, which often leads to higher conversion rates. In addition, your customers will get all the advantages that come with their PayPal account—like Purchase Protection and Return Shipping—along with Google Pay’s fast, simple checkout experience and increased security.
Google Pay lets customers keep all of their payment methods in one place. They’ll easily be able to switch between debit cards, credit cards, their PayPal account, and more just by choosing Google Pay at checkout.
PayPal merchants who enable the acceptance of PayPal through Google Pay can continue to get the PayPal benefits they already enjoy. This includes the ability to receive payments directly to their PayPal Business Account within minutes, no minimum processing requirements, and seller protection on eligible transactions.
If you’ve already implemented Google Pay, enabling PayPal is as easy as adding it to your list of allowed payment methods in the body of your requests:
const payPalPaymentMethod = { type: "PAYPAL", parameters: { purchase_context: { purchase_units: [{ payee: { merchant_id: "<YOUR_PAYPAL_ACCOUNT_ID>" } }] } }, tokenizationSpecification: { type: "DIRECT" } }; paymentRequest.allowedPaymentMethods = [payPalPaymentMethod, cardPaymentMethod];
Once you’ve done that, you’ll receive a token you can send to your servers as soon as your customers confirm their transaction. You’ll use this token to issue a call against PayPal’s payment service—see PayPal’s documentation for more details and best practices.
If you haven’t implemented Google Pay yet, check out our online API introduction video or our step-by-step guided codelabs for Android and Web to learn more about it. If you prefer to explore on your own, read our documentation.
We’re excited to offer developers the best of both worlds with Google Pay and PayPal, all while making payments simpler for customers and businesses around the world. Stay tuned for more updates.
Posted by Stephen McDonald, Google Developers Engineer and Jose Ugia, Google Developers Engineer
At Google I/O 2019, we shared some of the new features we’re adding to Google Pay and discussed how you can use them to add value to your customers—whether you accept payments on your app or website or engage with customers beyond payments through loyalty cards, offers, event tickets, and boarding passes.
Read on for a summary of what we covered during the event. If you want to hear the full story, check out the recordings of our sessions: Building Powerful Checkout Experiences with Google Pay and Engaging Customers Beyond Payments: Tickets, Transit, and Boarding Passes.
Better checkout experiences are more likely to increase your conversions. Here’s a look at some of the ways Google Pay can help you improve your checkout process from start to finish.
In an effort to bring customers more detail and transparency, we’ve made some changes to the Google Pay API. Going forward, the Google Pay payment sheet will display pricing information, so customers can double-check their order before they confirm their purchase. We’re also adding modifiers based on transaction conditions (like shipping options), so customers can see all relevant purchase details quickly, without going back to the merchant site, leading to a faster checkout experience.
Users paying online can see the price of the order dynamically before they initiate the transaction.
Along with these improvements to the payment sheet, we’re offering creative new button and onboarding options to encourage customers to choose Google Pay for faster checkout. To start, we launched the createButton API for web developers. This enables a dynamic purchase button that uses the right styling and colors and is localized to your user’s device or browser settings. We’ve also been experimenting with personalized buttons that display important information before users enter the checkout flow. For instance, we can show customers exactly what card they’ll be paying with or let them know if they need to sign in or set up Google Pay – and this information is displayed right on the button. As the button is hosted and rendered by Google Pay, all of this happens without you having to make any changes.
createButton
createButton API allows to display card information directly on the checkout button
The Google Pay API for Passes lets you connect your business to millions of Android users by linking your loyalty programs, gift cards, offers, boarding passes, and event tickets to their Google Accounts. This year, we’re launching new capabilities and integrations that will help you engage customers at more times and places.
Your passengers can add their boarding pass to Google Pay for a seamless check-in experience. Google Pay sends the passengers a high priority notification with their boarding pass just a few hours before their flight so they can easily access it when needed. They’ll also receive notifications with important dynamic information like gate changes or flight delays. These notifications are high priority and will stay prominent on passengers’ phones until they dismiss it or their flight takes off.
Google’s ecosystem can help create complete user journeys across multiple touchpoints. Earlier this year, we announced the ability to check-in to flights directly from the Google Assistant. Once a flight is ready for check-in, your passenger will receive a notification that takes them directly to the Assistant to complete the process. At the end of this flow, the user is issued a boarding pass that can be accessed from the Assistant or from Google Pay. This is built on top of the Passes API, which means that as an airline, if you already added support for boarding passes, you can just add the check-in with the Assistant integration on top of it.
From left to right: new high priority notifications, integration of Myki card inside of Google Maps, new transit tickets and automatic Gmail import.
We’re excited to announce we’re making transit an open API. This means if you’re a transit provider and currently offer barcode tickets for your transportation services, you can now utilize the Passes API to get your tickets digitized in Google Pay. We’ll also be enhancing this API to support dynamic barcodes. The barcodes on customers’ transit tickets or passes will update every few seconds – even if their device is offline. This allows you to increase security -- since your QR codes are changing all the time, it makes it harder to duplicate the ticket.
Now you can also give customers the opportunity to import your loyalty cards to Google Pay right from Gmail—just by adding some markup to your emails. When customers open the Google Pay app, they’ll be shown any loyalty cards from Gmail they haven’t added to Google Pay. With just a tap, they can add them all automatically so they can access them at any time. This feature is currently only available with loyalty programs, but we’ll be expanding to other types of passes in the future.
We’re working on making Passes available to your users on Google even if they haven’t installed the Google Pay app. We are starting with boarding passes and transit tickets, then plan to extend the same functionality to the other Passes. Stay tuned for more.
To learn more about Google Pay, visit our developer resources:
Google Pay is designed to make transactions simple from contactless payments to online purchases and even peer-to-peer payments. It also allows users to store tickets and passes, manage loyalty cards and keep track of transactions. With Google Pay, users can pay with all credit and debit cards saved to their Google Account, making hundreds of millions of cards enabled for faster checkout in your apps or websites. This includes payments for goods and services on e-commerce merchants, online marketplaces and Android apps.
When you integrate the Google Pay API into your app or site, your customers can then transact using any of those cards in as few as two clicks.
When users use their NFC-enabled mobile device or smart watch to pay in places such as supermarkets, restaurants or shops, the card selected is emulated from the device using a secure number that changes on every transaction. Only the bank or card issuer can decrypt this number to process the transaction. The process of securing your card details is called tokenization. Only cards from supported banks can be tokenized, and this is a necessary step to pay contactless using Google Pay.
Users can pay in-stores using NFC-enabled devices with forms of payment that support tokenization.
In contrast, when users pay in your app or on your site through Google Pay, they can select any card saved to their Google Account, including tokenized cards. This enables users to pay on any device in your sites and apps globally.
Users paying online can use any card saved under their Google account(s).
All forms of payments are stored in the user's Google account and protected by multiple layers of security. This includes payment methods that users have already saved to pay for services like YouTube, Google Play or to speed up checkout forms using Chrome Autofill.
You can integrate Google Pay's online APIs to increase conversions by providing a more convenient, more secure and faster way to pay to your users. Some of the benefits include:
Adding Google Pay to your site or application is just a few lines of code away. There are tutorials on how to integrate Google Pay in your website or Android app and step-by-step guided codelabs for Web and Android. Here is a more visual tutorial:
To get started, use this integration checklist (Android | Web) to make sure you have everything you need to complete the integration. When you’re ready to go live with your integration, request production access and follow the final steps to deploy your app (Android | Web) in a production environment.
The Payment Request API is a Web Payments W3C standard that provides a native browser experience for collecting payment information from the user. You can accept Google Pay via PaymentRequest directly, however this may not be available across browsers.
To enable Google Pay for your users across all major browsers with a single implementation, we recommend using the Google Pay JavaScript library as described above. This enables a native Payment Request experience on Chrome, while giving you the flexibility of supporting Google users on other browsers.
The payments sheet is presented natively when triggered from a browser with support for Payment Handler API (on the right), while it falls back to showing a pop-up on browsers that don’t.
As users’ needs evolve, we continue to add features and forms of payment to the Google Pay API –like the recent addition of PayPal– so you can get access to these new payment methods in your app or site without any additional development work.
Don’t miss Google Pay sessions at Google I/O this year to learn about the latest features we are bringing to Google Pay. Bookmark our sessions and check back for livestream details–we look forward to seeing you this week.
