Community
The 3D Secure 1.0 framework was originally introduced to address lack of consumer authentication in legacy online environments, mainly in cases where online merchant and consumer were not engaged in face to face transaction, i.e. when there was clear lack of confidence that consumer who is paying, was the legitimate owner of the payment card used for payment. “3D” means “3 Domain”, where the 3 domains are:
The simplest possible description of the 3D Secure flow is:
In my personal opinion, the biggest issue consumers faced during 3D Secure flow was that it looked in most cases like a clear case of a phishing attempt. Due to the fact that most of the card issuers had outsourced 3D Secure Access Control Server operation to a 3rd party (having their own domain name), the consumers were redirected to a URL that:
Consumers have been constantly warned that if anything like this happens, they should immediately abandon their web browser session (by simply closing it down) and not enter any personal information into the form … basically to ‘run away’. Vast majority of the consumers reacted, very justifiably, exactly like that. For some odd reason, 3D Secure was mainly criticized for additional friction in the payment flow, with the payments industry blaming significant checkout flow abandonments on couple of extra steps (those steps were in my view very justified for added security), instead on clumsy (and scary) security ‘phishing like’ implementation.
In March 2017, EMVCo released the ‘next generation of 3D Secure specification’ simply labeled as “2.0”. It is an overhaul of the original 3D Secure model, aimed at customer authentication flow optimization and reducing friction during online checkout process. The new framework introduces ‘frictionless flow’, where consumers will not be prompted to enter password, if the 3D Secure Access Control Server determines that it is not necessary. Beside the frictionless flow there is also “challenge flow”, which resembles, more or less, the original 3D Secure protocol. Hope is that this optimization may reduce likelihood of online checkout flow abandonment. The EMVCo spec also introduces concept of HTML UI Templates as an attempt to address the original ‘phishing’ issue, and avoid scaring and confusing consumers. Since HTML UI Templates mainly rely on incorporating consistent card issuer and payment network branding elements (i.e. logos) in authentication HTML pages, they may improve confidence and reduce the online checkout abandonment rates. Time will tell.
What About Authentication In W3C Web Payments Ecosystem?
The upcoming W3C Web Payment standard and the compliant web browsers, will provide fully standardized and very efficient online payment flow. The consumers will be able to use W3C compliant Payment Apps, provided by their favorite financial institutions (i.e. banks or credit unions, which are also the issuers of their payment cards). In most cases those FIs will likely just extend capabilities of their existing mobile / online banking apps to support the W3C Web Payments and enable them as the most natural handlers of W3C Payment Requests. In other words, the compliant browsers will become direct mediators between the merchants initiating payment requests and consumers using their card issuer’s W3C compliant Payment App to fulfill them.
To me it also smells like a possible beginning of an end of the ‘digital wallet’ era as we know it. In the efficient and direct W3C Web Payments flow, there may be no obvious need for digital wallets anymore. The consumers could start directly using the W3C Payment App from the bank that has issued their payment card. What if they have payment cards issued by several different banks? Again, they would likely end up having each of those bank’s W3C Payment Apps enabled as handlers of W3C Payment Requests and will be prompted in a very standardized way (by the compliant browser) to choose which bank’s W3C Payment App they want to use for each particular payment. Very cool indeed. Therefore, the W3C Web Payment compliant browser becomes a replacement for today’s ‘digital wallet’ … a killer app.
The W3C Web Payment framework also intentionally didn’t address consumer authentication. It leaves it to each of the W3C Payment Apps to authenticate the consumer. Banks providing payment apps will likely utilize their existing mobile / online banking authentication methods. This is clearly very convenient and beneficial for consumers, as it utilizes already familiar UX, doesn’t look like ‘phishing attempt’ and completely eliminates yet another set of authentication credentials to remember, protect and manage.
In such W3C Web Payments world - would we really need EMVCo 3D Secure? Would we even need ‘digital wallets’ that are in place today? These are relevant and very interesting questions in my opinion. I will leave it up to you to decide. Do not hesitate to let me know what you think.
This content is provided by an external author without editing by Finextra. It expresses the views and opinions of the author.
Hassan Zebdeh Financial Crime Advisor at Eastnets
08 October
Jelle Van Schaick Head of Marketing at Intergiro
07 October
Kuldeep Shrimali Consulting Partner at Tata Consultancy Services
Nikunj Gundaniya Product manager at Digipay.guru
Welcome to Finextra. We use cookies to help us to deliver our services. You may change your preferences at our Cookie Centre.
Please read our Privacy Policy.