DEV Community

Eiji Kitamura for Google Web Dev

Posted on • Originally published at Medium on

How payment methods work in the Payment Request API

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.

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:

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.


Oldest comments (0)