The online checkout process has problems. The average checkout has nearly 15 fields to fill out, and lengthy, complicated checkout processes are the second highest reason for cart abandonment. Mobile users have it even worse—despite the stellar growth of mobile traffic, actual checkout conversions are half as likely on mobile as they are on desktop. Burdensome navigation and difficulty entering payment information were two of the top three reasons why mobile users do not complete checkout.
Related: Progressive Web Apps Are Here and They’re Changing Everything
Browser makers have tried to take the burden off of users with technologies like Autofill, but this doesn’t improve performance issues and can lead to entering incorrect information. Payment services like Paypal or Amazon Pay attempt to fix some of these shortcomings, but they only apply if the user has already signed up for the service. Even then, it’s still a long handoff from user approval on a service site to payment on an ecommerce site. However, there is a better solution for online checkout in the form of the Payment Request API.
Payment Request API to the Rescue
As the Payment Request API becomes more popular, new users to your site are likely to have their information stored from previous sites and would be ready to checkout with a single tap.
The Payment Request API—a W3C recommended candidate as of March 2018—is an interface between the browser, the site, and a variety of payment methods. Instead of directing users to a new page, the API allows them to enter their billing and payment information into a browser dialog. Once users have that information stored in their browser profile, they will find the values prefilled with the option to enter new information if desired. The API can be used for any site that accepts payments; it can be implemented in Magento, Salesforce Commerce Cloud, custom sites, etc. It is not OS or app dependent, and can be used on desktop or mobile.
Payment Request API Features
The API allows a user’s information (payment information, shipping address, etc.) to be stored and reused in future checkouts at the browser level. As the Payment Request API becomes more popular, new users to your site are likely to have their information stored from previous sites, and would be ready to checkout with a single tap.
The API also speeds up the page performance because it requires fewer server requests. Because most (or all) of the checkout information can be represented in the dialogs, there is no need to load multiple pages for each step of the checkout. Equally, there’s no scripting necessary to produce a one-page checkout because the dialog provides the functionality. It also allows the user to use alternate payment services without adding iframes and APIs to support them. Finally, it reduces the page weight because the browser generates the fields, validation, and styles used by the dialog.
Another double-sided benefit, the API is more consistent for both users and for developers. The average site has its own checkout flow and styles. Sites built on a common platform might have similar fields or flow, but most want to keep the sites branding and unique feel through the checkout. This means that a new user will need to “learn” your site in order to check out. Request Payment API allows the checkout page to be branded along with the site, while the form users fill out is consistent across all sites using the API. Users won’t need to learn anything new to check out on your site. And once a user enters their billing and shipping address and a card, checkout might be a one or two-click processes.
By allowing the browser to control input and information management, we can be sure accessibility tools will know how best to allow users to check out.
For developers and site architects, there is a much lighter burden to produce an effective UX/UI. The browser handles the entering, storing, and retrieving the name, payment information, billing, and shipping information.
By allowing the browser to control input and information management, we can be sure accessibility tools will know how best to allow users to check out. As it is now, tools rely on guesses and complicated markup hints. The API also ensures that keyboard navigation is present and validation messages are consistent and helpful.
Using the API, developers can request information including:
|Contact Information||Shipping Methods|
It Provides Shoppers with Choices
In addition to basic credit/debit card support, developers can add support for alternate payment apps like Apple Pay, Google Pay, Paypal, etc., which gives shoppers the option to pay with the method they prefer. Simultaneously, developers have a lower barrier to allow the acceptance of these alternate payment sources, and users who don’t want or have them don’t need to see them (or download code at checkout to support them).
The Payment Request API is a perfect progressive enhancement for sites that already have a traditional checkout, but want to provide applicable users with the best experience possible.
Currently, the Payment Request API is available in all major browsers except Internet Explorer, older versions of Safari, and Firefox (where it is functional but disabled in the browser settings). The API is not a Google/Chrome/Android specific product, but Google does provide excellent documentation, as well as a developers demo site, if you’re interested in seeing how it performs.