A New Way to Pay on the Web – About Web Payments and the Payment Request API
by Eiji Kitamura
In my previous post, I wrote about ideas for improving the web checkout flow by optimizing forms. This time, I'll discuss an approach using a new standard API.
The difference is visually quite striking, so please take a look at this first:
You can try the demo here (you cannot actually purchase items, and credit card information will never be sent to the server).
As you can see, a dedicated payment user interface is used instead of traditional forms. In fact, this UI is not built by the website itself—it is provided by the browser. By invoking it, site operators can collect accurate payment information from users much more effortlessly than with conventional forms. What makes this possible is the Payment Request API, which I will introduce in this post.
The Payment Request API is a central building block of Web Payments, a suite of specifications aimed at standardizing payments on the web. The key components comprising Web Payments include:
The Payment Request API has been supported since version 53 in Chrome for Android, and other browsers such as Microsoft Edge and Samsung Internet Browser already support it as well. Chrome for Desktop is also scheduled to support it starting from version 61.
What is the Payment Request API? #
Essentially, what you can do with the Payment Request API is replace forms. Please note that it does not process payments by itself. In other words, all this API does is retrieve payment information; developers must handle the subsequent payment processing separately.
The information you can collect using this API includes:
- Shipping address
- Shipping options
- Payment method
- Payer contact information
Payment Request Flow #
If you watch the earlier video carefully, you can see several distinct steps:
- First, the user selects the items to purchase. Up to this point, everything happens normally within the website.
- Once the items are decided, the user taps the purchase button. At this moment, the Payment Request UI is displayed.
- The UI displays the following information from top to bottom (in Chrome's case), where the user selects their shipping address, payment method, and so on:
- Site name and domain
- Details of the items being purchased
- Shipping address
- Shipping options
- Payment method
- Contact information
- Tap the pay button
- Enter the credit card CVC number
- Purchase complete
There are three key points worth noting here.
Leveraging Autofill for Shipping Addresses and Contact Info #
Shipping addresses and contact information can be populated from data stored in the browser's autofill. Of course, users can also enter new details on the spot, but if they have entered them before, they can select them with a single tap. (This connects back to the previous post: restructure your forms so they can be parsed accurately.)
Leveraging Autofill for Credit Card Information #
Just like address information, credit card details—such as card number, cardholder name, and expiration date—can also be populated in a structured format. In this case, the CVC number (the 3- or 4-digit code on the back of the card) is not included in the autofilled data, so the user is prompted to enter it each time they finalize the payment as an authorization step.
In Chrome, in addition to credit card details saved in the browser, cards stored in Google Payments via the user's Google Account can also be used. (Similar integrations seem to be in place with Samsung Pass in Samsung Internet Browser and Microsoft Wallet in Microsoft Edge.)
Dynamic Updates Based on Shipping Address and Options #
The Payment Request API can also flexibly present "shipping options," such as free shipping or express shipping for an additional fee. It can also adjust shipping costs depending on the region, or even indicate that shipping is unavailable for unsupported areas. Naturally, the total amount updates automatically based on the selected shipping fee.
Completing the Payment #
Once the user verifies the details in the Payment Request UI and taps the "Pay" button, credit card CVC verification is performed, and only then is the data handed over to the website. The information passed at this point is JSON-formatted data containing raw credit card numbers and address details. How developers use this is up to them, but typically it is forwarded to an intermediary known as a Payment Gateway or Payment Processor to handle the actual fund transfer.
For detailed implementation instructions on the Payment Request API, please refer to the Japanese documentation.
Does Safari Support the Payment Request API? #
Update (2017/08/24): A flag for the Payment Request API was implemented in Safari Technology Preview 38, and its status has changed to "In Development." Hooray!
In Japan, where iOS has a large user base, this is probably the most frequently asked question. Safari has its own feature called Apple Pay JS. In short, it allows users to pay using Apple Pay on the web. While I'll leave the detailed differences for another time, their API structures are quite similar. Because of that, I published a library called appr-wrapper that lets you handle Apple Pay JS as if it were part of the Payment Request API. You can try it out on this site in both Safari and Chrome (you won't actually be charged even if you complete a payment).
Summary #
In this post, I discussed replacing traditional form-based payment information collection with the Payment Request API. However, some of you might feel that UX improvement alone isn't a compelling enough reason to adopt it. With numerous security incidents still being reported, many developers are likely concerned about the risks of handling raw credit card data.
The Web Payments standards are continuously being developed with solutions to these very problems in mind. I hope to cover that in upcoming posts.