This is a cross post from Medium.
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?
These are all incorrect; it's called "Payment Request API" (PR API). And it's not just a Google or Chrome thing, it's an open standard specification and is/will be available in different browsers. The API is currently supported in:
- 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
This is wrong. Even with the PR API, developers still have to send the payment information provided by users to a payment gateway or a payment processor in order to be processed and for the money transfer to happen.
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?
That can be true, but not always. There are two types of payment methods defined so far, "basic card" and "payment apps".
With "basic card", Chrome’s Payment Request sheet will show you a combined list of payment information from
- locally stored payment information
- payment information stored to the Google account associated with the user's Chrome profile
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
That's also incorrect. The Payment Request API is designed to handle virtually any kind of payment methods including bank transfers, cryptocurrencies, e-money, points, etc.
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.
With Payment Request API, my site won’t need PCI compliance
This is also wrong; PCI compliance is required. Here’s what you should check.
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.
Top comments (0)