Hello, welcome to the Monday, October 9th, 2017 edition of the Sands and the Storm Center's

Stormcast. My name is Johannes Ulrich, and I am recording from Singapore.

With me in Singapore for the next two weeks, the podcast may be published sometimes at a little bit

odd times of day, but I still should have a podcast once a day. First, I want to start

out with a relatively new web browser API, and that's the Payment Handler API. The last draft

was published October 4th, so late last week, and I think it's time to look at that API a little bit more

closely. The basic idea of this API is to have a uniform way to deal with payments and with that

also with stored credit card information and other payment information that's stored in the browser.

Now, overall, this payment API actually does a couple of things quite nice and more secure

than it's done in a traditional web application. In a traditional web application, the user enters their credit card

information, and that information is sent to the merchant. Of course, we have learned over the last

years that this is very problematic, given that you're sending the same data, the same credit

card number, to multiple merchants, if one

of these merchants gets compromised, then of course you have a problem that the

credit card has to be replaced. Of course, the number one reason why a

merchant would implement something like a payment handler API is to make it

easier and faster to checkout.

There are a lot of orders being lost or not being placed because the user can't find a credit

card number or can't enter it.

So as a result, we want to store it in the browser.

But while this may be a little bit problematic from a security point of view, what this payment handler API does right is that it no longer sends the payment card information to the merchant.

Instead, the payment card information is only sent to the processor.

...