This is a recollection of my talk at Polymer Summit 2016 titled “Sign-in and Payment without Forms”.

Last month, I was going to purchase a TV rack. I’ve been wanting one for a long time since I bought a stereo amp by sony last year. Because my old TV rack was too narrow to put my 2 speakers beside TV, I was expecting a wider one would give my family better ambience for listening to music or watching movies.

Purchasing a furniture online without touching actual device is kind of challenging. So I and my family went out to look for one, found an ideal TV rack in a relatively large shop. But unfortunately, they were out of stock. So we decided to purchase it online.

Looking at a catalogue and its product number, I could quickly find the same product in a small e-commerce website way cheaper (about 20%) than the shop I visited. So I decided to buy one there — on my phone.

According to a research, 66% of mobile purchases are through website, rather than native apps. That’s great to know. Why would I install a native app, create an account then finally purchase a stuff?

So I continued to checkout form to finalise purchase. But eventually… gave it up.

The reason was that the entire experience filling out the form and requiring me to create an account was so frustrating. Browser’s form autofill feature does help in general, but in that website, it didn’t work out quite well. Imagine how painful typing address, credit card and a password using tiny software keyboard on a phone.

The same research tells that conversion rates on mobile web is 66% fewer than that of desktop web. Even for returning users, remembering and typing password is a pain. Another research tells that 92% of users leave the site without resetting or recovering the account if they forget their password.

Web forms are causing lots of friction and we need to fix them.

Web standard recently introduced 2 new APIs that help users and developers overcome these situations. Payment Request API and Credential Management API.

Polymer Shop demo

So to demonstrate these 2 new APIs and how they play nicely together, we added them on Polymer Shop.

Let’s see how it works.

Say I’m looking for a sweater for upcoming winter. Let’s explore the shop. Found a nice looking hoodie. The price looks feasible. Let’s purchase. Press “BUY NOW” button. Now a dialog pops up. This is possible by using the Payment Request API. There are multiple shipping address information listed despite I’m not signed in. These came from the browser’s autofill feature. Let’s select one. A credit card number is also available. Once all information looks good, proceed to “PAY” to make actual purchase. I enter my CVC code and go. Behind the scenes, submitted information will be delivered to a payment gateway and process the payment. (But as this is a demo, it’s not actually transferred to anywhere.) Payment successful. So I went through my entire payment experience without filling out a form. And I didn’t even sign up or sign in to the shop. This is called “guest checkout”. After the guest checkout, I’m navigated to an account creation page. It offers 10% discount for my next shopping, that’s nice. Let’s create an account. Nice thing about this account creation form is that my email address is already filled. The email was provided as a part of the Payment Request API. So I can sign up to the site just by providing a new password. And my account is created. Now I see a new dialog asking if I want to store the credential information. Why not? “SAVE”. This information is stored to the browser and sync’d across devices as long as I’m using the same Chrome profile.

I’m on a different device. Let’s launch the same website. Because the credential information I have stored on previous device is propagated to this one through Chrome Sync, it’s available here as well. And even better is that I’m signed into the website without a single tap. This is called “auto sign-in”. This is possible by using the Credential Management API.

What is Payment Request API?

Payment Request API provides a standard compliant online payment flow.

Usually, making payment on the web requires a lot of information to be filled and submitted through forms. With Payment Request API, instead of filling out forms, users can make purchases just with a few taps.

If there are no address or credit card information available, users can add them on the fly on top of the same native UI. The address information can be stored and sync’d across devices and available from anywhere throughout future shopping experience.

The best part of using Payment Request API is that once those information is stored to the browser, we basically have all the data necessary to get through a checkout flow without creating an account. Even for the users who have never visited your website before can easily make purchases.

Payment Request API also allows third party payment methods to be part of the ecosystem. Anyone will be able to provide an app or a web app for merchants to process a payment in the future. One of such effort, Android Pay for Payment Request API is currently in beta.

To learn more about Payment Request API, follow g.co/PaymentRequestAPI. There are bunch of other resources linked from the bottom of the document.

Payment Request API integration with Polymer Shop

So, how did we integrate the Payment Request API into Polymer Shop experience? We created a `<shop-payment-request>` component which has no UI.

Nice thing about making it a web component is that some of predefined parameters can be set as element attributes declaratively like this:

<shop-payment-request

id=”payment”

currency=”USD”

supported-methods=”[‘visa’, ‘mastercard’, ‘amex’, ‘discover’]”

request-payer-email></shop-payment-request>

Requesting payment can be done through a function call. Because it returns a promise, you can continue by sending the result to a payment gateway when the promise resolves.

this.$.payment.buyItem(itemDetails, total)

.then(function(response) {

this._processPayment(response);

});

What is Credential Management API?

Credential Management API provides websites with a programmatic interface to the browser’s password manager, in a secure way. You can obtain and store user’s credential information using this API.

As you have seen at the Polymer shop demo, you can enable auto sign-in by POST’ing obtained credential info to the server on behalf of a user.

Sign-in using a third party identity such as Google or Facebook etc. is quite popular because it allows users one tap sign-ins. The problem is that it can not be remembered by the browser like passwords.

But Credential Management API can do it. It can store and retrieve the choice of those accounts, then you can invoke identity provider specific authentication flow to let the user sign-in.

Even if you choose not to use auto sign-in, you can still skip the sign-in form using account chooser without typing a password. This feature is also useful for those who have multiple accounts stored.

Android apps have a similar feature called Smart Lock for Passwords. By associating your Android app and your website, you can share the same credential information through the same Google account and its password manager.

To learn more about Credential Management API, we provide documents, a demo app, sample code and a codelab. Follow g.co/CredentialManagementAPI especially Credential Management API Integration Guide.

Credential Management API integration with Polymer Shop

We started by simply building <shop-account> component which basically provides the Form UI. It also included

Authentication logic including interaction with a server

Federated login logic

Credential Management API

Other UIs such as page loading, or notifications

Profile data

all together.

But because some features need to be used by other parts of the app, we’ve created a separate component called <shop-account-data>. That way, we could split view and logic of <shop-account> and made entire app’s architecture much simpler.

By adding <iron-meta> behaviour to the <shop-account-data>, we’ve made it available anywhere in the app. <iron-meta> makes a kind of alias for a component keeping it monostate.

<iron-meta id=”accountData” type=”account”></iron-meta>

Also, by returning a promise, things got much simpler by chaining functions to reflect results to the UI depending on the context.

shop-app.html ready: function() {

this.$.accountData.autoSignIn(true)

.then(function(profile) {

this.fire(‘show-snackbar’, {

text: ‘You are signed in!’

});

}, function(err) {

// Do nothing

});

}

shop-account.html var form = this.$.loginForm;

this.$.accountData.signIn(form)

.then(function(profile) {

this.fire('show-snackbar', {

text: 'You are signed in!'

});

}, function(err) {

this.fire('show-snackbar', {

text: 'Signed in failed.'

});

});

Summary

Payment Request API brings a standard compliant online payment flow. Credential Management API brings a programmatic interface to the browser’s password manager.

In Polymer Shop experience, we’ve enabled a guest checkout experience and demonstrated a frictionless sign-up / sign-in flow.

I’m hoping the day will come soon where entire shopping experience will be done on mobile web without friction caused by forms.

Thank you!