Blog article
See all stories »

W3C Web Payment Standardization As A Potential 3D Secure Killer?

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:

  1. Acquirer Domain (represented with 3D Secure Merchant Plug-In, which is integrated with online merchant site)
  2. Interoperability Domain (represented with 3D Secure Directory Server, which is operated by responsible payment scheme)
  3. Issuer Domain (represented with 3D Secure Access Control Server, which could be operated by the card issuer, or most frequently was outsourced to a 3rd party operator)

The simplest possible description of the 3D Secure flow is:

  1. Online merchant site collects the payment card info and passes it to the 3D Secure Merchant Plug-In, which forwards the card number to the payment network
  2. Payment network verifies if the card number is enrolled in 3D Secure, by querying its 3D Secure Directory Server.
  3. If the card is enrolled in 3D Secure, then payment network responds to the 3D Secure Merchant Plug-In with the URL, which is pointing to the issuer’s 3D Secure Access Control Server
  4. 3D Secure Merchant Plug-In displays an iframe (or pop-ups new browser window) and redirects consumer session to card issuer’s 3D Secure Access Control Server URL
  5. Issuer’s 3D Secure Access Control Server challenges consumer to authenticate themselves by entering password into the iframe / pop-up form.
  6. If the customer authenticated itself successfully, the issuer’s 3D Access Control Server responds to 3D Secure Merchant Plug-In with an “authorization code”
  7. 3D Secure Merchant Plug-In passes the “authorization code” to the online merchant site
  8. Online merchant site includes “authorization code” in the standard authorization request message, which is submitted via online processor and payment network to the card issuer, for final authorization
  9. Card issuer verifies the “authorization code”, as part of the standard payment request authorization processing.

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:

  • Was not the domain where they were shopping at,
  • Was not the domain of the bank that issued their card
  • Was not the domain of their card’s payment network (i.e.,, or

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.



Comments: (8)

Paul Love
Paul Love - Konsentus - Nottingham 25 July, 2017, 11:381 like 1 like

Great article - it does look like there is a compelling case for harmonisation between W3C, EMVCo 3DS, and the upcoming Payment authentication processes being defined as part of the Open Banking APIs.

Milos Dunjic
Milos Dunjic - TD Bank Group - Toronto 25 July, 2017, 12:22Be the first to give this comment the thumbs up 0 likes

Agreed ... thanks for taking time to read and discuss Paul

Nick Collin
Nick Collin - Collin Consulting Ltd - London 26 July, 2017, 12:12Be the first to give this comment the thumbs up 0 likes

Yes, great article and yes, there is clearly a need for harmonization.  I was not aware of the W3C payments activity until I googled it but now I'm somewhat concerned about industry participation on the working groups.  Although Amex is widely represented, MasterCard is less so, and Visa appears to be completely absent!  Is this an issue?  As someone wedded to the EMV infrastructure and deeply involved over the years in EMV 3DS, I believe, rightly or wrongly, that it should be "embedded" or at least "seriously taken account of" rather than "killed"!

Milos Dunjic
Milos Dunjic - TD Bank Group - Toronto 26 July, 2017, 12:38Be the first to give this comment the thumbs up 0 likes

Thanks Nick. Yes it is concerning that traditional payment networks are not the main force behind this standardization initiative. PayPal is also somewhat quiet about it. IMO, main winners, if this becomes ubiquitous in future browsers will be merchants and FIs like banks and credit unions.

Sadra Boutorabi
Sadra Boutorabi - GPayments - Sydney 08 August, 2017, 10:201 like 1 like

Thanks for sharing Milos.

Just posted a blog on why I think this won't be the 3DS killer!

I would love to hear your thoughts on this.

Nick Collin
Nick Collin - Collin Consulting Ltd - London 08 August, 2017, 12:14Be the first to give this comment the thumbs up 0 likes

I think you're probably right Sadra.  It always takes much longer for the payments industry to change than anyone ever expects.  The EMV chip standard was introduced in the early 1990's and is only now starting to be adopted in the US!  Hopefully 3DS will evolve gradually in the direction of whatever is good about the W3C initiative.

Incidentally, I've noticed that I'm now rarely asked to complete 3DS authentication even on sites which support it.  Presumably my bank has implemented some kind of adaptive neural network fraud detection software and decided I'm relatively low risk!

Milos Dunjic
Milos Dunjic - TD Bank Group - Toronto 26 August, 2017, 13:06Be the first to give this comment the thumbs up 0 likes

Hi Sadra thanks for your response and your own article as a direct response to this one. I have read your arguments and understand your reasoning. I may need to clarify the basic premise of my theory ... I agree that W3C Web Payment Standardization won't kill 3DS immediatelly and I generally agree with most of observations in your counter-article (not all though).

However IMO, over time, as every single 'obstacle to wide adoption of W3C Web Payment Standardization' that you listed is eliminated, 3DS will most likely become obsolete ... simply because there would be no '3 domains' anymore ... we will simply have Merchant Domain and Issuer Domain only, mediated directly by the compliant browser. There will be no need for Merchant Plug-Ins, 3DS Directories, etc, etc.

Once the Issuer W3C compliant Payment App is triggered (I see FIs becoming main providers of these), the Issuer's W3C compliant Payment App can use any authentication method to securely and reliably authenticate the customer and guarantee payment.

How long will it take for W3C Web Payment Standard to become widespread? I beilieve 5 years from now, the funny "Nascar of pay-with buttons" on online merchant sites shall be replaced with only 1 PAY button. But fully agree with you - FIs may be slow (we are catching up quickly though), politics of current players play a big role, etc. 

Hope this clarifies my thinking.

A Finextra member
A Finextra member 18 October, 2017, 08:08Be the first to give this comment the thumbs up 0 likes

Nick - it will probably be the CA RIsk analytics product implemented by HSBC/First Direct and RBS - i commented over on the other Finextra post on this subject... Its an intelligent adaptation of the 3DS protocol - pushing it back to a backstop role. 

Milos Dunjic

Milos Dunjic

AVP, Payments Innovation Technology Solutions

TD Bank Group

Member since

17 Jan 2016



Blog posts




This post is from a series of posts in the group:

Innovation in Financial Services

A discussion of trends in innovation management within financial institutions, and the key processes, technology and cultural shifts driving innovation.

See all

Now hiring