Forem: Eiji Kitamura

What’s new in Web Payments

Eiji Kitamura — Fri, 07 Aug 2020 05:42:12 +0000

It’s been a while since my previous post, but Web Payments team at Google including myself have been commited to work on improving it. Some may wonder what’s giong on with it, so let me share my talk at an online event called “web.dev LIVE” which Google’s Web DevRel team organized early July 2020.

It’s a short video, but it contains:

Recap of Web Payments
How it works
Status update
Upcoming features

Most importantly, we’ve published a set of documentation that explains how to build a native and a web-based payment app in detail.

web.dev

Integrate Web Payments into your payment app

Build a native payment app

Build a web-based payment app

…And more articles are coming!

If you are interested in building a Web Payments compatible payment app, let me know.

Web Payments, Payment Request API and Google Pay

Eiji Kitamura — Tue, 14 Aug 2018 04:29:01 +0000

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.

The one with the contactless logo (bottom) is a network token on the device; the other (top) is a card saved on the user’s Google account.

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.

chrome://settings/autofill

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 for basic-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.

Integrating the Payment Request API with a payment service provider

Eiji Kitamura — Wed, 22 Nov 2017 08:38:17 +0000

With the Payment Request API, payments on the web are drastically simplified. The UX can be consistent across websites, making it easier for users to enter and reuse their personal information such as shipping address or payment details. It also enables various payment methods on the web.

Let me quickly recap important payment concepts:

basic card — A payment method natively implemented to all Payment Request API capable browsers (Chrome, Samsung Internet, Edge). Card information is usually shared with form autofill data and returned as plain text from the Payment Request API.

payment app — A web app or a native app that provide payment methods represented as URL strings. Pay with Google, Apple Pay, Samsung Pay, Alipay are good examples. Card information is securely stored and typically returned as a tokenized text from the Payment Request API.

The Payment Request API changes whole ecosystem, but it’s not a silver bullet that takes care of payments end to end including processing. It’s a very common misconception, but you still need to deal with payment service providers (PSP).

Google’s Payment Request API documentation describes the API in detail, but leaves integration with a PSP part untouched. In this article, I’d like to give you ideas of how to integrate with a PSP.

For simplicity’s sake, I’ll focus on the credit card payment (basic-card) case in this article. This article may not apply to other payment methods, such as Pay with Google, Apple Pay, Samsung Pay, and Alipay.

What’s the current payment experience and integration like?

When you try to pay online using a credit card, you usually see a web form like this:

This form includes fields for cardholder name, card number, expiration year/date, and CVC code. By submitting this form, the merchant will receive these pieces of information to process the payment on behalf of the user.

Behind the scenes, most of the merchants send these information to a payment gateway or a payment processor (PSP, Payment Service Providers in this article) in order to process a payment and make an actual money transfer start.

There are roughly three types of integration patterns you can choose to connect with a PSP in general. Let’s see how each of them look like.

API Type Integration

The first integration pattern is called API Type. It’s straightforward, but requires relatively high technical skill to implement.

A merchant submits credit card information to their own server through a form. The server then forwards the information to a PSP through their API. PSPs usually provide a server side SDK to help implement these integrations.

Link Type Integration

Link Type is the easiest way to integrate with a PSP among three. Though flexibility of design and its user experience are not sophisticated, even a non-technical webmaster can integrate with a PSP using this type.

When a user is about to make a payment, the merchant forwards the user to a PSP-hosted page with a form to accept credit card information. The payment info the user submits through the form will be directly passed to and processed by the PSP. The user will then be brought back to the merchant webpage to (hopefully) find the payment is complete.

Tokenization Type Integration

The most modern approach among these three is Tokenization Type. This integration allows a merchant to gain security, convenience, and design flexibility at the same time.

Unlike Link Type, a form is shown in a merchant hosted page, but it’s actually served from a PSP’s domain through an iframe. User’s submission of card info will be directly passed to the PSP’s server, and the merchant will receive a token as a result. The merchant can then verify it through their server and ask the PSP to process the payment.

The point here is that most of these operations are handled by PSP’s client side SDK, which allows the merchant to process payments without touching a single digit of a user’s credit card number.

How can this be applied to the Payment Request API?

OK, now let’s think about how these patterns can be applied with the Payment Request API. Here’s a snippet of code you would use to invoke the API:

let request = new PaymentRequest(methods, details, options);
request.show().then(paymentResponse => {
  // process payment
});

Upon the user pressing “PAY”, the payment request will be resolved and you will receive a paymentResponseas the payment information. If the user chooses to use a basic-card as a payment method, it would look like this:

{
  "methodName": "basic-card",
  "details": {
    "cardholderName": "Jane Doe",
    "cardNumber": "4242424242424242",
    "expiryMonth": "12",
    "expiryYear": "2020",
    "cardSecurityCode": "111",
    "billingAddress": { ... }
  },
  "shippingAddress": null,
  "shippingOption": null,
  "payerName": null,
  "payerPhone": null,
  "payerEmail": null
}

You can then use the payment information part of it (details) to process the payment.

Let’s apply this information to the integration patterns I have described earlier.

API Type

This pattern is rather straightforward. Just send the payment info to the server, parse it, and then send it to a PSP’s API.

The important caveat here is that you need PCI compliance to integrate using this type, because you are obviously treating raw credit card information. PCI SAQ A won’t qualify, you should have PCI SAQ A-EP or PCI DSS. If you don’t know what I’m talking about, consult with your PSP. Unless your company is large enough, spends money and makes an effort to comply with PCI, you are not eligible to choose this option (except some countries that don’t prioritize PCI DSS).

Link Type

