Tag Archives: payment request api

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 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:

sample_payment_configuration.json

{
"provider": "google_pay",
"data": {
"environment": "TEST",
"apiVersion": 2,
"apiVersionMinor": 0,
"allowedPaymentMethods": [{
"type": "CARD",
"tokenizationSpecification": {
"type": "PAYMENT_GATEWAY",
"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 = [
PaymentItem(
label: 'Total',
amount: '99.99',
status: PaymentItemStatus.final_price,
)
];

// In your Widget build() method
GooglePayButton(
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. We also want to hear your thoughts and feature requests, and look forward to your contributions on GitHub.

Learn more

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

Google Pay integration patterns that drive conversions on Android

Posted by Jose Ugia, Developer Relations Engineer, Google Pay & Anthony Panissidi, Technical Writer, Google Developer Studio

How to drive conversions with Google Pay for Android

What do Gilt, MTS, Panera Bread, and SpotHero have in common?

At first glance, you probably only see four totally different businesses:

  • Gilt is an online shopping and lifestyle website.
  • MTS is a mobile network operator with 80 million users in Armenia, Belarus, and Russia.
  • Panera Bread is a chain of more than 2,000 fast-casual bakery-cafe restaurants in the US and Canada.
  • SpotHero is a digital parking marketplace that lets drivers reserve and pay for parking spots in more than 300 cities in the US and Canada.

However, all four businesses partnered with us to identify and adopt integration patterns that drive the most conversions on Google Pay for Android. In this blog post, we share these proven integration practices so that you can get the most out of Google Pay in your Android apps, as well as additional security tips that you can use to further secure your payment flows.

UI and UX patterns

Take a look at the following strategies to improve user experience in your app:

  • Payment-method selection
  • Express checkout
  • Guest checkout
  • Payment notifications

Payment-method selection

If you set Google Pay as a default payment option for ready-to-pay users, your users only need to click or tap twice to complete their transactions, so they enjoy a more-seamless payment experience and they're less likely to abandon their carts.

Phone with Gilt user interface

Our partners who implemented this pattern reported a significant increase in their success metrics. For example, at Gilt, 34% of total Google Pay checkouts were net-new Gilt member conversions and 57% of total Google Pay checkouts were reactivations of lapsed Gilt members.

Gilt member conversions increase

Express checkout

This feature lets your users purchase an item directly from the item's detail page without adding it to a cart, which shortens their path to purchase completion.

For example, Gilt integrated this feature into their checkout process so its users can complete the checkout process with only a few clicks or taps. The Google Pay button on their product page lets users move directly to checkout with Google Pay set as a default payment option.

Gilt Google Pay Integration

Guest checkout

This feature makes it easier for your users to complete purchases and convert, and more likely to create an account and engage again later.

To enable guest checkout, add Google Pay as an option to continue with the payment process alongside your account-creation elements.

For example, Panera Bread enabled guest checkout, and found a 7% increase in order value and 30% increase in wallet share.

Panera increase in order value and wallet share

As another example, SpotHero enabled guest checkout, and found that its sales funnel increased by 20 times while 87% of total checkouts were completed with Google Pay.

SpotHero increase in sales and total checkouts

Payment notifications

This feature lets your users pay directly from notifications, which reduces friction in the payment process and further increases conversions.

Users sometimes receive payment notifications that they expect, such as after they abandon carts, make donations, or need to add credit to a prepaid card. They typically find these transactions simple and familiar, so they're ready to pay quickly with a little nudge.

MTS credit adding option interface

MTS adopted this pattern to let their customers add credit to their accounts directly from notifications and experienced a 80% increase in conversions.

MTS users in Russia and increase in conversions

Learn more

For more information about how to implement these UI and UX patterns, see our sample open source app and developer documentation.

Security tips

Before we go, we also want to share these security tips to further secure your payment flows:

  • Use SSL for all connections between your apps and backend services over the public internet.
  • Do not collect or store payment data, or any other sensitive information in the clear within your app.
  • Order price can be calculated on the client side to show it in your UI and keep the user informed, but only allow for payments with calculations applied in your backend services.
Security Basics

Learn more

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

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:

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.

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.

Google Pay launches new, dynamic features for Online Payments and Passes APIs

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.

Making online payments even more seamless

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.

Dynamic updates for faster checkout

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.

More payment button options

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 API allows to display card information directly on the checkout button

Delivering extra value with Google Pay Passes

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.

High priority notifications for boarding passes

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.

Integration with the Google Assistant

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.

An open API for transit, with support for dynamic barcodes

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.

Loyalty Integration with Gmail

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.

What’s next

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.

Resources

To learn more about Google Pay, visit our developer resources:

All you need to know about Google Pay if you’re a developer

Posted by Jose Ugia, Developer Programs Engineer

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.

Ways to pay with Google Pay

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.

Why add Google Pay to your app or site?

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:

  • Simplify the checkout experience so users don’t have to remember their payment details, making the checkout process faster and reducing the percentage of abandonments.
  • Increase security by encrypting users’ choice of payment before it is sent back to your app. You can also use it to charge orders directly from your servers or payment processor.
  • Enable payments on multiple surfaces to provide more flexibility to your users. This also allows you to easily enable payments on other Google surfaces like the Google Assistant.
  • Increase conversions for new users by reducing friction for those who do not have an account on your app or site. The APIs support returning information like billing and shipping addresses in addition to forms of payment if needed to process an order.

Integrating Google Pay

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.

Google Pay and the Payment Request API

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.

Tune in to Google Pay at Google I/O 2019

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.