The final EMVCo defined standard for payments is used in
e‑commerce transactions and is known as Three‑Domain,
or 3‑D, Secure.
It aims to bring the same level of security to an e‑commerce transaction that
EMV chip technology brought to face‑to‑face transactions,
that the issuer can be really sure it is their customer that's making the
transaction and not a criminal pretending to be the customer.
And so the issuer makes sure that all the authentication of the
cardholder occurs in the issuer's environment.
This 3DS process is called different things by each card brand or card scheme.
At the time of making this course, Mastercard's is called IdentityCheck,
Visa's, Visa Secure, and Amex's, SafeKey.
I say at the time of making the course because these names are
things that can change quite frequently.
Let's think about Ann's transaction to buy some of
Wired Brain's Coffee to use at home.
She uses the Wired Brain Coffee website,
adds some bags of coffee beans to her basket,
hits the Checkout, and then enters her card data.
So what happens is that the transaction starts as
normal on the merchant's website.
The customer starts to enter their cardholder data.
However, once they press Submit,
rather than an authorization message being sent
directly from the merchant to the issuer,
the cardholder needs to be authenticated first.
So there's a bunch of data collected from the consumer's browser or,
if they're using an app, from the app.
And that bunch of data is sent to the acquirer and bundled up into an
authentication message that the acquirer sends to the issuer.
Now that goes via something called a directory server that's typically
sitting in the card scheme or card brand's network.
And then that routes it to an Access Control Server,
or ACS, in the issuer's domain.
The ACS looks at the information that it has been sent,
and it works out if it's got a reasonable degree of
confidence that it really is Ann.
If it is, then the transaction follows what's called a frictionless flow.
Then authorization will happen as normal.
However,
if the ACS isn't sure that it's Ann then the ACS wants to initiate
a direct conversation between Ann and itself,
and this is known as the challenge flow.
And practically,
this is going to happen in the browser or within an app that Ann's using.
Remember,
the point here is the issuer wants to make sure
that it really is the cardholder, Ann,
making the transaction and not a criminal pretending to be Ann.
So the issuer needs to get some information from
Ann that only Ann could provide.
At a simple level,
the issuer could ask the cardholder to enter a password that they've
memorized and that both the issuer and the cardholder know.
In fact, this is how the first version of 3DS used to work.
But now more commonly, the issuer wants to rely on something dynamic,
something that changes,
rather than a static password because static
passwords could be learned by criminals.
So the issuer could text a one‑time passcode to the cardholder's mobile phone.
Or the cardholder could be asked to generate a one‑time passcode
from an application they have on their device.
Quite commonly now,
the issuer will take advantage of the cardholder having the
issuer's app installed on their phone,
and they will send a push notification to the app that the cardholder
has to acknowledge for the transaction to take place.
And that push notification to devices is really the
direction of travel for 3DS authentication.
The cardholder then enters that one‑time passcode or passphrase or password,
or the issuer receives acknowledgement by the bank's own app that the cardholder
has authenticated themselves and approved the transaction.
So the issue is now satisfied that it is their
cardholder making the transaction.
And then the ACS generates a cryptogram,
and the cardholder is returned back to the checkout process for
the authorization to continue in the normal way.
However, as part of the authorization message,
the cryptogram is passed back to the issuer,
proving that the 3‑D Secure communication and authentication occurred.
So far,
we've established that in order of preference criminals would most like to
have a real physical card and the pin associated with it.
And if they can't have pins then just fake physical cards.
If they can't have those then they want to steal the data
that could get a transaction authorized,
which is magnetic stripe data on its own or data from an e‑commerce transaction.
So the question is how do we stop them?
And that's what we're going to explore in the next module.