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. visa.com, mastercard.com, americanexpress.com or discover.com)

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.