On today’s episode, Ryan McEndarfer going to be sitting down with Tim Sloane from Mercator Advisory Group who recently authored a new report talking about securing e-commerce. And in that report, he outlines a new API created by the W3C that has an interesting opportunity, particularly for merchants.
McEndarfer:
Now, Tim, you recently covered the new W3C API in a recent report titled Securing E-Commerce: Competing Technology Crowds the Market, and I was hoping that you could give us a little bit more of an overview about this new API.
Tim Sloane:
Ah, yeah, sure. So it’s actually called the WC3 Payment Request API. It’s been added to all of the major browsers at some level of conformance to the standard, which continues to evolve. But the concept is that it can be provisioned with any credential, independent of the payment network that credential is going to be presented to. And that credential will appear magically, when the web browser is on an e- commerce merchant site that accepts that credential. So it actually represents an entirely new kind of payment capability, and an easy way for new payment networks to be embedded into a browser.
McEndarfer:
Right. Now, you pointed out that the API is designed to be flexible enough to allow any native app or web app to become a payment method. So what makes this ability so disruptive to the market?
Sloane:
So if you think about how long it takes to roll out a new payment type, it’s usually in the order of decades. However, with this solution, it’s possible for a new payment type to be introduced into the browser very quickly. So if you take a look at it as an example at what happened when Apple indicated that they were going to use the W3C Payment Request API to integrate to the Interledger Protocol, the crypto market kind of went crazy, presuming that that meant that Apple was going to support bitcoin and other crypto coins within the browser, which absolutely could have been, except Apple didn’t go all the way. They integrated Interledger, but nobody has integrated Interledger into bitcoin. That could be done by somebody like Coinbase, or somebody else, to introduce a bitcoin-based payment instrument, as long as merchants adopt it and accept that new token.
So because it’s embedded in every browser, because it identifies a method for provisioning that browser with a credential from anyone, as long as the merchants want to accept whatever that credential is, and are enabled to do that, it will help new payment types hit the market much faster. I would use as an example a merchant that currently has cards on file could be introducing their own credentials into this environment that show up whenever the consumer goes to their website. That credential can be passed, [and] the merchant can then either use a credit card, or perhaps they use this credential to instead utilize the ACH, in order to avoid the traditional networks, and to avoid traditional interchange and lower their cost of acceptance.
McEndarfer:
Now, this API is going to eliminate, you know, the manual entry of payment information because the information will be secured by the browser. So could you walk me through why this is an additional benefit and what security it adds to the payment process?
Sloane:
So instead of the end user being required to enter their card data, what this approach does is it enables the token to be presented across the network, so that the merchant can maintain all of that confidential information in an encrypted format and not expose it to the internet, which should significantly lower the security risk associated with passing usernames, addresses and credentials across even a secure internet connection.
McEndarfer:
So it would appear that the W3C Payment Request API has a few players that are supporters of it, such as MasterCard, Visa, and American Express, so what are they looking to gain with supporting this new API?
Sloane
So the networks are competing in many ways with their own e-commerce solutions. That said, they certainly wouldn’t want a new payment mechanism to not be capable of supporting their networks. So step one for them is to participate to make sure that they can provision the browsers with a token, so that the Visa, MasterCard, Amex, etc. brands will show up within the wallet when the merchant accepts that network.
The other likely effort is to blunt what this API can do. And I don’t mean that in a negative way; I used to participate in a number of standard organizations, and every company that participates goes in looking for a way to leverage their position in the marketplace through that standard. And it’s likely that the traditional payment networks are also going in there jockeying to figure out how they might make their brand appear higher up in the infrastructure, or have some unique advantage within this W3C Payment Request API.
McEndarfer:
Excellent. So now before we wrap things up, do you have any final thoughts?
Sloane:
Well, it’s going to be fascinating to see how quickly the W3C is able to move this standard forward, expand its capabilities, and then get it deployed into the major browsers. You know, you mentioned that the payment networks are all participating in the W3C standardization effort, but more importantly, I think, all of the traditional web browser companies are: Microsoft, Google, [and] Apple. All of the browsers are participating and have a real goal of establishing the new payment mechanism in an effort to kind of disrupt the market. So it’ll be interesting to see whether merchants, who are probably best positioned to leverage this, decide to adopt it.
McEndarfer:
Excellent. Well, thank you, Tim, for taking the time today for speaking to us about the W3C Payment Request API, and we hope to have you back on the podcast real soon.
Sloane:
Thanks for having me and have a great day.