A Great Idea, But How Quickly Can the W3C Payment Request API Be Adopted?

Implications and Potential Solutions Regarding the Digital Disruption of Financial Institutions - PaymentsJournal

Peer-to-peer payment concept with map and world connection , Businessmen holding smartphones. Fintech concept.

Standards can drive rapid adoption, as seen with HTML, SMTP, and Java, to name just three. Now the W3C has released a new Payment Request API standard that is likely to be quickly embraced by suppliers of browsers, mobile devices, and apps. The problem however is this: Will the standard be deployed on every device regardless its ability to secure the payment credential or limited to only the devices that can secure the credential (in hardware or via tokenization in the cloud)? The answer will have a major impact on availability and the adoption curve:

“All major browser makers are now implementing Payment Request API. The Web Payments Working Group encourages merchants, Web developers, and users to experiment with these early implementations and provide feedback to the group. In parallel, the Working Group will be expanding its test suite for the API to help ensure browser interoperability.

Improved User Experience

Making purchases on the web, particularly on mobile, can be a frustrating experience. Every web site has its own flow, and most require users to manually type in the same addresses, contact information, and payment credentials again and again. This can lead to shopping cart abandonment and lost customer loyalty. Likewise, users may abandon checkout if their preferred payment methods are unavailable, but it can be difficult and time-consuming for developers to create and maintain checkout pages that support multiple payment methods.

The Payment Request API (and supporting specifications) enable merchants to create streamlined checkout pages where people reuse previously stored information, saving time and effort and reducing error.

With these technologies, users no longer complete Web forms to provide payment credentials, shipping information, and contact information. Instead, the user registers support for different payment methods —such as card payments, proprietary native mobile payments, bitcoin or other distributed ledgers, or credit transfers— with the browser or other user agent. During checkout, the browser determines which of the user’s payment methods match those accepted by the merchant. The browser displays just the matches, which simplifies selection of the user’s preferred payment application and makes the experience consistent across the Web. The user then chooses a payment method, after which the merchant receives relevant information through the standard API in order to complete the transaction.”

The W3C believes that this API will increase security:

“Payment Request API is expected to lower the cost of creating and maintaining a checkout page and increase payment security. The standard will make it easier to bring more secure payment methods (e.g., tokenized card payments) to the Web. The standard also means that merchants or their service providers can achieve a streamlined user experience without having to store customer payment credentials, potentially reducing their liability.”

It would appear to us that the time to market for solutions will depend on the level of security delivered. Regardless of where the implementation stores the credential, in the browser, in a proprietary wallet, or in the network’s own digital products such as Visa Check Out and MasterPass, the implementations will need to pass network certification testing. It seems logical that the duration of such testing might be dependent in some ways on who owns the environment that controls the credentials.

Overview by Tim Sloane, VP, Payments Innovation at Mercator Advisory Group

Read the full story here

Exit mobile version