Better Payments for the Web with the Payments API

(upbeat music) - Hi everyone, this is Eiji thank you for watching Better Payments for the Web with the Payments API.

Marcus from Mozilla gave a great talk about Web Payments at Web Directions Code three years ago. But in this session I'd like to recap what Web Payments is along with some updates to the APIs.

The Web has been struggling to provide a good way to make payments for a long time.

Let me show you some examples.

Some countries use Bank transfers.

One example I learned from my Indonesian colleague is very unique.

An online shop uses bank transfer as their primary payment method.

Even though they don't have an actual bank transfer integration implemented into their system.

What they do is to charge their customers additional random three digits to the total price, who that when they received the money through bank transfer, they can identify and verify the customer with a price before they can ship the purchased item. Most common way of making payment in many countries is to use a Credit card.

Just by entering a Credit card number, card owner's name, a verification code, and some other information in a form the customer can let the shop take their money. But the typical pitfall is that customers sometimes fail to fill the form properly or in the worst case, they give up on buying them item resulting in a poor conversion rate.

If you think about successful online payment flow in-app billing in the native app word is a great example.

You mentioned Google place in-app billing for example, it's so easy to make payments there.

Why is that? The biggest reason I can think of is constraints because the Payment API is restricted to the Marketplace specific one, that platform already knows who the user is and the customers don't need additional sign in. The payment method up is usually configured in advance. So the flow is simple.

The UX is consistent across different apps, so that users all easily getting used to it. That's great.

Then why don't we do similar things on the Open Web? And that's what Web Payment apps are trying to achieve and why they are becoming more popular nowadays. A Payment app is a native app or a Website where customers can register their bank accounts or Credit card numbers. When a customer is at an online shop and if the sub shop supports the Payment app, they can choose to launch the Payment app and make payment with just a few Tabs.

Using Payment apps helps, not only raise the conversion rate, but also make the transaction secure down form based payment because payment credentials are encrypted end to end, and it's hard for merchants to mess with it. The challenge with Payment apps is they have different deeper Professing Interfaces. That means Developers at Online Merchants, need to learn different proprietary APIs for different payment apps.

That's where Web Payments can help, Web Payments provides an open rail for payment apps, regardless of native apps or Websites.

They can also extend the user experience to be more streamlined with merchants because it's payment method agnostic.

You can support credit cards, bank transfers, direct carrier billing, e-money, cryptocurrency, whatever you want.

Let's take a look at how they work.

This is an example of a mobile native payment app using Web Payments, notice how native payment app is launched right in front of the merchant Website. And after the payment authorization, the app is closed and the customer is right back at where they were, on the merchant and confirm the payment.

In existing mobile native payment app integrations. The app is launched in a completely different context and the customer is redirected back to the merchant static payment confirmation page when the payment is authorised.

This is because an app is launched using an intent, and it's basically an app switch from the Browser. After the customer's payment authorization, the app opens a new Tab in the Browser to bring the customer back to the merchant and let them know the payment is authorised. The Web payment makes the user experience more streamlined into the merchant purchase flow. This example shows how a Mobile Website acts as a payment app using Web Payments.

The user experience here, is very similar to what you have just seen with the mobile native payment app.

This model and in context with the merchant website, one notable difference here is unlike native app with best payment app. Doesn't need an installation of itself in advance. I'll cover why that is later in this session. If you compare it with existing implementations, without Web Payments, the app is launched as a popup, an eye frame or redirect.

With Web Payments, you can expect a consistent and more sophisticated user experience.

Building a payment app using the web technology also means it works across platform, and that's why the same web based payment app can be available on Desktop and displayed within a small dialogue attached to the Browser Chrome.

Responsible design makes it available across Desktop, Mobile and different Browsers and platforms. You have just seen a few payment flows in action, but there are a couple of important players involved.

Merchant, the filler of products and payee of a payment transaction.

I believe most of you who are watching this video, will fall into this category.

