Mobile checkouts are a terrible experience. Consumers know this. Merchants really know this.

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


The new PaymentRequest API is currently available (only for credit cards, not Android Pay yet) in Chrome 52 on Android. 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 => {

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 = ''
    .then(function (canMakePayments) {
      if (canMakePayments) {

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:

Where web payments are going

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.

If you have any comments, please reach out to me @jcarp!