Addressing common misconceptions about the Payment Request API

Eiji Kitamura
Sep 20, 2017 · 4 min read

The Payment Request API was first made available in a production browser on Chrome for Android in July 2016. It’s the very first open web feature solely focused on “payment” and is expected to evolve the entire web platform and its ecosystem in the coming years.

In this article I’ll call out some common misconceptions about the API and try to address them as comprehensively as possible. If you have zero knowledge about the Payment Request API, you should probably read this page first.

Web Payment API? Chrome Payment API? Google Payment API?

  • Chrome for Android
  • Chrome on desktop (Mac, Windows, Linux)
  • Microsoft Edge
  • Samsung Internet Browser

And it’s coming to:

  • Chrome for iOS
  • Apple Safari
  • Mozilla Firefox

With Payment Request API, browsers will take care of processing payments, so developers won’t have to do anything

Consider the PR API as a replacement of a form implemented using JavaScript. Upon user tapping a “PAY” button, instead of a form being POSTed to a server, the website’s JavaScript will receive the user’s payment information so you can handle it however you want. Typically, you would forward that directly to a payment gateway to obtain a token and then process the payment from your server.

Payment Request API on Chrome will use payment info associated with my Google account, right?

Image for post
Image for post

With “basic card”, Chrome’s Payment Request sheet will show you a combined list of payment information from

  1. locally stored payment information
  2. payment information stored to the Google account associated with the user’s Chrome profile
Image for post
Image for post

You can check what’s available to the PR API (and forms as well) in Chrome’s autofill settings page.

The ones marked “Google Payments” are derived from your Google account. (Note that locally added information won’t be upstreamed and stored in Chrome.)

The other type of payment method is “payment apps” and they don’t necessarily represent credit cards. They can be e-money, cryptocurrency, or bank accounts (Don’t get too excited here, these type of payment methods are not generally available yet). It’s up to the payment app’s implementation and it is in an isolated world, which means payment apps can be served separately from Chrome or Google.

The same thing goes for other browsers, depending on their implementation. In Microsoft Edge, for example, the Payment Request API connects to Microsoft Wallet and has access to payment information associated with the user’s Microsoft account. In Samsung Internet Browser, the Payment Request API stores credit card information only when you are using a Samsung device.

Payment Request API handles credit cards well but not other form of payments

Payment Request API is fundamentally a mediator between a browser and a payment method. It’s designed to be flexible enough to allow any native app or web app to become a payment method, so technically anyone can develop their own payment app to serve a unique payment method.

Image for post
Image for post

With Payment Request API, my site won’t need PCI compliance

If your site is compliant with PCI DSS or PCI SAQ A-EP, you are probably working at a relatively large company and there’s not much to worry about to implement the PR API as long as you implement it securely.

If your site is compliant with PCI SAQ A, be careful. With PCI SAQ A, you are not supposed to handle raw credit card information directly. This means using the Payment Request API with “basic-card” as a payment method is outside of PCI SAQ A v3.2 compliance.

I will write more about this topic in a separate article, but consult with your payment gateway to learn how you can leverage the Payment Request API with their current setup. Or you may even ask them to support the Payment Request API!


Leave comments if you have any questions. For large topics I’ll cover the answers in subsequent articles.

Dev Channel

Developers Channel - the thoughts, opinions and musings…

Eiji Kitamura

Written by

Developer Advocate of Web at Google in Tokyo. Chrome, HTML5, Payments, Identity

Dev Channel

Developers Channel - the thoughts, opinions and musings from members of the Chrome team.

Eiji Kitamura

Written by

Developer Advocate of Web at Google in Tokyo. Chrome, HTML5, Payments, Identity

Dev Channel

Developers Channel - the thoughts, opinions and musings from members of the Chrome team.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store