Payment Handler, the provider of payment methods, which helps customers to pay money.

Both merchants and payment handlers have very unique requirements and they have respective dedicated APIs on the Web Payments.

The Payment Request API, is an API for merchants to invoke a payment app and receive a returning payment credential. It can also help merchants handle shipping address, shipping options and the contact information. The payment Handler API, is an API for payment handlers with Web-based payment apps, which received a payment request and returns a payment credential.

It can also help the payment handlers to provide customers shipping address and contact information to merchants.

Both of these APIs are being standardised at W3C Web Payments Working Group.

In fact, it's the first time for the web to have dedicated API for payment. Let's have a closer look at how each APIs work.

In a minimum payment request API call.

The merchant provides two information, a payment method identifier, and the total price.

The total price is of course the total price of the items that customer is about to purchase.

The payment method identifier is an interesting one.

It takes a form of URL which keeps Web Payments an open and thriving ecosystem.

Anyone can define their own payment method identifier and let merchants use it.

Based on the payment method identifier, the Browser discovers adjacent best payment method manifest, and then our web app manifest.

And finally, the brother determines an eligible payment app to launch either a native payment app or a web-based payment app.

By calling show method the app is launched after the customer interact with the app and authorises a payment.

The payment credential is returned.

The merchant then verifies the credential and finalises the transaction.

This is how the payment request API works on merchant side. Now let's flip over to the Payment Handler side on registration of a service worker is a requirement for our web-based payment app. However, as I mentioned earlier, it doesn't need to be registered in advance because the Browser can register the service worker just in time.

The service worker receives a payment request event. When the merchant called show method, it can then Open the Window to start our User Interaction.

The content of the Window is just a Website, ideally a PWA and how it is built is completely up to the Developer.

In fact, you don't have to build anything new and just continue using the existing Website. It's just small updates and the service worker to add up to Web Payments. Once the customer authorises a payment, resolves the promise with a payment credential so that the merchant can verify that to then finalise the payment.

For native app, you don't need a service worker to be registered. All you need to do is to set the manifest properly and receive a PAY intent, so that the app will be invoked and return a resulting payment credential when the customer authorises.

It's very simple.

If you're a payment handler and have a large number of native payment app instals consider integrating it with Web Payments.

If you hold a large number of customers payment information, you may consider integrating your web-based payment app with Web Payments.

There has been some confusion between Web Payments APIs and Wallets Specific JavaScript APIs, to clarify Web Payments APIs, such as Payment Request API and Payment Handler API are low-level webpack from print tips that are double Susie standard proposal.

These are Wallets such as Google Pay or Apple Pay are both payment apps built on top of Web Payments APIs.

Google Pay also provides a JavaScript Wrapper library so that it works on Browsers that support Web Payments, but horseback to a JavaScript solution, where it does not.

Support for payments APIs across Browsers is progressing slowly but steadily.

Today outside of Chrome limited support is available in Safari, Samsung Internet, Edge, Opera and Brave. Mozilla is working on adding support to Firefox as well.

Now I'd like to talk about two new exciting features around Web Payments. First one is Secure Payment Confirmation.

Earlier in this session, I mentioned that there are mainly two players involved in the payment transaction, a merchant and a Payment Handler, but depending on the type of component a Bank or an Issuer may play an important role, considering of card payment, customers usually send their Credit card number along with a Verification code.

It Used to be sufficient to identify our customer as the owner of the card but due to increasing numbers of fraud, there's a demand for stronger authentication. 3D Secure is the most widely deployed solution. Customers are asked to enter their Username and the Password or an OTP to verify their identity after Credit card number submission. While it helps raise a security, it also introduces friction to the customer's payment experience.

3D Secure two introduces risk-based authentication, which allows customers to skip the step whenever possible.

But it's relying on tracking technologies such as Cookies or Fingerprinting that could be used to abuse the user's privacy. This is why the payment industry needs to come up with a consistent low friction and strong authentication flow for Online Payments.

