Where Web Payments are Going

Published Jul 31, 2016 in Front End, Payments, Software Engineering, Talks

I gave a talk at the SF Payments Engineers meetup about Web Payments. Here’s the blogified 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.

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 Pay requires a merchant session
- You need to generate a merchant session on the server before beginning each checkout session
- This requires a new certificate (separate from your Apple Pay certificate)
- Apple doesn’t have complete docs on this but Tom Dale reverse engineered the protocol and open sourced his Apple Pay Merchant Session Server to demonstrate what the endpoint will need to do.
PaymentRequest supports itemization
PaymentRequest is payment-method agnostic

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)

Upside: customers have better payment UX, potential to increase mobile conversion
Downside: requires engineering time to implement (potentially reduced via work done by payment gateways)

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.

Upside: offer better UX to merchants
Downside: requires engineering time to implement

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

Upside:
- No further work is needed to support credit cards
- If these banks have already done the work to accept Apple Pay and Android Pay, no further work is needed there either
Downside:
- None

Issuing Banks (e.g. BofA, Chase)

Upside:
- Consumers potentially use their cards more
Downside:
- None

Networks (e.g. American Express, Visa)

Upside:
- Consumers potentially use their cards more
Downside:
- None

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.

jeffcarp

Software

Life