It’s been a while since my previous post, but Web Payments team at Google including myself have been commited to work on improving it. Some may wonder what’s giong on with it, so let me share my talk at an online event called “web.dev LIVE” which Google’s Web DevRel team organized early July 2020.
It’s a short video, but it contains:
Most importantly, we’ve published a set of documentation that explains how to build a native and a…
Many people are confused about the differences between Web Payments, Payment Request API, and Google Pay. In this article, I’ll clarify the differences and explain my recommendations for what merchants should implement.
With the Payment Request API, payments on the web are drastically simplified. The UX can be consistent across websites, making it easier for users to enter and reuse their personal information such as shipping address or payment details. It also enables various payment methods on the web.
Let me quickly recap important payment concepts:
basic card — A payment method natively implemented to all Payment Request API capable browsers (Chrome, Samsung Internet, Edge). Card information is usually shared with form autofill data and returned as plain text from the Payment Request API.
The Payment Request API makes it easy for a browser to pass known credit card details to a merchant. The API can also accept payments through apps which process payments anyway they wish, e-money, bank transfers, bitcoins, etc.
This article explains how payment method concept in the Payment Request API works so you can get a better view of the future of the Web Payments and possibly develop your own payment method.
Let’s dive in.
The first argument you give to the Payment Request API is a sequence of payment methods.
The Payment Request API was first made available in a production browser on Chrome for Android in July 2016. It’s the very first open web feature solely focused on “payment” and is expected to evolve the entire web platform and its ecosystem in the coming years.
In this article I’ll call out some common misconceptions about the API and try to address them as comprehensively as possible. If you have zero knowledge about the Payment Request API, you should probably read this page first.
These are all incorrect; it’s called “Payment Request API” (PR API). And it’s not just a…
A big shift to mobile is still undergoing. Increasing number of people are moving to mobile only.
In mobile, screen size is not the only difference. It’s ubiquitous, connection is flaky, input methods are touch-based, users are easily distracted. Subtle yet important differences are countless.
To win the business in this mobile world, seamless and speedy experience is the key differentiator. E-commerce is a great example.
Data shows 66% of mobile checkouts are done on web sites rather than on native apps. …
This is a recollection of my part of the talk at Chrome Dev Summit 2016 titled “Sign-in on the Web — Credential Management and Best Practices”.
Check the video for my colleague Sabine Borsay taking the first half of the talk describing the unique challenges we face on the web when personalizing user’s experience through sign-ins.
Unlike native apps, the web needs considerations for different attack surfaces and threat models such as XSS, CSRF, clickjacking, etc — as a result, session management has very different requirements on the web and on native.
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…
Developer Advocate of Web at Google in Tokyo. Chrome, HTML5, Payments, Identity