And we are looking into a new authentication mechanism for the web called a Web Authentication, WebAuthn is an API that enables authentication using hardware based public-key cryptography.

With WebAuthn, you can enable strong authentication using a biometric sensor attached to a user's device that complies with the standard called a Fido.

The API is already available across major Browsers. The good news is starting from iOS 14.

Safari will start supporting biometric authentication using touch ID and face ID.

If you want to learn about WebAuthn, Ben will be covering the topic in different session. So don't miss it.

We expect WebAuthn real help making the payment authentication low friction and much stronger than before.

However, it is not immediately suitable to solve the problem because we would what to avoid yet another context switch from a Payment Handler to an Issuer We secure payment confirmation, issuers can delegate their authentication to a Payment Handler.

Let's see how it works.

Let's say you're about to make a payment with a Credit card, using a form.

The Payment Handler needs the customer to authenticate against the card Issuer to prove their identity.

Instead of redirecting the customer to the issuer Website, let's use the Secure Payment Confirmation.

We secure payment confirmation.

A dialogue appears to make sure the customer is about to make payment.

Who is receiving the money? Which card number is used to make payment and the total price of the payment? Once the customer confirms the details, they press the verify button.

These three goes a platform dependent system dialogue to request the customer's biometric authentication. The important difference here is unlike ordinarily WebAuthn, the authentication is performed by the Payment Handler on behalf of the Issuer, Which means the customer could avoid being redirected to the issuer website and do an additional authentication there.

It's a huge UX improvement isn't? Note that in Fido standard, this biometric data is stored locally to the device at registration and used to verify the user and generate a signature on authentication. The biometric data will never leave the device also because of registration is bound to the origin. Fido can protect the customers from fishing. After a successful Cyber site verification of the signature, the customer is finally eligible to prove their identity and complete the payment.

This is how the Secure Payment Confirmation works. We are excited about this new feature and planning to test it with Stripe very soon. And we would like to learn different use cases from various payment methods.

If you are interested in this feature, please join this discussion at the Secure Payment Confirmation Spec Repository. The second new feature I'm excited about is Digital Goods API.

Digital Goods API brings the concept of marketplace especially in-app billing to the Primary Request API, by the way, have you heard about Trusted Web Activities? TWS are a new way to expose web contents in Android apps.

It's already available and being actively used. Unlike Web Views or Chrome Custom Tabs TWA's allow you to display web contents in full screen while getting access to the storage in Chrome.

Showing stress means you can keep the users signing in state or federal information such as Passwords and so on. In other words TWAs enable you to publish your PWA to any stores on the Android ecosystem, such as Google Play Store.

It's a great way for your customers to find your app from a platform specific Marketplace, not just from the web.

However, one important caveat here is that you will still have to comply with the regulations that the marketplace mandates you and well the most important and difficult regulations at marketplaces is that you need to use the marketplace specific in app billing method. When you're selling Digital Goods inside an app. That's where Digital Goods API comes in to make a Digital Goods purchase request.

You specify the item IDs, the user wishes to purchase.

Unlike other payment methods I have talked about earlier. By using the Digital Goods API, you can obtain information about the items you registered to the Developer Console based on the user's locale.

And then you can use the information to invoke the Primary Request API using the Marketplace Specific Payment Method in your TWA.

For example, Google Play Billing.

We will start experimenting with this new API soon on Chrome on Android and Chrome iOS for apps in the Google Play Store.

If you're a Developer working on a PWA or a Mobile Web Game, please consider making it available as a TWA and publish it to the Google Play Store. Your customers will be able to purchase Digital Goods using in app billing if they find that your TWA on Google Play Store, but they can also purchase the same item using any other ways of payment, such as Google Pay. If they instal your PWA on the web.

In this video, we have looked back at what is Web Payments? How it works, Secure Payment Confirmation, and the Digital Goods API.

If you're interested in building a Web premise-based payment app, we have recently published a new set of documents@web.dev/payments Thank you for watching.

(whooshing sound)