One of the hardest parts of the payments universe is increasing transaction speed and reducing friction for the consumer.
Let’s be realistic, we have gone from paying with cash to using a mobile phone in a very short time, but the last five years have brought significant change.
In the United States, we approached the EMV migration very patiently, and that patience was exercised, mainly, for making the consumer conscious of the changes they would face to pay in a more secure manner.
But when consumers started to notice the changes, the main change was the transaction time.
During the last 6+ years, we have heard of cardholders saying: “Those chip transactions take forever to finalize; I preferred the old times, when I just had to swipe the card and it was done!”
The truth is that mag stripe transactions were never immediate; consumers still had to sign or enter a PIN (for debit transactions), but the perception of never leaving the card out of their hands makes people think it was immediate.
It looks like, although there is still some ‘resistance’ to EMV transactions, people are getting used to the ‘insert’ behavior, and we do not hear many complaints anymore.
Two very important entities in payments have taken steps to satisfy that ‘Frictionless’ need we all seem to have…
EMV Co. SRC
Secure Remote Commerce (SRC) is a set of documents and specifications developed by EMV Co (https://www.emvco.com/emv-technologies/src/) in attempt to evolve remote commerce with card acceptance to become more secure and interoperable. Its intention, in addition to EMV 3DS, is to guarantee safe e-commerce transactions for all the participants, from Consumers to Merchants and Issuers.
The SRC specification, released in November 2017, defines interfaces to enable secure exchanges of data between all participating entities, methods to help protect transactions with dynamic data to enable consistent integration of new technologies and facilitate the delivery of a consistent user experience.
In Figure 1 you can see the generic flow of the SRC sequence of functions.
More information about the whole process and functions can be provided on demand.
Figure 1. SRC General flow diagram[1]
W3C Payment Request API
The World Wide Web Consortium (W3C) is an international community which has members such as Amazon, AT&T, Bank of America, Facebook, Library of Congress, Microsoft, Netflix and others, along with a full-time staff that works together to develop web standards (web design and applications, web of devices, web architecture, XML technology, web of services, browsing and authoring tools). Those standards follow a complex process designed to promote consensus, fairness, public accountability and quality; and, at the end of that process, the W3C publishes ‘Recommendations’, which are considered ‘Web Standards’.
The W3C started working on something called ‘Payment Request API’ and W3C initially stated that it was thought to be “an improvement to autofill”. Browsers (desktop and mobile) were storing information from users (addresses and other data), and the W3C wanted to improve that experience, especially for mobile users, in which the experience of entering all the information needed for e-commerce transactions is more difficult.
The first view of the Payment Request API was something called ‘Basic Card’, which was a form that could capture card details from the user. But Basic Card was never intended to be the only payment method. The W3C’s vision was to empower other payment handlers to be available to respond to payment requests.
After some time, the Payment Request API became more and more complex and complete, and now it is being used by almost all existing desktop web browsers and popular mobile browsers, including Google Pay and Apple Pay.
But, what does the API do? Well, that is a good question… According to the W3C website (https://www.w3.org/TR/payment-request/#goals), the goals and scope of the Payment Request API are:
- Allow the user agent to act as intermediary between a merchant, user, and a payment method provider (a card, Google Pay or Apple Pay, etc.).
- Enable user agents to streamline the user’s payment experience by considering user preferences, merchant information, security considerations, among other factors.
- Standardize the communication flow between a merchant, user agent and payment method provider.
- Enable a payment method provider to bring more secure payment transactions to the web.
In Figure 2, the general overview of how the Payment Request API interacts with the other participants, is shown:
Figure 2: Payment Request API Interaction[2]
SRC + Payment Request API = Frictionless Transactions
Finally! In 2018, EMV Co. and the W3C got together and started working to understand and help ensure the compatibility between SRC and the Payment Request ecosystem.
Due to the exponential expansion of remote commerce transaction quantities, many participants in the market are concerned about the most important issues affecting the user experience:
- The complexity of the whole ecosystem
- The friction occurring at check-out
The intent of EMV Co. and W3C working together is to reduce the impact of those main issues and improve the user experience by providing access to a card’s digital information and facilitating the check-out experience (making it Frictionless!).
The technical details deserve much more than this article can provide to explain the functionality, but there is something from the EMV Co website that bears repeating:
The synergies: The W3C Payment Request API within a web browser could be used to access the functionality of a role within the SRC ecosystem. This could reduce the need for repetitive (lots of friction) manual cardholder data entry, potentially causing some e-commerce transactions abandonment.
The differences: W3C work addresses a wide range of payment methods but focused primarily on the web transactions. EMV Co. covers the card-based payments across different devices and environments, meaning its coverage is broader.[3]
The W3C Payment Request API and EMV Co. SRC should not be viewed as competitors trying to solve the same challenge. Merchants do not have to choose between one or the other, because both can (or ‘should’) be combined to contribute towards consistent, easy and MORE FRICTIONLESS web-based payments.
In Figure 3[4] you can see the first draft flow diagram (still not defined as recommendations) which shows:
- The browser may be a payment handler that implements several SRC functions. It might have access to all the cards information stored by the user in the SRC environment.
- There might be interactions with many SRC systems.
- How a user can enroll a card in the SRC system through a payment handler. A card might be enrolled through other channels or by other roles.
Figure 3: Integration of SRC and Payment Request – Enrollment
In Figure 4[5] the EMV Co. SRC and the W3C Payment Request API are integrated to perform a transaction.
Figure 4: Integration of SRC and Payment Request – Transaction
Conclusion?
As stated previously, the work is still in progress, but the advance so far looks promising.
At the end of the day, providing less friction for
e-commerce users might increase that special feeling of efficiency, enabling us
to live in a much more frictionless world!
If you are interested on knowing more about
Digital Payments, EMV Co. SRC and W3C Payment Request API, do not hesitate and
contact Victor Madera ([email protected]).
[1] (https://www.emvco.com/emv-technologies/src/)
[2] (https://www.w3.org/TR/payment-request/#goals),
[3] (https://www.emvco.com/wp-content/uploads/documents/EMV%C2%AE-Secure-Remote-Commerce-and-W3C-Web-Payment-Specifications.pdf)
[4] (http://www.plantuml.com/plantuml/proxy?fmt=svg&src=https://www.w3.org/2018/12/src-prapi/src-enrollment.pml)
[5] (http://www.plantuml.com/plantuml/proxy?fmt=svg&src=https://www.w3.org/2018/12/src-prapi/src-pr3.pml)
