Many people are confused about the differences between Web Payments, Payment Request API, and Google Pay. In this article, I’ll clarify the differences and explain my recommendations for what merchants should implement.
TL;DR
- Web Payments is the name of the working group at W3C trying to standardize a set of open standards payments in the browser. It is also used generally to mean the overall effort to make payments better on the web.
- Payment Request API is one of specifications the Web Payments Working Group has written. The API governs how a user agent (browser) can communicate with an implementation (website) to exchange payment credentials. Payment Request API is a lower layer API for Google Pay API and can launch payment apps such as Google Pay.
- If you are a merchant, implement Google Pay API with its JavaScript library rather than the Payment Request API.
Read on to learn more.
What is Google Pay?
Google Pay is a recently launched consumer-facing payment app from Google. It unifies various payment services into a single brand and provides a simple, streamlined experience. Its main feature is to make payments easier, whether your customers are shopping at a physical store or online in your apps or websites.
Google Pay enables users to pay with any credit or debit card saved to their Google account, including cards provisioned on Android devices using the Google Pay app.
Network tokens are provisioned and stored to a device using a virtual account number. Tokenized cards are convenient for tap-to-pay at physical stores, but they also include a one time use element that makes them more secure than regular cards. They can also be updated automatically by the card issuer if the physical card details change for any reason.
Cards saved to Google are credit card numbers stored in a user’s Google account. They are typically stored when a user pays for Google Play, YouTube, Google Cloud, etc. Users can check their cards at https://pay.google.com/payments/.
Cards saved to Google are available for hundreds of millions of users that have made payments through various Google services — and so this can include users who haven’t installed or launched the Google Pay app.
Payment Request API and Google Pay API
Payment Request API in a nutshell
As many of you who have read my previous articles already know, Payment Request API is an open web standard that brings native UI to browsers and mediates a payment between a website and a user. It is a new, flexible, and structured form with a static native browser UI.
The API is already implemented in Chrome, Edge, Safari, Samsung Internet Browser, and Firefox is very close to finishing their implementation.
The Payment Request API specification is designed in a way that is flexible enough for a browser to support any payment method. There are two types of payment methods, standardized and URL-based. See “How payment methods work in the Payment Request API” to learn more about these payment method types.
Google Pay through Payment Request API
Google Pay is available through the Payment Request API as a URL-based payment method. Both network token and cards saved on Google are available through Payment Request API seamlessly. But there’s a non-negligible difference between the two.
Network token: Because it needs access to a secure area of the device (in fact Google Pay uses HCE but let me ignore in this case), network tokens are only available when the user is using a capable device. For Google Pay, this means using the Chrome browser on Android (as of August 2018). In other words, network tokens are not currently available on desktop or in browsers that do not support third-party payment apps.
Cards saved to Google: Meanwhile, cards saved to Google do not necessarily require the app. Because they are stored on the Google server, you can use Payment Handler API to take advantage of card information on the Payment Request API even on desktop. Card details are typically encrypted using keys from supported gateways (gateway tokenization), which avoids sharing credentials directly with the merchant.
Google Pay without Payment Request API
A user’s browser may not support Payment Request API (or Payment Handler API). This prompted Google Pay to provide a JavaScript library to bridge the gap.
By using the library, Google Pay may use Payment Request API and Payment Handler API if they are available, or it can use a traditional pop-up window approach. By doing this, Google Pay becomes available throughout any modern browsers.
basic-card and Google Pay
Cards saved to Google have been available through basic-card in Payment Request API in Chrome. That is indeed true, but only up to Chrome 70.
By going to chrome://settings/autofill (In later Chrome, chrome://settings/payments) you can check credit card numbers available for form Autofill. The ones with “Google Pay” beside them are actually cards saved to Google, propagated from a Google server. The ones without it are card numbers entered and stored locally.
This means the same cards saved on Google have been available both on Chrome Autofill as well as in Google Pay. But as I mentioned in “Integrating the Payment Request API with a payment service provider”, basic-card is intermediary solution. In fact, Chrome has announced its deprecation of cards saved on Google forbasic-cardin Chrome 70.
Note that basic-card will continue to be available using locally stored card numbers.
Use JS library for using Google Pay API
Prioritizing token-based payment method is recommended, given the risk of basic-card as I mentioned in my earlier post and therefore the JavaScript library should be used to implement Google Pay rather than directly implementing it through the Payment Request API.
Of course, Payment Request API is still useful for payment methods other than basic-card such as Apple Pay, Samsung Pay, or emerging new payment methods available through Payment Handler API. (By the way, by using the Payment Handler API, anyone can build their own payment method and payment app. Try your own.)
In the future, when many payment methods are equally available across different browsers, we’ll be able to rely on the pure Payment Request API.
In the next post I plan to cover a UX recommendation using multiple payment methods. Stay tuned.
Top comments (0)