Where Web Payments are Going

I gave a talk at the SF Payments Engineers meetup about Web Payments. Here’s the blog-ified version of that talk. Check out the slides from my talk here.


Mobile checkouts are a terrible experience for customers. Both consumers and merchants are both feeling the pain. Mobile checkouts convert about 66% worse than desktop checkouts.

A slide from the PaymentRequest presentation at Google I/O 2016.

Part of the problem is that every company needs to build their own credit card form. Checkouts range from great UX to terrible UX, but the heterogeneity is what really makes it a pain for consumers.

Apple and Google have set out to fix this problem by starting to develop standard browser APIs for collecting payment method details (like credit card numbers). Let’s take a closer look at these solutions from the perspective of a Front-End engineer.

Work happening right now

Google demoed the new PaymentRequest API at Google I/O in May 2016. It’s a new JavaScript API being worked on by the W3C Payments working group. It is currently available in Chrome 52 on Android.

Apple demoed Apple Pay on Safari at WWDC in June 2016. It is currently available on macOS Sierra and iOS 10.

Both Mozilla Firefox and Microsoft Edge have expressed interest in implementing PaymentRequest.

Apple and Google are shooting to have their new browser payment APIs ready before holiday season 2016.

Try it yourself

PaymentRequest

The new PaymentRequest API is currently available in Chrome 52 on Android (only for credit cards, not Android Pay yet). To initiate a PaymentRequest, first you must define your supported payment methods.

var supportedInstruments = [{
  supportedMethods: ['amex', 'mastercard', 'visa'],
}]

The values in the array above are part of a W3C specification in development called Payment Method Identifiers. After that, define the purchase details:

var details = {
  total: {
    label: 'Donation',
    amount: {
      currency: 'USD',
      value: '55.00',
    },
  },
  displayItems: [{
    label: 'CatDog',
    amount: {
      currency: 'USD',
      value: '65.00',
    },
  }],
}

Initiate the PaymentRequest by instantiating it with the previous two objects. It returns a promise with the payment information (raw credit card details, Android Pay token, etc.).

new PaymentRequest(supportedInstruments, details)
  .show()
  .then(instrumentResponse => {
    console.log(instrumentResponse)
  })

Here’s what PaymentRequest looks like on Android Chrome 52.

Apple Pay in Safari

First we need to verify that the merchant session is valid. If it is, we can show the Apple Pay button.

// Define session variable to be used later
var session

// Verify merchant session is valid
if (window.ApplePaySession) {
  var merchantIdentifier = 'merchant.com.canine-clothing'
  ApplePaySession.canMakePaymentsWithActiveCard(merchantIdentifier)
    .then(function (canMakePayments) {
      if (canMakePayments) {
        showApplePayButtons()
      }
    })
}

Next, we define the options we’ll pass to ApplePaySession.

var paymentRequest = {
  currencyCode: 'USD',
  countryCode: 'US',
  total: {
    label: 'Canine Clothing',
    amount: '19.99',
  },
  supportedNetworks: [
    'amex', 'discover', 'masterCard', 'visa',
  ],
  merchantCapabilities: ['supports3DS'],
  requiredShippingAddressFields: ['postalAddress'],
}

Next, when someone clicks our Apple Pay button, we call new ApplePaySession to pop up the dialogue.

$('.apple-pay-button').on('click', function () {
  session = new ApplePaySession(1, paymentRequest)
})

The first parameter to ApplePaySession, 1, is the API version number. This doesn’t seem like a common practice and it’d be interesting to find out more about the API design decision behind it.

Here’s what the Safari Apple Pay transaction consent dialogue will look like on desktop along with the iPhone consent dialogue:

Apple Pay vs. PaymentRequest

Both of these are pretty similar APIs. Here is how they differ:

Apple wants to eventually integrate Apple Pay with PaymentRequest. The team sent this email to the W3C Web Payments Working Group the day Apple Pay in Safari was announced:

Incentives and Conclusion

All this leads to the question: will payment providers move to adopt these new web payments APIs? what are the obstacles?

Let’s look at the incentives for each player in the value chain:

Merchants (e.g. Nike, HotelTonight)

Payment Gateways (e.g. Braintree, Stripe)

Their best interest is in supporting as many payment methods as possible. PaymentRequest and ApplePaySession are effectively new payment methods, so I predict that payment gateways will move to support them.

Acquiring Banks (e.g. First Data, NAB)

Issuing Banks (e.g. BofA, Chase)

Networks (e.g. American Express, Visa)

Given the tradeoffs and mutual benefit for everyone in the network, I predict that once new web payments APIs stabilize, the payment industry will quickly move to adopt them.