As you can easily imagine, the point of Link Type is to decouple the payment system from a merchant website. This means using the Payment Request API with the Link Type integration is theoretically not possible. You have to defer the Payment Request API calls to your PSP.

Tokenization Type

The Tokenization Type pattern is an interesting one. With this integration, you would send payment information to a PSP server to obtain a token in return. This allows your server to not deal with raw credit card information completely, keeping you away from requiring PCI compliance — unfortunately, this is wrong.

The fact that handling credit card information on the client side doesn’t require PCI compliance was a thing before PCI 3.1. PCI DSS 3.2 clarified it requires PCI SAQ A-EP or PCI DSS if you handle raw credit card info on the client side. In fact, the reason the Tokenization Type is so complex is to align with the easiest option for PCI (SAQ A) and never make a merchant touch such sensitive information, but yet enable them to integrate with their system.

OK, then, what does this mean to you? This means, in order to implement the Payment Request API with basic card, a merchant ought to be PCI compliant, otherwise defer it to a PSP.

In fact, some PSPs already started supporting the Payment Request API as part of their Pay with Google support (ex: Stripe, Braintree).

Conclusion

In order to bring the Payment Request API and let users see the Payment Request sheet on your website, you have two options:

If you have PCI compliance (PCI SAQ A-EP or PCI DSS), implement the Payment Request API yourself using the API Type integration.
If you don’t have PCI compliance (or PCI SAQ A), wait for your PSP to support the Payment Request API and use it through the Link Type integration or via their SDK as the Tokenization Type integration.

Some people may be disappointed to find that PCI compliance is still a requirement to implement the Payment Request API. But consider this is a path to the brighter future.

In the next post, I will describe how basic card is positioned, why it’s needed, what are payment apps and what the future would look like.

Special thanks to my colleagues and Daniel Heffernan from Stripe for reviewing this post.

Addressing common misconceptions about the Payment Request API

Eiji Kitamura — Wed, 15 Nov 2017 06:32:20 +0000

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.

How payment methods work in the Payment Request API

Eiji Kitamura — Wed, 18 Oct 2017 06:52:33 +0000

The Payment Request API makes it easy for a browser to pass known credit card details to a merchant. The API can also accept payments through apps which process payments anyway they wish, e-money, bank transfers, bitcoins, etc.

This article explains how payment method concept in the Payment Request API works so you can get a better view of the future of the Web Payments and possibly develop your own payment method.

Let’s dive in.

Payment methods are like plugins for Payment Request API

The first argument you give to the Payment Request API is a sequence of payment methods.

Each payment method consists of a required payment method identifier (supportedMethods) and an optional detail of the payment method (data).

In following example code snippet we declare 2 payment methods:

The basic cards; Visa, Master, JCB: basic-card
Android app that is built to integrate with the Payment Request API: https://bobpay.xyz

var methodData = [{
 supportedMethods: ‘basic-card’,
 data: {
   supportedNetworks: [‘visa’, ‘master’, ‘jcb’]
 }
}, {
 supportedMethods: ‘https://bobpay.xyz'
}];

A merchant can provide these as acceptable payment methods, so when a customer is visiting the site they will see the cards and apps filtered by the ones that are available to the user and select one to make a payment.

Payment Method Identifiers

There are two types of payment method identifiers:

Standardized payment methods, e.g., “basic-card”
URL-based payment methods, e.g., “https://bobpay.xyz”

Standardized payment methods

The Payment Request API example code illustrates that “basic-card” must be the most commonly used string for a payment method identifier. This is categorized as a standardized payment method and it’s actually supported by all browsers by default that implement the Payment Request API.

Payment Method: Basic Card (basic-card): A payment method that provides credit, debit and prepaid card payment information.

You can provide detailed definition by adding data property to the payment method data. supportedNetworks indicates which credit card brand you support and supportedTypes indicates which type of cards ( credit, debit and prepaid) are supported.

As you can imagine, there’s a registry of payment methods in the spec for standardized payment methods. basic-card is one example, but as of October 2017, no others exist yet in the registry. A few candidates are under active discussions:

Basic Credit Transfer Payment (basic-credit-transfer): A payment method to transfer money between bank accounts.
Tokenized Card Payment (tokenized-card): A payment method that provides tokenized card information.
Interledger Payment Method (interledger): A payment method that transfers money using the interledger protocol.
Basic SEPAmail Payment (sepamail): A payment method that supports payment by SEPAmail Applications such as RUBIS, GEMME or JADE.

URL-based payment methods

URL-based payment methods are usually represented using a URL string such as “https://google.com/pay" or “https://www.alipay.com/webpay". They represent a payment method and are usually tied with a particular payment app; but they don’t necessarily represent a one-to-one relationship. It’s totally possible one payment method is supported by multiple payment apps, or one payment app supports multiple payment methods.

For example, a third party payment app can support the basic-card as well as its specific https://bobpay.xyz payment method.

Unlike standardized payment methods, URL-based payment methods have no registry of payment methods. Anyone can develop and provide their own payment apps that support the payment method. This allows the Web Payments concept to develop a huge payment ecosystem on the web.

If you are interested in developing your own payment app, checkout Payment Method Manifest and see how a URL-based payment method identifier is converted to a concrete payment method. As of October 2017 only Android native payment apps are officially supported on Chrome, but web based payment apps support is coming too.

Android native payment apps specification is not standardized since it’s operating system specific, but an integration guide can be found here. Check it out if you are interested in developing your own payment apps for Web Payments ecosystem.

Summary

The concept of payment methods in Payment Request API is quite simple, but it is extremely important to understand the larger architecture. Hopefully many payment apps will emerge to make the Web Payments ecosystem more flexible and usable.