Let’s suppose that Jane Doe (cardholder) found a new pair of Jeans at H&M (merchant). Bank X (issuer) has issued a card for her, which she’s using now to initiate an online payment to get that new pair of jeans.
On the merchant’s website, she’s now prompted to enter her card number (and some other information). In order to increase the security of Jane’s online payments, the EU’s PSD2 regulation requires strong customer authentication (SCA) for the majority of online transactions (there are some exemptions). For many merchants, opting for the 3DS protocol is a convenient and standardized way to meet SCA requirements.
What’s the 3DS protocol about?
3D Secure or 3DS is an authentication protocol managed by EMVCo designed for authenticating a cardholder during an online payment transaction or an identity verification (enrollment). Services based on this protocol are branded under different names “Verified by Visa” (Visa), “SecureCode” (Mastercard)…etc.
3DS involves three domains:
- Acquirer domain (e.g. H&M) — Transactions are initiated from the acquirer domain
- Interoperability domain (e.g. Visa’s Directory Server)— It links the acquirer to the issuer
- Issuer domain (e.g. the cardholder Jane Doe, and the bank that issued her card) — The authentication of a 3DS transaction happens here
The 2.1.0 and 2.2.0 are the two active versions of the protocol.
The flow of a 3DS payment transaction
Merchants, such as H&M, won’t be familiar with the bank that issued the buyer’s card. But, your card scheme, whether it’s Visa, Mastercard, Bancontact, or any other card scheme out there, is providing a Directory Server (DS).
The merchant, in this case, H&M, is connected to one or more directory servers. Based on the PAN (Primary Account Number) of your card, the DS will know which Access Control Server (ACS) to call.
What’s the ACS about?
The ACS is on the issuer domain, but most banks would usually outsource the ACS to a third party. Its main functions include:
- Verifying whether a card number is eligible for 3-D Secure authentication
- Verifying whether a Consumer Device type is eligible for 3-D Secure authentication
- Authenticating the Cardholder or confirming the account information
Based on some given inputs (cardholder’s location, transaction amount…etc.), the ACS will decide whether a cardholder’s authentication is required for this transaction or not. If not, the transaction is called “a frictionless flow”, the ACS replies to the merchant via the DS with an authentication value, which includes the information he sends to the acquirer. The authorization request starts from this point and on (this part is beyond the scope of this article).
If the transaction requires authentication, then a “challenge flow” is engaged.
Steps 4 (Challenge Request Message — CReq) and 5 (Challenge Response Message — CRes) in the diagram happen during an authentication flow. The cardholder is challenged, how are they challenged? The ACS sends the authentication user interface to the cardholder browser — A page on their browser is displayed, where they’re prompted, for example, to scan a QR Code, the data entered by the cardholder is checked by the ACS. The CRes message indicates the result of cardholder authentication.
Step 6 and 7 include the pair Results Request/Response (RReq/RRes) messages. The 3DS Server receives an RReq message and in response, returns an RRes message to the DS, which then routes the message to the ACS.
A 3DS processing ends here — Next step is the payment authorization, which will not be covered in this article. A “payment successful” message is shown on the screen of the cardholder, Jane Doe, who will receive that pair of jeans in a few days.
Is the 3D Secure protocol really secure?
The new protocol version is improving online transaction security, but there is still room for improvement. Analysis of the protocol by academia has shown it has many issues. You can read more about it in this article, which explored the protocol through a reverse engineering approach.
Sources:
EMV® 3-D Secure Protocol and Core Functions Specification
W3C Web Payments and EMV 3-D Secure
Designed to Be Broken: A Reverse Engineering Study of the 3D Secure 2.0 Payment Protocol
