Native apps are boring and the web is not dead, said Sir Tim Berners-Lee in November of 2014, on the 25th anniversary of the commercial web. He’s entitled to that opinion: He’s the one, after all, who invented the World Wide Web.
His point then, and as it remains now, was that native apps — “walled gardens” as he called them — are limiting, almost by design. Web apps, he posited then, create richer user experiences by connecting users with more content and inspiring more collaboration.
Berners-Lee is also the director of the World Wide Web Consortium (W3C), an international body aimed at creating the standards and technologies that make the web dynamic, interesting and the foundation for those connected experiences, which span many channels and billions of connected endpoints today. Payments and commerce are among the most powerful tools to enrich those experiences for all the relevant stakeholders.
Getting past the app versus web debate when it comes to payments is probably a bit too stark, Ian Jacobs, payments leader for W3C, told PYMNTS. What isn’t is the reality that, as all of those different platforms “converge on one another,” there is a unique opportunity to let the browser do more of the heavy lifting when it comes to payments enabling a consumer’s online commerce experience.
That’s the idea behind the group’s Payment Request API, now live and undergoing real-world testing: to take consumer data involved in the online checkout experience and pass it to the merchant via the browser. More than the standard form fill, a consumer might opt to store their payment credentials and billing/shipping information in a particular browser, through which they are prompted at checkout to use those stored credentials. The API can ease the secure exchange of the data between the browser and an eCommerce site, saving the consumer from using their thumbs to fill out a frustrating checkout form on the merchant’s site, eliminating a source of friction and a possible motive to abandon the purchase.
The returns are promising so far. The ongoing testing of the Payment Request API has shown “mixed but mostly optimistic messages” from J.Crew, Shopify, Stripe and other merchants, as well as eCommerce and payment service providers, Jacobs told PYMNTS.
“Checkout times are dropping,” and by as much as 75 percent, he said, adding that there is still more consumer education and merchant development necessary to scale these efforts.
Payment Request API Update
Jacobs, who said his job is to “better payments by adding new capabilities to the web,” provided PYMNTS with an update of that Payment Request API work via the international standards group.
“We are still working out the user experience and kinks,” he said, “but we are starting to get traction in terms of deployments.”
In fact, all the major browsers, save Firefox, are currently shipping support for the Payment Request API. “Firefox is catching up a little bit” and will join that club this fall, Jacobs said.
“We are on the cusp of merchant adoption,” he said. “Now, we are pushing [the API] to the next level of visibility and development.”
The idea, he said, is to give consumers the payment options they want, while also allowing merchants to turn on payment methods they want to support. The browser could show the shopper the last payment method they used or one the merchant might like to promote that drives more volume their way.
The Payment Request API And Secure Remote Commerce
Earlier this year, Mastercard and Visa announced their support of EMVCo’s Secure Remote Commerce (SRC) framework, which was introduced in November of 2017.
SRC is an effort by the card brands to bring the EMVCo standard to the web and enable the tokenization of payment credentials, by what Jacobs and the W3C call “payment handlers.” The idea is that SRC will further a standard for secure transacting on the web via the mobile browser. The SRC framework calls for the creation of an encrypted token that is passed to the merchant at the time of a transaction, and a more consistent, interoperable and streamlined way of doing business on the web via the browser.
Public SRC specifications have yet to emerge, so the user experience is, as of yet, a work in process.
“We have yet to fully understand the relationship between SRC and Payment Request API,” Jacobs said. He pointed out that the Payment Request API allows merchants the flexibility to show the buttons they want, including a single-buy button, with a drop-down tray that shows stored and encrypted user credentials available for a consumer to select. There’s also the possibility, he continued, that a more curated set of checkout “buttons” will appear at checkout, based on the merchant and past consumer preferences.
Either way, Jacobs said that W3C is working to accommodate merchant requirements to transition to this new, browser-based, tokenized payment protocol without losing the utility they value, including links to existing loyalty and customer relationship management (CRM) systems.
“We are working very closely with the card brands, trying to bring tokenization” further into the web, Jacobs added. “I’m optimistic [that] we are trying to achieve the same goals.”
(In related news, Strengthening Data Security Through Tokenization is the subject of an upcoming PYMNTS digital discussion on Sept. 13.)
The Online, Browser-Based Payments Future
W3C anticipates a future where more connections will need to be made between payments and both the merchant and consumer sides, as biometric authentication, dynamically produced hard-number generation and other technologies move further into the mainstream, Jacobs said. The Consortium is also exploring ways to work better with 3DS (a messaging protocol that allows consumers to authenticate themselves with their card issuer when making card-not-present eCommerce purchases), and with mobile wallets and other online payment technologies.
When it comes to the future of buy buttons, Jacobs said, there’s “conceptually” room for both with the Payment Request API, and for a very good reason. Merchants will be hard-pressed to push buttons that drive sales to the background. That, too, remains a work in process — but progress it is. With more testing comes more data and learning for merchants, consumers and the payment brands that support both.
The only real loser? Checkout friction.
We’re always on the lookout for opportunities to partner with innovators and disruptors.
Learn More